From 306d0afbfe48f668b1c6c11b64b0d487bdb3dd44 Mon Sep 17 00:00:00 2001 From: Adrian Duke Date: Tue, 27 Jan 2026 16:30:42 +0000 Subject: [PATCH] protocol: Note on peering and fetches As part of the work to change the default scope, one of the tests surfaced an issue where the topology was Alice <--> Bob <--> Eve, however because of the previous 'all' scope Alice could receive Eve references via Bob, but since the scope was changed to 'follow' Alice would need to have a direct connection to Eve. TODO left here for future consideration. --- crates/radicle-protocol/src/service.rs | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/crates/radicle-protocol/src/service.rs b/crates/radicle-protocol/src/service.rs index e3991e41..e5b9cdb3 100644 --- a/crates/radicle-protocol/src/service.rs +++ b/crates/radicle-protocol/src/service.rs @@ -1597,9 +1597,18 @@ where ); return Ok(None); }; - // Refs can be relayed by peers who don't have the data in storage, - // therefore we only check whether we are connected to the *announcer*, - // which is required by the protocol to only announce refs it has. + // Ref announcements may be relayed by peers who don't have the + // actual refs in storage, therefore we only check whether we + // are connected to the *announcer*, which is required by the + // protocol to only announce refs it has. + // + // TODO(Ade): Perhaps it makes sense to establish connections to + // followed but unconnected peers. Consider: + // Connections: Alice ←→ Bob ←→ Eve + // Follows: Alice ←→ Eve + // Eve announces refs, and Bob relays these announcements to Alice. + // Then, Alice might determine that Bob does not have Eve's refs, + // and therefore connect directly to Eve in order to fetch. let Some(remote) = self.sessions.get(announcer).cloned() else { trace!( target: "service",