Gossipsub with relays

Users and Developers rust
1

I have non-public nodes A and B connected to a public relay node, with kademlia, identify, dcutr, autonat and gossipsub behaviours (relay node using relay instead of dcutr).

Nodes A and B are subscribed to the same topic. Messages broadcasted to the topic by A result in an InsufficientPeers error and B does not receive the message. Is this expected, if so is there a way around this?

I’m imagining a system with many web / non-public nodes that will rely on public relays but each constantly subscribing to new topics and broadcasting messages frequently.

If this use case is feasible, what is the most idiomatic method to discover public relays, would it be using rendezvous?

Any insight would be appreciated, thanks!

2

After finding some new sources on the topic I believe I have a solid understanding of this now but will still leave this post open for anyone else interested in the future:

I’ve realized that nodes will only propagate a message if it is subscribed to the topic of the message. This concerned me that a message from node A won’t reach node B if each of the node A’s direct peers aren’t subscribed, which is true. But by nature of gossipsub with kademlia, nodes should gossip around subscriptions and form connections with other peers on the network also subscribed to the topic, creating meshes.

As for my scenario with A ↔ Relay ↔ B, A’s message will only get to B if Relay is also subscribed to the topic. So B could request that Relay subscribes to the topic, sending a heartbeat message every so-often to keep Relay propagating those messages to B. I imagine Relay will need some form of rate limiting to help prevent abuse / bandwidth issues.

In the concern of a network with a large percentage of web / non-public nodes behind NATs. Of course dcutr (hole punching) can strengthen web ↔ web connections, but this isn’t 100% successful. In this case I could have web nodes rely on relays like described in the paragraph above.

Additionally, you could use rendezvous servers, DHT or any other peer discovery mechanism to help nodes discover public relays in a way that isn’t simply hard coded. This can also be done to discover nodes interested in a particular topic, strengthening meshes even further.

2 Likes
3

Hi
I am facing the same issue. can you please elaborate on how node B (or A) can request the relay to join the topic? (By request you mean force the relay to join?)

4

Have you tried setting runOnTransientConnection: true
on both the client and the server? It seems to work.

1 Like
5

I have implemented gossipsub with automatic relay discovery & direct dial in agi-any-day-now/p2pandemonium: A peer to peer framework for hosting shared interactive spaces written in Rust - Codeberg.org, but my approach required patching a few crates. The author of libp2p-relay-manager pointed me to feat(relay): implement autorelay by dariusc93 · Pull Request #6156 · libp2p/rust-libp2p · GitHub which should obviate both my libp2p-relay-manager patch and my relay client patch (to surface rejections so we can try another relay).

Edit: Oh I should mention the automatic relay discovery lives in libp2p-gossipsub-manager which I will probably split out at some point. Right now it derives a CID from the topic name, but I’m thinking about turning that into a more generic peer discovery behavior, because I’m planning to move from discovery based on room name to an invitation-based mechanism.