R1 · beacon protocol

Beacon Protocol.

Secure remote control for R1 agents. End-to-end encrypted. Cryptographic identity. Capability tokens with RBAC and delegation. Hub relay without plaintext access.

The problem it solves

Running an agent is one problem. Controlling it from another device, across NAT boundaries, with proof of who approved which action is a different problem. Beacon exists for that second problem. It does not replace STOKE. It supplies the identity, pairing, token, and advisory path that let remote actions be trustworthy before STOKE records them.

/claimme from both sides at once.

Start the pairing flow to watch the beacon terminal, relay-only Hub, operator device, and cryptographic identity glyph advance through the same SAS-verified handshake.

pairing idle
Beacon terminal · /claimme
Hub relay · metadata only
bytes relayed · 0000
Operator device
Cryptographic identity glyph
Capability token in scope
Out-of-band challengeThe QR and spoken phrase travel visually or verbally, not across the network.
Visual fingerprint checkBeacon and phone show the same fingerprint. A malicious relay cannot fake the human match.
SAS from shared secretBoth sides derive the same code only if the X25519 exchange is honest.
Per-device certOperator identity signs per-device certificates, so a lost phone can be revoked without erasing the operator root.

What the Hub sees

The Hub routes bytes, metadata, and advisory envelopes. It does not get the session plaintext. The Hub can therefore do useful control-plane work without becoming a content omniscient bottleneck.

Federation and self-hosting

Beacon is designed as a relay fabric rather than a single hosted service. Federation matters because operators will need multi-Hub topologies and self-hosted parity. The protocol claim is therefore stronger than “cloud remote control.” It is secure remote control with the same provenance and revocation guarantees even when the relay is not the vendor’s.