States

This page describes the conceptual protocol states involved in the DeRec flows.

The protocol is organized around six primary flows:

• Pairing

• Sharing

• Verification

• Discovery

• Recovery

• UpdateChannelInfo

These flows are message-driven interactions between an Owner identity (the Owner device and any paired Replicas) and the participants it interacts with — Helpers and sibling Replicas.

The state machines below describe the expected progression of these interactions.

This section is descriptive and intended to clarify protocol behavior.

Exact message structures are defined in the Messages section, and interaction sequences are defined in Flows.

Global State Variables

Protocol interactions reference the following identifiers:

• secret_id — Identifier for the protected Secret. Fixed for the lifetime of the Owner identity.

• version — Monotonic version of the Secret. Increments whenever the Secret's content changes.

• replica_id — Per-device stable identifier of the writer. Stamped on every share / Secret write so receivers can attribute origin and detect concurrent-write conflicts.

• owner_replica_id — The replica_id of the device that produced this version of the Secret, carried inside the Secret itself as a second attribution channel.

• channel_id — Communication channel between two participants.

The channel_id uniquely identifies a paired channel — Owner ↔ Helper, Owner ↔ Replica, or Replica ↔ Replica.

The combination of (secret_id, version, replica_id) identifies a specific share write on a Helper. Including replica_id in the key is what lets concurrent writes from sibling Replicas coexist side-by-side rather than overwriting each other.

The protocol does not mandate how versions are generated or managed beyond the monotonic-increment-on-content-change rule.

Owner State Machine

The Owner (or any Replica acting on its behalf) coordinates protocol flows with Helpers. Once a Replica has received the first Secret sync from the Owner identity, its state machine is identical to the Owner's — the protocol does not separate them past that point.

• Unpaired — No protocol relationship has been established yet on this channel.

• PairingInProgress — Pairing messages are exchanged to establish a trusted communication relationship with each peer (Helper or Replica).

• Paired — The two sides have completed pairing and may participate in protocol flows.

• Sharing — Shares are distributed for a particular secret_id and version — committed shares to Helpers and the full Secret to paired Replicas.

• Active — Normal operating state in which verification, discovery, and recovery flows may occur.

• Verification — The Owner identity challenges Helpers to confirm possession of share content.

• RecoveryMode — A recovery operation is initiated.

• Recovering — Shares are requested from Helpers and reconstruction is attempted once enough valid shares are obtained.

Replica channels: the Pending gate

Replica-mode channels (ReplicaSource ↔ ReplicaDestination) introduce one additional pairing state. After the cryptographic handshake completes, the channel sits in Pending and silently drops any inbound protocol traffic until fingerprint cross-confirmation succeeds on both sides. Only then does it transition to Paired. Owner ↔ Helper pairings skip this gate entirely.

Helper State Machine

Helpers store shares and respond to protocol requests from the Owner identity.

• Unpaired — No protocol relationship has been established yet.

• PairingInProgress — Pairing messages are exchanged.

• Paired — The Helper can participate in protocol flows.

• HoldingShare — The Helper stores share data indexed by (secret_id, version, replica_id). Multiple shares with the same (secret_id, version) but different replica_ids coexist side-by-side — this is how concurrent writes from sibling Replicas are preserved for later conflict resolution.

• VerifyResponding — The Helper responds to a verification request.

• RecoveryServing — The Helper returns share data when requested during recovery.

• Discovery — The Helper returns the catalogue of (secret_id, version, replica_id) tuples it currently holds.

Helpers do not communicate with other Helpers and do not know the size of the Helper Set.

Version Consistency During Recovery

During recovery, the Owner may receive shares associated with different versions.

Recovery requires obtaining a threshold number of valid shares corresponding to the same version.

Shares that fail validation must be discarded.

Recovery succeeds once the Owner identity reconstructs the Secret using a valid threshold of shares for a single version. When two distinct replica_ids appear for the same (secret_id, version) in the Helper responses, a conflict has occurred — see Conflict resolution for how the application reconciles before driving recovery.