feat(kad-dht): dht-clients can ignore peers that don't have supported transports

[SgtPooki]

Porting over libp2p/js-libp2p-kad-dht#481

This issue is specifically for improving the in-browser experience when using js-libp2p

Due to browsers having a limited capacity for dialing, we should enable the restricting the potential invalid dials as much as possible when running in the browser. I believe this improvement could significantly help with ipfs/helia#182

Original problem:

it seems like the distance calculation has no awareness of peers that may not have valid (for my node) transports, which could easily result in filling up closestPeers to ‘this.capacity’ that I can’t talk to because they don’t talk the same transport as me.

When running as a DHT-client, we should add a config option that can prevent adding peers to peerDistanceList unless that peer has a multiaddr of a supported transport. i.e. this.transportManager.transportForMultiaddr(addr.multiaddr)) see

js-libp2p/packages/kad-dht/src/peer-routing/index.ts

Lines 192 to 199 in a1fbb7e

	async * getClosestPeers (key: Uint8Array, options: QueryOptions = {}): AsyncGenerator<DialPeerEvent | QueryEvent> {
	this.log('getClosestPeers to %b', key)
	const id = await utils.convertBuffer(key)
	const tablePeers = this.routingTable.closestPeers(id)
	const self = this // eslint-disable-line @typescript-eslint/no-this-alias
	const peers = new PeerDistanceList(id, this.routingTable.kBucketSize)
	await Promise.all(tablePeers.map(async peer => { await peers.add(peer) }))

Exceptions or potential problems

note from @achingbrain regarding an exception/issue here when running as DHT server:

it's a nice optimisation to only add peers that we can actually dial, but if you are a DHT server and another peer asks you for peers closer to a given KAD ID, you might have previously excluded peers that you can't dial, but that the querying peer can.

[achingbrain]

Another thing to consider here is that when getting the closest peers, you're typically doing this to ask one to store a provider record or to retrieve it.

This query has to be replicable by another node on the network - the intermediate states of the peer distance list don't matter but the final list of peers does.

If the other peer has a different set of supported transports and they finish their query with a different set of peers as the "closest" they won't be able to resolve the provider record since they'll be asking the wrong peers.