Accelerated DHT Client
Opened this issue · 1 comments
We should decide whether we want to create a FullRT routing table implementation, and its associated refresh mechanism (crawler), or if the FullRT from the old implementation should be superseded by Reprovide Sweep. Note that the scope isn't exactly similar. Reprovide Sweep is more efficient at reproviding content than FullRT, but FullRT is (supposed to be) more efficient at lookup than a normal routing table (using Reprovide Sweep). IIUC most of the FullRT users are using it to reprovide content, so the switch to Reprovide Sweep would be an upgrade for them. However, we may break users depending on the FullRT for faster lookup, if we don't implement it in the new IPFS DHT implementation. There are other efficient routing table alternatives described in probe-lab/go-kademlia#2.
As the accelerated DHT client is an option in Kubo, we could ship the new IPFS DHT implementation without implementing the FullRT, and kubo could depend on the old IPFS DHT implementation if the accelerated DHT client option is set.
To be clear, this is more than "scope/nicetohave", as this is non-experimental feature in Kubo that we point users to. This will be required before we enable "go-libp2p-kad-dht/v2" by default in Kubo.