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.

[lidel]

+1, boxo is being pulled in by go-libp2p examples which is really unnecessary in non-IPFS apps.

It sounds we could clean this up and remove dependency on boxo without touching too much:

• have local version of utility funcs
• extract IPNS Record and Validator logic from boxo/ipns to ipfs/go-ipns-record (similar to https://github.com/libp2p/go-libp2p-record) and use it in both boxo and go-libp2p-kad-dht

@guillaumemichel would this be something you could add to your queue? (low priority, but useful cleanup) 🙏