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

Closed
opened 2026-08-09 02:56:02 +00:00 by Cordy · 3 comments
Owner

Carved out of #145, whose v0.5 scope (the orphan-key warning) shipped in v0.4.12. This is the structural fix, parked for the closed-beta window as a product call.

Idea: replace the two lists ("Keys you issued" / "Instances you can send to") with one card per peer relationship: alias, URL, the key they issued us (outbound credential), the key we issued them (inbound, shown as the non-secret id hint), senders allowlist, receivers allowlist, and the Test-connection button (#142) — all under a single name, because it is a single object. Key issuance happens from within the card, which makes the #145 name-coupling structurally impossible rather than merely warned about.

The registry storage model already supports this (issued keys and peers are joined by name today); it is purely a panel restructure. Evaluate during the v0.7 beta with Manuel — his fresh-eyes read of the current two-list panel is the real test of whether the warning suffices or the card is needed.

Carved out of #145, whose v0.5 scope (the orphan-key warning) shipped in v0.4.12. This is the structural fix, parked for the closed-beta window as a product call. **Idea:** replace the two lists ("Keys you issued" / "Instances you can send to") with **one card per peer relationship**: alias, URL, the key they issued us (outbound credential), the key we issued them (inbound, shown as the non-secret id hint), senders allowlist, receivers allowlist, and the Test-connection button (#142) — all under a single name, because it is a single object. Key issuance happens from within the card, which makes the #145 name-coupling structurally impossible rather than merely warned about. The registry storage model already supports this (issued keys and peers are joined by name today); it is purely a panel restructure. Evaluate during the v0.7 beta with Manuel — his fresh-eyes read of the current two-list panel is the real test of whether the warning suffices or the card is needed.
Author
Owner

Triage: build-solo, verify-tandem. I can build the per-peer relationship card (state, last-transfer, allow-list summary, enable/disable) UI + API. Verifying it needs a second Cairn instance and out-of-band key exchange (the #106 A↔B dogfood). Groups with #176 (the edit-allow-lists backend it renders).

**Triage: build-solo, verify-tandem.** I can build the per-peer relationship card (state, last-transfer, allow-list summary, enable/disable) UI + API. Verifying it needs a second Cairn instance and out-of-band key exchange (the #106 A↔B dogfood). Groups with #176 (the edit-allow-lists backend it renders).
Author
Owner

Greenlit — build after #176.

One relationship card per peer: alias, URL, the key they issued us, the id-hint of the key we issued them, Senders/Receivers (now editable in place via #176), the test-connection button (#142), and the per-peer enabled toggle (#176). Key issuance happens inside the card, making the #145 name-coupling structurally impossible.

The card is also the home for the #125 recipient-discovery UI: its Receivers list is the authoritative input that the ListRecipients RPC serves live to a sender's recipient picker.

**Greenlit — build after #176.** One relationship card per peer: alias, URL, the key they issued us, the id-hint of the key we issued them, `Senders`/`Receivers` (now editable in place via #176), the test-connection button (#142), and the per-peer `enabled` toggle (#176). Key issuance happens inside the card, making the #145 name-coupling structurally impossible. The card is also the home for the #125 recipient-discovery UI: its `Receivers` list is the authoritative input that the `ListRecipients` RPC serves live to a sender's recipient picker.
Cordy closed this issue 2026-08-14 02:00:37 +00:00
Author
Owner

Shipped in v0.6.21 (PR #232, squash-merged; CI green in 40s). The peering admin panel is now one relationship card per peer:

  • The two separate lists ("keys you issued" / "instances you can send to") are collapsed into a single card per peer name, joining the inbound key we issued them (id hint) with the outbound side (URL + send/receive allow-lists). The two halves can no longer drift apart — the #145 name-coupling is structurally gone because key issuance happens from inside the card / a single unified "Add a peer" name field.
  • Each card carries: issue/revoke the inbound key in place, inline edit of the send + receive allow-lists (PATCH, #176), a per-peer pause toggle (#176 enabled flag, fail-closed on both planes), test-connection, and remove.
  • Orphan inbound keys (a key issued with no matching outbound peer) surface as their own card with the existing warning.
  • Backend was v0.6.20 (#176).

Deployed to both dogfoods and confirmed live:

  • cairn-enc (IdP-managed, .249) — Running, image digest sha256:f9ac682f… (the published v0.6.21).
  • cairn-openbao (app-owned, .247) — Running, same digest.

Both rolled cleanly with no restarts. Visual click-through on files.c0rdyceps.ch is the remaining human step (the redeploy logged all sessions out — in-memory sessions — and I can't log in myself). Closing on shipped + deployed + digest-confirmed; reopen if the card behaves unexpectedly in the browser.

Shipped in **v0.6.21** (PR #232, squash-merged; CI green in 40s). The peering admin panel is now one relationship card per peer: - The two separate lists ("keys you issued" / "instances you can send to") are collapsed into a single card per peer name, joining the inbound key we issued them (id hint) with the outbound side (URL + send/receive allow-lists). The two halves can no longer drift apart — the #145 name-coupling is structurally gone because key issuance happens from inside the card / a single unified "Add a peer" name field. - Each card carries: issue/revoke the inbound key in place, inline edit of the send + receive allow-lists (PATCH, #176), a per-peer pause toggle (#176 `enabled` flag, fail-closed on both planes), test-connection, and remove. - Orphan inbound keys (a key issued with no matching outbound peer) surface as their own card with the existing warning. - Backend was v0.6.20 (#176). Deployed to both dogfoods and confirmed live: - `cairn-enc` (IdP-managed, .249) — Running, image digest `sha256:f9ac682f…` (the published v0.6.21). - `cairn-openbao` (app-owned, .247) — Running, same digest. Both rolled cleanly with no restarts. Visual click-through on files.c0rdyceps.ch is the remaining human step (the redeploy logged all sessions out — in-memory sessions — and I can't log in myself). Closing on shipped + deployed + digest-confirmed; reopen if the card behaves unexpectedly in the browser.
Sign in to join this conversation.
No labels
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Cordy/Cairn#150
No description provided.