7. Frame Types — MMP Specification

7. Frame Types

All frames are JSON objects with a type field (string). Implementations MUST silently ignore frames with unrecognised type values to allow forward compatibility.

7.1 Frame Type Registry

The table is rendered from the normative machine-readable frame registry; its own shape is validated by frame-registry.schema.json.

All cognitive content — observations, decisions, feedback, directives — MUST be sent as cmb frames. Only cmb frames enter SVAF evaluation, produce anchor weights, and modulate CfC state.

The registry distinguishes Core Secure wire types from retained legacy and runtime-extension types. A Core Secure participant MUST complete the three-frame authenticated handshake before it accepts cmb or cmb-encrypted. It MUST NOT silently downgrade to the legacy one-frame handshake or to an unsigned application frame.

The relay-* types are transport-scope (Section 4.4): they are exchanged between a node and a relay, never between peers, and never reach the application layer. The relay forwards peer frames as opaque payloads (Section 4.4.4) and does not originate any of the peer-scope types above.

Sealed control frames. Only the frames a session protects are bound to it. A frame in clear can be read and injected by whatever sits on the path — over a relay, the relay itself and, before relay authentication proves keys, any client that can claim a nodeId there (§4.4.1, §4.4.4). In a Core Secure session that is CONNECTED (§5.3), a sender MUST therefore send every peer-scope frame other than ping and pong sealed: a record in cmb-encrypted, and every other frame — peer-info, wake-channel, mood, cmb-fetch, cmb-fetch-result, cmb-anchors (§9.4), room-join (§5.8.1), the four authority frames (authority-statement, authority-digest, authority-fetch, authority-set, §6.6.8), error and every negotiated extension frame — as the inner frame of a control-encrypted envelope (§18.2.1). A receiver MUST discard any of those frames that arrives in clear on a CONNECTED session, with one exception: it MAY read an error in clear, as the informational frame it always is (§7.2), but a clear error changes nothing. It closes no session, moves no sequence and changes no state, because whatever sits on the path can forge it, and a receiver cannot tell whether its sender still holds a session. The one clear error a node acts on is 1011 UNKNOWN_SESSION, which MAY prompt a new handshake and nothing else (§5.2.2). A sealed error is the peer’s own: one whose action is Close (§7.2) ends the session. ping and pong MAY travel in clear or sealed, and a receiver handles a sealed one as liveness, exactly as a clear one, and answers a sealed ping with a pong, in clear or sealed (§5.4). The inner frame of a control-encrypted envelope MUST NOT be a handshake frame (including the legacy handshake), cmb, cmb-encrypted, control-encrypted, state-sync or a relay-* frame. A sealed frame that opens advances its direction’s sequence (§18.2.1) whether or not its inner frame is then accepted; refusing the inner frame changes nothing else.

Session-bound frames speak only for the session’s peer. wake-channel, mood, cmb-fetch, cmb-fetch-result, cmb-anchors, room-join, authority-digest and authority-fetch take their sender from the session: the proven nodeId of the peer whose keys opened them. A receiver MUST attribute them to that nodeId and the name the handshake bound to it (§5.2). None of them carries a sender field, and a receiver MUST NOT take a sender from inside a frame. peer-info describes other nodes; its entries are hints. A receiver MAY use a gossiped wake channel to try a wake, but MUST NOT let it replace a wake channel the named node registered over its own session, and MUST NOT bind an identity or a key from it (§18.3). Sealing proves who sent a frame, not that what it says about third parties is true.

Author-signed frames carry their own authority. A frame that carries a signed statement takes its authority from that signature, never from the session that delivered it: a signed statement may be relayed over any session, and the session only transports it. Sealing it still keeps it from the relay, and from injection. The key it is verified against depends on what it is. An authority statement, carried in authority-statement or authority-set (§6.6.3), is verified by §6.6.9 and §18.3.2: against the subject key of the grant its authorisedBy names, or the pinned anchor keys, under the one verification rule, and never against a key a registry or a session binds to a nodeId. A record (§18.3.1), and an extension’s author-signed frame such as a sym-attest-v1 attestation (§16.4), is verified against the key the receiver binds to the nodeId it names (§3.4), never against the key of the session that delivered it.

Deprecated — state-sync. The state-sync frame carried a node’s hidden-state vectors (h₁, h₂). Per the hidden-state locality invariant (Section 2.7), hidden state MUST NOT cross the wire. Implementations MUST NOT emit state-sync and SHOULD ignore it on receipt. It is retained in this registry only to reserve the type and document the deprecation; all peer influence flows through cmb frames evaluated by SVAF.

7.2 Error Frame

When a node encounters a protocol-level error, it SHOULD send an error frame before closing the connection (if applicable). Error frames are informational — the receiving node MUST NOT treat them as commands. A clear error changes nothing (§7.1). A sealed error is the session peer’s own notice: one whose Action is Close ends that session at the receiver too; any other sealed error is information.

Codes 1xxx are connection-level: they concern a connection or a session, and most close it; the Action column says which. Codes 2xxx are evaluation-level (informational). Error-frame codes are a registry of their own, separate from the relay’s WebSocket close codes (§4.4.9): an implementation MUST NOT send an error frame with a code in the 4000–4999 range, which those close codes occupy. Error frames MUST NOT contain sensitive information.

7.3 Type Naming and Extensions

Frame types are identified by their type string value. Core types (this specification) MUST NOT be redefined by extensions. Extension types MUST use <extension>-<name> format. Vendor types MUST use x-<vendor>-<name> format and MUST be silently ignored by non-supporting nodes.

Q&A