How to find nodes handling a custom protocol

Help Coding
1

Hi everyone,

When spawning an IPFS node, embedded LibP2P instance lets you specify a custom protocol handler

ipfs.libp2p.handle('/my-custom-protocol/1.0.0', (protocolName, conn) => { (...) })

You then can direct dial to that IPFS node requesting your custom protocol

ipfs.libp2p.dialProtocol(addr, '/my-custom-protocol/1.0.0', (err, connection) => { (...) })

All is working great, but I’d like to be able to dynamically find running nodes that handle my custom protocol. The scheme would be like a findProvs request for nodes to report they handle the specified protocol.

Does someone know how I could achieve this?

2

In go (not sure about js), we actually just use content routing for the moment as we don’t really have anything better. One side just “provides” a special block indicating that they speak the protocol (see https://github.com/libp2p/go-libp2p-discovery/).

(the plan is to add more rendezvous protocols as we go)

3

Thanks @stebalien. So the only way to do it right now (with the js implementation) is to provide/put a shared identifier to the DHT and then get/findProvs of that shared identifier for nodes, am I right ? I think hosting a specific block CID on running nodes and then identify nodes hosting that CID would be equivalent, without having to go through the DHT…

Basing on this I guess it would be possible to implement something like a “findProtocolProviders” method.

4

@alanshaw is the work being done about the DHT (that was not embedded in the v0. 35.0 release) the reason why dht.provide and dht.findProvs methods doesn’t work properly in the browser and in nodeJS ? The only provider findProvs returns is the current node so I can’t use it as a discovery/signaling mechanism to find nodes handling the same protocol.

5

Yes.

I think hosting a specific block CID on running nodes and then identify nodes hosting that CID would be equivalent, without having to go through the DHT…

Probably? Although you may run into weird issues (e.g., if you stop providing the service but continue to provide the block).

6

You’re write…but I think, considering how the network performs right now, getting a (big) list of nodes that may provide the protocol and then testing if it’s still the case is a better promise then not discovering half of the nodes or spending too much time in an exact match discovery :wink:

But I really wish it could be done the right way in near future! :blush:

7

Will it be much simpler to just include custom protocol information to “IPFS swarm peers” and other related peer info function?

8

Having the ability (option) to get more information from peers listing/finding functions would effectively make it easier in that “discovery” use case but also when trying to direct connect peers (ex: STUN for free), building DHT like systems over the IPFS network and I think a lot of other cases.