advertising supported protocols via the DHT

[raulk]

Many apps use the DHT as a discovery gadget.

But if you're looking for peers supporting a particular protocol, you would run around like a headless chicken connecting to peers left-and-right and testing whether they speak the protocol you seek. This is expensive.

Instead, I propose that peers advertise the protocols they support via a bloom filter, as part of signed peer routing records (see libp2p/libp2p#47).

This would limit the instances of "connecting for nothing" to only false positives -- that's a huge improvement.

---

EDIT: we'd be talking about 60 bytes extra per peer in the protobuf, for a bloom filter sized for 50 elements with 0.01 FPP and 7 hash functions: https://hur.st/bloomfilter/?n=50&p=0.01&m=&k=

[Stebalien]

@raulk could you walk through a use-case?

[raulk]

@Stebalien our DHT is public and any node can join it as long as they support the DHT protocol. Most peers are IPFS nodes, or higher-level applications of IPFS. However, we encourage libp2p users to use our DHT network as a public facility and we ship with our bootstrap nodes in config, so that's likely to happen.

The more popular our network gets across apps, the more easily IPFS will encounter nodes that do not serve bitswap. It could be happening already; we just don't realise. Likewise other apps will encounter lots of IPFS nodes that are useless to them.

In both cases, they have to undergo considerable connection and handshaking effort to find out the other party is useless.

By encoding supported protocols into a self-signed bloom filter, the other party can immediately learn if that node is useful at all.

Not just that, but you can use that data to build overlay DHTs where you bootstrap into the top-level network first, and as you encounter peers that advertise the protocol you seek, you phase the former members out, thus gradually limiting your DHT view to subnet of peers that's relevant to you.

You don't replace 100% of peers because you still need nodes on the top-level network ushering new joiners into the subnet.

[Stebalien]

I asked because one usually connects to a peer for a reason. Also, by the time we've found the peer routing record, we've usually done 90% of the work (crawling through the DHT).

For example:

1. When trying to find a file, one connects to nodes that advertise that they have the file (using a provider record). In this case, we'd likely be better served by including supported data exchange protocols next to this provider record (i.e., "I provide X over A, B, C"). We could put this in the peer routing record however, peers storing provider records throw out peer routing records pretty quickly.
2. WRT the DHT, this is what @jhiesey is working on (also discussed here: DHT 2.0 ipfs/notes#291 (comment)). Basically, when querying a specific "ring" of the DHT, we'd only be told about peers in that ring.

Basically, this sounds useful but I can't think of a specific use-case that wouldn't be better served with a different solution.

[raulk]

I might have misexplained myself. This solution is suitable when using random walks as a peer discovery gadget (not peer routing) for locating peers that speak a certain protocol.

[raulk]

Something like this would mitigate the effects of “accidental merging of DHTs”, which we’ve already had in the past.

[anacrolix]

I'm not sure how this improves the situation for DHTs merging, if DHT separation is implemented per filecoin-project/venus#1700 (comment).

[Stebalien]

This solution is suitable when using random walks as a peer discovery gadget (not peer routing) for locating peers that speak a certain protocol.

That sounds like we want a peer exchange protocol. That way, I can literally just ask my peers "know any peers that speak protocol X?". The way we'll actually do this will likely be:

1. Use discovery to find some set of peers that speak the protocol.
2. Use peer exchange to widen this set.

A random DHT walk is going to be suboptimal:

1. Peers will give me random peers that may or may not speak the protocol I want.
2. If I'm just walking the DHT to find peers that speak some protocol, connecting to a peer that doesn't speak the protocol is never actually wasteful. Even if they don't speak the desired protocol, I'd still need to talk to them to continue walking the DHT (to get the next set of peers).

---

Playing devils advocate, gossiping this information along with peerinfo records won't hurt and could be used as a passive discovery mechanism. We should probably do this eventually but I'm not convinced it'll solve any immediate issues.