16. Extension Mechanism
MMP is designed for extensibility. Extensions add new frame types, handshake fields, or protocol behaviours without modifying the core specification.
16.1 Extension Registration
Extensions are advertised via the extensions field in the handshake frame.
A node MUST ignore extensions it does not recognise. A node MUST NOT require a peer to
support any extension.
16.2 Frame Type Naming
Core types (this specification): MUST NOT be redefined by extensions.
Extension types: MUST use <extension>-<name> format
(e.g., mesh-group-join).
Vendor types: MUST use x-<vendor>-<name> format.
Vendor types MUST be silently ignored by non-supporting nodes.
16.3 Extension Negotiation
If both peers advertise the same extension in handshake, it is active. If only one peer advertises it, the extension is NOT active — the advertising peer MUST NOT send extension-specific frames to a peer that does not support them.
16.4 Registered and Candidate Extensions
| Extension | Status | Specification |
|---|---|---|
| mesh-group-v0.1.0 | Proposal | MMP Mesh Group Extension v0.1.0 — generic transient subgroup primitive formalising §5.8 (group identity, Bonjour + relay discovery, group-scoped CMB tagging, membership lifecycle). First use case: MeloTune Mood Room. (Draft — promotes to Published upon second-implementer adoption per the extension’s own §10, Promotion Criteria.) |
| group-directory-v0.1.0 | Draft | MMP Extension: Group Directory v0.1.0 — persistent group metadata, admin approval workflow, and directory enumeration. Higher-layer extension building on §5.8 mesh groups for chat-platform-style UX (browse / request-to-join / approve). (Draft — pre-implementation; promotes on first reference impl per §16.5.) |
| error-handling-v0.2.0 | Draft — Candidate Extension | MMP Extension: Error Handling v0.2.0 — application-layer CMB convention; no wire-format change. Failure as a first-class cognition event: evidence-carrying corrective requests with lineage-borne parentage, receiver-autonomous volunteering, one-level repair, and separate grounding of failure and fix. v0.2.0 adds a proposed receiver-local Adaptation-on-Failure loop (§6–§8): field accountability with a counterfactual-ablation guard, and a per-failure choice between decrementing the SVAF gate (boundary of responsibility) and ingesting to the CfC state (capability growth), routed by competence-distance. (Draft — the failure-event convention has an experimental reference implementation; the adaptation loop §6–§8 is proposed, not yet implemented, and gated on a register-first router-validation study; promotes per the extension’s own Promotion Criteria.) |
| trust-horizon-v0.1.0 | Draft — Candidate Extension | MMP Extension: CMB Trust Horizon v0.1.0 — application-layer CMB convention; no wire-format change. Validator-attested, knowledge-scoped trust-weight invariants: a grant governs how earned influence persists (never how it is minted), interpreted per receiver under operator policy, with Canon-retention separation. (Draft — a reference deployment reports an experimental implementation; independent interoperability not yet established; promotes per the extension’s own Promotion Criteria.) |
16.5 Extension Lifecycle
Extensions progress through a defined lifecycle:
- Proposal: submit as a Draft extension with a specification document and at least one reference implementation.
- Review: community review plus spec maintainer approval. Draft extensions MAY be deployed experimentally but MUST NOT be treated as stable.
- Promotion to Core: an extension MAY be promoted to a core frame type. Promotion requires a spec version bump (see the versioning policy, spec index) and MUST maintain backward compatibility with existing deployments of the extension.
16.6 Versioning
Extensions use Semantic Versioning independently of the core MMP specification version. An extension version bump MUST NOT require a core spec version bump unless the extension is being promoted to core.
Q&A
Can an extension become a core frame type? — Yes. An extension that proves stable and
widely adopted MAY be promoted to a core frame type via a spec version bump. Group membership
illustrates the path: the group handshake field (Section 5.2)
and group isolation (Section 5.8) are core, while the mesh-group extension document that formalises
the richer subgroup lifecycle remains a Proposal record (Section 16.4).