Follow-up to #58 (closed via PR #68).

#58 wired Pending → Delivered/Failed off the inbox UPDATE response — i.e. the contract write landed on the recipient's inbox shard. That proves the encrypted message is stored on the network. It does not prove the recipient ever opened, decrypted, or saw it.

This issue is about the stronger "receiver acknowledged" signal: the recipient's client (or user) confirms the message arrived at their UI, and that confirmation flows back to the sender's Sent row.

Why a separate issue

#58's "delivery" is really write-ack. Useful, cheap, no extra round trip. But the user's mental model of "Delivered" usually means "the other party got it" — which requires recipient-side participation. That's a different protocol surface and worth scoping separately.

Open question: do we keep Delivered semantics as today (write-ack) and add a new Read / Received state, or rename the current state to Sent/Stored and reserve Delivered for receiver-confirmed? Leaning toward the latter for honesty, but it churns the local-state schema and Playwright assertions.

Design options

A. Read-receipt via recipient inbox state delta

Recipient UI, on first decrypt of a message, writes a small ack record into its own inbox state delta. Sender subscribes to recipient inbox (already needed for sending) and watches for ack records keyed by (sender_pk, msg_id).

• Pros: reuses existing inbox UPDATE plumbing, no new contract.
• Cons: leaks recipient liveness/online-ness to sender (privacy regression). Couples sender to recipient inbox subscription beyond the send window.

B. Ack-via-reply only

No infra. "Delivered" only flips when recipient replies. Honest but very weak — most messages never get acked.

• Pros: zero plumbing.
• Cons: indistinguishable from "recipient ignored". Bad UX.

C. Dedicated ack delegate / contract

Recipient signs {msg_id, sender_pk, ts} and posts to an ack contract keyed by sender. Sender subscribes to its own ack contract.

• Pros: clean separation of concerns. Sender doesn't need to keep watching recipient inbox. Privacy posture tunable (anonymized ack, batched, etc.).
• Cons: new contract surface, new delegate, more code.

D. AFT-coupled return path

Bundle ack with the token return / refund flow. Recipient's AFT activity already touches sender's allocator.

• Pros: piggybacks existing channel.
• Cons: couples economic and delivery concerns. AFT shouldn't know about message-level ack.

Recommendation (preliminary)

Option C (dedicated ack contract) is the cleanest long-term but biggest lift. Option A is the cheapest path that produces a real signal — accept the liveness leak for now, revisit privacy when threat model tightens. Option B is a non-starter alone but composes with A or C as a fallback.

Acceptance (sketch)

• Recipient UI emits an ack record on first successful decrypt of a new inbox message.
• Sender's Sent row transitions `Delivered` (write-ack, today's Sent: per-message delivery ack from inbox contract #58 semantics) → new state (e.g. `Read` / `Received`) when ack observed.
• Ack is authenticated (recipient ML-DSA signature over {msg_id, sender_pk}) so a third party can't forge confirmations.
• No infinite-watch: sender stops listening for ack after some bound (timeout → state stays `Delivered`, no `Read` flip).
• Privacy: document what is leaked (at minimum: "recipient was online and decrypted at time T").

Out of scope

• Recipient opt-out / read-receipt suppression (separate UX issue once mechanism exists).
• Per-message return-of-token semantics.
• Group-message multi-recipient ack aggregation.

Related

• Sent: per-message delivery ack from inbox contract #58 — write-ack (closed, merged via feat(ui): wire Sent delivery ack from inbox UpdateResponse (closes #58) #68)
• Sent / Drafts / Archive folders #47 — original Sent-folder issue