One question I still haven't found answer to: what's with the name? What does it mean / why is it the way it is?

Should it be read as CJ DNS, i.e. something to do with DNS? Or CJD (author's initials) NS (??? again, name server?)? C (?) J (JavaScript/Node) DNS?

Related, what the hell it is, actually? You say in other comment that it's a mesh network, they say it's a network, but I see a program to install. How a program is a network? What does it do?

Tor is a network, and yet you have to install a program to connect to it. You can think of the cjdns program like a driver that allows you to connect to a cjdns network.

To answer your question on what it does : cjdns is a routing protocol that intends to replace the current IP protocol. Like the standard IP protocol, it needs a way to communicate with another node to function (the default gateway). From there, you can communicate with the rest of the network. Your packets will go to the default gateway, who will then redirect it to the "closest node" recursively, until it reaches its destination.

You can setup cjdns over the current internet (essentially making cjdns an "overlay network" like tor) using UDP, or through an ethernet link.[1]

CJDNS indeed works in a mesh : anyone can route other people's traffic, somewhat similarely to tor. The only difference is that you need to manually configure your "Entry Node" (to lift tor terms). See [0] for the reasoning.

About the name, the creator is Caleb James DeLisle, so I guess CJDNS stands for Caleb James DeLisle's NameServer ? Doesn't really make much sense but I don't see how bad a thing it is.

[0]: https://github.com/cjdelisle/cjdns#2-find-a-friend [1]: https://github.com/cjdelisle/cjdns/blob/master/doc/configure...

Caleb James Delisle's Networking Suite

"One question I still haven't found the answer to: what's with the name?"

"Where did the name cjdns come from?

Cjdns was based on a codebase which was originally intended to handle name resolution (DNS) and so it was a combination of 'cjd' and 'dns'. The project changed direction early on and currently is still lacking DNS resolution but the name stuck. Make up your own acronym for it if you like."

Source: https://github.com/SlashRoot/cjdns

What is it? The author has said it is meant to be a single binary: a router. The router accepts "customized" IPv6 addresses, e.g., each address contains a public key fingerprint. The packets are also custom, each containing a full route to the destination, which might be reminiscent of the bang path in UUCP. The nodejs stuff is just a prototype method of getting data from the router.

I remember watching a video of him explaining this at a cafe a number of years ago. Not sure if that was the first "public announcement". In that video he mentions a concern over censorship via DNS. And then he states that at a certain point he realized routing was easier to do than DNS.

http://www.youtube.com/watch?v=zINQYkl01N8

He uses NaCl. As for the name "cjdns" and why he started out experimenting with DNS, my guess was always that the original experimentation he did with NaCl was probably related to encrypting and forwarding DNS packets (or perhaps custom "name system" packets), since encrypting DNS packets was the "PoC" for NaCl.

Lead author is CJD. cjdns == cjd network suite

Is cjdns more of same address-centric hosting? If y, would not NDN content-addressing be the more smarter internet fix?

http://youtu.be/opKJsVTcofg#t=164 Ask the network for what you want. Not say 'who' you wanna talk to, but say 'what' you want.

Smarter for what exactly? content-addressing is great if what you are looking for is pieces of content, it's not if you want to talk to services.

Here's the tl;dr: a practical encrypted mesh network that can work over the traditional internet protocol (IP) or over real-world links and radio antennas.

Since the parent was deleted and I couldn't comment by the time I finished typing, here's the non-tl;dr:

The main advantage is non-hierarchical routing. Your ip address is in fact the fingerprint of your public key, which is used to encrypt all traffic.

Because of this the address allocation works a lot different and there's no need for a central authority. The lack of a central authority is usually a problem if you ever tried to merge two large internal networks you might have run into the issue that both networks have used 10.0.0.1 for something. This isn't possible in cjdns because you can just generate as many key pairs as you want, which would map to one out of 2^120 possible addresses which are very unlikely to collide. Merging two networks is just a matter of configuring one or more peers and the networks are able to see each other (this is so easy, it might happen by accident).

The main difference to other projects is that you don't need to write code to support it. If your application supports unicast ipv6, your application is able to run on top of cjdns.

That sounds like a good way to get very inefficient routing.

Supposed I have keypair A at a friend and keypair B for me, how is cjdns going to find the fastest route between me and my friend?

Tbh, this doesn't look like something that could scale to Tbps Bandwidths... It seems a lot of processing is required to properly route the packet to the next hop and that happens independently of whether the next hop is even remotely an ideal one.

Atleast, as far as I can tell from this page.

There are some issues with cjdns with pure DHT on small footprint devices with poor connectivity. The author is hence currently introducing experimental supernodes, which are stable fat nodes with large memory which can build routes quickly.

Two questions about mesh networks:

1. at some point there will be an expensive hop across the ocean, or between cities, that will likely only be built once, then shared. Won't whoever owns that hop have similar centralized control of any non-local traffic, similar to an isp?

2. how meshy should mesh networks be? On one extreme, every computer can be directly connected to every other computer in the world. On the other, every computer can be connected to just one neighbor, and requests are routed through many hops. What is the prevailing wisdom on the optimal amount of peers nodes should have on average in a mesh network?

While the project is interesting, what is up with running it off nodejs!?

What? It's written in C.

The build system is written in nodejs -- it turned out way faster than both CMake and classic Makefiles.