• 1 Post
  • 20 Comments
Joined 2 months ago
cake
Cake day: June 14th, 2026

help-circle

  • 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.)


  • Yeah, you’re right - you can tell any AI to write in a certain style. But look, the “problem” we’re solving here is just: I translate my own language into English with AI. I could use Google Translate instead - and that’s not a bad thing either. Tons of companies build online translators, earbuds that translate live calls in your ear - they all use AI too. Does that bother anyone? No.

    Sure, I could tell the AI to talk like a teenager, or like a shepherd up in the mountains herding sheep. But come on. I came here to talk about an actual topic, not to spend every reply proving how I’m allowed to talk to you.

    So honestly - let it go. If it bothers you that much, just don’t write with me. Maybe someone will turn up who doesn’t care whether I use a translator or AI or whether I’m just good at English. Maybe someone wants to talk in Portuguese or Luxembourgish - no problem. But that’s not what this forum is even about.

    I respect that you wrote to me, I do. But I came home from work to check for new replies, doing my own computer work in between, and honestly - this is a riot. You’re solving a problem that isn’t a problem. Not for me anyway. I genuinely do not care who translates my language into English. What matters is that I’m talking about something real. Instead we keep circling the same thing: AI, am I a bot, should it be this way or that. Ah well. Ah well.

    (English isn’t my first language - AI helps me translate. Still. :))




  • You might be right. I can see there are a lot of people here who simply don’t like AI. I talk in my own language and AI translates it - I just read it and decide whether to send it or not. So when it comes out sounding like AI wrote it, fair enough - but the thoughts are mine, and I stand behind them.

    I won’t argue with you. Honestly, all these negative takes only make me stronger. It’s a school too - it tells me to keep going my own way and reach my goal. That’s the good part: a person shouldn’t give up just because they hear a lot of negativity. I go my own way and I’ll get there - and in some things, I already have.

    Thanks for what you wrote, genuinely. Have a good day - or evening, I don’t know where in the world you are.

    (English isn’t my first language - AI helps me translate.)





  • You’re right that you can tell, and I’m not hiding anything. English is not my language - I think in another one. I don’t have a translator built into my head, so yes, I use AI to talk to you here. And I use AI to build the project too. I’m not ashamed of that. I’m a carpenter who can also write software and run my machines with code I made myself - AI is the tool that lets me do more than I could alone.

    Honestly, the thing I feel most right now is just glad I can talk to you at all. You and I speak completely different languages, and here we are having a real conversation about something we both care about. I think that’s valuable. People connecting and talking - that’s a good thing, not something to apologize for.

    I know the world is split between people who hate AI and people who use it. I don’t think it’s going to stop or go away. It will keep going, and it’s on us - the humans - how we use it. I’m trying to use it for something positive. If the messenger is good enough to pass an independent audit one day, I’ll be proud that a carpenter built it with AI and it still held up.

    So - no hiding. Thank you for the honest criticism, and for talking with me.


  • Yeah, I have looked at them, and you’re right - I should be careful not to describe this as solving an unsolved problem, because it isn’t one. DeltaChat, SimpleX, Session and Jami all exist and several go further than I do on PII. Session and Jami in particular don’t need an email, which is more than I can say - I traded that bit of privacy for account recovery, deliberately, but it does mean they’re ahead of me on pure “zero identifiers.”

    So I won’t pretend I filled a gap nobody else had. Honest version: I went down the rabbit hole, didn’t love how the free mainstream options handle data, and built my own partly to learn and partly because I wanted it to exist. Where I’d say it differs is the no-install browser/PWA approach and post-quantum from the start - not “nobody else does private messaging.”

    The “scratch your own itch even if it’s been done” point is basically how I’d defend it too. I’d rather be honest that it’s one more option in a crowded field than oversell it as something new. Appreciate you listing those - genuinely useful for me to study how they each handle the no-PII side.


  • 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.



  • 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.


  • 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.


  • 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.


  • Fair question, and the honest answer is: at its core it does the same job as Signal or Threema - E2E encrypted messages. I’m not claiming to beat them. The differences are in a few specific spots:

    • Post-quantum encryption already in place: ML-KEM-768 combined with classic X3DH, plus Double Ratchet. Signal is rolling this out; a lot of the others don’t have it yet.
    • No phone number at signup. Though I’ll be upfront - right now it uses email instead, which I realise is still a personal identifier, just a less sensitive one than a phone number. Fully identifier-less first contact (like Briar/SimpleX do it) is something I’m still chewing on.
    • You can see every login to your own account - where from, with a risk flag - so if someone tries to get in, you know immediately. Haven’t seen that surfaced this directly elsewhere.
    • Runs as a PWA, so nothing to install from an app store - opens in the browser on phone and desktop. Disappearing messages, large file transfers, no ads, no tracking.

    Where I’m honestly NOT ahead of Signal yet: Signal hides connection metadata (who talks to whom) better than I currently do - that’s what I’m working on next. And Signal has years of independent audits behind it. Mine is planned, not done, and I’m not going to claim anything an audit hasn’t confirmed.

    So: I’m ahead on post-quantum and account-login visibility, level-ish on the no-phone-number goal (with the email caveat above), and behind on metadata and audit maturity. That’s the honest scorecard.


  • This is genuinely the most useful reply I’ve gotten - thank you for taking the time. The breakdown of what the phone number actually does for is clarifying; I’d been thinking of it purely as a privacy leak, but you’re right that it’s also doing the “shared identity token” job, and dropping it means I have to solve that some other way (I use a locally generated ID, but I’ll admit discovery/trust-on-first-contact is the weakest part).

    The supply chain point is the one that lands hardest, and it’s fair. “Trust me, the developer” is worth nothing if the code underneath isn’t inspectable - I hadn’t framed it that sharply to myself until you put it that way.

    One thing I’d like your read on, since you clearly think about this properly: if a small project gets to open source + standard vetted libraries + a transparent build, but realistically can’t afford a full third-party audit for a while - is that a “come back when you’re audited” situation, or is open + standard libs + reproducible builds enough to be worth a careful person trying? Trying to understand the actual order of priorities, not just the wishlist.


  • 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.


  • 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.