PROTOCOL NOTES / 10

10 · Graceful departure and organizer-local termination

Participants: UI, Engine, Peers, Service

Implemented software · Physical qualification pending

Starting state

Admitted rider or organizer chooses leave; other riders may have sealed or open membership.

Ordered events

  1. UI → Engine

    leave is an explicit local command

  2. Engine → Peers

    Announce signed local leave when connected

  3. Engine → Service

    Revoke media and stop local ride resources

  4. Peers → Peers

    Mark departed member unavailable and repair topology

Fields and messages

Signed leave common body; fixed roster retains departed identity/index; no global terminate or eviction field.

Authorization and invariants

Local organizer status does not create authority for an unimplemented global kill. No roster removal or key rotation is implied.

Timers

Immediate local cleanup; missing remote notice falls back to 3/6-s direct liveness and root freshness.

Resource lifetime

Persistent identity/settings survive. Ride token, source keys and PCM receive best-effort cleansing; containers/libraries prevent perfect-erasure claims.

What the rider sees

Local ended/idle flow; other riders retain their own active/ready states and see unreachable member.

Failure branches

Lost leave message cannot keep a half-open peer forever; organizer leaving before seal can strand approval and requires a fresh ride to admit new people.

Resulting state

Local audio/transport/ride secrets retire. Remaining sealed members may continue or partition; open admission cannot gain further organizer approvals.

Evidence boundary

Host leave/partition/liveness tests and compiled foreground service instrumentation.

← All scenarios

Authority: RWCP v2 reviewed scenario catalogue, scenario 10. Public examples are synthetic. This guide is maintained against the private implementation; it does not imply access to its source.