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 additional device the Owner pairs as a ReplicaDestination joins the set that receives every update to the Secret.

A replica device is, once fully synced, indistinguishable from the original Owner to the rest of the network. Helpers cannot tell whether they're talking to the Owner or to one of its replicas, and neither can other replicas — every replica authenticates against the same per-channel keys, every replica can drive the protocol against the Helper set and against sibling replicas, and every replica holds the same plaintext secrets. The only field that distinguishes them is replica_id, which the protocol stamps on every outbound write so the Helper can detect concurrent writes from siblings. See Conflict resolution for what the Helper does with that.

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 delivered to every paired replica device. The wire mechanism is the same ProtectSecret flow Helpers receive, but a replica receives the full Secret instead of a single VSS share — see Secret synchronization for the payload shape.

The unidirectional model

A replica relationship is directional. When device A pairs with device B in a ReplicaSource → ReplicaDestination configuration, 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: device B as ReplicaSource, device A as ReplicaDestination. The protocol does not require this and does not arrange it automatically. Applications that want every device in a set to mirror every other device's state pair them pairwise at the application level.

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, 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.

• 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.