Decide the person+subject conversation-grouping model

[Hohnik]

Part of MailChat MVP: email-as-chat spec

Question

Define how messages become "conversations" grouped by person + subject — the core novel piece of MailChat. Specifically:

• What counts as "the person" in a conversation when a thread has multiple recipients or CC'd participants?
• How are subjects normalized for grouping (Re:, Fwd:, and the German AW:/WG: prefixes real T-Online mail will use)?
• Is standard Message-ID/In-Reply-To/References header threading used as a signal alongside person+subject grouping, or superseded by it?
• Does the same contact emailing from two different connected accounts merge into one conversation, or stay split per account?

This decision shapes the conversations/, messages/, sync/threading.py, sync/normalize.py, and contacts/ modules.

Ground the discussion in real message samples from the IMAP read-only proof of concept (real Re:/AW: patterns, real multi-recipient threads) rather than hypothetical examples.

[Hohnik]

Decided via grilling, grounded in real message samples from the T-Online account (Louis.de DL-4916597 ticket thread, Leni Limmer's dual gmail/googlemail addresses, a CC'd Horbach thread).

1. Unit of grouping: a conversation = (person, normalized_subject) tuple — not one continuous per-person stream. A new subject from the same contact starts a new conversation card. ("Person + subject" in the destination text is load-bearing, not just a display label.)

2. "The person": primary correspondent only — sender (inbound) / recipient (outbound), excluding all of the user's own connected-account addresses. CC'd participants show on the message but don't affect grouping or fork conversations. Real example: an inbound thread from ammar.memic@horbach.de to the user with oliver.reinhart@horbach.de CC'd — groups under Memic; Reinhart is just a visible CC'd name.

• Deferred to fog: participant-set/group-chat-aware grouping (when the CC set itself should matter) is real future need, not in MVP scope.

3. Contact identity: exact email address (case-insensitive) = one contact. No automatic alias merging. Real example: leni.limmer@gmail.com and leni.limmer@googlemail.com are almost certainly the same human but stay separate contacts in the MVP. Manual merge is a later fast-follow, deliberately not built now so the model stays simple/unsurprising.

4. Subject normalization: repeatedly strip (Re|Aw|Fwd|Fw|Wg)\s*:\s* case-insensitively wherever it appears in the string (not anchored to the start only), then collapse whitespace and trim; idempotent. Anchored-only stripping was tested against real data and fails: the Louis.de thread has Re: inserted after the vendor's own DL-4916597: ticket-id prefix in one message, which an anchor-only strip would leave in a different subject-group than the other three messages in the same human conversation.

5. Header threading: Message-ID/In-Reply-To/References are not used for grouping — (person, subject) is the sole key. Real data shows headers are shallow (single-hop In-Reply-To, no full References chain) and often absent entirely, too unreliable to drive merging. Headers are still stored per message for future use (e.g. reply ordering, thread visualization).

6. Cross-account merging: the same contact emailing two of the user's connected accounts merges into one conversation — no account component in the grouping key. This is core to the app's value proposition (unifying multiple inboxes into one chat view); splitting per account would just be N separate mini-mail-clients. "Self" exclusion in rule 2 must be account-set-aware (any connected address counts as "you"), not single-address.

Modules this shapes: conversations/, messages/, sync/threading.py, sync/normalize.py, contacts/.