Honestly, I wouldn't even consider using it unless it were reviewed by a professional cryptographer. There are already battletested options that don't require a phone number or sharing info with a company. For that, I like XMPP with a client that uses OMEMO for encryption.
this post was submitted on 14 Jun 2026
8 points (59.1% liked)
Privacy
10528 readers
8 users here now
A community for Lemmy users interested in privacy
Rules:
- Be civil
- No spam posting
- Keep posts on-topic
- No trolling
founded 3 years ago
MODERATORS
That's fair, and honestly it's the right instinct - I wouldn't tell anyone to bet their safety on something unreviewed either, including mine. I'm one guy who got obsessed, not a cryptographer, and I'm not going to pretend otherwise.
Genuine question since you clearly know the space: for a small independent project, what's the realistic path to that kind of review? Is a professional audit the only thing that counts, or does open-sourcing the code so people can poke at it move the needle at all on its own?
And thanks for the XMPP/OMEMO pointer - I'll go read up on how they handle the no-phone-number side, since that's the part I cared most about.
Is a professional audit the only thing that counts, or does open-sourcing the code so people can poke at it move the needle at all on its own?
To me, open sourcing the code is a move in the right direction but it doesn't make up for a professional review of your encryption system.
The thing about encryption is that there are many subtle ways to get something wrong, even when just implementing it with a well known and trusted library. I took a deep dive course on Designing Secure Encryption for Practical Use and while I learned a ton from it, the main take away for me was that I shouldn't do it if its intended for serious use. At least not without expert reviewers.
Regarding XMPP, it's architecture is like email. Anyone can stand up their own server and your User ID looks like an email address: user@chatserver.org. Like email, you can send messages to anyone on any server if you know their ID. Phone numbers are simply never involved.
That's the clearest answer I could've asked for, thank you - so the order is: audit is the thing that actually counts, open source is necessary but not sufficient on its own. That reframes my priorities, and honestly it's a bit sobering in a good way.
And I really appreciate you sharing the course takeaway, because that's the part that lands. "There are many subtle ways to get it wrong even with a trusted library" is exactly the fear I should have and sometimes talk myself out of. The fact that someone who actually studied this concluded "don't do it solo for serious use without expert review" is worth more to me than any feature I could add.
So I'm taking this as: keep building and learning, be honest that it's not for high-stakes use until it's been properly reviewed, and treat the audit as the real gate rather than a nice-to-have. I'd rather say that out loud than oversell it to someone who actually needs the protection.
And thanks for the XMPP explanation - the email-style federated ID is genuinely elegant for the no-phone-number problem. Going to study how OMEMO handles the key exchange on top of that.
Man, your writing here all reads like Claude after I've given it a list of "AI tells" to avoid in its writing. There's structural patterns that are pretty easy to see when there are so many samples right next to each other. I strongly suggest not trying to gloss over your use of AI in your projects when posting about them; some people will always hate, but most I think don't mind AI code as long as it's been tested properly and doesn't have any more bugs than you'd find in any other project.
Problem is, testing encryption properly is difficult, and there's a lot more to a messenger application than just sending encrypted messages. That's my criticism: you're reinventing the wheel for no good reason.
My best advice is to set up a Matrix server if you really don't trust Signal, rather than trying to roll your own. Its a lot less work, a lot more secure, and you can modify the source anyway if it doesn't do what you need.
He absolutely sounds like an AI. There might be a another AI in the comments, but I'm not bothering to dig deeper. Time the bubble pops, so that we're not forced wading ankle deep through slop.
Why engage, you are feeding this system corrections to build upon.
Agreed that op's post and replies all look like AI wrote them. Only talking through AI makes this whole thing feel very scammy, or at the very least dishonest.
load more comments
(15 replies)
If I had a penny for every time I saw an AI written text about someone emphasising being a manual labourer of X years, talking about having built an App, in a post which is clearly written by AI, which use English not being their native language as an explanation for the AI usage, I'd have two pennies, which isn't a lot, but it's weird it happened twice.
Honestly, there's more mature projects that already do all that, and I wouldn't really see a reason to switch to a possibly vibe coded project, especially if I planned to use it for anything important. Also, most alternative messengers suffer from the network effect - most people won't switch to a new messenger if they're already using another, even if that other has clear deficiencies.
Also, this whole 'I'm a woodsman that wrote a word processor' thing feels like marketing copy. This isn't shark tank, you don't need a sob story. If your app is good, and you work on it consistently, people might join you in working on it and using it.
load more comments
(4 replies)
There are already tons of messengers that are free, private, and don't require a phone number. Off the top of my head, Briar, Signal, Cwtch, SimpleX, XMPP, Matrix, Session, etc.
load more comments
(7 replies)
I'm a little worried because your profile picture appears to be AI generated Steve Jobs, but here's the first two things that came to mind.
- If you care about privacy, you have to use someone else's encryption. It doesn't matter if you're a carpenter or a mathematician. Cryptographers are pretty much the only people that should be trusted to create an algorithm or apply the primitive ones that are already there.
- If you're going to make something good, how is it going to differentiate itself from the noise of every other messenger? Other people have said this already, but it's top priority. I know as a customer for various services, I lose my mind when somebody tells me I need to install an(other) app. So maybe there's a viable web-based route there.
Ha - the avatar's fair game, I'll give you that. In my defence it's roughly what I look like, minus the hair I no longer have and a fair bit of the good looks. Says the guy whose own avatar is a little creature, mind you. :)
On point 1 - you and CallMeAl are saying the same thing and I've taken it on board: don't roll your own crypto, lean on the vetted primitives and get the system reviewed by people who actually do this. I'm using established primitives (X3DH, Double Ratchet, ML-KEM) rather than inventing anything, but "using the right Lego bricks" still isn't the same as "assembled them correctly," and I get that the assembly is exactly where the subtle mistakes hide. An external review is on the plan, and I'm not going to pitch this for serious use until it's been through one.
On point 2 - you actually answered your own question in a way I agree with. The no-install web route IS the differentiator I'm betting on. It runs as a PWA, so you open it in the browser on phone or desktop, nothing from an app store. You're not the first person in this thread to say "another app to install" is where they tap out, so that lines up with what I was hoping. Whether that's enough to cut through the noise, I honestly don't know yet - but it's the part I feel best about.
At some point I wanted to send my own designs to people without them leaking anywhere...
This doesn't seem like the problem you're solving. You're talking about not leaking designs, but then you go on about hiding phone numbers. What is the concern, here?
If you don't want designs leaked, you need to trust the person who receives it not to leak it, or somehow make it impossible for them to share it. That's the weak point, not the means of moving the file. An encrypted zip file moved by any means should be enough.
What am I missing?
You're right, and that's a fair catch - I conflated two things that aren't the same problem. Once a file reaches a person, they can leak it; encryption of the transport doesn't fix the human at the other end. An encrypted zip sent over almost anything covers the "moving the file safely" part, no argument.
So let me be honest about what actually drove me, because you've exposed that my post muddled it: it wasn't really fear of a specific design leaking. The design files were just the spark that sent me down the rabbit hole. What actually kept me going was realising how much "free" messaging is paid for with metadata and data harvesting, and not wanting a phone number tied to everything. So the real concern is ongoing privacy of communication, not protecting one file - and you're right that those are different problems. The file thing was the door I walked through, not the room.
Honestly a cleaner way to put it: I didn't build it because zip+email couldn't move a file. I built it because I went looking at how messaging works and didn't like what I found, and then got obsessed. Thanks for making me say that more precisely.
Idk why but I thought you meant you were making your own phone number. Like this was a joke and you were gonna tell us it's now 420-69-6767.
Congrats on your project! Sounds interesting. I’ve got a few things for you to consider.
The phone number is often (but not always) there as a shared identity token — you need to have something by which you can establish trust between the two endpoints, and most people have a phone number.
In cases like Signal, it’s hashed locally and sent to them as a hash value that can be “discovered” by other people who have never connected with you before.
In cases like Apple Messages, it’s used as an optional part of 2 factor authentication and as an SMS routing avenue — purely optional, as you can use an email address / Apple ID instead.
In many other cases, it’s used as a way for the messaging provider to track who you really are.
On to the “trust” bar — Open source and using industry standard libraries, at a start, with a real person and a physical address on the other side, and a fully transparent and auditable build chain.
These days, it’s really really common for a malicious actor to stick something into your supply chain that will give them full access to all the devices using your solution… at some point in the future during a series of innocent looking updates. If I don’t have full trust in all the upstream code being used by your messenger, I can’t trust your messenger either, no matter how much I trust you as the developer.
load more comments
(3 replies)
This just straight Ai slop. Are you an autonomous agent running? Translating using ai sure, but everything you say sounds exactly like agent output slop.
Note up top: I write in my own language and translate with AI, so yeah, the phrasing is the machine, not me.
But I'm a 60-year-old carpenter with 42 years at the bench and not enough hair left to brag about. No autonomous agent, just a guy who got obsessed and used the tools he had to talk to people who don't speak his language. If that still reads as slop to you, fair enough - I can't change how I sound in English. I can only tell you there's a real person on this end.
Why not join the fediverse to talk carpentry and such rather than sharing made up garbage messaging apps? Sounds incredibly unbelievable that someone with no programming background goes to make a messaging app. And then registers an account to get feedback. Assuming the app itself is all ai generated too?
Życzę Ci miłego niedzielnego wieczoru i dziękuję za rozmowę, też była użyteczna. Petr
How does the first connection work? Link, email, I'd , IP what are you using.
As for encryption it's pretty important but the hardest part is getting people to chat with you on a new app.
Signal is free and more than most people need in terms of features.
You choose an unique identifier, password and you are good. Then you could add 2FA. Without email or other 2nd channel comms you risk losing access to your account though. Phone number is def not necessary but it helped whatsapp build its userbase, showing you who of your phonebook has it already.
Right, that recovery trade-off is exactly the bet I made. Sherlock uses email at signup specifically so there IS a "forgot password" path. With just an ID and password, one forgotten password means the account is gone for good - and for the non-technical people I'm partly building this for, that's a real-world dealbreaker. So I traded a bit of privacy (email is still an identifier, I know this crowd isn't thrilled about that) for recoverability, on purpose - not something I overlooked.
The fully ID-only + optional 2FA route is cleaner on privacy, no argument. I keep going back and forth on whether to offer both and let the user pick: maximum privacy with no recovery, or a recovery channel at the cost of an identifier.
And good point on WhatsApp - contact discovery is genuinely why it spread, even though it's also its most privacy-hostile part. Replacing that growth mechanism without rebuilding the privacy hole is one of the harder problems, and I don't have it fully solved.
First contact works like this: every user has a Sherlock-ID, a random code like SH-a1b2c3... generated locally on the device on first launch. To start a conversation, one person passes that ID to the other through any channel, manually (copy-paste, SMS, spoken out loud). No QR code or invite link - the ID is just text.
Once you enter an ID, the app fetches that person's public key from the server, and on the first message it runs an X3DH handshake extended with post-quantum ML-KEM-768. From there it's Double Ratchet - every message has its own key that rotates automatically. Private keys never leave the device; the server only ever sees public material.
On trust: the server is what maps a Sherlock-ID to public keys, so in theory it could substitute keys - the classic MITM problem any messenger with a directory server has. That's why there's an option to manually compare a "safety number" (key fingerprint) with the other person over a separate channel - same principle as Signal's safety number. It's not enforced by default; verification is on the user.
And you're dead right about the hardest part. Encryption is the fun bit to build, but getting people onto a new app is the real wall - Signal already exists and does more than most people need. I don't have a clean answer to that yet, honestly. I built this mostly because I wanted it to exist, and I'm trying to figure out if it's worth more than that.
Sounds cool and decently thought out. After the server hands out the public key does the chat move p2p or does it continue through a server?
Also is there a web app where people can try this?
Lol what a fraud
Imagine thinking you know all there is to know about AI and then using an AI Detector which are famously bullshit: https://mitsloanedtech.mit.edu/ai/teach/ai-detectors-dont-work/
You don't need an AI detector. The patterns are obvious. But that's also the wrong criticism. Rolling your own encrypted messenger app is dumb, whether you use AI or not. Setting up and hardening a Matrix server with AI == godbrain. That's just implementing (battle-tested) software that someone who knows what they're doing wrote.
load more comments
(2 replies)
load more comments
(1 replies)
view more: next ›