Membership & Leave Operations

Forward-only invariant — load-bearing

The apply-time membership check is a function of two things only: the signer's identity and the governance-DAG position the signer signed against. It is not a function of the receiver's current local state. This is the forward-only property: a write authored at governance position P stays valid forever, even if the receiver has since applied a MemberRemoved for the signer at a later position P' in its local DAG.

Why this matters

Without forward-only, two peers receiving the same set of ops in different orders would end up with different state:

• Peer A receives MemberRemoved first, then the pre-removal delta. If "is the signer currently a member?" gates the apply, the delta is rejected.
• Peer B receives the delta first, then MemberRemoved. The delta applies; the later removal doesn't retroactively undo it.

That divergence cascades: any subsequent delta that reads the (different) state diverges further, context root hashes drift apart, and the network has no honest convergence point. Forward-only removes the receive-order dependence: pre-removal writes always apply on every peer, regardless of when the receiver learns about the removal.

How it's implemented

Every state delta carries a governance_position field that names the governance-DAG heads the author observed at sign time. On receive, the apply path calls membership_status_at(signer, delta.governance_position) — which walks the ancestry of the signed heads and replays the membership state machine. The walk visits only the prefix that was already final when the delta was signed; anything causally after the signed cut (including a later MemberRemoved for this signer) is invisible to the walk and cannot retroactively invalidate the delta.

Where this can break

Two classes of change would silently re-introduce the divergence described above:

• Calling the check with the wrong position. Any caller of membership_status_at that passes the receiver's current state (or any post-cut heuristic) instead of the signed delta position breaks forward-only. The three production call sites — gossip-receive, governance-pending drain, and snapshot-sync replay — each carry inline comments naming this contract; reviewers should flag any new caller that doesn't pass delta.governance_position verbatim.
• Changing the prefix walk to visit descendants. A "performance optimization" that has the BFS catch up to local heads after visiting the signed heads would observe ops the signer hadn't signed against, including later MemberRemoved ops. The forward-only contract is documented on the public membership_status_at function; the internal BFS in prefix_walk_membership implements it, and the prefix_walk_forward_only_* regression tests pin the boundary.

Scope

Forward-only applies to MemberRemoved and MemberLeft — operations that revoke authorship. It does not apply to role demotions (MemberRoleSet transitioning a Member to ReadOnly): those are enforced against current state at the receive path, separately from the cross-DAG check, because a member who was demoted retains a different relationship to their pre-demotion writes than a member who was fully removed. See is_read_only_for_context for the live-state role gate.

leave_context — local-only opt-out

Stop syncing a context on this node. No DAG op, no broadcast, no key rotation. Other members never observe the leave; from their perspective the leaver is still in the membership list (which is implicit anyway, computed from group membership + auto-follow).

Storage

Two separate stores live side by side: the synced ContextIdentity row (key at crates/store/src/key/context.rs:120, value at crates/store/src/types/context.rs:117) and a node-local ContextLeftMarker tombstone in a new column.

The marker lives in Column::ContextLocal (a new column specifically for node-local context-scoped state — never synchronized). Keying is identical to ContextIdentity so the (context_id, member_pk) pair is the unit of opt-out:

A separate column instead of a flag on ContextIdentity for two reasons: (a) ContextIdentity is part of the synced membership shape, so adding a node-local field to it would conflate replicated and node-local state; (b) extending the existing Borsh value would break deserialization of pre-existing on-disk rows, requiring a migration. The dedicated column makes the node-local-ness explicit at the storage layer and keeps the synced shape clean.

Flow

1. Client calls leave_context(context_id).
2. Handler resolves the local ContextIdentity via find_local_signing_identity — scans the column for the row where this node holds the private key. Falls back to the namespace identity if no local row exists.
3. In a single batched store handle (so they land in one commit), the handler:
   1. Writes the ContextLeftMarker row in Column::ContextLocal.
   2. Deletes the corresponding ContextIdentity row, which stops sync (the sync layer iterates these rows).
4. Calls node_client.unsubscribe(&context_id) to leave the gossipsub topic, mirroring join_context's subscribe.
5. Auto-follow handler (auto_follow.rs:255) checks for the marker via has_left_context on every ContextRegistered event and skips the auto-rejoin if it finds one.

Properties

What this is not

• Not a kick. Leaver still appears in any "members of this context" query.
• Not a cryptographic leave. If the user wants forward secrecy on a context, they must leave the group containing it (which rotates the group key).

leave_group — distributed, two-phase, no cascade

Self-removal from a single group. Reuses the existing MemberRemoved key-rotation pipeline but the publisher/rotation responsibility splits across two parties: the leaver publishes the leave op, then a remaining admin publishes the KeyDelivery with the fresh group key. The leaver never holds the new key.

New op

Distinct from MemberRemoved for audit clarity — "this member chose to leave" vs "this member was removed" are semantically different events even when they have similar effects.

Preconditions

