Rust prototype implements Signal-style post-quantum E2EE messaging core

A Signal-style stack, rebuilt in Rust

A developer publishing as moral666 has released QT, an open-source prototype of the cryptographic and transport core of an end-to-end encrypted messenger, written in Rust. According to the project's README, the code implements X3DH and its post-quantum variant PQXDH for session establishment, the Double Ratchet for ongoing message encryption, Sealed Sender for metadata protection, and the Noise Protocol Framework over WebSocket for transport — a stack the author says follows the same design Signal uses, extended with post-quantum key agreement. (The repository name collides with the Qt toolkit, but the project is pure Rust and unrelated to it.)

The project reached the front page of Hacker News on 12 October, where the post title claims the server sustains 10,000 connections on 124MB of RAM. That figure appears only in the post title; the README does not describe the benchmark behind it, so it is best read as an unverified headline claim rather than a documented result.

What is built and tested

The README is unusually candid about maturity. It states plainly that this is not a finished product and includes a frank section on whether the code actually works before asking readers to invest time. What the author says exists and passes tests:

• The core: session establishment (X3DH plus the post-quantum variant) and continuous encryption via the Double Ratchet, covered by more than 14 automated tests, including cases that are supposed to fail and do.
• Transport: Noise Protocol protection over real WebSocket connections, not simulated ones.
• Server: a relay that delivers messages without seeing their content or learning the sender, tested to survive being killed mid-operation with kill -9.
• Storage: encrypted local persistence, with tests confirming a wrong passphrase opens nothing.
• A terminal client, exercised with fully separate processes talking to each other.
• FFI bridges to Kotlin, Swift and Python, with the Python path tested.
• An Android proof-of-concept app that the README says has run on a real phone, though it is not yet published as its own repository.

What is still missing

The gaps are listed without embellishment: there is no real conversation screen (the Android app currently offers only a demo button), no internet-accessible server deployment, and no TLS — the transport uses plain ws://, which the author says suits testing only. Federation between independent servers, so that no single authority could switch off the network by shutting down one host, is planned but absent. The database passphrase currently arrives as a command-line argument rather than from the platform keystore or Secure Enclave. Most importantly, there has been no independent security audit, and the author explicitly advises against trusting the system with real conversations before one exists.

Deliberate design choices

Identity in QT is anchored to a cryptographic key rather than a phone number or email address. Each person's identifier is derived from their public key, and nobody picks a username — an intentional decision to avoid the metadata trail that phone-number registration creates. The README frames the effort as building communication infrastructure whose security comes from its architecture rather than from a privacy policy, citing the Chat Control legislation under discussion in the European Union as part of the motivation.

The code is dual-licensed: AGPL-3.0-or-later for open-source use, with a separate commercial licence available by written agreement for organisations that need different terms.

Running it

Compiling the workspace requires Rust via rustup — the post-quantum core feature specifically needs Rust 1.81 or newer — plus redis-server and libsqlcipher-dev. One cargo command runs a demonstration that walks step by step through a complete encrypted conversation between two fictional parties, and separate CLI binaries let two independent processes register with a local relay, send and receive messages.

Why it matters

PQXDH exists to counter the harvest-now, decrypt-later scenario, in which encrypted traffic recorded today could be unlocked by a future quantum computer. Signal's protocol family has become the reference design for secure messaging, and independent reimplementations like this one test whether that design survives being rebuilt outside its original ecosystem, while giving researchers and auditors a second codebase to compare against. Writing it in Rust also narrows the memory-safety bug class that has historically plagued cryptographic C code. If the 10,000-connections-on-124MB figure holds up under scrutiny, it would show that a full post-quantum E2EE stack can run on remarkably modest infrastructure. The caveats are real — no audit, no TLS, an unfinished client — but as a technical prototype this is a serious implementation rather than pseudocode or diagrams, which is precisely what its author set out to prove.