I was able to see all of archy-x250-mad2's peers after accepting a peer request and then promoting the guy who invited me to "trusted"
Tested with a new install of 129 connecting to a 127. I'll have to retest 129 to 129
Steps to Reproduce
Machine1 created an invite
Machine2 accepts the invite
Machine2 now sees Machine1 in the peer list
Machine2 promotes Machine1 to trusts
Now all of Machine1's peers populate his peer list
Expected Behavior
I don't know! Can there be multiple federations where you don't leak everyone's peers?
It doesn't seem right that be cause my neighbor invited me over, I can decide I trust him enough to fiddle though his contact list.
Actual Behavior
Archipelago Version
v1.7.127-alpha
Hardware
x86_64 (Intel/AMD)
Relevant Logs
No response
Screenshots
No response
### Description
I was able to see all of archy-x250-mad2's peers after accepting a peer request and then promoting the guy who invited me to "trusted"
Tested with a new install of 129 connecting to a 127. I'll have to retest 129 to 129
### Steps to Reproduce
Machine1 created an invite
Machine2 accepts the invite
Machine2 now sees Machine1 in the peer list
Machine2 promotes Machine1 to trusts
Now all of Machine1's peers populate his peer list
### Expected Behavior
I don't know! Can there be multiple federations where you don't leak everyone's peers?
It doesn't seem right that be cause my neighbor invited me over, I can decide I trust him enough to fiddle though his contact list.
### Actual Behavior
### Archipelago Version
v1.7.127-alpha
### Hardware
x86_64 (Intel/AMD)
### Relevant Logs
_No response_
### Screenshots
_No response_
Reviewed against the current federation implementation. The present wording conflates several different concepts: a directly trusted peer, a peer learned through another node, a non-trusted routing hint, and peer advertisement/discovery. Trust is not currently inherited, but the privacy and product semantics of advertising peer relationships need to be defined more clearly, with better user-facing names, before deciding whether the existing behavior should change. Keeping this open but deferring it for a later federation terminology/privacy design pass; no code change in the current release.
Reviewed against the current federation implementation. The present wording conflates several different concepts: a directly trusted peer, a peer learned through another node, a non-trusted routing hint, and peer advertisement/discovery. Trust is not currently inherited, but the privacy and product semantics of advertising peer relationships need to be defined more clearly, with better user-facing names, before deciding whether the existing behavior should change. Keeping this open but deferring it for a later federation terminology/privacy design pass; no code change in the current release.
Closing as intended behavior, with the terminology the report asked for now written down.
What the reporter saw is by design: a Trusted peer sharing its own peer list ("advertisement") is what makes one invite enough for reachability across the federation — the peers learned that way enter as Discovered peers, hard-capped at Observer with TrustSource::TransitiveMerge. The code has always guarded this (TRUST IS NOT TRANSITIVE, core/archipelago/src/federation/sync.rs): a peer can never expand our trusted set on its own authority, and every trust level traces to an operator decision.
What was genuinely missing was the vocabulary — the report conflated four different concepts. Those now have names in docs/peering-trust-model.md (9df580bf): Trusted peer (invite-verified), Discovered peer (learned via advertisement, Observer-capped), Routing hint (what a Discovered peer contributes — reachability, not trust), and Peer advertisement (the mechanism itself).
Deferred, deliberately: the "don't advertise my peers" privacy toggle. It is a real option with real trade-offs (it hides peers who may want discovery, and degrades routing for every node trusting you) — that is a product decision, not a code patch. If you want it, reopen this or file a feature issue and we'll scope it properly.
Closing as intended behavior, with the terminology the report asked for now written down.
**What the reporter saw is by design:** a Trusted peer sharing its own peer list ("advertisement") is what makes one invite enough for reachability across the federation — the peers learned that way enter as **Discovered peers**, hard-capped at Observer with `TrustSource::TransitiveMerge`. The code has always guarded this (`TRUST IS NOT TRANSITIVE`, core/archipelago/src/federation/sync.rs): a peer can never expand our trusted set on its own authority, and every trust level traces to an operator decision.
**What was genuinely missing was the vocabulary** — the report conflated four different concepts. Those now have names in docs/peering-trust-model.md (`9df580bf`): *Trusted peer* (invite-verified), *Discovered peer* (learned via advertisement, Observer-capped), *Routing hint* (what a Discovered peer contributes — reachability, not trust), and *Peer advertisement* (the mechanism itself).
**Deferred, deliberately:** the "don't advertise my peers" privacy toggle. It is a real option with real trade-offs (it hides peers who may want discovery, and degrades routing for every node trusting you) — that is a product decision, not a code patch. If you want it, reopen this or file a feature issue and we'll scope it properly.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Description
I was able to see all of archy-x250-mad2's peers after accepting a peer request and then promoting the guy who invited me to "trusted"
Tested with a new install of 129 connecting to a 127. I'll have to retest 129 to 129
Steps to Reproduce
Machine1 created an invite
Machine2 accepts the invite
Machine2 now sees Machine1 in the peer list
Machine2 promotes Machine1 to trusts
Now all of Machine1's peers populate his peer list
Expected Behavior
I don't know! Can there be multiple federations where you don't leak everyone's peers?
It doesn't seem right that be cause my neighbor invited me over, I can decide I trust him enough to fiddle though his contact list.
Actual Behavior
Archipelago Version
v1.7.127-alpha
Hardware
x86_64 (Intel/AMD)
Relevant Logs
No response
Screenshots
No response
Reviewed against the current federation implementation. The present wording conflates several different concepts: a directly trusted peer, a peer learned through another node, a non-trusted routing hint, and peer advertisement/discovery. Trust is not currently inherited, but the privacy and product semantics of advertising peer relationships need to be defined more clearly, with better user-facing names, before deciding whether the existing behavior should change. Keeping this open but deferring it for a later federation terminology/privacy design pass; no code change in the current release.
Closing as intended behavior, with the terminology the report asked for now written down.
What the reporter saw is by design: a Trusted peer sharing its own peer list ("advertisement") is what makes one invite enough for reachability across the federation — the peers learned that way enter as Discovered peers, hard-capped at Observer with
TrustSource::TransitiveMerge. The code has always guarded this (TRUST IS NOT TRANSITIVE, core/archipelago/src/federation/sync.rs): a peer can never expand our trusted set on its own authority, and every trust level traces to an operator decision.What was genuinely missing was the vocabulary — the report conflated four different concepts. Those now have names in docs/peering-trust-model.md (
9df580bf): Trusted peer (invite-verified), Discovered peer (learned via advertisement, Observer-capped), Routing hint (what a Discovered peer contributes — reachability, not trust), and Peer advertisement (the mechanism itself).Deferred, deliberately: the "don't advertise my peers" privacy toggle. It is a real option with real trade-offs (it hides peers who may want discovery, and degrades routing for every node trusting you) — that is a product decision, not a code patch. If you want it, reopen this or file a feature issue and we'll scope it properly.