Module registry 

The extensible message-type registry (SPEC §4) — the runtime seam through which every downstream subsystem (dig-chat, dig-email, dig-video, peer-RPC, IPC) plugs its own message types into the one base protocol WITHOUT dig-message depending on any of them.

Three pieces make the seam:

• MessageBand + MessageType::band — the normative id allocation (each subsystem owns a 256-wide band), so a reader can classify any id it sees.
• MessageKind — the compile-time contract a type declares: its reserved id + its typed, byte-deterministic Streamable payload.
• MessageRegistry — the runtime table that maps a MessageType to a decode-and-handle closure, populated additively.

Forward compatibility (SPEC §4, the §5.1 additive-only spirit) is the load-bearing property: a message_type the registry has never seen MUST fail CLEANLY — MessageError::UnsupportedType for a request/stream shape (so the caller replies with an error), a silent drop for a one-shot/response shape — and MUST NEVER panic. An old reader therefore keeps working when newer senders introduce new types.

Structs

MessageRegistry

The runtime message-type table (SPEC §4). Maps a MessageType to its decode-and-handle closure, populated additively by each subsystem at startup.

Enums

Dispatch

The outcome of dispatching a decoded payload (SPEC §4). Both variants are success — an unknown one-shot dropping is the intended forward-compat behavior, not an error.

MessageBand

A subsystem’s reserved id band (SPEC §4). Each named band is owned by one subsystem and allocated additively within it; ids that fall in no allocated subsystem band classify as MessageBand::Reserved.

Constants

BAND_CORE

The base of the core band (handshake / ack / error / keepalive) (SPEC §4).

BAND_DIG_CHAT

The base of the dig-chat band (SPEC §4, #768).

BAND_DIG_EMAIL

The base of the dig-email band (SPEC §4, #794).

BAND_DIG_VIDEO

The base of the dig-video-chat signaling band (SPEC §4, #795).

BAND_EXPERIMENTAL

The base of the experimental / vendor band — never shipped as a canonical type (SPEC §4).

BAND_IPC

The base of the dig-ipc-protocol band (authenticated local dig-app ↔ dig-node IPC) (SPEC §4).

BAND_PEER_RPC

The base of the peer-RPC band (peer-to-peer request/response) (SPEC §4).

BAND_PRESENCE

The base of the presence / directed data-request band (SPEC §4).

BAND_RELAY_CONTROL

The base of the node↔relay sealed control band — register / hole-punch / retainer traffic between a DIG Node and its relay (SPEC §4, #1199). RESERVED: owned by the dig-relay/dig-node relay-control wire, no concrete ids allocated yet.

BAND_RELAY_MESH

The base of the relay↔relay mesh band — frames exchanged between relay instances forming the relay mesh (SPEC §4, #1200). RESERVED: owned by dig-relay’s mesh wire, no concrete ids allocated yet.

BAND_SOCIAL_GRAPH

The base of the dig-social-graph band — the social-graph connection manager’s directed connection offers/acceptances (SPEC §4, #1192, #991 SG-2). RESERVED: no concrete ids allocated yet beyond the first-consumer MSG_TYPE_CONNECTION_OFFER (#991), which lives in dig-social-graph.

Traits

MessageKind

The compile-time contract a message type declares to plug into the registry (SPEC §4). A downstream crate implements it for each of its payload types; dig-message never depends on that crate.