Gateway-owned channel architecture¶

Definition¶

A gateway-owned channel architecture puts a single long-lived process in sole ownership of every external channel connection (each messaging platform, device, or session), and requires every other participant, interactive clients and headless nodes alike, to reach those channels only through that gateway's own typed, schema-validated protocol, with connection trust graded by origin rather than granted uniformly.

Explanation¶

Rather than letting each client or automation open its own connection to an external platform, the gateway becomes the one process that opens and holds the session (a WhatsApp connection, a Telegram bot session, and so on), so there is exactly one place that can violate a platform's single-session assumption and exactly one place to audit for that channel. Everything else, a desktop client, a CLI, a headless device node, a web UI, is demoted to a peer that speaks the same typed protocol to the gateway rather than to the channel directly: requests and events are validated against a shared schema, and side-effecting requests carry idempotency keys so a dropped connection can retry safely instead of double-firing an action. Trust is not binary: a connection from the same host can be auto-approved for a smooth local experience, but every other connection, across the network, through a tunnel, from a new device, must complete an explicit pairing handshake and is issued a device token for subsequent connects, so whether a peer is first-party is answered per-connection rather than assumed from network location alone.

Key Properties¶

Exactly one long-lived process owns each external channel or session, eliminating races between multiple clients trying to hold the same platform connection
All other participants (interactive clients and headless nodes) connect to that owning process over one typed, schema-validated protocol instead of touching the channel directly
Side-effecting requests carry idempotency keys so a client can safely retry after a dropped connection without double-executing the action
Trust is graded by connection origin: local loopback connections can auto-approve, while every non-local or new-device connection needs an explicit pairing handshake and device token

Relationships¶

No relationships recorded yet.

Applications¶

Designing any system that bridges several external messaging or device channels into one agent or automation layer: centralize each channel's session in a single owning process instead of letting every client dial out to the platform directly; put idempotency keys on any request that can retry after a network drop; and decide trust by connection origin, auto-approving same-host and requiring pairing for anything remote or unrecognized, instead of one shared secret for every client.

Sources¶

https://github.com/openclaw/openclaw/blob/main/docs/concepts/architecture.md
https://github.com/openclaw/openclaw