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, every Replica is operationally equivalent to the Owner — it can drive any flow toward the Helpers on the same footing.

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. The same handshake serves Owner ↔ Helper, Owner ↔ Replica, and Replica ↔ 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, replica_id) tuples 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 reconstructs the Secret once at least t valid shares are obtained.

6. UpdateChannelInfo Flow — Maintenance side-channel that broadcasts updated communicationInfo and/or transportProtocol to one or more paired peers without re-pairing; either party may initiate.

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.

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, version, replica_id) 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, replica_id) tuples a Helper currently holds — used to reconcile state before driving Recovery, and to surface concurrent-write conflicts between Replicas.

• Recovery Flow retrieves shares from enough Helpers (≥ t), validates them, and reconstructs the Secret locally. No separate decryption step.

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

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 monotonically by the writing device 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.

In practice, Helpers store and return shares indexed by (secret_id, version, replica_id) — including replica_id in the key is what lets concurrent writes from sibling Replicas coexist side-by-side rather than overwriting each other.

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.