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 Published 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 §10.) |
| symbit-v0.1.0 | Proposal | SYMBit Economic Layer — protocol-level reward primitive for agent cognitive contributions. SVAF outcomes as value function, lineage DAG for credit distribution. (Specification forthcoming) |
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 Section 18) 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. Mesh groups (Section 5.8) started as an extension proposal before being promoted into the core spec.