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.
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.
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?
Atleast, as far as I can tell from this page.
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?