Normative · Part
Abstract and scope
Abstract
Section titled “Abstract”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.
What SSP/1 is for
Section titled “What SSP/1 is for”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.
What SSP/1 does not specify
Section titled “What SSP/1 does not specify”- 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.
Conventions
Section titled “Conventions”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.
Terminology
Section titled “Terminology”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.
Relationship to the object plane
Section titled “Relationship to the object plane”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.
Known gaps
Section titled “Known gaps”SSP/1 has open gaps, and they are enumerated rather than left for a reader to discover. See limitations before implementing.