[sanity]

Problem

The unified mail delegate (#364) holds identities, contacts and local state behind an origin-scoped, per-item compare-and-swap protocol, and does signing and decryption itself. The UI still talks to the two v0.2.x delegates (identity-management, mail-local-state), keeps identity seeds in page memory, and relies on a permission-overlay pump and empty-response acks.

Approach

Switch the UI to the unified delegate in layers, each compiling and tested:

1. Release freeze (30066eb). The migration from the v0.2.x delegates lands in the next PR of this chain, so .release-freeze makes scripts/release.sh refuse to run until it does; scripts/release-freeze_test.sh (in CI) shows the refusal.

2. Client (7b0cba3, ui/src/mail_delegate/).

   • Request ids are random, and each call waits for the one response carrying its id. A call with no answer is Unknown, never "absent".
   • Two backends:
     • The node. It registers the candidate delegate once per page load with the pinned v0.2 cipher/nonce, then sends.
     • Offline. The delegate's own code runs in the page over an in-memory store, so offline tests exercise the real protocol rules.

3. Typed operations (d1c1ae2, mail_delegate::ops).

   • Identities: create/import/update/confirm, plus paged delete, which repeats on Continue without asking again.
   • Items: paging, and a read-merge-write that retries a lost compare-and-swap.
   • v1 crypto: decrypt, seal, authority and removal signing (hashes ascending), and the v1 AFT parameters.
   • Exports, and grant revocation.

   Tests pin interop with the UI's own v1 crypto both ways: the delegate decrypts what the v0.2 client encrypts, and the v0.2 client opens and verifies what the delegate seals.

4. Contacts (9c8767a, 2f712d2, 2f99f82, 0deea6d, ui/src/app/contact_store.rs). Loading runs in a root-scoped task; a scoped spawn panicked inside node_comms. Each loaded contact's inbox is primed (Cross-node send fails silently with 'missing contract parameters'; UI shows 'Sent' #191), as the reload path did before.

   • One Contact item per contact, keyed by address.
   • The address book updates immediately, and writes persist from a spawn_forever task; a refused or unanswered write shows a toast.
   • Contacts load at startup.

5. Revoke export permission (a5b461b). Settings → Backup & restore gets "Remembered export permission", which sends RevokeExportGrant.

   • Fixes toasts pushed from detached tasks: push_toast uses use_context, so from a spawn_forever task it panicked silently. push_toast_detached uses the root's queue.
   • ui/tests/export-permission.spec.ts runs it against the in-page delegate; it failed before the fix.

6. Identities and crypto in the delegate (0ffc1fe). The page holds no private key.

   • Sending seals once in the delegate; the assignment hash is taken from that same ciphertext, which is the one stored.
   • Inbox states are decrypted by the delegate in a task (never in node_comms, which delivers the delegate's answers). Whole-state updates keep what is already decrypted; a removal that lands mid-decryption wins.
   • Removals (ascending hashes), settings changes, and new, self-healed or migrated inbox states are signed by the delegate. A migrated inbox advertising another encryption key is no longer re-signed (the delegate signs only with its own key); it is reported instead.
   • Delegate work that the node loop needs (listing identities, migration markers, token-generator parameters, initial inbox state) runs in tasks that hand results back as NodeActions (app/identity_store.rs).
   • Migration markers (Deliberate inbox/AFT WASM bump → per-identity state migration (future) #213/Inbox migration: improvements for robustness #251) live in each identity's IdentitySettings item; the loader records them before any migration GET is dispatched.

7. Identity lifecycle (0ffc1fe, 27857d7).

   • Create: the delegate creates the identity and returns its recovery key once (Reply::CreatedIdentity, golden line appended, guard mutation in check-guards-fail.sh; the delegate test checks both halves of the returned key), so sign-up keeps its backup step. Discarding at that step deletes the identity (the delegate asks).
   • Restore (key or JSON) is ImportIdentity{UserRestore}; rename is UpdateIdentity; delete loops on Continue.
   • Backup modal and Settings reveal the key through the consented ExportRecoveryKey (ExportedKeyPanel); the key lives only in that panel's resource.
   • Offline builds seed the example identities in the in-page delegate.

8. Local state as items (2c16e6e, ui/src/local_state/items.rs). Drafts, sent, kept and archived messages, read/deleted marks and settings are items owned by the identity's address; the v0.2.x local-state delegate is no longer used.

   • Received-message ids are blake3(ciphertext)[..16], so marks stay on the right message across reloads and reordering. Drafts and sent use their UUID bytes.
   • Deviation: the UI keeps a u64 message id rather than widening it across ~20 call sites: the first 8 bytes of the 16-byte item id, top bit cleared (local_state::RECEIVED_ID_LIMIT; the top half is reserved for folded own-Sent rows). Two of one identity's n messages share a UI id with probability about n²/2^64 (~5×10⁻¹² at 10,000 messages); writes use the full 16 bytes. Ids carry no time: nothing orders on them.
   • Each write returns on the delegate's acknowledgement. The WriteTracker count and the old delegate's empty-response-as-ack handling are gone; "Deleting…" / "Archiving…" resolve on the write's own answer, and the write is never raced against a timer (dropping it could leave a multi-step write half done).
   • Settings merge field by field, nested, over compare-and-swap, so two tabs changing different settings keep both.
   • Local state loads after the identities are announced, outside the node loop, and is merged into what the page already holds (see 12); delivery-state writes triggered from the node loop run detached (awaiting the delegate there would deadlock).

9. Removals (fec6fec). The permission pump that answered the node's own permission prompts, its policy helpers, the pending-recipient tracking it read, and the Settings card that edited saved decisions. The node asks the user now; the stored fields stay decodable but nothing acts on them.

10. Deletion progress and detached toasts (1dd39a8). Deleting a large identity shows "Deleting identity x… N items left", updated per page. Toasts pushed from detached tasks (local-state write failures, identity loading, migration landed, delete failure) go to the app root's queue instead of use_context, which panics outside a component.

11. e2e step 3 (0551137). Proves the mail delegate ran on the node from the node's own log: the first-run "Module cache miss — compiling" line naming the committed candidate's code hash. (A UI log::info line goes to the browser console only, never the gateway log.)

12. Startup load, id partition, storybook (ba8092c). Three regressions from 8 and 6:

    • Persistence layer: sent/deleted messages don't survive refresh or session #286 (live node: an identity's row vanished after it was created). The startup load listed the identities, then loaded their local state (one delegate round trip per item) before announcing them, and the announcement replaced the identity list wholesale, dropping one created in between. Identities are now announced first and upserted; local state loads afterwards and is merged: only the identities the load read are replaced, and global settings only if nothing in the page changed them since the load began.
    • Reply fails when recipient added sender under a different local nickname #289 (live node: "Add to address book" never shown). Hash ids sat above SENT_FOLD_ID_BASE (1 << 48), so every received message passed for a folded own-Sent row. Received ids now have the top bit cleared and folded rows use the top half. An audit of the other id uses found every ordering is by time (one stale "newest root_id" comment fixed).
    • Offline storybook. The storybook host builds a second User, whose example identities the in-page delegate already held; the second create was refused as a conflict and the expect panicked before the story rendered. Existing example identities are reused.

13. Offline deletion and CI coverage (fb78336). The offline build deleted an identity from page memory only, so the in-page delegate kept it. Both builds now delete through one loop (identity_store::delete_with_progress). cargo make test also runs the UI's library tests in the offline build, which CI never did, so the in-page delegate's tests (mail_delegate::local) now run there.

14. Review round 1 hardening (1dda377..8f39920):

    • Releases: every production publish path (release.sh, publish-email, publish-container, publish-production) runs scripts/check-release-freeze.sh first. The freeze test never runs a release.
    • Archive: the inbox removal waits for the archived copy's acknowledgement.
    • Key material: loading fetches none. Token-generator delegates are registered at first use. Recovery keys and restored seeds are held in wiped memory, and restore input is size-capped.
    • Correctness: rename takes the delegate's ack, decryption retries entries past the reply budget, consented calls outwait the delegate's prompt, and unreadable migration markers are never overwritten.
    • Concurrency: a failed or cancelled delegate registration is retried, a racing write never undoes a delete, read marks are sent once, and an early delivery state is kept. A deleted identity's cached state doesn't pass to a new identity under the same alias.

Status: in review

Transitional exposure until step C: V1AftParams returns the v1 token-generator delegate's parameters, which carry the identity's ML-DSA signing seed, to code running in the Mail page. The page now asks for them only on the send path. The buffer the delegate returns is zeroized, but decoding it into stdlib DelegateParameters/Parameters and handing it to the node's client API makes plain copies that live across the send path's awaits and are freed, not wiped. Consent does not cover this op. Step C removes it, together with the anti-flood tokens, before any release, and the release freeze stops a publish before then.

Review round 1 is fully addressed. The last items:

• Startup merge: every change to the local-state snapshot goes through one apply, and while a load runs it is journaled; the load is applied under the journal. A draft saved meanwhile stays, a Sent row deleted meanwhile stays deleted, a settings change keeps the fields it changed, and a deleted or renamed identity is not brought back.
• Interrupted deletion: Op::ListDeletingIdentities (appended) lists identities whose approved deletion has not finished; Your identities offers "Finish deleting", which does not ask again. A deletion that may be partly done says so ("may be incomplete; it will finish when you retry") instead of "was not deleted", and a restore of such an identity says to finish the deletion first.
• Offline coverage: the in-page delegate runs with v1-transition, and the local-state writes and load are tested against it. The UI's call sites still persist only in node builds (the offline store lives for one page and its example messages are not delegate items).
• Hardening: a dropped call's waiter is removed and a reply with no waiter is not decoded; local-delegate with use-node is a compile error.
• Not changed: the local-state cache stays keyed by alias. Re-keying it by address would change the frozen wire-v1 LocalState shape and about 20 accessors; delete and rename already move or drop the cached state, and the startup merge now honours both.
• No change needed, now tested: an identity created but never confirmed (the tab closed in between) has its inbox and AFT record re-published by the existing own-contract self-heal on the next load (First send to a recipient hangs recipient node, all contract GETs fail #288): the node answers the load's GETs NotFound and the own-contract arms re-PUT them. A live-node test reloads at the reveal step and checks this (round 5). Its token-generator delegate is registered on first send, and Settings shows the "not backed up" banner until its key is saved.

Deferred to B3: the confirm-identity prompt for unconfirmed identities before send/publish (ops::confirm_identity is ready; only the migration produces unconfirmed identities).

Deferred to C: the AFT token-generator delegate's registration handling (token_generator_management and the v0.2.x identity-creation plumbing it drives). The node's empty answer to its RegisterDelegate is a real answer, and it all goes with the anti-flood tokens.

Review round 2 fixes (9c59c89..778c689):

• Identity-scoped local state, item owners and the early-delivery stash are keyed by the identity's address, not its alias. Writes after a rename persist, and finishing an old identity's deletion never touches a new identity with the same alias. Rename no longer moves state.
• A contact is persisted only after the address book accepts it. Stored contacts whose aliases clash, with each other or with your identity, all load as alias~<address prefix> with a warning.
• An archive's inbox removal targets the inbox it was made in, even if you switch identity while the archive is being confirmed.
• Decryptions from a superseded inbox state are dropped, in-flight decryptions are not repeated, and per-message failure codes are kept: unreadable messages are not asked for again, and a failed call is retried with backoff.
• Journaling starts before identities are announced, so changes made while unfinished deletions are listed are replayed.
• A late autosave or read mark never recreates a discarded draft or a deleted message's kept copy. This uses the page's discard tombstone and the stored deleted flag (the flag covers read marks in other tabs; drafts across tabs are covered in round 3). Delegate tombstones were not added, because they need their own pruning index.
• An identity-index entry left by a half-finished deletion is pruned when deletions are listed and before a new identity is stored.
• "Finish deleting" runs one attempt at a time. (Read-mark retries are reworked in round 3.)
• push_toast from a spawn_forever task (Dioxus root scope) falls back to the root queue instead of asserting.
• An unanswered prompt: the node's empty answer at its 60 s timeout already ends the waiting call. It is now reported as unanswered rather than declined.

Review round 3 fixes (778c689..4790208), each with a test shown failing without it:

• A draft discarded or sent in another tab is not brought back by this page's autosave (a sent draft could otherwise reappear and be sent twice). The page remembers the drafts it has seen stored; a save that finds one missing writes nothing, and the compose sheet stops autosaving and says so.
• A read mark is never re-sent by renders. The read-mark task retries a transient failure (no answer, busy, conflict) up to 3 times with backoff; a failure that remains is reported once.
• An identity arriving after a stored contact with the same alias moves the contact to its clash label instead of overwriting it, whichever loads first. The suggested-alias fallback no longer resolves an ambiguous alias (a relabelled contact, or two contacts suggesting one name).
• "Finish deleting" re-renders when a deletion starts or ends: its state is a signal.
• A failed prune of recordless identity-index entries no longer fails ListDeletingIdentities; the prune runs again on the next listing. Delegate change: guard mutation added, candidate rebuilt.
• Tests that were missing or vacuous: forgetting a deleted identity is asserted on its address key; the startup journal order (announce_then_merge); the archive removal target through store_then with an identity switch mid-wait (DeferredRemoval::pick, which also turns an unloaded inbox into an error rather than a panic); and a live-node test that a renamed identity's draft and settings persist across reload (R10).

Review round 4 fixes (4790208..1af39c9), each with a test shown failing without it:

• An archive's or delete's inbox removal finds the inbox by the identity that owns it, as the folder view does, never by its position in the inbox list (which is the order inbox states arrived). With two or more identities the old lookup could pick another identity's inbox, match nothing there, and leave the message in its own inbox. The tests list inboxes in arrival order with the other identity's first.
• A draft records the address of the recipient chosen for it (since round 5, the recipient's identity address rather than their inbox contract id), and is sent to that address only. If the To field has since come to name a different key (an identity created later under a contact's name) or the recorded recipient was removed, the send is refused with a message and the user chooses again. A draft from older data without a recorded address is resolved once when opened; an ambiguous name asks the user.
• Before sending, a draft this page saw stored is checked against the delegate: if another tab sent or discarded it, the send is refused, so it cannot be sent twice. The banner no longer offers to send it from here.
• Relabelled contacts are tracked explicitly, not recognised by a ~ in the label (a contact named bob~work is an ordinary contact); a clash label never overwrites an entry that already holds it; forgetting an identity forgets its seen drafts and recorded recipients.
• The live-node rename test waits for the sheet's data-autosave="saved" (set once the delegate acknowledges what is on screen) instead of sleeping.

Review round 5 fixes (1af39c9..9ea757f), each with a test shown failing without it:

• One send at a time per compose sheet. Send checks the draft with the delegate first, and a second click during that round trip could send the message twice. The first click claims the send; the button is disabled and reads "Sending…" until it settles. Two tabs sending the same draft within a couple of round trips can still both pass the check; that window is documented at the check, with claim-before-send (a compare-and-swap delete, undone if the send fails) as the way to close it.
• Typed or picked names are never refused as ambiguous. The refusal applied to fresh typing and autocomplete picks, so a name could become impossible to send to (your identity that took a contact's name; a new contact reusing a name two contacts had clashed on). They now resolve to the entry that holds the name. Only a reopened draft with no recorded address whose name has become ambiguous starts unresolved, and sending it asks the user to choose.
• Drafts record the recipient's key, not their inbox contract. The inbox contract id depends on the inbox contract's code, so a new inbox generation (step C) would have refused every saved draft. A draft now records the recipient's identity address (fmail-addr: + address_of(vk)), and the inbox is resolved from the key at send time. "No longer in your address book" and "couldn't work out who this was addressed to" are told apart.
• Messages are removed by id without assuming the list is sorted. A single removal binary-searched a list kept in arrival order with hash ids, so most archives and deletes left the row in the model. Audited the other ordering assumptions in ui/src: thread groups sort by time first, delegate paging reads a sorted index, and the removal payload is sorted on purpose.
• An identity whose deletion began leaves the page. After a deletion that failed past its first page, the delegate hides and refuses the identity; both builds now drop it from the page (by address, signing it out if open) when it is listed as unfinished, so only "Finish deleting" remains and nothing is left after finishing.
• Clash labels can't land on another stored contact's name, an identity's name or a label already given out (a contact was silently dropped on insert). Removing one of two contacts that clashed on a name gives the other its name back without a reload, unless an identity holds it.

Testing

• Round 5: UI tests 339 in the default build, 346 offline; clippy clean (-D warnings) natively and on wasm32 for both builds. Red→green, by re-applying the old behaviour: the double-click guard; the ambiguity refusal (three address-book tests); contract-id recording (two); the binary-search removal; the page keeping a partly deleted identity; the bare clash label; no rename-back on removal. New live-node test: an identity left at the reveal step gets both contracts on the next load, and a further load finds them. No delegate or protocol code changed in this round.

• Round 4: UI tests 330 in the default build, 337 offline. The removal tests fail against the positional lookup; the recipient and relabel tests (address book) and the send-check and recorded-address tests (in-page delegate) all fail with their fix removed. These UI checks were run by hand; check-guards-fail.sh covers the delegate and protocol.

• Round 1, last items (each shown failing against the code it guards): six startup-merge tests (removing the journal replay fails all six); V1AftParams offline equals the v0.2 client's encoding (fails with the feature off); five local-state persistence tests against the in-page delegate (archive-before-remove fails when the removal ignores the outcome); an interrupted deletion is listed and finishes without asking (delegate test plus a guard mutation) and the same through the in-page delegate; deletion and restore failure texts; a dropped call leaves no waiter. UI tests now: 309 in the default build, 310 offline. Delegate: 65 tests.

• UI library tests (earlier rounds): 282 in the default build, 273 offline (--no-default-features --features example-data,no-sync, now in cargo make test). Offline runs exercise signing, decryption and deletion through the real (in-page) delegate. New in this round, each shown failing against the code it guards:

  • a startup load replaces only the identities it read and keeps a settings change made meanwhile (red against the wholesale replace);
  • received ids stay below the folded-row range (red without the mask);
  • a thread is ordered by time even with anti-chronological ids;
  • a large identity reports what is left after each page until it is gone (red when progress is not reported).

• Playwright (offline): mail-delegate-identity.spec.ts: the key shown at creation is the one a later reveal exports, and leaves the page when the panel closes; a deleted identity's key restores it as new with the same fingerprint (red against the in-memory-only delete). Existing specs cover restore by key and JSON, the backup panel, delete confirmation and revoke. threads-storybook.spec.ts passes again.

• e2e-real-node: Persistence layer: sent/deleted messages don't survive refresh or session #286 and Reply fails when recipient added sender under a different local nickname #289 pass again; new: two tabs changing different settings keep both. Two tabs can't share a delegate offline (each page has its own), hence the live test.

• Delegate: 64 tests with and without v1-transition, including the_recovery_key_comes_back_on_creation_only; protocol golden test covers reply_created_identity.

• Candidate WASM (now 7fLRKWh2hrQkNctnDzBnVUxzn4nQcwcZ3NgJ3jN7L3mQ); check-delegate-candidate.sh, check-frozen-artifacts.sh, check-frozen-immutable.sh and check-guards-fail.sh pass.

• Strict clippy (-D warnings): the workspace and the offline UI build.

• Release freeze: scripts/release-freeze_test.sh.

Round 7: host-fault runs

Every earlier round found another bug of one class: an outcome the host cannot report (a failed read looks exactly like an absent key; a write or a reply may or may not have landed) treated as success, failure or absence. No test could reach it, because the in-memory host never failed.

The harness (delegates/mail-delegate/src/tests/faults.rs, env.rs):

• MemEnv can now fail calls, seeded and deterministic: reads that miss, writes and removals the host refuses, per-call chance or the Nth call on a key. The host model is that a failed read is transient (an immediate re-read succeeds).
• Seeded runs drive create, import, rename, delete-with-Continue, item put/delete/get/list and the identity listings, with lost replies. They then heal with faults off and check:
  • identity records and index entries agree (no unlisted key, no leaked slot);
  • no marker that licenses a prune outlives its create or deletion;
  • a deleted identity leaves nothing;
  • every item is indexed under a stored owner, and every entry names a stored item;
  • no acknowledged write is lost and no acknowledged delete undone;
  • no generation is handed out twice.
• The default is 300 seeds × 60 ops (FAULT_SEEDS, FAULT_OPS, FAULT_RATE); seeds that failed earlier are pinned.

What it found. Before the fixes, 219 of 300 seeds broke an invariant. After them, none of 300 at a 6% fault rate, and none of 2000 × 80 ops at 6% or at 20%. The bugs:

• A missed read could destroy data. One missed read of the generation counter reused a generation; of an index, rewrote it without its entries; of a record, let a create overwrite it or a prune unindex a live key. The store now confirms every miss with an immediate re-read.
• Space::del returned Ok on a miss while the key stayed. It now removes the key anyway, and Ok means gone.
• A create whose write and undo both failed leaked an identity slot for good. The "entry may have no record" marker is now written before the slot is claimed.
• A deletion answered Deleted while its marker, which names the address, could remain. The retry now finishes it without a prompt.
• An item index entry whose record was gone held a cap slot. Listing now frees it.

UI items from the same review (each with a test that fails without it):

• Identities are selected by id, not by position, so removing one from the middle no longer selects the wrong identity or panics.
• A rename now reaches user.identities too, and a rename with no answer is judged by re-reading the identity.
• Message marks are reclaimed only after a second non-empty inbox state, against every message any state held, and never for a mark written mid-reclaim.
• One lost read no longer makes a draft "gone elsewhere" (the send check, autosave and the item delete helper re-read).
• A delegate error naming no delegate is the token generator's while one of its requests is in flight, and never ends a call holding a consent prompt open.
• Stored contacts sharing a signing key are all kept on load, and mail to that key is refused until the user deletes the wrong one. This supersedes round 6's "settle by the name typed".
• A deleted message's copies go before its "deleted" mark.

Round 7, continued (live-node failures and the remaining should-fix items):

• "A renamed identity's draft and settings persist across reload" failed 3 of 4 e2e runs from a51fd85 on. The startup load lists identities, then prepares each one (a delegate round trip apiece) before announcing them, so its snapshot could land after a rename. Applying it replaced the entry with the same address, bringing the OLD alias back; the new alias then named no identity, and every draft, sent and settings write under it failed with "no identity" (autosave stuck at pending). A listing now never overwrites an entry the page holds at a newer delegate generation (Identity::upsert; test a_stale_identity_snapshot_does_not_undo_a_rename, red before). A failed autosave now shows as failed with a Retry instead of staying pending (367b056).
• "An identity left at the reveal step gets its contracts on the next load" failed twice. The test reloaded as soon as the self-heal was logged, which happens before the PUT is sent, so a reload could cancel it and the next load rightly self-healed again. The UI now logs when the node acknowledges a self-heal PUT, and when it loads the AFT record; the test waits for both acknowledgements, then for both contracts to be found, before its checks (9571d95, 93ccdc9).
• Startup loads (identities, local mail state) retry, then say to reload; an unknown unfinished-deletions listing is reported. A lost create not listed yet is re-checked before "not created". A reached storage limit is named in the failure toast. A failed publish keeps the identity on the page and lets the self-heal publish its contracts. Acknowledged writes drop their optimistic copies of message bodies (9099a7d, 3dad39a).
• Not changed: a lost create is still matched by alias. The delegate refuses duplicate live aliases atomically, so the only mismatch is another tab of the same app creating that same alias first, and the user is then shown their own identity of that name through the consented export. The reasoning is at after_lost_create (904025c).

https://claude.ai/code/session_01Xxpwzvt4ucaGfbeCr77Jns

[AI-assisted - Claude]