cryptxt
local-first · e2ee · self-hosted

Your people.Your conversations.

Cryptxt is the encrypted messenger you host yourself — private chat, voice and video with post-quantum crypto, anonymous IDs and an encrypted SMS fallback for when the internet is off.

Why it exists

Every other messenger asks you to trust someone else.

Signal asks you to trust Signal. WhatsApp asks you to trust Meta. Both encrypt the message and both still see who talked to whom, when, and from where. Cryptxt removes the third party entirely — the server in the message path is one you own.

  • No vendor account, no vendor infrastructure, no vendor policy change.
  • Metadata stays inside your perimeter because there is nowhere else for it to go.
  • The whole stack is source-available, so "trust us" is replaced by "read it".
01 — Identity

An identity, not a phone number

Start anonymous with a cryptographic Cryptxt ID. Phone numbers are strictly optional and can be added later purely for SMS recovery — never as your handle, never as a discovery key you did not opt into.

  • Anonymous ID by default
  • Optional phone, opt-in discovery
  • Per-device linked keys
02 — Cryptography

Post-quantum by default

PQXDH plus the Double Ratchet on every session, MLS group cryptography that scales past hundreds of members, and SFrame-encrypted calls. The primitives are vendored and review-gated rather than pulled fresh from a registry at build time.

  • PQXDH + Double Ratchet
  • MLS groups (mls-rs)
  • SFrame AES-256-GCM calls
03 — Sovereignty

Runs on your metal

The whole stack sits behind your own domain. Docker Compose gets a lab running in ten minutes, Helm handles production, and signed air-gap tarballs cover networks that never touch the internet at all.

  • docker compose up -d
  • Helm charts for production
  • Signed air-gap tarballs
04 — Resilience

Works when networks don’t

An encrypted SMS fallback keeps the same keys and the same forward secrecy when data is blocked or throttled. Offline-first clients let you read, compose and verify with no signal at all, then sync when the link returns.

  • Encrypted SMS fallback
  • Offline-first clients
  • Same keys on every path
Under the hood

Nothing here is novel. That is the point.

Every primitive below is a published, reviewed design. Cryptxt’s contribution is assembling them so that no server you do not own ever sits in the path.

SessionPQXDH + Double RatchetPost-quantum handshake, per-message forward secrecy
GroupsMLS (mls-rs)Tree-based rekeying, scales past hundreds of members
CallsSFrame AES-256-GCMEnd-to-end encrypted media, SFU never sees plaintext
MetadataSealed senderThe server cannot read who sent what to whom
IdentityEd25519Out-of-band safety numbers, per-device verification
At restSQLCipherLocal database encrypted with a device-held key
03rd-party
servers in the message path
6clients
one codebase, one crypto core
10min
to a single-box deploy
100%
of the stack, yours
The app

Six platforms. One design. Same keys.

Desktop gets a rail-and-workspace layout tuned for long sessions. Mobile gets a chat surface that reads at a glance. Every client shares one crypto core.

Cryptxt — Secure chat: Cipher messages, E2EE by default
Secure chat
Cipher messages, E2EE by default
Cryptxt — Anonymous ID: Sign up with no phone number
Anonymous ID
Sign up with no phone number
Cryptxt — Encrypted calls: SFrame-protected voice and video
Encrypted calls
SFrame-protected voice and video
Cryptxt — App lock: Biometrics and at-rest encryption
App lock
Biometrics and at-rest encryption
The film

Encrypted. Personal. Yours.

What Cryptxt is for, in short. Then the compose file, and it is yours to run.
Deploy

Running in your infrastructure this week.

Pull the compose file, point it at your domain, let certbot issue the certificate. That is the whole first-run path — no sales call in front of it, no account to create.

$git clone https://github.com/cryptxt/cryptxt-server
$cp .env.example .env # set your domain
$docker compose up -d