Developers
Run it. Verify it.
Everything you will need to stand on this stack: the quickstart, the verification paths, and the relay API — written in the same terms as the code.
01The router — arrive with a question
State the question. Take the route.
Six questions cover the whole developer surface. Each one resolves to a single page and a single path, printed beside it.
- What does the relay learn about you? /docs/api The API, field by field. A field not listed is not read.
- Are you talking to the right person? /docs/key-verification Verified once, in person, through the Entangled pairing — then automatic.
- Is the app the code we published? /docs/reproducible-builds The signed release manifest and the byte-identical hash path, from v1.0.0.
- What runs beneath every platform? /docs/crypto-core One Rust library, primitive by primitive.
- Can you run the relay yourself? /docs/self-host The relay stack as designed, and where the self-host path stands.
- Starting from nothing? /docs/getting-started Create, entangle, verify — coming soon.
02The six paths — first steps to self-host
Walk them in order, or jump to yours.
Getting started
Create your Serpent ID, entangle with a peer, verify — coming soon.
02Key verification
Prove who you are talking to once, in person, through the Entangled pairing.
03API
REST and WebSocket references for the relay — the exact shapes the server reads.
04crypto-core
The Rust library beneath every platform, primitive by primitive.
05Verify your build
From v1.0.0, check a build against the signed release manifest and the byte-identical hash path.
06Self-host
The relay stack as designed, and where the self-host path stands.
03The request shapes — every field the relay reads
Read every field the relay deserializes.
Four requests carry the whole messenger. Tap through the exact shapes — every field the server deserializes, and what stays opaque to it.
POST /auth/register
{
"serpent_id": "string — 3–64 chars: letters, digits, - and _",
"password": "string — 8–128 chars"
}
// 200 —
{
"token": "<jwt>",
"user_id": "<uuid — internal routing id>",
"profile_id": "PROFILE-XXXXXXXX-XXXXXXXX"
}Those two fields, plus the connecting address the relay sees to answer at all, are the identity surface — there is no name, no number, and no address book. Full reference.
POST /sessions/init
{
"responder_id": "<uuid>",
"handshake_init": "<base64 — serialized hybrid HandshakeInit>",
"bell_transcript": "<base64 — canonical Q-Entangle-Bell v1 bytes>",
"bell_transcript_hash": "<base64 — SHA3-256 of the canonical bytes>",
"bell_op_sig": "<base64 — operator signature over the transcript; optional>"
}The Bell fields are optional. When present, the server recomputes SHA3-256 over the transcript bytes and re-checks the CHSH window; a mismatch is counted and, once enforcement is armed on the deployment, refused with X-Qeryx-Bell-Missing: 1. The messenger bootstraps its sessions through the pre-key bundle path, not this endpoint. The secrets are born on the two devices.
This is not QKD. Not quantum networking. Not quantum teleportation. We do not violate the no-communication theorem. Above an X25519 + ML-KEM-1024 floor that alone provides confidentiality, a session can fold a Tsirelson-bounded CHSH witness transcript into its key derivation — a deterministic classical co-possession witness, not physical entanglement; security never depends on it.
POST /messages
{
"recipient_id": "PROFILE-… or <uuid>",
"encrypted_content": "<base64 — ciphertext; opaque to the relay>",
"nonce": "<base64>",
"message_type": "text | image | video | file | location | voice",
"reply_to_id": "<uuid, optional>",
"conversation_id": "<string, optional — group routing>",
"idempotency_key": "<string, optional — client-side dedup>"
}encrypted_content and nonce are opaque bytes to the relay — the content behind them is indistinguishable ciphertext.
GET /ws
Authorization: Bearer <jwt> // one socket, typed frames dispatched on msg_type: delivered · delivery_ack · read — delivery call_ready · call_accept · call_reject call_end (and video variants) — call signaling group media control · transparency gossip
Message payloads inside frames are the same opaque ciphertext as the REST surface. Full reference.
04The writing law — what a sentence here must do
Hold these pages to their own law
Every security sentence on these pages names a primitive, links an artifact, or states what the system cannot do. The relay carries ciphertext; it cannot read messages. Where a capability is not built yet, the page says so in the present tense — a roadmap is labeled a roadmap.
Where do the shapes on these pages come from?
The request and response shapes in the API reference mirror the structures the server actually deserializes, field by field. A field not documented here is not read.
Something here disagrees with the code
Then one of them is wrong and we want to know which. Report it through responsible disclosure — documentation drift on a security surface is triaged like a bug.