I was going to ask how the routing algorithm differs from eg Kademlia[1], but then I realised this explicitly builds on Kademlia’s ideas.[2] Kademlia uses “bit

I was going to ask how the routing algorithm differs from eg Kademlia[1], but then I realised this explicitly builds on Kademlia’s ideas.[2] Kademlia uses “bitwise XOR of peer id” as a distance metric for routing; after querying the DHT you can immediately build a routing table for reaching a particular peer, and you instantly know a next hop for any particular destination you had in mind. Yggdrasil’s contribution is that it only does this next-hop thing when you first wish to connect to an Yggdrasil IP; instead of just sending to The closest current peer and expecting them to forward, you recursively ask that peer if they have any closer ones to a particular address and add them to your list. When you can’t get any closer, you have either found that peer (and a public internet IP you can contact them on), or the closest node to them that can forward there (eg over non public network, Bluetooth, etc), or you can’t find them. Very cool. Future work alluded to at the bottom of that post: > Also, while the current DHT should be fine for peer-to-peer type applications, I wouldn’t want to be the keyspace neighbor of an especially popular server, as this would mean a large number of DHT lookups would go through my node. A caching DHT could, in principle, be able to address that issue without changes to the protocol, but that’s not a very high priority given the size of the current network. [1]: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia... [2]: https://yggdrasil-network.github.io/2018/07/28/addressing.html https://yggdrasil-network.github.io/2018/07/28/addressing.ht...