A dumb pipe,
on purpose.

The relay was built for Backroom, a macOS agent app with an iOS companion. The phone needs to reach the Mac from anywhere, and the Mac sits behind NAT where nothing can dial it. So both ends connect out to this relay, present the same room id, and the relay pipes frames between them.

Nothing about it is Backroom-specific. Any two endpoints that already share a secret can derive a room id from it, seal their traffic end to end, and use the relay as a meeting point. It is a generic pipe, and it is documented as one.

The relay is structurally unable to read traffic, not merely promising not to. There is no key material anywhere in the codebase, and no code path that parses, transforms, or logs a frame's payload. The access model has two parts, both deliberate:

• End-to-end encryption on the endpoints provides confidentiality and integrity. Every byte crossing the relay is ciphertext sealed under a key derived from an offline pairing.
• The room id is an unguessable capability. It is a high-entropy secret the two devices already share. The relay admits at most two connections per room, so even a party who somehow learns a room id cannot join an established pair.

There is no relay-side auth secret, and that is a decision, not an omission: a shared relay secret would have to be distributed to every client, which is strictly worse than a per-pair capability. The full security model spells out the threat model and what each class of attacker actually gets.

No database. No persistence. No accounts. No auth server. No message history. No rooms-list endpoint. No admin API. State is an in-memory map of room id to its at-most-two peers, and nothing survives a restart. That is correct behaviour: a dropped connection just reconnects.

Every one of these omissions is load-bearing for the dumb-pipe security model. A relay that could list rooms or replay history would be a relay worth compromising.