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.
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.
Yeah; I think you’re on the right track. Without the audit, you’ll have got it to the point where people with whom you’ve already established some level of trust should be able to use it. If it takes on a life of its own, you’ll need the external formal audit to establish trust with the larger audience. But any sort of a security review will be beneficial; implementing security is hard.
That framing really helps - "fine for people who already trust you, formal audit before it goes wider" is a clean line to hold myself to, and it stops me from overselling it in the meantime. I'll treat the audit as the gate for any broader claim.
Thank you for taking this much time with it. You gave me the most useful thread in here by a mile - the supply-chain point and this trust-staging both reframed how I think about it. Genuinely appreciated.