# Member lifecycle

The hard part of a bearer-link system is not initial entry. It is what happens when people leave, lose devices, rotate
keys, or need access cut.

This page summarizes the lifecycle model. The full technical version is in [The Verified Room](./room-link-auth.md).

---

## Removal

For gated Spaces, removal has two layers:

| Layer | Status | Meaning |
|---|---|---|
| **Cut writes** | Shipped | A revoked member's next turn is refused. |
| **Cut reads by server gate** | Shipped for email-gated Spaces | The server refuses to decrypt and return entries to the removed member. |
| **Cut reads cryptographically** | Designed for single Spaces; live in the Bridge | Future content is sealed to a new epoch key the removed member never receives. |

The shipped private-Space behavior is useful because the client is thin: a removed member can hold the old key, but the
server refuses to act as their decrypting read path.

Open Spaces are different. If the link reads, then anyone holding the link can read.

## History vs future

Revocation cannot make someone un-see content they already read. That is true for every end-to-end or sealed system.
The practical distinction is:

- **history**: content a member already saw remains known to them
- **future**: new content can be blocked by read gates now and by epoch re-key in the stronger model

For rooms with hard compartment boundaries, design epochs up front.

## Key rotation

Rotation means opening a new epoch and sealing future entries to a fresh key. The Bridge already uses epoch re-key for
membership changes. Single-Space epoch re-key is designed but not the ordinary production ledger path today.

Per-member signing keys can rotate independently: revoke the old grant and admit the new key.

## Replacing a compromised identity

A member identity is a signing key bound by a grant. If that key is compromised:

1. Revoke the old grant.
2. Admit a fresh member key.
3. Re-key the epoch where the crypto-strong future read cut is required.

The Space and other members do not need to be rebuilt.

## Metadata that remains

Lifecycle operations do not hide traffic shape. The platform may still observe that a room exists, when it changes,
and roughly how large writes are. In Google/OIDC-gated rooms, identity appears transiently during verification and is
discarded; the membership policy itself is sealed in the config.

## Related pages

- [Identity and admission](./identity-and-admission.md)
- [Recovery](./recovery.md)
- [The Bridge](./the-bridge.md)
- [The Verified Room](./room-link-auth.md)