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.
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.
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?
Sherlock is not P2P. After the server hands out the public keys, the chat still goes through the server - it doesn’t switch to a direct device-to-device connection.
It works like this: the sender encrypts the message on their device and sends the encrypted version to the server (Firestore). It sits there as ciphertext until the recipient fetches it and decrypts it on their own device. The server is a relay - it stores and delivers, but never sees the content, because the keys live only on the devices.
Why through a server and not P2P: P2P needs both devices online at the same time and reachable on the network. With a server model you can send a message while the other person is offline, and they get it later - more practical for everyday use. The trade-off is that the server sees metadata (who, to whom, when) - the content stays encrypted, but the fact of communication is known to the server. Same model as Signal or WhatsApp; they relay through servers too, not P2P.
And yes - there’s a web app you can try, it runs in the browser with no install: sherlockprivate.com. Fair warning, it’s a young project and not externally audited yet, so please don’t put anything high-stakes through it - but if you poke at it, I’d genuinely value what you think.
(English isn’t my first language - AI helps me translate.)
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.