Get Tesseract.
Encrypted messaging with no phone number, no username and no profile picture. Available on iPhone today; the rest are being built.
There is no web version and there will not be one — keys that live in a browser tab are keys someone else can serve you. Every client listed here holds its own keys on the device.
Don’t take our word for any of this.
Every encrypted messenger says it is encrypted. The only difference that matters is whether you can go and check. The code is published under the GPL, which means you can read it, build it, and fork it if we ever do something you don’t like.
ios/SecretR00M/Crypto/.
How it works ↗
What the design actually does, written down —
key exchange, what the server holds, what it cannot hold.
Found a flaw? ↗
Report it privately rather than opening an issue.
We would rather hear it from you than from an attacker.
Can’t read code? Ask something that can.
“It’s open source, go look” is not much of an offer if you don’t write Swift. So don’t take ours — take this prompt, paste it into Claude, ChatGPT or any other assistant that can browse, and let it read the repository and report back. We wrote it to invite criticism, including a question about what it cannot prove.
I am considering using an encrypted messaging app called Tesseract, and I cannot read code. Its source is public. Please read it and give me a plain-English verdict. Repository: https://github.com/keniprimo/SecretR00M Licence: GPL-3.0 Start here: ios/SecretR00M/Crypto/MessageCrypto.swift ios/SecretR00M/Crypto/KeyExchange.swift ios/SecretR00M/Crypto/Handshake.swift ios/SecretR00M/Crypto/KeyGeneration.swift ios/SecretR00M/Crypto/NonceTracker.swift relay/ (the server) ARCHITECTURE.md and SECURITY_ARCHITECTURE.md Answer each of these, and say so plainly when you cannot tell: 1. Are messages actually end-to-end encrypted? Which algorithms are used, and are they standard, well-regarded ones, or home-made? 2. Where are private keys generated and stored? Does any private key, password or PIN ever leave the device? 3. Can whoever runs the server read message contents? What metadata can they see or retain - who talks to whom, when, how often? 4. Is there anything resembling a backdoor: key escrow, a hardcoded or default key, a silent extra recipient, a debug bypass left enabled? 5. Does the app contact any analytics, advertising or crash-reporting service? The project claims it does not. 6. What are the weakest parts of this design? What would you fix first? 7. What can you NOT determine by reading this repository alone? On question 7, be specific and unflattering. I already know you cannot confirm that the build published on the App Store was compiled from this exact source, and that the server I connect to may not be running the code in this repo. Tell me everything else in that category. Be sceptical rather than polite. Cite file paths and line numbers. If something looks wrong, sloppy or unusual, say so directly - I would rather hear it now.
What this does and does not settle. A model reading the repository can tell you whether the code in front of it does what we say. It cannot tell you that the app Apple served you was built from that code, or that the relay you connect to runs it — no published source can prove either, for us or for anyone else. Treat the answer as one real data point, not a certificate. And note that the security report in the repository is our own automated test suite, not a third‑party audit: Tesseract has not had one yet, and we will say so here when it does.