Skip Navigation

hoblik

@ hoblik @lemmy.world

Posts
1
Comments
25
Joined
2 wk. ago

  • Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism.

    Jump

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

  • Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism.

    Jump

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

  • Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism.

    Jump

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

  • Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism.

    Jump

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

  • Carpenter here. I got fed up with messengers wanting my phone number, so I built my own. Looking for honest criticism.

    Jump

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