Add DHTRouter interface

[hsanjuan]

The implementation of ipfs/specs#476 suggests that content routers should support a DHT-specific operations (GetClosestPeers).

Content routers depend on routing interfaces defined in the routing package and some decorator interfaces defined here. So it seems like the natural place to add yet another interface for this type of router.

[hsanjuan]

This interface will be used from boxo and kubo, it would be weird that it lives in boxo as that would create yet another place where routing interfaces live. As long as I have not misunderstood things.

[guillaumemichel]

This interface doesn't match kad-dht GetClosestPeers.

This only seems to be used by ipfs/specs#476, in which closerThan and count are currently not used, because implemented neither in Go nor JS DHT.

We could nonetheless use the count and closerThan parameters in boxo to return less than 20 peers, by filtering the results of the kad-dht GetClosestPeers(). But I wouldn't make a generic DHT interface including these unsupported parameters.

It is certainly fine to define this interface in boxo, since it is only used in the routing API so far. We can reevaluate later when/if this interface is used somewhere else.

[guillaumemichel]

Also, other routing API funcs aren't defined in go-libp2p-routing-helpers either. The methods also don't match the interfaces used in go-libp2p-routing-helpers and go-libp2p-kad-dht.

[hsanjuan]

Also, other routing API funcs aren't defined in go-libp2p-routing-helpers either. The methods also don't match the interfaces used in go-libp2p-routing-helpers and go-libp2p-kad-dht.

Those are slightly different. The contentRouter there implements the methods that Kubo/Boxo work with, which are those in libp2p/routing and routing-helpers.

This interface doesn't match kad-dht GetClosestPeers.

Yes, I need to respect the spec, and those options should be handled as deep as possible. I know DHT doesn't have them now, so the layer right above (Kubo in this case) will have to deal with them and ignore them or respect them... I'm also fine with the spec being more aligned with reality and dropping the options or limiting them.

[lidel]

@hsanjuan my vote would be to remove unsupported parameters from spec (ipfs/specs#476 (comment))

[hsanjuan]

@lidel sounds good, I will circle back to this work eventually and carry out the parameter removal accross the board.