Show dev.to: I launched Quldra - a post-quantum, single-device Signal alternative

Source: Dev.to

Overview

Quldra is a live, post‑quantum, single‑device messenger with no phone‑number or email requirement. It runs on iOS, Android, and offers web‑chat sessions through the app. Development took about eight months.

Key technical details

• End‑to‑end encryption using ML‑KEM‑768 (NIST FIPS 203) for key exchange and ChaCha20‑Poly1305 for message and media encryption.
• Single device per account, enforced server‑side by a fingerprint hash on every request. Recovering to a new device triggers a hard reset of the old one within 8 seconds.
• Accounts are identified by a username and a recovery code; there is no way to contact a user outside the app.
• Supports direct messages, group chats (invite‑based), and temporary web‑chats for users who haven’t installed the app.
• Media uploads up to 200 MB are encrypted client‑side and stored as opaque ciphertext in S3‑compatible object storage; the server never sees plaintext.

Note: Quldra is not a fork of Signal, not multi‑device, not federated, and not free forever at scale. The base app is free; heavy bandwidth usage is metered after a threshold.

Trade‑offs I Made

• No typing indicators – they leak metadata about who is typing and when, which can reveal parts of a social graph.
• No built‑in cloud backup – the only way to move to a new device is via recovery, which wipes history. This aligns with a strict “no copies” interpretation of end‑to‑end encryption.
• No phone‑number‑based contact discovery – users must know a recipient’s username, reducing onboarding friction but preventing bulk contact‑list uploads.
• Media storage architecture – the first version stored ciphertext in a PostgreSQL BYTEA column, which worked for images but broke for video. It was later migrated to object storage; starting with S3 from day one would have avoided this pain point.
• Early web‑chat implementation – launching mobile‑only first would have allowed six months of focused feedback before adding a web surface, reducing the trust‑boundary surface area.
• Community building – releasing without an existing user base means I’m “shooting in the dark.” Understanding client needs and possibly pivoting to alternative chat formats would improve the project’s sustainability.

Contact & Support

• Bug reports: support@quldra.com or the in‑app support form. I’m a solo developer and read every message.
• Security issues: Please disclose responsibly (email first). I don’t have a formal bug bounty yet, but I will credit and compensate valid findings.

If the trade‑offs above align with what you want in a messenger, give Quldra a try. It’s available on the App Store, Play Store, or via the website at quldra.com.

The Series

1. My road to ML‑KEM‑768 over X25519 for my messaging app
2. Device‑distinct messaging: why I killed multi‑device and how fingerprint hashing enforces it
3. Delivering E2EE media without blowing up Postgres
4. This post (the current overview)