What is the best way to establish a connection to a node if I only know the PeerId?

[thomaseizinger]

I have a node that is listening on a publicly reachable port. As such, doing any form of NAT traversal is not required. I've also successfully tested that - using the identify protocol - the node is able to figure out its publicly reachable address.

What I am trying to achieve is have a 2nd node connect to the first one solely based on the PeerId.

Idea 1 - Use the DHT

My first attempt was to use Kademlia and the official libp2p bootstrap nodes discoverable through /dnsaddr/bootstrap.libp2p.io.

It works using the DHT but we get a lot of unwanted connections. I presume this is because it is actually the IPFS DHT (/ipfs/kad/1.0.0) that we are connecting to. Our nodes are not IPFS node and hence we don't support any of the protocols. As a result, our logs get spammed with many incoming connections that routinely disappear again.

If this is the way to go about solving this problem, my question would be: Can I somehow avoid all these nodes connecting to me? I know that I can configure Kademlia to use a custom protocol string but I assume once I do that, I can no longer use the official libp2p bootstrap nodes because those will not support the custom protocol and hence my other nodes cannot discover the first one.

Idea 2 - Use the relay protocol

A second idea I had but I didn't yet get around to try it out is the circuit relay protocol.

• Do the libp2p bootstrap nodes implement the circuit relay protocol?
• Assuming I establish a connection to the libp2p bootstrap nodes, can I dial my node by dialing something like: /dnsaddr/bootstrap.libp2p.io/p2p-circuit/p2p/<MY_OTHER_PEER_ID>?

Given that my first node is actually listening on a publicly reachable port, it feels a bit of a waste to use the relay protocol here.

[mxinden]

I presume this is because it is actually the IPFS DHT (/ipfs/kad/1.0.0) that we are connecting to.

Correct.

Can I somehow avoid all these nodes connecting to me?

No, you can't, unless you spoof your address.

know that I can configure Kademlia to use a custom protocol string but I assume once I do that, I can no longer use the official libp2p bootstrap nodes because those will not support the custom protocol and hence my other nodes cannot discover the first one.

Correct.

Do the libp2p bootstrap nodes implement the circuit relay protocol?

Using libp2p-lookup it seems like they do:

$ libp2p-lookup --network ipfs --peer-id QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
Lookup for peer with id PeerId("QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ") succeeded.

Protocol version: "ipfs/0.1.0"
Agent version: "go-ipfs/0.8.0-dev/0401f60"
Observed address: "/ip4/84.158.40.6/tcp/35108"
Listen addresses:
        - "/ip4/104.131.131.82/tcp/4001"
        - "/ip4/104.131.131.82/udp/4001/quic"
Protocols:
        - "/p2p/id/delta/1.0.0"
        - "/ipfs/id/1.0.0"
        - "/ipfs/id/push/1.0.0"
        - "/ipfs/ping/1.0.0"
        - "/libp2p/circuit/relay/0.1.0"
        - "/ipfs/kad/1.0.0"
        - "/ipfs/lan/kad/1.0.0"
        - "/libp2p/autonat/1.0.0"
        - "/ipfs/bitswap/1.2.0"
        - "/ipfs/bitswap/1.1.0"
        - "/ipfs/bitswap/1.0.0"
        - "/ipfs/bitswap"
        - "/x/"

Assuming I establish a connection to the libp2p bootstrap nodes, can I dial my node by dialing something like: /dnsaddr/bootstrap.libp2p.io/p2p-circuit/p2p/<MY_OTHER_PEER_ID>?

Yes, you could, though (1) you need to ensure all your nodes are connected to the same set of bootstrap nodes and (2) all your traffic is relayed which is both not very performant and also incurring additional costs on the bootstrap nodes.

You might as well want to take a look at the eth2 discovery mechanism https://docs.rs/discv5/0.1.0-beta.3/discv5/ or the rendezvous protocol, though I am not aware of a Rust implementation for the latter.

[thomaseizinger]

Using libp2p-lookup it seems like they do:

Thanks, that is a very useful tool! I'll definitely start using that :)

