15
Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism. (lemmy.world)
submitted 4 months ago by to c/privacy@lemmy.world
57 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [S] 3 points 4 months ago (2 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 4 months ago (1 child)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] [S] 1 point 4 months ago

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

  • permalink
  • fedilink
  • source
  • parent