Extensions — Domain Roadmap (canonical, living)
What this domain is: the optional, opt-in capability layer above the core protocol. An extension is a contract: implement it and you interoperate with peers that also implement it. The core floor never requires any of these (except TREE's get/put, which lives in core) — they are the "agree with us → you interoperate" surface, validated 3-way (Go/Rust/Python) and generated by keystone.
Floor: Go/Rust/Python --profile full 0-FAIL (release-green) · 26 extension specs landed + ~10 in proposal.
network-peer-vsstandard-peer-is an organizational tag, not structure. We file extensions in those two folders for navigation, but the split carries no boundary meaning — all 26 extensions ship toentity-system-architectureregardless of folder. The real dependency structure is the topology (TOPOLOGY-CORPUS-FOR-PAPERS.md— planned, not yet authored): a foundational tier (CONTINUATION/SUBSCRIPTION/REVISION/INBOX/HISTORY/QUERY) heavily depended-on, an identity sub-cluster (IDENTITY/ATTESTATION/QUORUM/ROLE/GROUP), and a leaf network frontier — which cuts across the folder tags. The exhaustive file list isINVENTORY-RELEASE-CORPUS.md(planned, not yet authored).
The maturity ladder (recap)
M0 Proposed → M1 Ratified → M2 Landed → M3 Implemented → M4 Peer-converged (3-way) → M5 Validated (vectors) → M6 Keystone-converged. Trajectory is the orthogonal "is it moving?"
axis: 🟢 stable · 🟡 active · 🔴 volatile/pre-review.
The extension domain spans the full ladder — from the frozen v1 set (M5, 🟢) through the network/resolution family still converging (M2–M4, 🟡) to early proposals (M0–M1).
Stage A — The v1 extension set (M5, 🟢 stable): READY
The mature core library. 3-way converged + gated by conformance vectors (validate-peer
categories / fixture corpus / GUIDE-CONFORMANCE §9). These are the shippable v1 surface.
Each spec's own
**Version**header is authoritative for that document. This table restates those headers for navigation and is not the authority — if the two disagree, the header wins and this table is the defect. Re-synced against the headers at the 0.8.2 line.
| extension | ver | what it provides |
|---|---|---|
EXTENSION-TREE | 4.3 | snapshot / diff / merge / extract, the HAMT trie, tracked roots, the published root. Extends core's system/tree handler rather than registering its own — see the note under Stage A |
EXTENSION-CONTENT | 3.6 | content-hash address space, closure materialization, partial-sync |
EXTENSION-TYPE | 1.2 | runtime type registration |
EXTENSION-REVISION | 3.12 | revision chains, diff/merge-config, deletion markers |
EXTENSION-SUBSCRIPTION | 3.18 | reactive subscriptions, cross-peer mirror |
EXTENSION-CONTINUATION | 1.23 | forward continuations, structural-transform chains |
EXTENSION-INBOX | 5.9 | message inbox, delivery |
EXTENSION-HISTORY | 1.7 | parent-ref history walk |
EXTENSION-QUERY | 1.7 | entity query / path-prefix |
EXTENSION-COMPUTE | 3.27 | expression evaluation, the lowering toolkit |
EXTENSION-GROUP | 1.4 | group membership |
EXTENSION-IDENTITY | 3.10 | identity convention over the attestation substrate |
EXTENSION-ATTESTATION | 1.3 | generic attestation edge substrate |
EXTENSION-QUORUM | 1.2 | K-of-N quorum primitive |
EXTENSION-CLOCK | 1.3 | logical/wall clock |
EXTENSION-ROLE | 2.0 | role assignment + delegation (M4→M5: v2.0 root-cap green round pending) |
How an extension attaches, which is not visible from a version column and which an implementer needs before choosing an order. Most extensions register a new handler at a new pattern (
system/content/*,system/inbox,system/query, …) and install throughSDK-OPERATIONS§11.6'sregister_handlerwithout touching anything the core peer already bootstrapped.EXTENSION-TREEis the exception: its §9 addssnapshot/diff/merge/extract/create/destroyto core's existingsystem/treehandler rather than registering its own, andSDK-OPERATIONS§11.6 returns 409 on a pattern collision and forbids silent overwrite — so installing TREE onto a conformant core peer is not yet expressible through the registration primitive.EXTENSION-TYPEmay be in the same class.EXTENSION-TREE§9 additionally records thatsystem/tree/snapshot/nodeandsystem/tree/tracking-configrequire bootstrap type IDs in the core protocol's table. Both are open specification items; an implementer building TREE onto a separately-built core peer should expect to need them resolved.
Phase note: ROLE v2.0 is the one Stage-A item with a pending convergence round (root-cap shape); promote to M5/🟢 on green. The identity stack (IDENTITY/ATTESTATION/QUORUM/GROUP) is a layered substrate — ATTESTATION is the generic edge primitive, IDENTITY is a convention over it.
Stage B — The network / resolution family (M2–M4, 🟡 active): CONVERGING
The peer-to-peer surface — transport, relay, routing, name resolution, discovery, encryption. Landed as specs; implementation converging. This is the release-critical work-in-flight.
| extension | ver | maturity | phase / open work |
|---|---|---|---|
EXTENSION-NETWORK | 1.6 A14 | M4 | transport family; v1 publish/relay gate 3-way green. Base wire framing is core. Amdt 8 (session entity) / 11 (dispatch-fallback) / 13 (reachability facts) / 14 (establish_live seam) folded. |
EXTENSION-RELAY | 1.3 | M4 | dispatch-fallback seam folded; §8 store bounds (retention clamp + storage refusal) landed; R8 raw-frame gaps tracked. 2 of the 4 modes still carry no normative text |
EXTENSION-ROUTE | 1.0 | M3 | source-routed multi-hop; Go build-tested, cohort catching up |
EXTENSION-SIGNALING | 1.1 | M3 | system/signaling rendezvous carrier + system/nat/*; built three ways, unwrapped surface + punch not yet built |
EXTENSION-SUBSTITUTE | 1.3 | M4 | CDN release v1 (Tier-1) — Mechanism-A storage substrate |
EXTENSION-REGISTRY | 1.21 | M2→M3 | substrate + local-name + peer-issued resolve landed; v1 NOT complete (see Stage E) |
EXTENSION-DISCOVERY | 1.1 | M2→M3 | mDNS peer-finding; impl-ready |
EXTENSION-ENCRYPTION | 1.0 | M2→M3 | self/peer/group; BLOCK-0 byte-pin green 3-way; BLOCK-1 end-to-end gating v1.0 (Stage E) |
Phase ordering in this family: NETWORK transport → RELAY/ROUTE forwarding → REGISTRY/DISCOVERY resolution → ENCRYPTION confidentiality. The unsolved root under all of it is consumer↔consumer connectivity (browser/phone ↔ desktop, both NAT) — the cheapest attack is the browser WebRTC transfer demo (Milestone 1), off the critical path but the proof point.
The connectivity build order (the consumer↔consumer root — now designed)
The "unsolved root" now has a designed, dependency-ordered build plan (2026-07-22); steps #0 and #1 are folded spec as of 2026-07-31. Each step is additive — none a wire renumber. (Corrected 2026-07-31: this previously said every step rides "the already-reserved NETWORK §10.2 seam." Two refinements — the facts are a NETWORK amendment and ride no seam at all, and the punch needed its own seam, §10.3, because §10.2 returns a delivered result where traversal must return a reusable connection. The carrier is also not a NETWORK amendment at all: it is a new handler with its own conformance posture, so it landed as its own extension.) Operator calls settled: signaling carrier = stateless rendezvous (v1), QR secondary-under-review; substrate = TCP-simopen first, our-QUIC the sequenced upgrade; relay/async = opt-in dedicated-peer tier.
| # | unit / proposal | what | buildable | depends on |
|---|---|---|---|---|
| 0 | ✅ NETWORK §6.7 (Amendment 13, folded 2026-07-29) | reflection + dial-back + candidate gathering + network-reflect/network-dialback caps | now — landed spec; the two ops are not yet in any tree | — |
| 1 | ✅ EXTENSION-SIGNALING.md v1.0 (folded 2026-07-31) | system/signaling rendezvous carrier + system/nat/* coordination + the punch + TCP-simopen; registers behind NETWORK §10.3 (Amendment 14, the live-establishment seam) | BUILT — carrier/key/coordination/pool + clients in all three (rust extensions/signaling + cmd/entity-signaling-node; go ext/signaling + cmd/signaling-meet; py entity_handlers/signaling), Go's validator carries a signalingMeet cross-impl check. Stage 2 (unwrapped surface, punch) not yet built. | #0 |
| 2 | our-QUIC transport (study Iroh, build our own) | the quic candidate substrate — better punch reliability | after #1 proves the coordination protocol | our own QUIC transport (large, separate) |
| 3 | PROPOSAL-EXTENSION-WEBRTC-TRANSPORT (bring fwd, unit #3) | fills the reserved webrtc §10 slot; SDP/ICE schema on the signaling carrier — the browser leg | parallel track (browser demand; the cheapest end-to-end exercise of the whole arch) | #1 signaling carrier |
| 4 | RELAY Mode-C (opt-in) | live relayed circuit — last-resort fallback when a punch fails and liveness is needed (symmetric-NAT pairs) | gated on a real-time driver | RELAY; a driver |
Rides alongside (infra, not on the punch critical path): PROPOSAL-REGISTRY-SERVICE-ADVERTISEMENT
(advertises the reflector/signaling pools + optional relay fallbacks) + GUIDE-REFERENCE-DEPLOYMENT
(budget tiers). Cohort build target / the integration test: entity-chat — buildable today on the
async floor (mDNS + registry + INBOX/CONTINUATION + EMBED, all Active); live P2P (steps 1+) is the upgrade,
not a blocker. A real five-layer chat exchange (discover→resolve→connect→message→render) between two
conformant peers is the best integration test the whole stack has — and, per the CDN-corridor meta-rule,
the only real validation gate for the connectivity/infra/chat design. Near-term spine: #0 + #1 +
entity-chat-on-the-async-floor. #2/#3 are parallel/deferred; #4 is opt-in.
Stage C — Early / parked (M0–M2, 🔴)
| extension | ver | state |
|---|---|---|
EXTENSION-TRANSACTION | 0.1 | initial design, pre-review |
EXTENSION-DURABILITY | 0.1 | exploratory, extracted from INBOX §10; optional, not active |
Stage D — Proposed, not landed (M0–M1): design intent in proposals/
Not shipping as specs; several are real and load-bearing-but-forthcoming (cited in landed specs
as (planned)): BRIDGE-HTTP · BRIDGE-SMTP · GOSSIP · PEER-MANIFEST-STATIC-HANDSHAKE ·
NAME-GRAMMAR · UNIVERSAL-RESOLUTION · GROUP-V1.5 · STATIC-PEER-HOSTING-UMBRELLA · DOMAIN-LOCAL-IO ·
APPLICATIONS-DOMAIN · ENCRYPTED-SESSION. (The archived NAT-TRAVERSAL DRAFT is brought forward,
reconciled, as the two connectivity proposals above — see the Stage B build order.)
Stage E — Forward-feature backlog of LANDED extensions (NOT shipping v1)
The "Landed" label hides incomplete sub-features one level down. Tracked so "Landed" isn't misread as "complete." Each is a forward feature of a shipped spec, not a separate proposal.
EXTENSION-REGISTRY (v1 NOT finished — its own COMPLETENESS banner is authoritative):
| feature | ref | state |
|---|---|---|
Live registration open/allowlist/manual | §6a.9 | 🟡 design folded, build in flight |
| Signed binding-manifest impl | §6a.7 | 🟡 format locked, impl deferred |
domain-control DNS-challenge format | §6a.9.1 | 🔴 not yet designed |
| Other backends: did-web / dns-txt / dht / consensus-anchored | §12 | 🔴 not yet designed (each its own proposal) |
| Aggregator Mode-A federation · outbound DID/DNS bridge | §8.2 / §12 | 🔴 v1-deferred |
EXTENSION-ENCRYPTION (base v1.0 landed; close-out gated on BLOCK-1):
| feature | state |
|---|---|
| BLOCK-1 end-to-end validation (relay-encrypted send, group re-key, rotation/revocation, storage round-trip, cross-tier interop, key separation, sender auth) | 🟡 dispatched, gating v1.0 |
| Sealed-sender / padding / hybrid-PQ / Shamir Tier-3 (§19) | 🔴 designed, not impl |
EXTENSION-ENCRYPTED-SESSION (Signal/Noise/MLS sibling, §20) | 🔴 deferred post-release |
Notes for the content/papers project
- The honest framing: Stage A is the shippable library; Stage B is the release-critical frontier; Stage E is named forward work so "Landed" isn't oversold.
- The per-spec
Status:header is unreliable (many M5 extensions still read "Draft" — see canonical map §6). Use the M-level here, not the header.