DHT should be part of go-libp2p instead of go-ipfs

[vasco-santos]

Taking into account the objective of creating interop tests for libp2p, as well as for libp2p-kad-dht and my current focus on creating DHT interop tests on IPFS interop#36, I noticed that the DHT in JS land is a piece of js-libp2p, while in GO land, the DHT is used directly by go-ipfs, and not through go-libp2p go-ipfs/core/core.go#L514.

This does not feel right to me since the DHT is a really important part of libp2p and considering our focus on interop tests, as well as creating testbed scenarios, we must have the DHT available in libp2p.

I found a really old issue go-libp2p#56 for tackling this, and what happened was to remove the implementation of the DHT from go-ipfs to a specific module, but keeping its use directly on go-ipfs.

Is there anything blocking this?

cc @bigs @Stebalien @diasdavid

[Stebalien]

It is a part of libp2p, it's just not a direct dependency of go-libp2p. go-libp2p is just a meta-package. IIRC, the issue was that go-libp2p-kad-dht depends on go-libp2p (for tests, IIRC). Our DHT needs to construct a host and all the logic for constructing a host lives in go-libp2p.

I'm not sure what the best solution here is that doesn't introduce a cyclic dependency. In other package managers, we could make the dht's tests a separate package but that's a bit difficult at the moment with gx.

[vasco-santos]

Thanks for the explanation @Stebalien , I see your point.

That way, maybe the daemon can expose both go-libp2p and go-libp2p-kad-dht for allowing tests using the DHT, as well as to allow the DHT to be used through bindings from other languages. I don't know if you are already considering something like this

[Stebalien]

Personally, I'd like to put the DHT in a separate daemon/process but we may punt on that till later. This is one of the reasons we may want to consider multiple daemons. The daemon we want for applications may look very different from the one we'll want for testing.

[daviddias]

This issue was just helpful for understanding this decision

[marten-seemann]

The DHT is currently living in https://github.com/libp2p/go-libp2p-kad-dht, so this is resolved (?).