DHT should not depend on boxo

[Wondertan]

Even though boxo/ipfs is the primary user of DHT, it does not mean that DHT should depend on it. It's used only for utility functions and the ipns validator. This basic usage does not justify importing the full-blown boxo for the tradeoff of conceptual cyclicity and go.mod bloat.

[Wondertan]

Also, my motivation here comes from seeing the recent versions and the nice improvements to DHT they bring, but the failure to update the project due to DHT's dependence on boxo. It requires fully migrating to it, which is PITA, especially because of ipfs/boxo#281.

[p-shahi]

cc @Jorropo @guillaumemichel

[guillaumemichel]

@Wondertan agreed that kad-dht shouldn't depend on boxo. The (longer term) goal is to split the DHT implementation (currently go-libp2p-kad-dht), in 2 different repos. One generic dht implementation living in the libp2p org, and the IPFS instantiation of the DHT living in the ipfs org (maybe even within boxo).
There is an ongoing effort for a larger refactor and split of the repo, but no ETA yet.

[Wondertan]

Do you mean ComposableDHT?

[guillaumemichel]

It should be the case with the ComposableDHT, but we already want to split the repo before during a repo refactor.