Replicas

The DeRec protocol's replica feature lets an Owner sync the Secret with additional devices. There is no protocol-level limit on how many devices an Owner can have as replicas; each device paired as a ReplicaDestination joins a replica group that receives every update to the Secret.

To the Helpers, every member of a group is the Owner. Helpers cannot tell which device they are talking to: every member holds the same per-Helper keys, publishes to a Helper as the Owner, and helper-bound messages carry no replica identity. Inside the group, two things tell members apart:

• replica_id — the stable per-device identity. Every member is stored under it, and the protocol stamps it on replica-bound messages so a member can be attributed on the one channel every member shares. See The replica_id field.

• ReplicaRole — Source or Destination, persisted per member and carried in the roster. Exactly one member is the Source. The role breaks ReplicaDiscovery ties and moves to a successor when the Source is removed. See Source and Destination roles.

Apart from those, members are operationally equivalent: any member can publish, verify, recover, and remove another member.

Replicas exist to synchronize the Secret across devices that belong to the same entity or human being — a user's phone and laptop, or a team's primary and disaster-recovery hardware. Replicas are not a multi-party construct. Every replica device sees every secret.

Synchronization is driven by Secret versions. Whenever the Secret changes, the new version is published to every paired member. The wire mechanism is the same ProtectSecret flow Helpers receive, but a member receives the full Secret instead of a single VSS share — see Secret synchronization for the payload shape. Delivery to members is best-effort: a member that misses a version is reported in ReplicaSyncComplete.behind and catches up later.

Two replica-only flows sit alongside it, both documented in Flows:

• ReplicaDiscovery — a device that was offline asks every other member which version it holds and pulls the newest, concluding with ReplicaDiscoveryComplete. Convergence is automatic while the group is writing; this closes the gap for a quiet group. Nothing triggers it automatically.

• UnpairReplica — removes a member. start only announces the removal: it completes when the application publishes a roster omitting that member. A group with no Secret to publish cannot complete a removal at all. See Replica removal.

The unidirectional model

A replica relationship is directional. When device B scans device A's contact and pairs as ReplicaDestination, device B becomes a replica of device A: it learns device A's Secret and can act as device A toward A's Helpers and toward A's other replicas. Device A learns nothing about device B's Secret — if B is also the Owner of a Secret of its own, that Secret is invisible to A.

To make the relationship bidirectional — each device a replica of the other — the application drives a second pairing in the opposite direction, under the other Secret's secret_id. The protocol does not require this and does not arrange it automatically.

The core security trade-off

The replica feature gives every paired device the full Secret. The Secret contains everything the Owner has — the plaintext user-facing secrets, the per-Helper keys negotiated with every paired Helper, the single shared key the replica group uses to talk among itself, the roster of paired peers, the metadata. The full field-by-field treatment lives in Secret.

The benefit: a replica can drive recovery against the Helpers without contacting the original Owner. The original Owner can be permanently lost and the Secret still recovers — that is the whole point of the feature.

The cost: a replica device that is compromised is equivalent to a compromised Owner. There is no privilege separation between Owner and replica. A compromised replica can read every secret, impersonate the Owner toward every Helper, overwrite the Secret, remove other members, and tear down channels.

This trade-off is the central topic of Recovery transitivity. Applications using the replica feature should read that chapter before deciding which devices they are willing to pair as replicas.

When replicas are NOT the right tool

Replicas synchronize the Secret across devices that belong to the same entity. They are not:

• A multi-party authorization mechanism. Every replica has the cryptographic ability to act unilaterally as the Owner. There is no "M-of-N replicas must agree before publishing" semantics, and the protocol does not enforce one. Any member can remove any other, the Source included.

• A read-share channel. A replica receives the full Secret, including plaintext user secrets. Do not pair a device as a replica with a party that should only see a subset.

• An alternative to threshold recovery. Replicas are a copy of the Owner-side state, not an additional layer of cryptographic protection. The threshold guarantee still comes from the Helper set; replicas sit on top of it.

• A bidirectional sync protocol. A replica relationship is directional — see The unidirectional model. Applications that need mutual mirroring set it up by pairing in both directions.

In this section

• Source and Destination roles — pairing roles, group roles, replica_id, succession.

• Pairing replicas — the fingerprint gate, the adoption decision, the group-key handover.

• Secret synchronization — publishing, hydration, catch-up.

• Recovery transitivity — why every member is Owner-equivalent.

• Conflict resolution — two copies of one version, and what the application must do.

• Replica removal — who may remove whom, the two-half safety rule, succession.