Skip to content

Protocol Adapters

Matrix's transport is NATS. Every actor invocation, event, and state record flows over NATS subjects. Other protocols are adapters that translate from their wire shape into NATS publishes/subscribes and back. The actor doesn't know or care which adapter brought the call in.

PageStatus today
NATSNative. Production. The reference implementation.
HTTP gatewayProduction. system.gateway.http serves webapp routes and exposes gateway.http.request ops.
WebSocketProduction. Browsers connect to NATS via /nats-ws.
MCPPartial. Actors expose declarations through $introspect; an MCP server adapter is workstream material.
REST/OpenAPI bridgeTarget. The contract is defined; the bridge actor is partially implemented.
gRPC bridgeTarget. Documented in ACTOR-COMMUNICATION-CONTRACT.md; not implemented.
AsyncAPI bridgeTarget. Documented; not implemented.

Why this layer exists

The static accepts | emits | streams | state declarations on every actor are protocol-neutral. An adapter walks the declarations and generates a protocol-specific surface:

DeclarationOpenAPIgRPCMCPAsyncAPI
acceptsPOST endpointsUnary RPCsToolsRequest channels
emitsSSE endpointsServer streamingPub channels
streamsServer streamingPub channels (durable)
stateGET endpointsUnary RPCsResources
subscribesSub channels
blackboardGET/PUT endpointsBidirectional streamingResourcesPub/Sub channels

Source: WORKSTREAMS/core-and-packaging/ACTOR-COMMUNICATION-CONTRACT.md § "How they map to protocol gateways".

Read order

If you are implementing an adapter, read in this order:

  1. NATS — the canonical wire model.
  2. HTTP gateway — the production-grade adapter to study.
  3. WebSocket — the same-origin browser path.
  4. MCP — the LLM-native discovery surface.
  5. The three target adapters (REST/OpenAPI, gRPC, AsyncAPI) — design targets not yet shipping.

See also