Developers
Run it. Verify it.
Everything you 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 Six groups of four, compared out loud.
- Is the app you installed the code we published? /docs/reproducible-builds The signed release manifest and the byte-identical hash path.
- What runs beneath every platform? /docs/crypto-core One Rust library, primitive by primitive.
- Can you run the relay yourself? /docs/self-host The production stack, and where the self-host path stands today.
- Starting from nothing? /docs/getting-started Install, create, entangle, verify. Four moves.
02The six paths — install to self-host
Walk them in order, or jump to yours.
Getting started
Install, create your Serpent ID, entangle with a peer, verify. Four moves.
02Key verification
Compare six groups of four and prove who you are talking to.
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
Check the signed release manifest and the byte-identical hash path.
06Self-host
The relay stack as it runs in production, and where the self-host path stands today.
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"
}Two fields. That is the complete identity surface the relay ever learns. 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 — ML-DSA-87 operator signature>"
}The server recomputes SHA3-256 over the transcript bytes and rejects the request if the binding does not hold. 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. We bind a key-derivation function to a verifiable physical measurement no classical adversary can fabricate in advance.
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 shipped 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 app I am holding
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.