It's live. Quldra is a post-quantum, single-device, no-phone-number, no-email messenger. iOS, Androidm, and a possibility to have web-chats through the app. Took me around 8 months to get to this point.

This post is what it is, how it's uilt, and the trade-offs I made along the way. The three previous posts in this series cover the details of some of the pieces - I've linked them inline.

What it is?

• End-to-end encrypted, with ML-KEM-768 (NIST FIPS 203, the post-quantum standard) 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. If you recover onto a new device, the old one hard-resets within 8 seconds.
• No phone number, no email. Accounts are usernames with a recovery code. I do not have a way to reach you, and I prefer it that way.
• DMs, group chats, and invite-based group joining. Also a separate way to start webchats for temporary chats with people who haven't installed the app yet.
• 200MB media uploads, encrypted client-side, stored server-side as opaque ciphertext in S3-compatible object storage. The server never sees plaintext for any message or file.

What it isn't?

• Not a Signal fork. Signal is excellent; I'm not trying to improve on it, I'm trying to make something with different trade-offs for people who want them. I'm also open-ended in terms of the product future as well, so all feature requests are taken into consideration.
• Not multi-device. Deliberately. If you want your messenger on every screen, Quldra isn't it.
• Not federated or decentralized. The server is a single service I run. Your contract is with me, not with a protocol.
• Not free forever at scale. The base app is free; heavy bandwidth usage is metered after a threshold. I'd rather be honest about that than pretend E2E infrastructure is costless.

Why I built it?

• I wanted a lightweight messenger with no obligatory ties. I believe in the right to privacy. This doesnt mean that I built this for criminals; rather, it means that everything doesn’t need to be tracked and monitored. Quldra clients are not the product.

• ** Post-quantum cryptography is the right default for new apps.** "Harvest now, decrypt later" is a real threat model for messaging - the content I send today should still be private in 20 years. ML-KEM-768 is the current best answer; not using it on a 2026 greenfield app felt like a mistake I'd regret.

• Multi-device is an attack surface sold as a feature. Every device with session keys is a point of compromise. I wanted a protocol simple enough that I could reason about it without flowcharts - one user, one device, one key per conversation, recovery means clean slate.

• I wanted to see if I could do it. I’ve been a software developer for 15+ years. I have an interest in cryptography and am fascinated by the rise of quantum computers. I feel like this will make a huge dent in the field. Up to this point, the entire project has been orchestrated solely by me.

Trade-offs I made that I'd defend

No typing indicators. They leak metadata — specifically, they leak the fact that you're typing a message to a specific person at a specific time. Over a long enough window that's a social graph. I decided the UX gain wasn't worth the leakage.

No built-in backup to cloud storage. The only way to get your messages on a new device is recovery, which wipes history. This is unpopular. It's also the honest version of "end-to-end encrypted" — if I could restore your messages, I would have a copy of something, and I don't want to have a copy of anything.

No phone-number-based contact discovery. You have to know someone's username to message them. This makes onboarding harder. It also makes Quldra resistant to "upload your whole contact list to find friends" flows, which I find profoundly user-hostile.

Trade-offs I made that I'd undo if I could

The first version of media storage put ciphertext in Postgres BYTEA. It worked for images, broke for video, and took me a painful week to migrate to object storage. If I were starting over, I'd build the S3 path from day one. Full post-mortem here.

I built the web chat too early. I should have shipped mobile-only for six months, gathered feedback, and then decided whether a web surface was worth the extra trust boundary. Instead I have three products to maintain from day one.

**Most importantly:I should have built a following before releasing anything. I’m currently in a position where I’m shooting in the dark, and for this project to continue, I need to better understand clients’ needs. I’m also open to pivoting to alternative chat formats.

What I want from you

Two things:

1. If you find a bug, tell me. support@quldra.com or the in-app support form. I'm solo, I read everything.
2. If you find a security issue, tell me before you tell anyone else. I don't have a formal bug bounty yet but I will credit and pay for real findings in bandwdith. Email is the same.

And — if the trade-offs above sound like what you want in a messenger, try it. App Store, Play Store, or quldra.com for the links.

Finally, If you see that post-quantum secure messaging is the future but would like to implement it in a different messaging sector let me know. It's possible to pivot to web-chats, support chats, chat sessions, etc.

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.

I'm Martin, building Quldra from Auckland. You can find me on LinkedIn or just reply here.