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.

Hello,

Sorry to bother you again. I just wanted to share some architectural changes I’ve made recently.

I’m taking advantage of the fact that you’re the only one who has given me valuable feedback so far, so please feel free to ignore this message if you judge it’s not worth your time.

Along with moving the public key away from Firebase (the MITM issue), and implementing the sealed sender feature (sender information encrypted before it reaches Cloudflare), I’ve added a TOR service that the sender uses to connect to Cloudflare, both for the wake-up (instructing Cloudflare to send the FCM message via Firebase) and for signalling. I think this strengthens the “sealed sender” property.

I don’t think I can avoid cloud services entirely, except when the two peers are within Bluetooth range, I have that feature too. But I believe the sealed sender design limits metadata leakage in a reasonable way. My understanding is that Signal does something similar.

I’m now focused on defining a solid architecture rather than working on my landing page, which, as I appreciate, was initially built with a marketing mindset. So, I’m now more interested in technical feedback. I’ll get to the landing page later, once things have settled.

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.

Removed by mod

Removed by mod

You got it right. Messages are sent as soon as both the devices are online. The retry pipeline runs on Android’s WorkManager, which cooperates with Doze and App Standby instead of fighting them, so the app doesn’t sit in a tight loop draining battery while waiting. Testing with friends and family hasn’t shown any battery drain so far, but honestly that’s a small sample, maybe a dozen devices total, and friends and family are always a little bit biased. That’s exactly why I’ve gone to Open Testing on Google Play. I need real people, on real networks, on real battery profiles, to find the cases I can’t reproduce alone. If you (or anyone reading) wants to poke at it, that’s the most useful thing you could do for the project right now.

Discovery is through standard webRTC signalling done using Cloudflare, then all the user messages are sent peer to peer, no server in the middle. I have used AI mainly to troubleshoot and correct bugs.

Removed by mod

Removed by mod

Removed by mod

Removed by mod

Removed by mod

Removed by mod

The initial identity exchange between two devices isn’t done via Firestore, it’s done offline (shared by QR code). The key material used to verify a peer is authentic never touches the internet. Signalling is done through Firestore, and here it’s fair to say metadata isn’t hidden: Firestore knows that userId 01 contacted userId 02 at a certain date and time.

Removed by mod

Removed by mod

Removed by mod

Removed by mod