Module prefixes 

The control-frame prefixes a 1:1 sealed conversation is carried on.

A frame’s type is the reserved prefix its content begins with. The six here are the ones both ends of a pair speak: everything needed to establish a session, carry sealed payloads over it, and confirm it came up. They live in this crate because a leaf node emits and parses them with a different MLS implementation than the engine, and two ends that disagree about a prefix byte do not have a conversation at all.

What is not here

The engine reserves many more: connection lifecycle, group frames, relay answers, presence, the sealed rich body, document sync. None of them reach a leaf node, and the registry that gates them is engine machinery. The split is deliberately “what a pair needs” rather than “every prefix”, because the second would put group and relay vocabulary into a crate that builds for a part with 1536 KB of flash.

The registry still lives in the engine

Naming a prefix here does not reserve it. Reservation is the INTERNAL_PREFIXES array in offline-protocol, which drives refusal of application content that begins with one, and which is generated from the same macro invocation that names these. Adding a prefix to this module without adding it there registers nothing.

Constants

ENCRYPTED

Carries a sealed payload: the compact envelope in base64, or the JSON envelope that is the permanent floor.

KEY_PACKAGE

Carries a key package payload, JSON, signed on the control plane.

SESSION_CONFIRM_ACK

Answers SESSION_CONFIRM_PROBE. Empty body, signed.

SESSION_CONFIRM_ENCRYPTED

A confirmation that travels inside an ENCRYPTED envelope and never on the wire as a frame of its own.

SESSION_CONFIRM_PROBE

Asks a peer to confirm it holds a working session. Empty body, signed.

WELCOME

Carries an MLS Welcome, JSON, signed on the control plane.