this post was submitted on 25 May 2026
15 points (74.2% liked)

Privacy

9997 readers
66 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
15
Peer to Peer Messaging App (lemmy.ml)
submitted 2 weeks ago by GradleSurvivor@lemmy.ml to c/privacy@lemmy.world
31 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 1 week ago* (last edited 1 week ago) (1 children)

i won't comment on your tor-to-cloudflare-to-google design because i haven't looked at it and don't expect i'll make time to anytime soon.

I don’t think I can avoid cloud services entirely

Lots of similar things are able to avoid cloud services entirely; your perceived need to use them is driven by your so-called "server-free" design which isn't really free of servers at all because, as the saying goes, "there is no cloud, just other people's computers".

You could also use Google's push notifications but make them optional, btw. Making the protocol have a hard dependency on that is a choice you are making.

when the two peers are within Bluetooth range

having users' devices transmit fixed identifiers while moving around is terrible for privacy / great for surveillance, and firmly in the category of things which i not only do not recommend but implore people to not build. please don't.

I’m now focused on defining a solid architecture rather than working on my landing page

But your landing page is still up, and still making unsubstantiated claims and encouraging users to trust in (aka rely on) a thing which is totally half baked. You are still peddling snake oil. You should fix that.

The App is not for sale anyway at the moment, if and when I will eventually try to sell it, I was thinking about a monthly subscription, that would cover the cloud services costs plus some revenue.

I see, now we're getting down to it :)

A few questions on that front:

  1. Did you disclose to your beta users (and the general public you're asking for help here from) that they/we are doing volunteer work for what you intend to be a for-profit endeavor?
  2. How do you plan to limit access to your cloud services so only subscribers can use them?
  3. If someone wants to fork the software (assuming you're planning to keep it under a free software license) presumably users of the fork will not be able to communicate with the users who are paying you, since the whole thing fundamentally requires the cloud infra you're paying for? Or, if you actually want forks to be interoperable, how do you expect that to work?
[–] GradleSurvivor@lemmy.ml 1 points 1 week ago (1 children)

About cloud services: The core idea behind the "server-free" design is to keep users' messages from ever touching the cloud. Wake-up notifications and signalling (metadata) do require some kind of cloud service before the peer-to-peer connection is established. The only way to avoid third-party cloud services entirely would be to build your own, though I'm not sure that would really change how the dependency is perceived from a client's perspective.

About Bluetooth: Messages are still end-to-end encrypted, anyway It’s a user choice, you don’t have to use it, and I found a lot of people appreciate this feature, Briar has it.

About the landing page: At least I’m clear I’m still in beta, evolving situation, anyway I’m working on the right wording.

About the questions:

  1. Did you disclose to your beta users... I did in my “learn more about Open Testing”, but again, I’m going to change the text to be more explicit.
  2. How do you plan to limit access... Beta testers get it free forever, no gating needed for them. Only post-launch signups will need a subscription, and that gating (a server-side check on the Play purchase token) is planned, not built yet.
  3. If someone wants to fork... That is right, a fork on its own backend can't talk to my users, because both sides need to use the same signalling infrastructure to find each other. Separate forks aren't interoperable by default.
[–] cypherpunks@lemmy.ml 1 points 1 week ago

The core idea behind the “server-free” design is to keep users’ messages from ever touching the cloud

"but why" meme, with the the text "but why?" over an image of Ryan Reynolds in medical scrubs in the film Harold & Kumar Go To White Castle

given that the messages are encrypted, what is the advantage that you perceive in using "the cloud" (servers) only for signaling rather than transmitting the actual ciphertext through them? Wouldn't your "cloud" servers see "just the metadata" either way?

It saves some costs for you, but it comes at the cost of requiring users to be online at the same time to exchange messages... is there some other advantage that you see?

a server-side check on the Play purchase token

ah, so it will be the kind of "free open source software" which can only be used via Google Play 🙄

Separate forks aren’t interoperable

that's another thing you should inform potential users of explicitly, if you want to be honest.