#145 - Peering panel: issued-key name and peer-entry name silently form one relationship — surface or unify the coupling - Cordy/Cairn

Cordy commented

2026-08-09 01:39:02 +00:00

Owner

Third UX find of the #106 dogfood (after #142 test button and the #140/#143 transport bugs).

The trap, hit live: on the receiving instance the admin issued a key named dogfood but registered the peer entry as Main-Cairn. Inbound transfers authenticate against the issued key, take the issued key's name, and look up the peer entry with that same name for the receivers allowlist. Different names → lookup finds nothing → fail-closed STATUS_UNKNOWN_RECIPIENT on the sender's side, with no hint that the receiver's two list entries simply don't share a name.

Nothing in the panel communicates that the name is the join key. Two separately-headed lists ("Keys you issued" / "Instances you can send to") actively suggest independence, and the natural mental model — "key name = who I gave it to, peer name = what I call them" — produces exactly this bug.

Short term (this milestone): a warning row in the panel when an issued key has no same-named registered peer: "This key can authenticate, but transfers from its holder will be refused: no peer entry named X defines who may receive." Mirror check on registering a peer whose name matches no issued key (fine for send-only peerings — make it informational, not a warning).

Longer term (product call, v0.6+ discussion): unify the two lists into one relationship card per peer — alias, URL, the key they gave us (outbound), the key we issued them (inbound, id-hinted), senders, receivers, test button (#142). One name because it is one object. The storage model already supports this; it is purely a panel restructure plus issuing keys from within the card.

Live example preserved: beta had key dogfood + peer Main-Cairn; the reverse direction worked only because enc coincidentally used dogfood for both.

Third UX find of the #106 dogfood (after #142 test button and the #140/#143 transport bugs). **The trap, hit live:** on the receiving instance the admin issued a key named `dogfood` but registered the peer entry as `Main-Cairn`. Inbound transfers authenticate against the issued key, take the **issued key's name**, and look up the **peer entry with that same name** for the receivers allowlist. Different names → lookup finds nothing → fail-closed `STATUS_UNKNOWN_RECIPIENT` on the *sender's* side, with no hint that the receiver's two list entries simply don't share a name. Nothing in the panel communicates that the name is the join key. Two separately-headed lists ("Keys you issued" / "Instances you can send to") actively suggest independence, and the natural mental model — "key name = who I gave it to, peer name = what I call them" — produces exactly this bug. **Short term (this milestone):** a warning row in the panel when an issued key has no same-named registered peer: *"This key can authenticate, but transfers from its holder will be refused: no peer entry named X defines who may receive."* Mirror check on registering a peer whose name matches no issued key (fine for send-only peerings — make it informational, not a warning). **Longer term (product call, v0.6+ discussion):** unify the two lists into one relationship card per peer — alias, URL, the key they gave us (outbound), the key we issued them (inbound, id-hinted), senders, receivers, test button (#142). One name because it is one object. The storage model already supports this; it is purely a panel restructure plus issuing keys from within the card. Live example preserved: beta had key `dogfood` + peer `Main-Cairn`; the reverse direction worked only because enc coincidentally used `dogfood` for both.

Cordy added this to the v0.5 — Instance peering (federation v1) milestone

2026-08-09 01:39:02 +00:00

Cordy referenced this issue

2026-08-09 02:29:42 +00:00

Peering dogfood: second instance on k3s + live A↔B e2e #106

forgejo-actions referenced this issue from a commit

2026-08-09 02:48:04 +00:00

feat: v0.5 closeout — home-at-login (#146), peer test button (#142), orphan-key warning (#145)

Cordy referenced this issue

2026-08-09 02:48:45 +00:00

v0.5 closeout: home-at-login (#146), Test connection (#142), orphan-key warning (#145) #149

Cordy referenced this issue from a commit

2026-08-09 02:49:03 +00:00

Merge pull request 'v0.5 closeout: home-at-login (#146), Test connection (#142), orphan-key warning (#145)' (#149) from feat/v05-closeout into main

Cordy commented

2026-08-09 02:55:41 +00:00

Author

Owner

Short-term half shipped in v0.4.12 (PR #149), live on the dogfood. The panel now fetches peers before rendering issued keys and warns inline on any issued key whose name matches no registered peer (case-insensitive, matching CanReceive's semantics): "no peer entry with this name: its holder can authenticate, but transfers will be refused." The exact dogfood-vs-Main-Cairn trap from the dogfood now announces itself where the admin is looking, on the correct side of the wire. The mirror case (peer with no same-named issued key) stays quiet as designed — it's a legitimate send-only peering.

The long-term half — one relationship card per peer (alias, URL, both keys, senders, receivers, test button as one object) — remains open as a product call for the v0.6/v0.7 window; leaving this issue open to track it, or it can be re-scoped/closed if the warning is judged sufficient for v0.5.

Short-term half shipped in **v0.4.12** (PR #149), live on the dogfood. The panel now fetches peers *before* rendering issued keys and warns inline on any issued key whose name matches no registered peer (case-insensitive, matching `CanReceive`'s semantics): *"no peer entry with this name: its holder can authenticate, but transfers will be refused."* The exact `dogfood`-vs-`Main-Cairn` trap from the dogfood now announces itself where the admin is looking, on the correct side of the wire. The mirror case (peer with no same-named issued key) stays quiet as designed — it's a legitimate send-only peering. The **long-term half — one relationship card per peer** (alias, URL, both keys, senders, receivers, test button as one object) — remains open as a product call for the v0.6/v0.7 window; leaving this issue open to track it, or it can be re-scoped/closed if the warning is judged sufficient for v0.5.

Cordy closed this issue

2026-08-09 02:55:52 +00:00

Cordy referenced this issue

2026-08-09 02:56:02 +00:00

Peering panel v2: one relationship card per peer (successor to #145's warning) #150

Cordy referenced this issue

2026-08-09 03:03:23 +00:00

When peering works end to end: describe it in README + ARCHITECTURE #124

Cordy referenced this issue

2026-08-14 00:40:56 +00:00

Peering panel v2: one relationship card per peer (successor to #145's warning) #150

Cordy referenced this issue