Protocol Overview

This section provides a protocol-level overview of DeRec. It is the bridge between the conceptual chapters (Roles, Secret, Key Objects, Lifecycle, Replicas) and the normative specification (States, Messages, Flows).

It describes:

• The protocol scope and responsibilities

• The end-to-end protocol lifecycle in terms of normative flows

• How the remaining specification sections are organized

This section is non-normative. Normative behavior is defined in States, Messages, Flows, Error Handling, and Versioning.

Scope

The DeRec protocol standardizes how an Owner identity (one or more devices) coordinates with a set of Helpers to:

• Distribute shares of the Secret across the Helper Set using a threshold secret-sharing scheme

• Verify that Helpers still hold valid share material

• Recover the Secret when a threshold of valid shares is reconstructed

• Synchronize the full Secret across the Owner identity's Replica devices

DeRec does not mandate:

• Storage backend choices

• Transport mechanisms — every protocol message is encrypted under a per-channel Shared Key, so the protocol does not require a secure transport channel (only the initial ContactMessage during pairing is exchanged out-of-band).

• Authentication UX, account recovery UX, or device UX

Actors and Trust Boundaries

• Owner: drives all protocol flows, splits the Secret into shares, distributes them to Helpers, and reconstructs the Secret from a threshold of valid shares during recovery.

• Helper: stores share material and returns it only under protocol-defined rules.

• Replica: an additional device under the same Owner identity that holds a synchronized copy of the full Secret. Once synced, any member of the replica group can drive the Owner-side flows toward the Helpers, publishing as the Owner. Each member keeps a persistent ReplicaRole: exactly one member of a group is the Source, the rest are Destinations.

Security depends on the threshold model: fewer than t Helpers cannot reconstruct the Secret, and the Secret is never transmitted to any Helper. The Owner and every Replica share the same trust boundary; the protocol does not separate them cryptographically.

Protocol Lifecycle at a Glance

The protocol is organized into a small set of flows. Each flow is a structured message exchange between participants — typically Owner-or-Replica and Helper, or between Replicas under the same Owner identity.

1. Pairing Flow — Establishes a trusted communication context and a Shared Key between two participants; on completion both sides rotate to a long-term channel id derived from that key. Each side advertises every transport endpoint it serves (supportedTransports); the receiver keeps the ones its transport policy admits. The same handshake serves Owner ↔ Helper and replica pairings; replica-mode pairings add a fingerprint cross-confirmation gate and a shared-key handover into the replica group.

2. Sharing Flow — The Owner splits the current Secret into shares using a threshold secret-sharing scheme and distributes one committed share per Helper. The same flow also fans out the full Secret to every paired Replica so the Owner identity stays synchronized across all its devices.

3. Verification Flow — The Owner (or any Replica acting on its behalf) challenges a Helper to prove possession of a stored share without reconstructing the Secret.

4. Discovery Flow — Owner asks a Helper to enumerate the (secret_id, version) pairs it currently holds, so the requester can reconcile its view before driving recovery or routine inventory.

5. Recovery Flow — Owner requests shares from Helpers and validates each one on arrival; a malformed share or one whose Merkle proof fails is set aside as corrupted, and an explicit refusal is not counted. Valid shares are grouped by commitment root and ciphertext, and the largest group is tried first. SecretRecovered writes nothing: a device recovering from loss then runs a local restore step to re-establish its channels and commit the recovered snapshot.

6. Unpair Flow — Owner-only. Asks a Helper to end the relationship and delete its data for the channel, then drops the channel locally.

7. UpdateChannelInfo Flow — Maintenance side-channel that announces updated communicationInfo and/or a new endpoint list (supportedTransports) to paired Helper channels without re-pairing. Either party of a Helper channel may initiate.

8. ReplicaDiscovery Flow — Replica-only. A member asks the group which version each member holds and pulls the newest, closing the gap left by a group that has not written since it came back. It fetches only when some member holds a strictly newer version; a fetched copy is applied, never reported as a conflict.

