this post was submitted on 25 May 2026
19 points (74.4% liked)

Privacy

10569 readers
566 users here now

A community for Lemmy users interested in privacy

Rules:

  1. Be civil
  2. No spam posting
  3. Keep posts on-topic
  4. No trolling

founded 3 years ago
MODERATORS
iopq@lemmy.world
19
Peer to Peer Messaging App (lemmy.nz)
submitted 2 months ago by GradleSurvivor@lemmy.ml to c/privacy@lemmy.world
30 comments fedilink hide all child comments
 

I have been working on an Android App quite a while now, starting from a simple idea.

A messenger where messages travel directly between phones with no servers in between. Using direct WebRTC encrypted connections (SRTP/DTLS), there are no servers that stores, reads, or relays content. Group chats use a gossip protocol where members relay to other members.

The only infrastructure the app touches is a signalling relay to set up the connection (no message content), a push notification to wake up a sleeping phone (also no content), and a TURN relay for restricted networks (encrypted packets only).

I wrote a detailed white paper explaining the full architecture: https://www.mindtheclub.com/white-paper.html

The app is in Open Testing on Google Play (1,000 tester cap): https://www.mindtheclub.com/beta-signup.html

I’m interested in this community's perspective on whether the architecture holds up.

you are viewing a single comment's thread
view the rest of the comments
[–] cypherpunks@lemmy.ml 1 points 2 months ago* (last edited 2 months ago)

The scanner gets the other party’s fingerprint from the QR, the scanned party gets the scanner’s fingerprint sealed inside the contact request, encrypted to a key the scanner has already verified

that sounds reasonable

The “no single point of failure” sentence conflated three different things (availability, compromise, compelled disclosure) and treated them as one. I’ve rewritten the relevant section.

I wouldn't say your previous text conflated these things per se; it said all three aren't possible failure modes when all three in fact are.

And unless I'm mistaken, you didn't rewrite it but rather simply removed that bullet point altogether? I think it would be more honest for the 'white paper' to explicitly acknowledge that Google and Cloudflare are both single points of failure for availability, and also enumerate what an adversary gains by compelling or otherwise compromising them. Assuming your qrcode key verificaion works as described, it sounds like it's "just" metadata (who talks to who, and when, who is in what groups with who, users' online/offline and location history, etc) and also the ability to do targeted denial-of-service. Right?

Also it would be nice to disclose what your business model is; presumably you're paying for these cloud services, but how much? and how long and to what scale can you afford to do so?

I hope you'll forgive my bluntness; to be clear I appreciate you building something with cryptographic identifiers and not requiring phone numbers, but it isn't something i would use or recommend as long as it relies on companies like google or cloudflare.

i don't see any advantage over SimpleX except for that it "doesn't require a server" (and btw SimpleX's default preset servers also don't have a very confidence-inspiring answer to the business model question i asked you here - it's we'll do some freemium thing later), but, since you still require cloud services, sacrificing the ability to store-and-forward a message to someone who is offline doesn't seem like a very good tradeoff 🤔