feat(ui): carry private-room secrets in the invitation

[sanity]

Problem

For River private rooms, a newly-invited member can become a member offline (the invitation pre-signs their AuthorizedMember, the contract is permissionless) but cannot read the room until an owner-signed AuthorizedEncryptedSecretForMember blob appears in the contract's encrypted_secrets. Only the room owner's signing key can mint that blob, so the owner's chat-delegate (or owner's open UI) must come online after the join to back-fill it. If it never does, the invitee is stuck on [Encrypted message - secret vN not available] (Bug #6 / #276, Ivvor 2026-05-17).

This also breaks for non-owner member invites: any member can invite (the invitation chain), and the inviting member holds the room secret — but cannot mint an owner-signed blob.

Approach

Embed the room's symmetric secrets directly in the Invitation artifact (Invitation::room_secrets). The inviting member — owner or not — already holds the secrets; the invitee seeds them into RoomData on accept and can decrypt the room (and seal their own nickname for the join PUT) immediately, with zero realtime involvement from the owner's delegate.

The room contract and chat-delegate are untouched — encrypted_secrets stays owner-only and its owner-delegate back-fill becomes pure eventual-consistency durability. This is a UI-only change: no contract/delegate WASM change, no migration entry.

Plaintext, not ECIES-wrapped — a deliberate change from the originally-planned ECIES wrapping. The invitation already carries invitee_signing_key in the clear, so the whole artifact is a bearer credential; ECIES-wrapping the secret to the invitee's key adds no confidentiality (the decryption key sits in the same blob). Plaintext also avoids decrypting attacker-influenced ciphertext on the join path: river_core::ecies::decrypt panics on a malformed blob, and the release profile is panic = "abort", so a malformed invitation would abort the whole UI. Making that path fallible would require changing common/ (→ delegate WASM change → migration), which this PR specifically avoids.

Persistence: a new #[serde(default)] RoomData::invitation_secrets field rides inside the existing rooms_data delegate blob, so the secret survives a page refresh (RoomData::secrets itself is #[serde(skip)]). repopulate_secrets_from_state folds it into the in-memory secrets map on every ingestion. A contract encrypted_secrets blob is authoritative and wins on version collision. Plaintext-on-disk is consistent with the existing self_sk / self_nickname already in the persisted RoomData.

Prune safety needs no contract change: the invitee's join PUT carries a join_event they authored, so post_apply_cleanup keeps them as a message-author regardless of any encrypted_secrets blob.

Security note

Embedding the secret means an interceptor of the invitation link can passively decrypt the room without joining. This is a change in degree only — the invitation already carries a full signing key, so it was always a bearer credential. Mitigation is unchanged: treat invitations as single-use, short-lived, delivered over a secure channel.

Out of scope

riverctl is not modified. CBOR's tolerance of a missing #[serde(default)] field keeps old/new invitations interoperable without touching cli/. The CLI cannot decrypt private rooms at all today; full CLI private-room support is a separate follow-up.

Testing

cargo test -p river-ui --bins — 229 pass, including 9 new tests:

• Invitation CBOR round-trip preserves room_secrets; deterministic encoding; legacy (pre-field) invitation decodes to empty (backward compat).
• collect_invitation_secrets sorted / empty.
• repopulate_secrets_from_state folds invitation_secrets; contract blob wins on collision.
• seal_invitee_nickname seals from the invitation secret as fallback; returns None (defers member_info) when no secret is available.

cargo clippy -p river-ui --target wasm32-unknown-unknown --features no-sync — clean (pre-existing warnings only, none in changed files). cargo fmt applied.

Recommended pre-merge manual check (not yet run): the AGENTS.md Playwright-MCP flow — a non-owner member invites someone while the owner's node is stopped; the invitee should see decrypted history immediately and survive a refresh.

[AI-assisted - Claude]

[sanity]

Comprehensive PR Review: #301 — re-review after fixes

Summary

• PR Title: feat(ui): carry private-room secrets in the invitation
• Type: feat
• CI Status: check-delegate-migration ✅, check-room-contract-migration ✅, license/cla ✅; build + ui-playwright-tests pending at review time
• Linked Issues: addresses Bug #6 / PR #276 (no Closes #)
• Review tier: Full — touches cryptography / secret handling, wire format (Invitation CBOR), and persistence (RoomData delegate blob)
• Reviewers run: Round 1 (HEAD 7a057add) — code-first, testing, skeptical, big-picture + Codex (gpt-5.5). Round 2 re-review (HEAD 67d016d8, after blocking fixes) — skeptical + Codex; the code-first / testing / big-picture findings were doc/test items, verified resolved by direct diff inspection.

---

Code-First Analysis

Alignment: matches. The end-to-end path is complete and verified — inviter (invite_member_modal.rs, invite_via_dm_picker_modal.rs) → Invitation::room_secrets → PendingRoomJoin → get_response.rs pending-invite branch → RoomData::invitation_secrets → repopulate_secrets_from_state fold → in-memory secrets. Non-owner-issued invitations are handled (reads room_data.secrets, which any member holds). No discrepancy between code and the PR description.

Testing Assessment

Coverage: adequate. 235 river-ui unit tests pass (15 new across the two commits).

Test Type	Status	Notes
Unit	✅	Invitation CBOR round-trip + deterministic encoding + legacy-decode; collect_invitation_secrets; the H2 cross-call regression; RoomData minimal-legacy-blob decode + refresh serde round-trip; seal_invitee_nickname (fallback / version-mismatch / contract-precedence); seal_invitee_nickname call-site source-grep pin
Integration	N/A	UI-only change
E2E	⚠️	The owner-offline non-owner-invite scenario is not in cargo test; recommended as a Playwright-MCP manual check before merge

Skeptical Findings

Round 1 found two blocking issues; both independently corroborated and now fixed:

Concern	Severity	Status
H1 — app.rs:197 info!("{:?}", invitation) leaked plaintext room_secrets to the browser console (derived Debug for [u8;32] is transparent; SigningKey's own Debug is not, so this was a new leak)	High	Resolved — hand-written redacting Debug for Invitation (members.rs) and PendingRoomJoin (invites.rs); round-2 skeptical confirmed no remaining transparent {:?} sink
H2 — cross-call ordering: a stale/garbage invitation secret folded before the owner's encrypted_secrets back-fill permanently shadowed the authentic blob (the !contains_key filter skipped re-decrypting it)	High	Resolved — the contract-blob loop in repopulate_secrets_from_state now always decrypts and overwrites (owner-signed secret is authoritative) and prunes the superseded invitation_secrets entry; regression test added; round-2 skeptical traced the multi-call sequence and confirmed correctness

Round-2 re-review found no new blocking findings. Borrow/ownership in the new loop, the version filter (<= current_version, no off-by-one), and seal_invitee_nickname precedence were all verified safe.

Big Picture Assessment

Goal alignment: yes. Diff is tightly scoped (UI-only; every non-core line is a mandatory struct-literal update). No removed tests/code, no anti-patterns. Migration claim verified — no common/, delegates/, contracts/, or Cargo.{toml,lock} changes; check-delegate-migration and check-room-contract-migration both green. AGENTS.md staleness (the Invitation-in-common/ line, the Private Room Support section, the #251 note) was corrected in the fix commit.

Documentation

• Code docs: complete — new public items documented; repopulate_secrets_from_state doc-comment updated for the fold.
• Architecture docs: AGENTS.md updated (Private Room Support, #251 note, common/ types list).

---

Recommendations

Must Fix (Blocking)

None outstanding — H1 and H2 resolved and re-verified.

Should Fix (Important)

None outstanding.

Consider (non-blocking)

1. CLI invitation mirror (known, out of scope). Codex re-flagged that cli/src/api.rs's separate Invitation struct was not given room_secrets. This is deliberate and documented in the PR's "Out of scope" section: the CLI cannot decrypt private rooms at all today (it seals nicknames as SealedBytes::public), so a CLI invitee of a private room already gets degraded behavior; the wire format stays compatible via CBOR #[serde(default)]. Full CLI private-room support is a separate feature — recommend a follow-up issue rather than expanding this PR.
2. localStorage carries the plaintext invitation (skeptical, informational). save_invitation_to_storage persists the whole Invitation (now with room_secrets) to localStorage. Not a new exposure class — the invitation already carries invitee_signing_key (a private key) in cleartext, so localStorage already held a full bearer credential. Consistent with the PR's stated threat model.
3. E2E verification before merge — run the Playwright-MCP flow: a non-owner member invites someone with the owner's node stopped; the invitee should see decrypted history immediately and survive a refresh.

---

Verdict

State: Ready to Merge — pending build + ui-playwright-tests going green on the current HEAD.
HEAD SHA reviewed: 67d016d8c75aff7629cffce253e92e32e78d6f01

Re-review after fixes for round-1 findings H1 and H2 — both resolved and confirmed by an independent round-2 adversarial pass (skeptical reviewer + Codex). No new blocking findings. The remaining items are a documented out-of-scope CLI follow-up and a recommended manual E2E check.

[AI-assisted - Claude]