build: freenet-stdlib 0.6→0.8 upgrade + delegate/room-contract migration

[sanity]

⚠️ WIP DOGFOOD — DO NOT MERGE

This branch dogfoods the freenet-stdlib 0.6.0 → 0.8.2 upgrade to prove that room + delegate data survives before we ever touch the shared production River contract (raAqMhMG7KUpXBU2SxgCQ3Vh4PYjttxdSWd9ftV7RLv). It is not for merge as-is: it pins stdlib via a [patch.crates-io] to a local checkout (so CI will fail to resolve deps — expected), and the full browser delegate round-trip was not executed live in this pass.

What changed

1. stdlib 0.6.0 → 0.8.2 (workspace Cargo.toml), patched to the local freenet-stdlib checkout until the leak-fix 0.8.3 is published to crates.io. The leak fix is WebApi(browser-client)-only and does not affect the contract/delegate WASM bytes this upgrade re-keys, so the patched 0.8.2 is byte-equivalent to what we'll ship on for the migration surface.

2. Fixed the one real 0.8 API break (DEFAULT_CIPHER/DEFAULT_NONCE) in ui/src/components/app/chat_delegate.rs. stdlib 0.8 removed these constants — they were a world-known XChaCha20 key + nonce. Replaced with a random 32-byte cipher + 24-byte nonce generated once per install and persisted in localStorage.

   • Key finding: a node built against stdlib-0.8 core (freenet-core #4140/#4143) ignores the client-supplied cipher/nonce entirely — register_delegate derives a per-delegate DEK from the node's own KEK via HKDF, and decrypts pre-0.8 secrets (written under the old world-known cipher) via a built-in LEGACY_DEFAULT_CIPHER fallback (decrypt_secret_blob Tier-3). So old-secret decrypt/re-encrypt is the node's job, not River's. Persisting a per-install random value is the correct, forward-compatible choice: harmless on 0.8 nodes (discarded), and a per-install secret (not world-known) on any older node that still honors it.

3. Registered the last stdlib-0.6 generation so the 0.8 build migrates from it:

   • legacy_delegates.toml V25 = 8bb5d06f… (delegate_key 3e0e0737…)
   • common/legacy_room_contracts.toml V25 = 58a5e73c…

4. Rebuilt room-contract + chat-delegate WASM against 0.8 (re-keys):

   Artifact	OLD 0.6 code_hash	NEW 0.8 code_hash
   room_contract.wasm	58a5e73c…e47c50	18227bb6…a7b151
   chat_delegate.wasm	8bb5d06f…51cc8d	f4cea6bf…cf24b48
   delegate_key	3e0e0737…10eda80	da2ce32f…bc65eb61

Migration wiring decision

River's bespoke probe machinery (fire_legacy_migration_request + the #292 room backward-probe in common/src/migration.rs) is kept as-is. freenet-migrate 0.1.0 is pure/synchronous and has no WebSocket-driver equivalent for River's app-side probe loop, so a full crate swap is out of scope this pass. The requirement met here is correctness: the 0.6 legacy hashes are registered so the existing (24-prior-bumps-proven) probe machinery carries data forward. freenet-migrate's clean-fit surface (build-time codegen + hash-guard + key derivation) is byte-identical to River's derivation (proven by the crate's own codegen_stdlib_consistency test + River delegating to stdlib's ContractKey::from_params), and is a good candidate for a later, separate adoption PR.

Verified

• ✅ River builds against 0.8: room-contract + chat-delegate WASM (--locked, reproducible), river-ui compiles (cargo check, wasm target).
• ✅ Migration registry tests pass (migration_test + room_contract_migration_test, 4+4), validating the V25 entries and delegate_key == BLAKE3(code_hash).
• ✅ Delegate/contract ABI is 0.6↔0.8 compatible (the make-or-break): the OLD 0.6 delegate WASM imports the exact same host functions with byte-identical type signatures as 0.8 (get_secret/set_secret/remove_secret/get_secret_len/logger.info); the room-contract imports match too. So the installed 0.8.2 node can execute the 0.6 WASMs — the migration's core requirement holds.
• ✅ freenet-migrate 0.1.0 test suite green against local stdlib 0.8.2.

NOT verified live (yet)

• The full browser delegate-migration round-trip (create room+message+DM+signing-key under the 0.6 UI, then load the 0.8 UI and confirm the room list / per-room signing keys / DM history migrate forward). Delegate migration is browser-only; this is the one remaining live gap.
• The pre-0.8-node → node-upgraded-to-0.8 cross-version secret path (old secrets written under the real world-known cipher, then node upgraded). A fresh local 0.8 node writes secrets under derived DEKs, so it does not reproduce this.

Live riverctl-driven room-contract migration test against a real 0.8 node is running separately; result to follow in a comment.

🤖 Generated with Claude Code

[AI-assisted - Claude]

[sanity]

Live verification: room-contract migration 0.6→0.8 WORKS on a real 0.8.2 node

Ran a riverctl-driven room-contract migration against an isolated freenet local 0.8.2 node (OLD riverctl built from origin/main @ 74862fd8, stdlib 0.6.1; NEW riverctl from this branch, patched stdlib 0.8.2). Both WASM b3sums matched the registered hashes (OLD 58a5e73c…, NEW 18227bb6…).

Keys derived (base58):

• Owner VK / room id: HtxpCJFU3ZSU7PYDHQLG5DoCjApnfEm6YwN8qyjaUQnE
• OLD 0.6 contract key: FhoNSwKH3PTJqC9g7FH1PzZGK9tPjeBJjt71jgVYQ2n1
• NEW 0.8 contract key: 6kzKtterGwcf3KND4sS22uADynrKiyBWwctBBoqRiMbb (distinct — confirms re-key)

What was proven:

1. The 0.8 node runs the 0.6 contract WASM — room create (PUT), message send, message list all succeeded under the OLD key (message list returned hello-from-old-0.6-contract). Confirms the ABI compat established statically.
2. Identity/room import can't recover a room several contract-WASM generations behind (restores stale "old IDs") #292 backward-probe recovery + forward-migration works. A fresh client (empty config, knows only the owner key) logged:

   Room not present on current contract 6kzKtterGwcf…; probing 25 previous contract generation(s)
   Recovered room from a previous contract generation (probe 1/25)
   Migrated recovered room forward onto current contract 6kzKtterGwcf…
   STDOUT: [alice]: hello-from-old-0.6-contract
   

   Probe 1/25 = registry entry V25 = the OLD 0.6 hash added in this PR.
3. Migration persisted — a second fresh client read the message directly on the NEW key with no probe; independent fdev (0.8.2) execute get showed byte-identical state (1190 bytes, b3sum e318306b…) under both old and new keys, message bytes visible in the CBOR.

Bug found (pre-existing on main, NOT a regression): the in-place upgrade path (ensure_room_migrated, cli/src/api.rs:2039) aborts fatally with missing contract on an isolated node before recovery runs, because the "contract absent → migrate" logic is only in the timeout branch, not the prompt-error arm. Filed as #395. Its production severity depends on networked timeout-vs-prompt-error behavior (untested). Once the new contract exists on the node (via any fresh-client recovery or room republish), the in-place path works.

Still NOT verified live: the browser delegate migration round-trip (room list / per-room signing keys / DM history) — delegate migration is browser-only; riverctl doesn't touch the chat delegate. The delegate side is verified at the static level (ABI import/signature parity 0.6↔0.8, V25 compiled into LEGACY_DELEGATES, unchanged probe mechanism from 24 prior bumps).

[AI-assisted - Claude]

[sanity]

Blocker 1 resolved: chat-delegate cipher stability in the sandboxed gateway iframe

The bug

In production River runs inside the gateway iframe with an opaque origin, so window.localStorage throws SecurityError. Both load_persisted_cipher_material() and persist_cipher_material() (ui/src/components/app/chat_delegate.rs) then silently no-op, so chat_delegate_cipher_material() generated a fresh random cipher/nonce on every set_up_chat_delegate() — which fires on every reconnect and every sleep/wake — rotating the client-supplied delegate cipher within a single page.

The fix

Added a process-memory fallback (IN_MEMORY_CIPHER_MATERIAL, a thread_local! — wasm is single-threaded, so effectively process-global): when localStorage is unavailable the cipher/nonce is generated once and stays stable for the page lifetime. Order is unchanged where storage works (try localStorage first, write-through when available), so a normal top-level origin keeps cross-reload stability; only the storage-denied iframe path changes, from per-call rotation to page-stable. Pinned by cipher_material_is_stable_within_process.

Pre-0.8 reachability assessment (the safety justification)

On stdlib-0.8 nodes the node ignores the client-supplied cipher/nonce and derives a per-delegate DEK from its own KEK (freenet-core docs/secrets-at-rest.md; wasm_runtime/secrets_store/store.rs), so cipher rotation is harmless across the whole 0.8 fleet. The only place the client cipher still matters is a pre-0.8 node that honors it.

I checked whether a stdlib-0.8 River client can even reach such a node. It can — the residual is not gated out by wire incompatibility:

• No protocol-version handshake. The node selects only an encoding (EncodingProtocol Native/bincode vs Flatbuffers; River pins ?encodingProtocol=native) in freenet-core .../client_events/websocket.rs; it never rejects a client by stdlib version.
• RegisterDelegate bincode layout is byte-identical from stdlib v0.1.22 → 0.8.3: ClientRequest/DelegateRequest/HostResponse variant ordering unchanged, and RegisterDelegate { delegate, cipher, nonce } fields/order unchanged. The flatbuffer schema for it is also unchanged. The only 0.6→0.8 bincode break (NodeDiagnosticsResponse.contract_states map-key type, stdlib 0.7.0) is an unrelated HostResponse::QueryResponse variant never exercised by the delegate-register exchange.

So the pre-0.8 cipher-honoring case is reachable at the protocol level. What makes it unlikely in practice: a cipher-honoring node is freenet-core ≲ 0.2.58 (stdlib pre-0.8, ~April 2026, before #4143/#4144); every release from ~0.2.60 ignores the client cipher, and the live network runs ~0.2.9x with auto-update. Such an ancient non-updated peer almost certainly no longer exists, but I can't prove from code that none do.

Honest scope of the fix: it removes the within-page (reconnect / sleep-wake) rotation, which was the actual regression. In the iframe it does not make the material stable across a full page reload (localStorage still no-ops there), so for a hypothetical pre-0.8 honoring node it reduces rather than fully eliminates the theoretical cross-reload brick. On the entire 0.8 fleet this is moot (client cipher ignored).

WASM unchanged (migration verification still holds)

The cipher code compiles into river-ui, not the delegate WASM. cargo make sync-wasm reproduces byte-identical artifacts:

• chat_delegate.wasm = d91e33fc… (delegate_key b61dc292… = BLAKE3(BLAKE3(wasm)))
• room_contract.wasm = 74f3dff1… (ui/ and cli/ in sync)

check-migration / check-room-contract-migration confirm no migration entry is needed.

Also in this change

• Corrected the two legacy-migration TOML descriptions: 0.6.0 -> 0.8.2 → 0.8.3 (matching the actual pin).
• Bumped riverctl 0.1.73 → 0.1.74 so check-wasm-sync passes (the 0.6→0.8 bump changed room_contract.wasm, and that check requires the CLI version to differ from the crates.io-published one).

[AI-assisted - Claude]

[sanity]

Full-tier review complete — GO for republish

Reproducible canonical build. room 74f3dff1 / delegate d91e33fc / delegate_key b61dc292, built twice byte-identical.

Both migrations re-verified against the real shippable keys on an isolated 0.8 node:

• Room migration (backward-probe → new key): recovered message byte-identical.
• Delegate migration: room list, per-room signing keys, private-room secret, old messages, and rooms_meta all carried across; 10→10 secrets; zero #204/deserialize errors; data confirmed on the real b61dc292 namespace.

External Codex + adversarial cipher-security review: clean. The one finding (cipher rotation in the sandboxed gateway iframe) is fixed via a thread_local page-stable in-memory fallback plus an honest doc note. Documented residual: a pre-~0.2.58 cipher-honoring node, effectively unreachable on the 0.2.9x fleet.

Legacy-registry audit complete. V25 anchors the last live 0.6 generation; no missing live generation.

CI green on ed54ec7d (build, check-wasm-sync, check-delegate-migration, check-room-contract-migration, ui-playwright-tests all SUCCESS).

Scope notes. Orthogonal pre-existing bug #395 (riverctl in-place upgrade) does not affect fresh-client recovery. Republish is a deliberate, in-the-loop operation: it re-keys the shared contract, old invite URLs die, and the Official room is recreated.

[AI-assisted - Claude]