The protocol standard
A standard, formed in the open.
A protocol only one team can change is a product. We are beginning to turn Secure Net into a standard: a written specification that anyone can implement, changed only through public proposals, review and a recorded decision by people.
Where this stands: the process is a draft and has not been ratified. The committee that will decide does not exist yet beyond the founder.
How a change is made
Every change to what two implementations must agree on goes through a Secure Net Improvement Proposal. The peach mark shows the steps only people can take.
Step 1: A public proposal
Anyone writes down the problem and the intended solution as a numbered Secure Net Improvement Proposal.
Step 2: Examination (a decision for people)
Maintainers and independent developers look at security and at whether existing sites and applications keep working.
Step 3: Working code and tests
A reference implementation and tests show the change does what it says. Without them it can be discussed, not accepted.
Step 4: A recorded decision (a decision for people)
The Technical Steering Committee accepts or rejects it, and writes its reasons into the proposal.
Step 5: Into a numbered version (a decision for people)
Only after the required review does it become part of a versioned specification. Accepting it does not deploy it anywhere.
A proposal moves through these states: Draft, Public review, Technical review, Accepted or rejected, Implemented, Released.
Breaking changes cost more
A change that would make an up-to-date site and an older one disagree needs a higher level of approval and a published plan: who must update, by when, what happens to those who have not, and how to go back.
AI can prepare. It cannot vote.
AI tools may draft proposals, write code and tests, and review. They cannot sit on the committee, and their approval never stands in for a person's. Work an AI prepared says so.
The parts of the specification
23 parts, each numbered. Each carries the status its own document gives it. Draft means written and usually implemented, but not yet reviewed and accepted.
Read from GitHub on 15 November 2026 at 23:17 UTC, and refreshed about every 10 minutes.
CVP-000
Status: Draft, version 1How the standard works: language, versions, compatibility, registries, conformance
CVP-001
Status: Draft, version 1Identifiers, keys, signatures, rotation, recovery, personas, migration
Implemented, but its document is still to be written.
CVP-002
Status: Draft, version 1Canonical encoding and signed records
CVP-003
Status: Draft, version 1Account-wide envelopes and community keys (older; superseded for new messages by CVP-016)
Implemented, but its document is still to be written.
CVP-004
Status: Draft, version 1Spaces, channels, membership and policy
Implemented, but its document is still to be written.
CVP-005
Status: Draft, version 2Site-to-site federation
Implemented, but its document is still to be written.
CVP-006
Status: ReservedAttachments, retention and backup
Number set aside. Nothing written yet.
CVP-007
Status: ReservedReports, disclosures and federation controls
Number set aside. Nothing written yet.
CVP-008
Status: Draft, version 1Extensions, themes and feature negotiation
Implemented, but its document is still to be written.
CVP-009
Status: ReservedBridges and labels
Number set aside. Nothing written yet.
CVP-010
Status: Draft, version 1Conformance: profiles, statements and tests
CVP-011
Status: Draft, version 1Commons ledger: replication and failover
CVP-012
Status: Draft, version 1Governance: motions, debates and votes
CVP-013
Status: Draft, version 1Private tokens (RFC 9497 VOPRF)
CVP-014
Status: Draft, version 1Consent capsules
Implemented, but its document is still to be written.
CVP-015
Status: Draft, version 1Quantum resistance and the sealed relay
CVP-016
Status: Draft, version 2End-to-end sessions: post-quantum handshake, ratchet with encrypted headers, devices, sender keys, new devices
CVP-017
Status: Draft, version 1Actors and discovery: self-certifying actor documents and handles
CVP-018
Status: Draft, version 1Activities and objects: the ActivityStreams vocabulary, signed on devices
CVP-019
Status: Draft, version 2Delivery: public, direct, audience and group envelopes, end to end encrypted; sealed sending
CVP-020
Status: Draft, version 1Repositories and sync: an actor's public activities as a signed, portable, verifiable set
CVP-021
Status: Draft, version 1Lexicons: new object types named by domain
CVP-022
Status: Draft, version 1Groups: Messaging Layer Security (RFC 9420) with a hybrid post-quantum suite
CVP-001
Status: Reference code and testsIdentity, keys, recovery, personas and moving between sites
CVP-002
Status: Reference code and testsOne exact encoding for everything that is signed
CVP-003
Status: Partly doneEncryption between people and devices
Group messaging by a recognised standard (MLS) is proposed in an open pull request, not yet accepted.
CVP-004
Status: Reference code and testsCommunities, channels, membership and rules
CVP-005
Status: Reference code and testsHow sites talk to each other
CVP-006
Status: Not in the standard yetAttachments, retention and backup
Exists in Commonveil. Not yet written into the standard.
CVP-007
Status: Not in the standard yetReports, disclosures and site controls
Exists in Commonveil. Not yet written into the standard.
CVP-008
Status: Reference code and testsExtensions, themes and agreeing on features
CVP-009
Status: Not startedBridges to other networks
CVP-010
Status: Partly doneTests any implementation can run to prove it conforms
The reference library's own tests exist. A suite for other implementations does not.
CVP-011
Status: Reference code and testsA community history that sites can copy and take over from
CVP-012
Status: Reference code and testsProposals, debates and votes
CVP-013
Status: Reference code and testsPrivate one-use tokens
CVP-014
Status: Reference code and testsConsent that can be withdrawn
CVP-015
Status: Reference code and testsQuantum resistance and the sealed relay
Awaiting human security review.
CVP-016
Status: Reference code and testsEnd-to-end sessions: a post-quantum handshake, a ratchet, several devices and sender keys
Awaiting human cryptographic review.
The first three proposals
The process starts by being applied to itself, and to work that came before it.
- Status: Draft
SNIP-0001: The proposal process
Proposes adopting the process described on this page.
- Status: Public review
SNIP-0002: The sealed relay and quantum-resistant signatures
Written into the code before this process existed. It is recorded as experimental until a qualified person has examined it.
- Status: Draft
SNIP-0003: Post-quantum end-to-end sessions
Implemented for review in version 0.4.0. Not yet examined by any human reviewer.
What a standard still needs
These do not exist yet. Each is somewhere you could help.
Independent review
A qualified person examining the cryptography and the checks between sites.
A second implementation
Someone outside Comutability building software that speaks the protocol.
A conformance suite
Tests any implementation can run to show it follows the specification.
A committee
Three to five human maintainers, including independent contributors.
Sites run by different people
Proof that it works across servers nobody here controls.
Plain-language documentation
So people who are not developers can judge what it does for them.
Take part in forming it.
You can ask a question, point out a problem or write a proposal. You do not need to be a cryptographer: questions from people who would use this are as useful as code.