SOVM/1

Sovereign Mesh is SOVM/1, one specification with numbered parts: a shared substrate, a synchronization layer, and an encrypted object plane above it. The two layers are architecture, not document boundaries — an implementation may build either layer without the other, and the seam between them survives as a conformance claim (the object plane without synchronization is the host-only profile of the conformance clause).

Layer	Part	Replicates
Upper	SOP/1 — Sovereign Object Plane	High-volume immutable data as encrypted objects
Lower	SSP/1 — Sovereign Synchronization Protocol	Small mutable state, plus identity, ordering and policy

Why two layers

Because the two kinds of data want opposite mechanisms, and forcing either into the other’s shape is expensive.

Immutable data — measurements, telemetry, logs — has no conflicts to resolve. Adding an object to a set is commutative and idempotent, so it needs no ordering, no merge algebra and no coordination. Paying per-row replication cost for a hundred million sensor readings is pure waste.

Mutable state — configuration, entity records, catalog metadata — genuinely can be edited on two machines at once, and must converge to the same value afterwards. Deterministic merge is unavoidable, and content-addressed immutable objects cannot express it.

So each layer uses the cheapest primitive that is actually correct for its data. That is the organising decision of the whole specification.

How they divide

flowchart TD
  accTitle: How the two Sovereign Mesh layers divide responsibility
  accDescr: Application queries reach a local engine that reads both the mutable state maintained by SSP/1 and the immutable object plane maintained by SOP/1. SOP/1 depends on SSP/1 for identity, admission, scope, hybrid logical clocks, mutable convergence and the mailbox. SSP/1 depends on SOP/1 for nothing.
  app["Application / query"] --> engine["Local query engine"]
  engine --> mutable["SSP/1<br/><small>mutable state, merge semantics</small>"]
  engine --> objects["SOP/1<br/><small>immutable encrypted objects</small>"]
  objects -->|"depends on"| host["SSP/1 host interface<br/><small>identity, admission, scope, HLC, mailbox</small>"]
  mutable --- host

SOP/1 depends on SSP/1 for six things. SSP/1 depends on SOP/1 for nothing — it is implementable and useful on its own.

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

That dependency list is written down as a contract in the host interface, which means SOP/1 can also run over a different host that satisfies it. The object plane’s data path — encryption, content addressing, manifests, placement, compaction — touches none of SSP/1’s wire format, canonical encoding, cursors or merge algebra.

Where each part stands — what exists, what is gated, what is implemented — is one page: the status of this specification.

One substrate

Two layers does not mean two stacks. Both share one substrate, and it is a normative part of its own — the shared substrate: deterministic CBOR ([RFC 8949]), COSE_Sign1 records under one profile, BLAKE3 over exact signed bytes as the single hash convention, one chained-record schema for policy-shaped state, one padding function, and one transport family. An implementation of the whole specification carries one codec and one signature container, and a structure defined in either layer verifies with the same machinery in the other. Neither layer restates a substrate rule.

The transport family is the concrete case. SOP/1 names iroh as its preferred live network substrate — endpoints addressed by public key over QUIC, direct paths attempted first, NAT traversal where possible, encrypted relay fallback where not — and SSP/1’s default live binding is mutually authenticated QUIC with raw public keys, chosen deliberately to be the same family. A mesh running both layers therefore carries one transport stack rather than two. Neither layer mandates a specific implementation: SSP/1 defines a binding profile, not a dependency.

Document classes

SOVM/1 has four document classes, and only four.

Class	What it is
Part	A normative division of the one specification — the substrate, the layers, the host interface. Versioned with the specification, never independently
Module	A claimable conformance unit: whole sections plus a single omission behaviour, indexed on the profiles page
Binding specification	How SOVM/1’s messages cross a named transport, plus a registered identifier. Adds no semantics
Annex	A capability layered on registered extension points, carrying its own status and gates

One annex is currently specified:

Annex	Host	Adds
SOP/1 blob annex	SOP/1	Unstructured objects (photos, video, audio) as chunked-AEAD blobs — object kind blob, format SOP-BLOB-1

An implementation that does not adopt an annex fails closed on its identifiers (SOP/1 §12.3), which is what makes omission its default state.

There is no separate successor-document class: a change to the specification is applied to the specification and published as a revision of it. SOVM/1 carries one revision track, and this is Revision 2 of it — the changelog records every revision and what it changed.

How to read it

Conventions states how the requirement keywords are to be read, which encodings every part shares, and how a section is cited. Terminology holds the vocabulary the parts share and the five words that mean different things in each.

Which to read

If you want to understand the system, start with what sovm is and then how it works. The specification is not a good introduction, and it is not written to be.

If you are implementing the object plane, read the host interface first — it is the contract you must satisfy or supply — then SOP/1.

If you are implementing synchronization, read SSP/1 in order. Read its limitations before writing code, not after.

If you are evaluating whether to build on this at all, read the status of this specification and the two limitations pages. They are short, and they are where the honest answer lives.