feat: Add GossipDiscovery and thus make broadcasting our addressing information optional

[Frando]

Description

Background:

Currently, iroh-gossip always and unconditionally includes a node's NodeAddr in Join and ForwardJoin messages. This is a good feature if no other node discovery sources are available, because in the case of ForwardJoin it allows a node receiving a ForwardJoin to directly connect to the original sender (which is not the node we received the ForwardJoin from). However, ForwardJoins take a number of hops in a random walk, and by the time a node replies to a ForwardJoin and thus tries to establish a connection to the original sender, the address info included in the ForwardJoin might already be outdated, because the original sender has switched relays or networks. As long as other discovery mechanisms are enabled on all nodes, it might be better to rely on those instead of trying to connect to the outdated address info.

Change in this PR

The always-on inclusion of a node's address info as PeerData in Join messages is removed, as is adding received address info to the endpoint via Endpoint::add_node_addr. This means that by default, iroh-gossip only works well if the endpoint has other discovery mechanisms enabled. Instead, this PR introduces a new GossipDiscovery struct. It can be constructed before building an endpoint and gossip, and is then added to both the endpoint (through EndpointBuilder::discovery and the gossip (through GossipBuilder::use_gossip_for_discovery). If done, the behavior is exactly as previously: when our node address changes, the changed address is pushed into the gossip state to be included in future Join messages. When we receive PeerData with node address info, it is added to the GossipDiscovery, which is a regular discovery source to the endpoint. Endpoint::add_node_addr is not used anymore, which will make @flub happy.

The PR also adds a test that demonstrates the change with regard to ForwardJoin: Without discovery, we cannot contact nodes from a ForwardJoin. With the GossipDiscovery, everything works as previously.

Based on #50 (without #50, we'd get NeighborUp messages for peers from ForwardJoin even though we cannot connect to them)

Breaking Changes

• iroh-gossip does, by default, not broadcast node addresses with Join messages anymore. If you are not using discovery services on the endpoint, use the new GossipDiscovery to keep the previous behavior. See the docs of GossipBuilder::use_gossip_for_discovery for details.
• GossipBuilder::spawn is not async anymore, and returns Gossip instead of Result<Gossip>.

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh-gossip/pr/51/docs/iroh_gossip/

Last updated: 2025-03-28T20:21:14Z

[flub]

However, ForwardJoins take a number of hops in a random walk, and by the time a node replies to a ForwardJoin and thus tries to establish a connection to the original sender, the address info included in the ForwardJoin might already be outdated, because the original sender has switched relays or networks.

How long does a ForwardJoin live? Discovery methods are also not the fastest and don't react instant to relay address changes. E.g. DNS discovery has several caching servers in between which are not fully under iroh's control.

[Frando]

How long does a ForwardJoin live?

In the default config up to 6 hops on a random walk between connected peers.

[flub]

How long does a ForwardJoin live?

In the default config up to 6 hops on a random walk between connected peers.

Heh, I guess I meant in units of time... I assume 6 hops are like, less than a second? In which case the staleness of it's addressing info really isn't an issue I guess.