How it works
Registration & key publication
Making an account means solving a puzzle and publishing some public keys. No email, no phone, no CAPTCHA, no IP — and the server learns nothing that identifies you.
Anyone can walk up and ask for an account — Privex can’t check ID, so instead it makes every new account cost a little computing effort, like a bouncer who skips the ID check but makes you solve a puzzle first. Your device makes all its keys itself, hands over only the public halves, and keeps the private halves locked on the device.
A new device generates four keypairs + one-time prekeys locally, solves a Redis-backed hybrid PoW,
and publishes the public bundle. The server verifies the PoW, checks that user_id derives from
the Ed25519 key, verifies both identity signatures over the signed-prekey bundle, then writes the directory
rows and a KT register entry in one transaction. No IP, email, or phone is involved.
Step by step
Generates all four keypairs plus a batch of one-time prekeys, entirely offline.
Issues a proof-of-work challenge (a SHA pre-filter plus a memory-hard Argon2id step) and stores it for 10 minutes.
Solves the puzzle and submits it with the public key bundle to POST /keys/register.
Consumes the challenge (single-use), checks the puzzle, confirms the user_id derives from the identity key, and verifies both signatures on the signed prekey.
Writes the directory row + prekeys and appends a register entry to the transparency log — all in one transaction. No IP is recorded.
Stores its private keys and master seed encrypted in IndexedDB.
What the server learns
Server can observe
- Public keys and public signatures.
- A
user_idderived from identity-key material. - PoW completion timing and aggregate registration counters.
Server cannot learn
- Private keys, recovery phrase, or password.
- Contacts, device inventory, or message plaintext.
- Your IP address (no access logs with the supplied config).