Private & Public DHTs

[Stebalien]

Followup from a discussion with @aschmahmann.

Proposal: Run a second private DHT, mounted on /lan/dht/proto, in parallel to the public DHT.

With the next release of the DHT, DHT nodes will default to an "auto" mode that will only turn them into DHT servers when they learn that they are globally reachable. Unfortunately, as described in ipfs/kubo#6737, this will break offline/vpn/etc. DHTs.

The proposal is to run an additional DHT, on a separate protocol, with a special routing table filter that only admits nodes we believe are on our local network (e.g., nodes where the remote address is non-routable, nodes with the same public IP, etc.). All (or maybe just auto?) nodes with DHT support will act as servers in this local DHT and these two DHTs will be queried in parallel.

This will help in three ways:

1. IPNS, content routing, etc. will transparently work in offline, disconnected networks and VPNs.
2. Content routing will be very fast between peers in a local network.
3. Given proper address scopes, we can advertise local address records to this local DHT, and public address records to the global DHT, finally fixing Segregate routable and non-routable networks #436.

[Stebalien]

In terms of implementation, this should be very simple as we already have all the components. We need:

1. The ability to combine multiple DHTs: https://github.com/libp2p/go-libp2p-routing-helpers.
2. Custom protocol prefixes (already supported).
3. The ability to filter peers before we consider entering them into the routing table. We already have rudimentary support for this in the stabilize branch, we just need to be able to pass an arbitrary function into the constructor.

[bonedaddy]

Is this going to be heavily tested and benchmarked before being implemented? This seems like a massive change that will probably break functionality for more than one system in ways that are unknown due to the relatively low test coverage across all repositories.

[Stebalien]

Is this going to be heavily tested and benchmarked before being implemented?

Yes.

This seems like a massive change that will probably break functionality for more than one system in ways that are unknown due to the relatively low test coverage across all repositories.

Well, we don't want undialable nodes to join the main DHT so, by default, nodes won't join as servers unless they can determine that they're publicly dialable.

However, we also don't want to break VPNs, offline networks, test networks, etc. Adding a second private DHT is the solution that's least likely to break those. In terms of overhead, "private" DHTs should be tiny in most cases so queries should take no time (in most cases, all nodes will be directly connected anyways).

[Stebalien]

Related: libp2p/go-libp2p-kad-dht#564

[willscott]

a lan/wan split DHT implementation is now merged into go-libp2p-kad-dht in libp2p/go-libp2p-kad-dht#570

[Stebalien]

This has been released.