Implementation status
Publishing a specification before an implementation is deliberate — the design benefits from review while it is still cheap to change — but it makes an honest status page mandatory.
Where things stand
Section titled “Where things stand”SOP/1 (object plane)
Revision 8 is frozen as the implementation baseline. Further design change requires a successor document, not a revision. Two implementation-time items remain open by design.
SSP/1 (synchronization)
A new specification, complete enough to implement, sharing SOP/1's CBOR/COSE substrate, with its open gaps enumerated. It is not wire-compatible with any prior mesh synchronization protocol, and no interoperability with one is claimed. The absent conformance corpus is the largest remaining gap.
SOP/1 blob extension
A hand-authored extension specification bringing unstructured objects (photos, video, audio) onto the object plane. It changes nothing in SOP/1 and carries its own three decision gates (GB1-GB3), all open. Not implemented.
Implementation
Not started. No code, no released library, no wire-compatible peer. The dependencies the specification names are not yet integrated anywhere.
Decision gates
Ten gates (G1-G10) govern promotion from baseline to normative production protocol. All ten are open.
Interoperability
No conformance test vectors have been published for either layer. Until they exist, independent implementations cannot be checked against each other.
What comes next
Section titled “What comes next”The specification’s phased plan begins with isolated conformance prototypes. Ahead of that, three questions are being answered first, because each can reshape the design and each is cheap to test relative to the full Phase 0:
- Encrypted-Parquet interoperability. SOP/1 assumes an encrypted Parquet object can be written by one toolchain and read by another. Support across available implementations is uneven, and the size-padding requirement in particular may not be achievable with any current writer.
- Whether MLS can sign with a key it does not hold. The design binds the MLS credential to a device identity whose private key is non-extractable and may live in secure hardware. If the MLS implementation insists on owning its own signature keypair, the identity-binding design in section 5 changes shape.
- The cost of the sequencer. The blind commit sequencer in section 22 is a new stateful service with demanding correctness properties. It is plausibly the largest single piece of work in the specification and has not been sized.
Results will be published here as they land, including negative results. A gate that fails is information, not an embarrassment — the size-padding capability in particular is specified to fail closed rather than degrade, so “this cannot be done with current tooling” is a legitimate and useful outcome.
Known risks to the design
Section titled “Known risks to the design”These are recorded because a reader evaluating SOP/1 should know where it is least settled, not only where it is strongest.
| Area | Risk |
|---|---|
| Parquet encryption | Writer/reader interoperability is unproven; object size padding may be unachievable |
| Query path | One key per object may conflict with how query engines register decryption keys |
| MLS on constrained nodes | Group state must survive process death, long offline periods and software upgrade, including on mobile platforms |
| Hardware identity | Secure-element integration is platform-specific and may not be available everywhere |
| Sequencer | Correctness under equivocation, migration and state loss is intricate and untested |
| Performance | Encrypted Parquet has non-trivial overhead that has not been benchmarked on target hardware |
Two scope caveats
Section titled “Two scope caveats”The specification was written before sovm was positioned as a general-purpose sovereign mesh, and two artifacts of that remain visible. Neither affects the mechanism, but both are worth knowing before you build against the text.
The credential strategy assumes one human. Section 5.3 decides that a machine uses a single credential reused across all groups, and justifies it on the grounds that in a single-operator mesh the delivery service already links machine to group through routing, so pseudonymous per-group credentials would add overhead without a privacy gain. That reasoning is sound for its stated case and the section explicitly defers per-group pseudonymous credentials to a “multi-user future”. If your mesh has multiple operators whose activity should not be correlatable to each other, this is the one decision to revisit — everything else in the design is agnostic to how many humans stand behind the trust authority.
The examples are drawn from one application. Section 4.4’s table-classification example and the worked lifecycle in Appendix C use a personal-data vocabulary. They are illustrative, not normative, and will be generalized in a future revision. Read them as one instance of the pattern rather than as the intended scope.
Reading the specification with this in mind
Section titled “Reading the specification with this in mind”The specification uses RFC 2119 keywords throughout, which can read as more settled than the situation warrants. A useful convention while the gates are open:
- MUST / MUST NOT — a design commitment that an implementation is expected to honour, and which conformance vectors will eventually test.
- SHOULD — a considered default, more likely than the rest to move in response to implementation experience.
- Anything gated — treat as intent. Section 27 lists exactly which properties are gated and on what evidence.