Status: Phase 1 placeholder. Substantive content lands in Phase 5 per §8.1.

Statement

Groups are MLS-protected (Marmot / RFC 9420) multi-party chats with epoch-bound forward secrecy. The UI must not lie about MLS state — KP availability, epoch progression, removed members, and admin-driven commits are all surfaces the user is entitled to understand at a glance.

Why

Groups is the most protocol-rich product surface in the system. The user experience is downstream of: KeyPackage publish/refresh, Welcome handling, epoch advancement on every commit, exporter-secret derivation per epoch, admin-only commit policy in ES-administered groups, member removal with forward-only ratchet semantics, and the per-group push notification routing through the EC2 worker.

Treating groups as "messaging but with more people" produces a UI that breaks at every protocol seam. A removed member's UI must reflect that they no longer have the exporter secret to decrypt new messages — but old messages remain readable from local IDB. A user re-invited after removal does not get message history from before the new Welcome. A KP rotation is invisible to the user but must not be invisible to the developer auditing.

How

This stub is intentionally thin. Substantive G-1 content matures in Phase 5. Expected coverage at maturity:

Group list with per-group unread badges restored from IDB read markers
Member roster with KP-availability indicators (Ready for group chat vs Not ready)
Admin-only affordances surfaced only when clientState extensions confirm the user is in adminPubkeys
System messages (member added / removed / left) rendered with a different primitive than user messages, never confused
Removed-member "you have lost access to this group" surface, not a generic error
Per-group settings: avatar (MIP-01), description, relay list (0xF2EE)

Phase 5 fills these in with audit citations and per-surface specifications.