9. UnpairReplica Flow — Replica-only. Announces a member's removal from the group. Any member may remove any member, the Source included. It removes nothing on its own — the removal completes when a member publishes a roster omitting that member. See Replica removal.

Master Protocol Diagram

This diagram shows the DeRec protocol at the level of flows. Each edge represents a protocol flow between participants. In practice, the Owner identity runs the same set of flows with multiple Helpers in the Helper Set and with each paired Replica.

Note: this is a conceptual overview. Exact message sequences, validation rules, and error signaling are specified in the Flows, Messages, and Error Handling sections. Unpair, UpdateChannelInfo, ReplicaDiscovery, and UnpairReplica are maintenance and replica-group flows and are not drawn.

What the diagram is showing

• Pairing Flow establishes a trusted communication context — same handshake serves Owner ↔ Helper and Owner ↔ Replica pairings.

• Sharing Flow distributes one committed share per Helper (indexed by secret_id, channel_id, version) and the full Secret to every paired Replica on the same trigger.

• Verification Flow lets the Owner (or any Replica acting on its behalf) confirm a Helper still holds the expected share content without reconstructing the Secret.

• Discovery Flow enumerates the (secret_id, version) pairs a Helper currently holds — used to reconcile state before driving Recovery or for routine inventory. It carries no writer identity: concurrent writes are refused at store time with VERSION_CONFLICT, not surfaced here.

• Recovery Flow retrieves shares from enough Helpers (≥ t), validates each on arrival, and reconstructs the Secret locally from the largest group of shares that agree on commitment root and ciphertext. Shares that disagree with the winning group are reported as corrupted alongside SecretRecovered. A device recovering from loss follows reconstruction with a local restore step that re-establishes its Helper and Replica channels.

• UpdateChannelInfo Flow is a maintenance side-channel — not shown on the diagram above — that lets either party of a Helper channel announce updated communicationInfo and/or a replacement supportedTransports list, most commonly to rotate transport endpoints without re-pairing.

• Unpair, ReplicaDiscovery, and UnpairReplica are also not drawn. See Flows, ReplicaDiscovery, and UnpairReplica.

Core Identifiers Used by the Protocol

Protocol operations are keyed by identifiers that appear throughout messages and validations:

• secret_id: identifies which protected Secret is being referred to. Fixed for the lifetime of an Owner identity.

• version: identifies a specific snapshot of that Secret. Incremented by one on every publish round by the writing device.

• replica_id: application-assigned stable identifier of a replica-group member. Stamped on replica-bound writes and their acknowledgements so a member can be attributed on a channel every member shares. Helpers neither receive nor send it. 0 is reserved as the "absent" sentinel and is not a valid identity.

• channel_id: identifies a paired channel. One per Owner ↔ Helper pair; one per replica group, shared by every member — which is why a member is keyed by replica_id instead.

In practice, Helpers store and return shares indexed by (secret_id, channel_id, version). Exactly one share exists per key: a second write at an existing version carrying different content is refused with VERSION_CONFLICT, not stored alongside.

Validation and Determinism

Implementations must produce interoperable behavior. That requires:

• Well-defined message semantics (Messages section)

• Clear state constraints (States section)

• Deterministic flow rules (Flows section)

• Explicit error signaling rules (Error Handling section)

A key principle is that protocol messages are validated before they are accepted, stored, or used for reconstruction.

How to Read the Protocol Specification

If you are implementing DeRec, this ordering is recommended:

1. States — Understand the allowed protocol states for Owner and Helper and which transitions are valid.

2. Messages — Learn each message’s purpose, fields, and validation rules.

3. Flows — Implement each flow as a sequence of message exchanges using the constraints from States and Messages.

4. Error Handling — Implement consistent error mapping and retry behavior.

5. Versioning — Ensure compatibility rules for message/schema evolution and distinguish protocol versioning from secret distribution versioning.

Relationship to Other Sections

• The Concepts sections explain why DeRec is designed the way it is.

• These sections explains what the protocol does at a high level.

• The Protocol Specification sections define exactly how implementations must behave.