Gateway Control Plane: Connect, Authorize, Dispatch, Broadcast

This chapter focuses on deterministic ingress: how requests enter, get authorized, get routed, and how events flow back.

Minimal verifiable loop

openclaw gateway
openclaw dashboard

See: Protocol and Control UI.

The chain

1. Handshake: first frame must be connect (challenge/auth).
2. Authorization: role + scopes decide whether a method is allowed.
3. Dispatch: route req(method, params) to a handler.
4. Broadcast: push execution progress as event streams (with per-event scope guards).

Practical implementation notes

1) connect must be the first frame

Don’t allow any business methods before the handshake completes.

2) Keep authorize separate from dispatch

Treat these as distinct layers:

• authorization decides whether a method is allowed
• dispatch decides which handler runs it

3) Prefer plugin/extra handlers, then core handlers

If you have extension points, resolve extra/plugin handlers first, then fall back to core. Governance notes: Hooks + plugins governance.

4) Broadcast needs scope guards + slow-consumer protection

Some events must be scoped (approvals/pairing/ops). Also protect the server from connections that can’t keep up.

Minimal frame shapes (for logs/packet captures)

Request:

{ "type": "req", "id": "1", "method": "chat.send", "params": { "text": "hi" } }

Response (ACK with runId):

{ "type": "res", "id": "1", "ok": true, "result": { "runId": "r_123" } }

Event:

{ "type": "event", "event": "agent.delta", "payload": { "runId": "r_123", "delta": "..." } }

Code entry points (optional)

• src/gateway/server.impl.ts
• src/gateway/server-runtime-state.ts
• src/gateway/server/ws-connection/message-handler.ts
• src/gateway/server-methods.ts
• src/gateway/server-broadcast.ts