• Signer has a direct row in the group (computed via check_group_membership_path; reject with NotADirectMember if the signer is only an inherited member — they must leave the anchor instead).
• Signer is not the Owner (OwnerCannotLeave; must TransferOwnership first).
• If signer is admin, removing them does not leave the group with zero admins (LastAdmin via existing ensure_not_last_admin_removal).

Flow

1. Leaver's client calls leave_group(group_id).
2. Server-side validation runs the preconditions above.
3. Leaver publishes MemberLeft { member: signer } via the governance DAG. Signed by the leaver. Targets this group.
4. Op broadcasts to all members of the group. Each receiver applies it: deletes the (leaver, group_id) row from local membership state. Leaver's own node also drops sync state for this group's contexts and (optionally) purges encrypted blobs.
5. The first remaining admin to ack the op enters phase two:
   1. Generates a fresh group key via build_key_rotation (group_keys.rs:266).
   2. Wraps it for each remaining member (leaver excluded).
   3. Publishes RootOp::KeyDelivery carrying the wrapped bundles.
6. Each remaining member receives KeyDelivery, unwraps their bundle, replaces the active group key. New writes use the new key from now on. The leaver's old key still decrypts historical content but not new writes.

Cascade behavior

Failure modes

• Network partition between phase one and phase two. MemberLeft lands but KeyDelivery is delayed. Forward secrecy briefly weak — the leaver is no longer in the membership list but new writes are still under the old key (which they hold). Heals on partition resolve.
• All admins offline. MemberLeft lands; rotation never fires until an admin returns. Operational mitigation: alert when no rotation follows a leave within a configurable window.

Rejoin

• Restricted group: requires fresh add_group_members from a remaining admin. New keys delivered via the existing membership-add path.
• Open group (if leaver had a redundant direct row): same. If leaver's path to the group was via inheritance from a parent, that inheritance is automatically restored as soon as they rejoin the parent.

leave_namespace — cascading, heaviest

A namespace is the root group. Leaving it cascades through every descendant where the leaver has a direct row, rotating each scope's group key independently. Plus the namespace's own root key. This is the only operation in the proposal that fans out across multiple scopes.

Preconditions

• Signer has a direct row at the namespace root.
• Signer does not own the namespace OR any subgroup beneath it. If they do → MustTransferOwnership { groups: [...] } listing every owned scope.
• Removing the signer doesn't leave any scope (namespace or descendant) admin-less. If it would → LastAdmin { group: G } reports the offending scope, forcing a successor promotion before retry.

Flow

1. Client calls leave_namespace(namespace_id).
2. Server-side validation walks the subgroup tree:
   • Compute direct_groups = [namespace, G1, G2, ...] — every group in the namespace where the signer has a direct row.
   • Run owner check + last-admin check across all of them. If any fails, surface the offending scope and bail before publishing anything.
3. Signer publishes a single MemberLeft { member: signer } at the namespace root.
4. The cascade handler (cascade_remove_member_from_group_tree, mod.rs:811) fans out: locally and on each receiver, fire the MemberLeft-equivalent for each scope in direct_groups.
5. Per-scope key rotation runs the same phase-two pattern as leave_group, in parallel. Total network ops: one root-level MemberLeft + N KeyDelivery ops where N = number of direct memberships in the subtree.
6. Local cleanup on the leaver's node:
   • Soft mode (default): archive namespace data as read-only. Leaver can browse their historical view.
   • Hard mode (opt-in): purge keys, DAG entries, encrypted blobs.

Edge case — last member of the namespace

If the leaver is the last remaining member, MemberLeft writes locally but has no peers to broadcast to. The namespace effectively dies on the leaver's node.

If the leaver is also the owner AND last member, they're stuck in the cycle — they must transfer ownership but there's no one to transfer to. Use a dedicated DeleteNamespace op (analogous to DeleteGroup but at root) that bypasses the owner-cannot-leave rule.

Failure modes

• Same as leave_group, multiplied across scopes. Each rotation can fail independently.
• Partial cascade: if some sub-rotations succeed and others don't, the leaver's root row is gone everywhere but some peers may have lingering ghost rows in subgroups. Eventually consistent — peers detect the leaver-not-in-root state and reconcile on next sync.

Open Questions

1. Soft vs hard local cleanup default for leave_namespace. This proposal defaults to soft (archive). Privacy-conscious products may want hard (purge) as the default.
2. Admin-mutual demote. Today admins can demote each other. Should this be restricted to Owner-only? This proposal preserves current behavior; revisit if a security concern surfaces.
3. Old owner after TransferOwnership. Becomes a regular admin (this proposal) or just a member (alternative)? Admin retains operational continuity; member is a cleaner "step-down" semantic.
4. Multi-scope transfer ergonomics. If an owner of a namespace + 5 subgroups wants to leave, does the UI surface 6 separate prompts or one bulk-transfer flow?
5. Cascade visibility in leave_namespace. Remaining peers see one user-facing event (MemberLeft) or N events (one per cascading scope's KeyDelivery)? Recommend collapsing to one user-facing event with internal fan-out.
6. Owner-leaves-with-no-successor edge case. Dedicated DeleteNamespace op (this proposal) or refuse outright?