Lol what a fraud
this post was submitted on 14 Jun 2026
12 points (61.1% liked)
Privacy
10014 readers
486 users here now
A community for Lemmy users interested in privacy
Rules:
- Be civil
- No spam posting
- Keep posts on-topic
- No trolling
founded 3 years ago
MODERATORS
Imagine thinking you know all there is to know about AI and then using an AI Detector which are famously bullshit: https://mitsloanedtech.mit.edu/ai/teach/ai-detectors-dont-work/
You don't need an AI detector. The patterns are obvious. But that's also the wrong criticism. Rolling your own encrypted messenger app is dumb, whether you use AI or not. Setting up and hardening a Matrix server with AI == godbrain. That's just implementing (battle-tested) software that someone who knows what they're doing wrote.
Your comment means absolutely nothing to me. I hope you know that.
I'm surprised you think I care. I've seen what you're dumb enough to fall for.
Mate, I told everyone in this very thread that I translate with AI - it's in three of my comments. You can't "expose" something I said openly myself. A fraud hides it; I announced it. The AI detector just confirms what I already told you. Carpenter, foreign language, AI translation - all stated up front. Nothing to catch here.
If I had a penny for every time I saw an AI written text about someone emphasising being a manual labourer of X years, talking about having built an App, in a post which is clearly written by AI, which use English not being their native language as an explanation for the AI usage, I'd have two pennies, which isn't a lot, but it's weird it happened twice.
Honestly, there's more mature projects that already do all that, and I wouldn't really see a reason to switch to a possibly vibe coded project, especially if I planned to use it for anything important. Also, most alternative messengers suffer from the network effect - most people won't switch to a new messenger if they're already using another, even if that other has clear deficiencies.
Also, this whole 'I'm a woodsman that wrote a word processor' thing feels like marketing copy. This isn't shark tank, you don't need a sob story. If your app is good, and you work on it consistently, people might join you in working on it and using it.
Man, your writing here all reads like Claude after I've given it a list of "AI tells" to avoid in its writing. There's structural patterns that are pretty easy to see when there are so many samples right next to each other. I strongly suggest not trying to gloss over your use of AI in your projects when posting about them; some people will always hate, but most I think don't mind AI code as long as it's been tested properly and doesn't have any more bugs than you'd find in any other project.
Problem is, testing encryption properly is difficult, and there's a lot more to a messenger application than just sending encrypted messages. That's my criticism: you're reinventing the wheel for no good reason.
My best advice is to set up a Matrix server if you really don't trust Signal, rather than trying to roll your own. Its a lot less work, a lot more secure, and you can modify the source anyway if it doesn't do what you need.
Why engage, you are feeding this system corrections to build upon.
He absolutely sounds like an AI. There might be a another AI in the comments, but I'm not bothering to dig deeper. Time the bubble pops, so that we're not forced wading ankle deep through slop.
Agreed that op's post and replies all look like AI wrote them. Only talking through AI makes this whole thing feel very scammy, or at the very least dishonest.
This post piqued my interest because I'm a dev that changed careers to finish carpentry (still working on my own projects in my spare time of course).
load more comments
(11 replies)
Honestly, I wouldn't even consider using it unless it were reviewed by a professional cryptographer. There are already battletested options that don't require a phone number or sharing info with a company. For that, I like XMPP with a client that uses OMEMO for encryption.
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.
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?
To me, open sourcing the code is a move in the right direction but it doesn't make up for a professional review of your encryption system.
The thing about encryption is that there are many subtle ways to get something wrong, even when just implementing it with a well known and trusted library. I took a deep dive course on Designing Secure Encryption for Practical Use and while I learned a ton from it, the main take away for me was that I shouldn't do it if its intended for serious use. At least not without expert reviewers.
Regarding XMPP, it's architecture is like email. Anyone can stand up their own server and your User ID looks like an email address: user@chatserver.org. Like email, you can send messages to anyone on any server if you know their ID. Phone numbers are simply never involved.
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.
This just straight Ai slop. Are you an autonomous agent running? Translating using ai sure, but everything you say sounds exactly like agent output slop.
load more comments
(3 replies)
There are already tons of messengers that are free, private, and don't require a phone number. Off the top of my head, Briar, Signal, Cwtch, SimpleX, XMPP, Matrix, Session, etc. Does your messenger offer something that these don't?
load more comments
(7 replies)
I'm a little worried because your profile picture appears to be AI generated Steve Jobs, but here's the first two things that came to mind.
- If you care about privacy, you have to use someone else's encryption. It doesn't matter if you're a carpenter or a mathematician. Cryptographers are pretty much the only people that should be trusted to create an algorithm or apply the primitive ones that are already there.
- If you're going to make something good, how is it going to differentiate itself from the noise of every other messenger? Other people have said this already, but it's top priority. I know as a customer for various services, I lose my mind when somebody tells me I need to install an(other) app. So maybe there's a viable web-based route there.
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.
At some point I wanted to send my own designs to people without them leaking anywhere...
This doesn't seem like the problem you're solving. You're talking about not leaking designs, but then you go on about hiding phone numbers. What is the concern, here?
If you don't want designs leaked, you need to trust the person who receives it not to leak it, or somehow make it impossible for them to share it. That's the weak point, not the means of moving the file. An encrypted zip file moved by any means should be enough.
What am I missing?
load more comments
(1 replies)
Idk why but I thought you meant you were making your own phone number. Like this was a joke and you were gonna tell us it's now 420-69-6767.
Congrats on your project! Sounds interesting. I’ve got a few things for you to consider.
The phone number is often (but not always) there as a shared identity token — you need to have something by which you can establish trust between the two endpoints, and most people have a phone number.
In cases like Signal, it’s hashed locally and sent to them as a hash value that can be “discovered” by other people who have never connected with you before.
In cases like Apple Messages, it’s used as an optional part of 2 factor authentication and as an SMS routing avenue — purely optional, as you can use an email address / Apple ID instead.
In many other cases, it’s used as a way for the messaging provider to track who you really are.
On to the “trust” bar — Open source and using industry standard libraries, at a start, with a real person and a physical address on the other side, and a fully transparent and auditable build chain.
These days, it’s really really common for a malicious actor to stick something into your supply chain that will give them full access to all the devices using your solution… at some point in the future during a series of innocent looking updates. If I don’t have full trust in all the upstream code being used by your messenger, I can’t trust your messenger either, no matter how much I trust you as the developer.
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.
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.
view more: next ›