Both devices hold one key
A shared key is bound to one target. Devices announce presence as opaque tags. The board learns that someone is present, never who or what.
Open Relay Protocol · Apache-2.0 core, AGPL-3.0 board
Secure WebRTC signaling whose server can't read your signaling.
ORP is an open, privacy-preserving rendezvous protocol for peer-to-peer and WebRTC apps. Two devices meet through a server that is structurally unable to read your messages, keys, or signaling — an enforced wire-format invariant, not a no-log promise.
01 — How it works
How ORP works
ORP brokers a meeting between two devices that already share one key bound to one rendezvous target. The exchange runs in three sealed phases; the board only ever sees routing tags.
Sealed WebRTC offer
The initiating peer seals its WebRTC offer (SDP/ICE) and relays it through the board. The board forwards bytes it cannot open.
Sealed answer, then connected
The responder seals its answer back the same way. The peers open a direct channel; the board is now blind to the conversation entirely.
02 — Metadata exposure
What the server can and cannot see
Blindness is enforced by the wire format. There is no frame shape that carries plaintext the board could read, so the property holds even if the operator is hostile, compromised, or compelled.
The board cannot see
- Message contents
- Private keys
- Unsealed signaling (SDP / ICE)
- Who you are — only opaque tags
The board can see
- That two endpoints rendezvous (the social graph)
- Opaque presence and routing tags
- The
frame_kindrouting tag - Sealed payloads it cannot open
03 — Interactive demo
See a rendezvous happen
Two devices share one key bound to one target and relay sealed payloads through the board. Drag to orbit, step through the phases, then flip to the board's view and watch everything it cannot read collapse to opaque tags.
In the board's view, device identities reduce to opaque tags and every
payload reads SEALED. The only thing the board reads is
the frame_kind routing tag — exactly the
collision-table observables, nothing more.
04 — Comparison
ORP vs a traditional signaling server
A conventional signaling server reads the introduction even when the call is end-to-end encrypted. ORP removes that trust from the path.
| Traditional signaling server | ORP blind board | |
|---|---|---|
| Reads SDP / ICE | Yes | No, sealed |
| Reads keys | Often | No |
| Sees social graph | Yes | Yes (stated) |
| Guarantee type | Policy (no-log promise) | Invariant (wire format) |
| Externally verifiable | No | Yes, via the test suite |
05 — Threat model
What ORP protects, and what it does not
Protects against
A hostile, compromised, or compelled board reading your contents, keys, or signaling. The guarantee lives in the wire format, so it does not depend on the operator's conscience.
Stated limits, up front
- No forward secrecy. The inner message layer is static, so a key compromise can expose past sealed payloads.
- The social graph is visible. The board can see that two endpoints meet. This is not 100% anonymity, and we do not claim it.
- Replay and linkability bounds. Presence tags carry documented limits, with scoped mitigations rather than absolute guarantees.
06 — Evidence
The proof is in the test suite
The guarantee isn't a promise; it's checked by an adversarial suite you can run yourself.
Adversarial tests
The suite is written to attack the invariant, with a per-test note of exactly what each one proves.
Board-view scan
Asserts that everything the board can observe is limited to opaque tags and sealed payloads it cannot open.
Wire-byte scan
Inspects raw datagram bytes on the wire to confirm no plaintext contents, keys, or unsealed signaling leak.
git clone https://github.com/Prograde-Solutions/orp
cd orp
npm install
npm test # runs the adversarial suite07 — Use cases
What you can build on ORP
P2P & WebRTC apps
Video, voice, data channels, and file transfer that need signaling without a metadata-reading middleman.
Privacy-preserving messengers
Add a rendezvous layer whose server can't be compelled to hand over what it never had.
Federated & self-hosted tools
Run your own blind board; neighbor propagation lets nodes cooperate without widening what each can see.
Sensitive peer discovery
Secure peer discovery where the introduction point must be provably blind, not policy-blind.
08 — Getting started
Get started in three commands
npm install
npm run demo # in-process demo
npm run demo:real # against real transport adaptersimport { protocol, sealedbox } from '@orp/core';
// Both peers already share one key bound to one target.
const session = protocol.rendezvous({ key, target });
// Seal a WebRTC offer; the board forwards bytes it cannot open.
await session.send(sealedbox.seal(offer));
const answer = sealedbox.open(await session.recv());Illustrative shape; confirm exact API signatures in the API reference. Production deployers supply a WebSocket transport and a real WebRTC endpoint — see the production-transport gap.
09 — FAQ
Frequently asked questions
Can the server read my messages?
No. The rendezvous server is structurally blind: message contents, private keys, and unsealed signaling never reach it in readable form. It sees only opaque tags and sealed payloads it cannot open. This is enforced by the wire format, not by a logging policy.
Read more →Does ORP have forward secrecy?
No. The inner message layer is static and does not rekey per message, so a future key compromise can expose past sealed payloads. This is a stated trade-off, documented in the threat model.
Read more →Can the server see who I talk to?
It can observe that two endpoints rendezvous, which is the visible social graph. It cannot read what they exchange. ORP does not claim full anonymity.
Read more →How is this different from Signal's model?
ORP targets the rendezvous and signaling layer and makes the server structurally unable to read signaling, keys, or contents, as an invariant of the wire format. It does not provide forward secrecy and it does not hide the social graph, both of which it states plainly. It is signaling infrastructure, not a full messenger.
Read more →Is the board really stateless?
The board exposes a single stateful channel and holds only the routing state it needs to broker a meeting. It does not hold readable message contents or keys.
Read more →What happens if a key is compromised?
Because there is no forward secrecy, a compromised key can expose past sealed payloads encrypted under it. A key is bound to one target, so the exposure is scoped to that target rather than a whole directory. Identity rotation (ORP-004) limits the lifetime of an identity key.
Read more →Read the spec. Run the tests. See for yourself.
ORP is open source: Apache-2.0 core, client, spec, and tests; AGPL-3.0 board. Star the repo, open an issue, or implement against the spec.