To be specific, I don't think CJDNS is a bad technology. On the contrary, I think it is interesting and will have a valuable role in influencing then next few decades of the Internet. However it's not a replacement for the use cases that Byzantium Linux or Commotion Wireless try to address. While most of the CJDNS fanboys will try to tell you that CJDNS can replace Layer-3 routing (and they're not completely wrong) the problem is that it's not a practical alternative for our deployment model. Creating connections between nodes in CJDNS requires more collusion in that new nodes must know the correct public key and password to create a link with another existing node. This is good for security, but not conducive to the rapid and organic deployment that we're looking for. Furthermore, as a mobile node roams from one AP to the next, they would need to re-negotiate the link (and discover key/pw again) with each new AP. If the AP offers up some kind of layer-3 routing to other networks which have nodes (such as the Internet) then you don't have the re-negotiation problem. However, in our use case Internet access is not a guarantee. And what provides for that layer-3 routing anyways? We'll that's exactly what Byzantium and Commotion try to solve with OSLR or Babel or BATMAN. Furthermore, CJDNS doesn't route IPv4 traffic to the IPv4 Internet, at least not by itself. You would need to do some kind of 4-in-6 tunneling. Which is yet another layer of overhead and latency, and another "moving piece" that can fail and disrupt service for users. So based on my understanding of CJDNS, it's not a competing technology in our problem domain, although some of the functionality overlaps. And in certain cases, they are actually complimentary projects. CJDNS, in its typical and most practical deployment, is an overlay network. That means it needs an existing network to run on top of, and that's exactly what Byzantium or Commotion can provide. A couple of other points of interest I've come across. Starting with Wikipedia (I know it's not authoritative and often out of date). " The address is generated initially when a node is set up, through a brute-forced key generation process (keys are repeatedly generated until the result of double SHA-512 begins with 0xFC). This process is unique, as it guarantees cryptographically bound addresses (the double SHA-512 of the public key), sourced from random data (private key is random data, public key is the scalar multiplication of this data)." Two things. First of all, wouldn't brute-forcing the key generation exhaust the entropy available in /dev/random and force the use of less random bits from /dev/urandom? Also, don't the public/private keys need to be based on prime numbers, not just random numbers? The strength of RSA is the assumption that factorization of large _prime_ numbers is mathematically a hard problem to solve. This last part is probably just the Wiki-author's misunderstanding. I'm giving cjd the benefit of the doubt because he seems like he would know better.

From the projectmeshnet wiki. "While you can technically add as many as 255 peers, more is not better. The software likes to run with about 3 peers and will work fine even if only 1 of them is functioning. ~ CJD"

A limitation of 255 peers seems arbitrary and actually quite low. I'm sure it would be fine for permanent infrastructure nodes, however it seems quite restrictive for mobile ad-hoc nodes which might roam in and out of range with dozens or hundreds of other nodes. I still think CDJNS is a cool project and I'm keeping an eye on it, just not for rapid deployment in disaster relief scenarios. The usability cost, while modest compared to alternative overlay networks, is still quite high in comparison to the solution we have been building. Hypothetically, we could make CJDNS just as automatic, but in the process we would be discarding some of the security benefits it's trying to achieve. No one tool is a panacea for the problems facing the Internet. The use cases we are facing today are so diverse that no single solution can encompass them all. Projects like CJDNS and Byzantium are successful because they focus on solving one chunk of the problem space and doing it as well as possible without getting distracted by every shiny use case that comes along. We also benefit from adherence to standards and best practices that allow us to interoperate with the other projects that are solving other chunks of the problem space. That's my $0.02. Ben the Pyrate On 11/26/2012 09:25 AM, Eugen Leitl wrote:

Guys, can you give me the beef with what you think is wrong with cjdns' design? Please make sure to look at the latest work, including L2 transport.

I'll forward your comments to cjd.

----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE