Mail threads: group back-and-forth between two users

[iduartgomez]

Feature request

Group messages exchanged between two identities into a conversation thread instead of showing each message as a standalone inbox entry.

Motivation

Today every received/sent message is a flat list item. A reply to a reply has no visible relationship to the original. For a 1:1 back-and-forth between two users, the inbox should collapse the exchange into a single thread the user can expand.

Scope (proposal)

• Detect related messages between the same two participants (sender ↔ recipient pair) and group them.
• Threading key: needs a stable conversation identifier. Options:
  • subject-normalization (strip Re: prefixes) + participant pair, or
  • an explicit in_reply_to / thread_id field carried in the encrypted message payload (cleaner, requires a message-schema addition).
• UI: thread shows as one row; expanding reveals the ordered message list; reply stays within the thread.
• Sent + received messages must interleave in chronological order within a thread.

Open questions

• Schema change vs. heuristic grouping. A thread_id in the message body is more robust but touches the inbox message format (ui/src/inbox.rs, common/).
• How threads interact with the Quarantine folder.

Acceptance

• Two identities exchanging N messages render as one expandable thread.
• Replies attach to the existing thread, not a new entry.

[iduartgomez]

Investigation notes (context for implementation)

No threading metadata exists anywhere today — no thread_id, message_id, in_reply_to, or subject-as-key on the wire.

Key structs:

• On-chain Message (contracts/inbox/src/lib.rs:171) — opaque ciphertext blob, contract never sees plaintext.
• Plaintext DecryptedMessage (ui/src/inbox.rs:522) — has title (subject), from, to, cc, time. No thread fields.
• Render struct Message (ui/src/app.rs:749); list built by MessageList() at ui/src/app.rs:1593, sorted newest-first by sort_cmp_inbox() (app.rs:814).

Sent vs received are separate stores: sent messages live in the mail-local-state delegate (SentMessage, UUID-keyed); received live in the inbox contract. They share NO common id, so correlating a sent message with its reply requires adding a shared key.

Schema path: DecryptedMessage is serde_json-encoded inside the ML-KEM ciphertext (ui/src/inbox.rs:643 ser, :633 de). Adding #[serde(default)] thread_id: Option<String> is a backwards-compatible JSON extension — old clients ignore it. Does NOT touch the contract WASM; INBOX_CODE_HASH does not rotate.

Recommended: Option B — add thread_id: Option<String> to DecryptedMessage; reply echoes the original's id (or a compose-time UUID). Touches ui/src/inbox.rs (struct), ui/src/app.rs (compose prefill + MessageList grouping), and modules/mail-local-state/src/lib.rs (SentMessage.thread_id so Sent↔Inbox correlate). Heuristic subject+sender grouping (Option A) needs no schema change but can't link your own sent messages to replies and is fragile on "Re: Re:".