Bit of an odd intro: I’m a carpenter, 42 years at the bench. I’m the type who can’t stand making the same thing everyone else makes, so I’ve always chased the technical side too - CNC, laser cutting, and lately building software to run my machines.
At some point I wanted to send my own designs to people without them leaking anywhere, and I went down the rabbit hole of how messaging actually works. What got me was realising how much of the “free” stuff is paid for with our privacy. That annoyed me enough that I decided to build my own messenger, mostly to learn. It grew from something simple into a real thing. I called it Sherlock.
Two things I cared about: proper encryption, and NOT tying it to a phone number - I built a different system for that.
I’m not going to pretend I reinvented cryptography. I’m a woodworker who got obsessed. So I’d rather hear it straight from people who actually know this stuff:
- How much does the “no phone number” approach really buy you if I get the rest wrong?
- For a small independent project, what’s the bar before any of you would even consider trusting it - open source, audit, something else?
Genuinely here for the criticism, not the pats on the back.
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.
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: [email protected]. 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.