Skip to Content
♜ ReignHub / Docs
Architecture

Protocol and extension boundaries

Connection endpoints use /p2p/; providers retain native agent protocols.

Public connection endpoints

EndpointResponsibility
/p2p/configCapabilities, signing identity and optional probes
/p2p/signalHandshake and direct-connection signaling
/p2p/relayEnd-to-end encrypted application frames
/healthzService health

Use packages/protocol and docs/platform/protocol.md as the source of truth for request types, device registration and pairing APIs.

A connection

From pairing to encrypted conversationsFirst-time authorization establishes trust. Both direct and relay paths use end-to-end encryption.ControllerReignHubConnection serviceWorkerHost computerReignHub1 · Discover and request pairing2 · Host approval / password3 · Exchange candidates, establish direct path4 · E2E encrypted RPC and live outputDirect unavailable → encrypted service relay
First-time authorization establishes trust. Both direct and relay paths use end-to-end encryption.

Devices register identities with the same service and receive connection IDs. Pairing proves control through host confirmation or password verification and establishes local trust. Signaling exchanges candidates, then encrypted RPC invokes providers over direct or relay transport.

Snapshots and incremental events have cursors/sequences. Gaps trigger resynchronization; replayed transport data must not become a new instruction.

Service authorization

The official service may issue short-lived signed leases bound to host, controller, product and connection entitlements. Hosts verify them at a shared call boundary, preventing direct access from bypassing quotas.

Self-hosted services use the same protocol without a commercial subscription. On the official service, your plan determines host device, agent and relay access.

Edit this page on GitHub

On this page