or the rendezvous protocol, though I am not aware of a Rust implementation for the latter.

That sounds also very interesting! Do you know of any public nodes that implement this protocol already?

[mxinden]

That sounds also very interesting! Do you know of any public nodes that implement this protocol already?

Maybe the WebRTC rendezvous servers do: https://github.com/libp2p/js-libp2p-webrtc-star#hosted-rendezvous-server

[aschmahmann]

Our nodes are not IPFS node and hence we don't support any of the protocols. As a result, our logs get spammed with many incoming connections that routinely disappear again.

Does the rust DHT implementation have a client-only option? Part of being a DHT server node is expecting that nodes will regularly connect to you, ask questions, and then disconnect. If you are a client (including making sure that you aren't advertising your support for /ipfs/kad/1.0.0) then you can ask questions from the DHT and you shouldn't be getting connections from arbitrary peers.

Note: When switching from server to client mode there will be some lag time on the inbound connections stopping as peers retry you and learn that you aren't a member of the DHT anymore.

Do the libp2p bootstrap nodes implement the circuit relay protocol?

Using information from Identify to figure out what protocols a node supports is something to be careful with. Sometimes protocols have different properties/subcomponents and may not support what you are looking for. For example, there are nodes that have the circuit-relay protocol enabled/advertised that are announcing "I speak the relay protocol and will happily talk to peers behind relays" as opposed to "I am willing to serve you as a public relay", I'm pretty sure the bootstrap.libp2p.io nodes are not public relays.

[mxinden]

Does the rust DHT implementation have a client-only option?

I wasn't aware of this notion in the libp2p Kademlia protocol. The Rust implementation does not support client mode, though contributions would most certainly be welcome. If I understand correctly the node-to-be-found would still need to operate in server mode, correct?

For example, there are nodes that have the circuit-relay protocol enabled/advertised that are announcing "I speak the relay protocol and will happily talk to peers behind relays" as opposed to "I am willing to serve you as a public relay", I'm pretty sure the bootstrap.libp2p.io nodes are not public relays.

As a side note, as far as I can tell we could solve this particular issue via libp2p/specs#105 for circuit relay v2.

[aschmahmann]

If I understand correctly the node-to-be-found would still need to operate in server mode, correct?

Yes. It's just that if you are in server mode then you'll start getting added to other people's routing tables and then you'll start getting used for queries. This means that @thomaseizinger's issue of seeing inbound connections come and go is likely just normal DHT behavior not an instance of IPFS nodes connecting for arbitrary reasons and then going away. However, it doesn't seem like running rust-libp2p as an IPFS public DHT server implementation seems like a good idea as if it doesn't support the same behavior (e.g. the ability to store IPNS records) then it might just end up hurting the network.

The Rust implementation does not support client mode, though contributions would most certainly be welcome.

I can write up the issue + description of how to implement it, although I'm a Rust novice ATM.

Update: issue #2032

As a side note, as far as I can tell we could solve this particular issue via libp2p/specs#105 for circuit relay v2.

It helps, although it's not everything. Different relays might decide to only serve certain people, or offer different SLAs (e.g. limited relays used for coordinating NAT holepunching vs full VPN style relays).

[thomaseizinger]

This client-mode is really interesting, thank you for pointing that out @aschmahmann !

I think in my particular situation, it wouldn't help much though. Most of our nodes are actually behind NAT (it is kind of a federated star architecture). Those behind NAT are obviously not reachable even though they are normal members of the DHT.

They need to connect to some of the reachable nodes and this is where the problem resides: Those reachable nodes are getting spammed with inbound connections and many of them actually do not disappear over time, they just idle.

What I am trying to achieve is have the nodes behind NAT discover the publicly reachable ones while at the same time have the publicly reachable ones not be connected to arbitrary other nodes that don't serve any purpose.

I can achieve this with a custom Kademlia DHT but that means I need to host my own bootstrap infrastructure which is kind of a shame. The rendezvous protocol sounds interesting but I am not sure if that is already widely supported as part of the libp2p bootstrap infrastructure. If it is, I would be very interested in writing an initial Rust implementation!