Skip to content

Normative · Part

Abstract and scope

This document specifies the Sovereign Synchronization Protocol (SSP/1), the lower of the two Sovereign Mesh layers. SSP/1 replicates small, genuinely mutable state across the nodes of a single trust authority, and supplies the identity, ordering and policy primitives that the Sovereign Object Plane builds on.

SSP/1 is an eventually-consistent change-event replication protocol. It defines:

  • the change event as the unit of replication, carried as a COSE-signed deterministic-CBOR message;
  • a hybrid logical clock giving a total order across nodes without a coordinator;
  • per-event authentication binding each event to the node that authored it;
  • deterministic convergence by per-column last-writer-wins with causal-length existence tracking, so concurrent edits and concurrent delete/re-insert resolve the same way on every replica;
  • per-peer cursors and applied watermarks giving at-least-once delivery with idempotent apply;
  • an optional realtime mode pushing events over a held live connection as they are produced, with the batch cycle as the correctness backstop;
  • the scope mechanism bounding what may replicate at all;
  • node admission, vouching and revocation;
  • an abstract mailbox contract for asynchronous delivery.

The dividing principle across the two layers is to use the cheapest primitive that is actually correct for the data in question.

High-volume append-only data — measurements, telemetry, logs — does not need conflict resolution, and paying per-row replication costs for it is waste. That data belongs in SOP/1 as immutable encrypted objects.

What is left is comparatively small and genuinely contended: configuration, entity records, catalog metadata, user preferences — state that two nodes can edit while partitioned and that must converge to the same value afterwards. Deterministic merge is unavoidable there, and SSP/1 is where it lives.

So SSP/1 is not a scaled-down object plane, and SOP/1 is not a generalization of SSP/1. They are different mechanisms for different data, deliberately kept apart.

  • Bulk data replication. Objects are SOP/1’s concern.
  • Transport. SSP/1 defines message semantics and an abstract mailbox contract, not a wire binding. See transport.
  • Transport confidentiality. Provided by the binding. SSP/1 requires only that a mailbox operator cannot read payload plaintext.
  • Group key management. Where a mesh runs SOP/1, MLS (RFC 9420) manages cryptographic group state. SSP/1 does not define a group-key protocol of its own.
  • A vendor service API. Node registration, account management and quota are product concerns outside this specification.

The requirement keywords, the deterministic-CBOR rule and the JSON-like rendering of CBOR structures are the specification’s conventions and are not restated here.

Two are specific to this part: canonical encoding is normative everywhere bytes are signed or hashed, and the data model states where; durable signed structures follow the SSP/1 COSE profile over the substrate’s container.

mesh — the set of nodes under one trust authority that replicate to each other. SSP/1’s trust boundary runs around the mesh: other authorities, relays, mailbox operators and shared infrastructure are outside it.

node — one member of a mesh.

trust authority — whoever holds the mesh’s root of trust and decides admission. May be one person or an organization; SSP/1 does not model which.

site_id — a node’s stable identifier: the first 16 bytes of BLAKE3(IK_pub), where IK_pub is the node’s P-256 root identity public key in the 33-byte SEC 1 compressed encoding (identity). The derivation takes the compressed encoding and no other: a key presented in any other encoding is rejected rather than converted (encoding canonicity), because without the pin one key yields two site_ids. Rendered as 32 lowercase hex characters. A node has exactly one site_id for the life of its identity key.

mesh_id — the mesh identifier: the first 16 bytes of BLAKE3("sovm-mesh-id-v1" || IK_pub_founder), where IK_pub_founder is the root identity key of the node that created the mesh, in the same 33-byte compressed encoding with the same reject-don’t-convert rule — one founding key must not yield two meshes. Stable across key rotation. The label is a hash-derivation separator with no verifier and no fail-closed semantics — a mesh_id is an opaque 16 bytes compared for equality — which is why it does not carry a version that tracks the key encoding.

change event — the unit of replication. See data model.

HLC — a hybrid logical clock timestamp: the pair (physical_ms, logical).

mailbox — an asynchronous store-and-forward channel that moves opaque payloads between nodes of one mesh without being able to read them.

syncable scope — the bound on which tables may replicate. See scope.

row tombstone — the sync layer’s deletion marker: a delete tombstones a row, and a later, higher-HLC upsert legitimately resurrects it (semantics). Where this part says “tombstone” unqualified, it means this one; the object plane’s permanent identity tombstone is a different construct, and terminology holds the distinction.

purge — a reserved SSP/1 operation token with no specified message format, which an implementation MUST fail closed (scope §18.2). The object plane’s physical purge is a different operation; see terminology.

SOP/1 depends on SSP/1 for six things, and SSP/1 depends on SOP/1 for nothing:

SOP/1 needs Defined in
Stable node identity and its signing key terminology, identity
Admission and removal decisions identity
Scope policy lookup scope
Hybrid logical clock values data model
Mutable-table convergence semantics
An asynchronous mailbox transport

An implementation MAY implement SSP/1 alone. An implementation of SOP/1 requires SSP/1 or another host satisfying the host interface.

SSP/1 has open gaps, and they are enumerated rather than left for a reader to discover. See limitations before implementing.