Let apps using IPFS define app-specific DHT for content routing about ipfs HOT 5 CLOSED

@bertrandfalguiere it's worth noting that a properly functioning kademlia has lookup times that scale as log(n) so the lookup time benefits to per-application DHTs may not be huge. However if there are other properties (e.g. churn rate) that are better in the application DHT then that could potentially be a big help.

I'd really like to see this happen to add functionality rather than just performance (e.g. application specific record types), but we'd have to design it so that running multiple global DHTs doesn't cost us too much on the performance side of things. Using some of the techniques from Coral (e.g. using the results of a query in a smaller DHT to seed a query in a larger DHT) could be helpful in achieving this.

from ipfs.

There's been some discussion about this and now Protocol Labs has launched an RFP to study multi-level DHTs: https://github.com/protocol/research-RFPs/blob/master/RFPs/rfp-7-MLDHT.md

from ipfs.

That is really interesting, but I think they address similar but different problems.

IIUC, the RFP want to explore a layered/Coral-style/nested DHT to solve the following problem:
A lot of nodes in the world have the data I want. How to query the ones close to me in priority? (i.e: there are a lot of possible paths, how to find a quick path?)

The above general idea would be to run parallel DHT and address the following problem:
There is only a limited set of nodes susceptible to have the data I need (the nodes running the application). How to only ask them and not bother the mainline DHT? (I.e: I know there are a limited number of path, how to quickly find a path?)

from ipfs.

The envision is to have a libp2p daemon common to the Eth app + the social Network app + the p2p sharing file client. If the p2p file-sharing app decides to use the default DHT, this unique daemon will have a Eth client DHT, a social network DHT and a default DHT (maybe splitted in local + global like the coming go-libp2p, maybe something more layered if the RFP put light on a better design).

from ipfs.

For the sake of maintenance, I am going to close this. This repo is not even the best place, given that libp2p has forums for specifically this sort of discussions: https://discuss.libp2p.io. Thanks!

from ipfs.