Privex architecture wiki

How Privex stores, moves, and refuses your data.

A visual guide to every database, key, and layer behind Privex — a zero-knowledge, end-to-end-encrypted messenger whose server is built to be architecturally blind. Read it as an everyday explainer or flip to the technical spec.

Two ways to read Use the Plain / Technical switch in the top bar. Plain explains with everyday analogies — doormen, sealed envelopes, receipt books. Technical gives the exact tables, algorithms, and TTLs from the codebase. Your choice (and dark/light) is remembered across every page.

The four laws

Everything in this wiki exists to uphold four promises. They are not policies the operator chooses to follow — they are properties the architecture makes true.

Law 1 · Read

content

The server can’t read your messages. Not “won’t” — can’t. They’re locked before they leave your device.

Content is PQXDH + Double-Ratchet encrypted client-side (WASM) before any byte reaches the network. The server never holds a plaintext or a key.

Law 2 · Identify

users

The server can’t tie activity to a real you. There’s no name, email, phone, or IP anywhere in it.

Accounts are pseudonymous px_ ids derived from a public key. No PII column exists; no IP is ever logged.

Law 3 · Trace

relationships

The server can’t map who talks to whom. The sender’s name is sealed inside each message.

Sealed Sender puts the sender identity inside the ciphertext; the queue row stores recipient-only, no sender, no conversation id.

Law 4 · Confirm

usage

The network shouldn’t even be able to tell you use Privex. Phase 2 — today via cover traffic; full metadata hiding (Nym) is planned.

Target: Nym mixnet + bridges + fixed polling. Phase 1 ships cover traffic, 1024-byte padding, jittered receipts, and no IP access logs.

The shape of the system

Your device does all the locking. Only sealed, unreadable blobs cross to the server, which acts as a blind mailroom in front of storage that holds nothing but ciphertext and public keys.

Plaintext and private keys never leave the client. Sealed Sender ciphertext crosses a direct WSS transport (Phase 1) to an oblivious Axum API, which routes to Postgres (public keys + sealed queues), Redis (ephemeral TTL state), and an object store (encrypted chunks).

Privex, top to bottom
where the lock happens and what crosses each boundary
device (trusted) transport server (untrusted) storage (untrusted)
Figure. The trust boundary sits right at your device. Everything to the right of it is treated as hostile — and given nothing it could leak.

Current snapshot

Server tables
11
Client stores
10
Queue TTL
30 d
PoW TTL
10 m
Custom crypto
0

Built from the codebase (migrations 0001–0012, server/src, apps/web/src) and PRIVEX_DOCS_V2.md. Where code and spec differ, this wiki follows the code.

Start anywhere

Storage

Server database

Every table, column, and why a stolen disk is useless.
Storage

Client vault

Your keys and history, encrypted on your own device.
How it works

Sending a message

The full journey of one sealed message.
Crypto

Identity & keys

Hybrid post-quantum keys and your pseudonym.
System

Threat model

Nine attacks, and the wall each one hits.
System

Master map

The whole system in one interactive picture.