mab122
/
radicle-heartwood-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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.
This commit is contained in:
Adrian Duke 2026-01-27 16:30:42 +00:00 committed by Lorenz Leutgeb
parent 0684d1ccdf
commit 306d0afbfe
1 changed files with 12 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
crates/radicle-protocol/src/service.rs
View File

@ -1597,9 +1597,18 @@ where
); );
return Ok(None); return Ok(None);
}; };
// Refs can be relayed by peers who don't have the data in storage, // Ref announcements may be relayed by peers who don't have the
// therefore we only check whether we are connected to the *announcer*, // actual refs in storage, therefore we only check whether we
// which is required by the protocol to only announce refs it has. // 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 { let Some(remote) = self.sessions.get(announcer).cloned() else {
trace!( trace!(
target: "service", target: "service",