Abstract and scope

Specification status

SSP/1 is a new specification, not a description of an existing deployment. It has no released implementation and no ratified conformance corpus. Where it resembles an earlier protocol that shipped elsewhere, that protocol is a predecessor rather than a compatible peer: SSP/1 is not wire-compatible with any prior mesh synchronization protocol, and no interoperability with one is claimed or intended.

Read the protocol family for how SSP/1 and SOP/1 divide responsibility.

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, content-addressed 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

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

• 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

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in BCP 14 ([RFC 2119], [RFC 8174]) when, and only when, they appear in capitals.

Every SSP/1 message is CBOR ([RFC 8949]). Where a canonical encoding is normative — everywhere bytes are signed or hashed — the Core Deterministic Encoding Requirements of [RFC 8949] section 4.2.1 apply; see the data model. Durable signed structures are COSE_Sign1 messages ([RFC 9052]) under the SSP/1 COSE profile. Text in this document renders CBOR structures with JSON-like syntax for readability; the wire form is always CBOR.

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 32-byte Ed25519 root identity public key. 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. Stable across key rotation.

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.

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

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