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.

Yep, true. As I said, the conversation we had today was very helpful for me to understand and work on some stuff, and I will continue to work on it. There is another couple of observations I would like to think about. So genuinely, thank you for your time and feedback, of course I respect the decision, not going to re-post.

Thank you very much for this feedback. It gives me the opportunity to discuss in more depth some details you have rightly highlighted and, more importantly, I have updated my white paper accordingly, (How MTC Connects You).

On the Cloudflare and Google dependency, you’re right, and you put your finger on the line in the white paper that overstated the case. 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.

The accurate framing is narrower, message content never reaches any third party, there is nothing on Cloudflare’s, Google’s, or our side to hand over, because no one ever received it. But availability does depend on those providers being reachable, and metadata exposure exists at the signalling and push layers.

To address the metadata exposure, I have implemented a sealed-sender design inspired by the Signal’s approach, the wake-up payload is encrypted with the recipient’s public key and the sender’s identity is inside that envelope, so the push provider sees the recipient but not the sender.

The per-step detail of what each component can and cannot see is now on How MTC Connects You.

About MITM under a compromised provider, both peers verify each other’s public key independently after one QR scan. 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. A compromised directory cannot substitute either key without producing a fingerprint mismatch on one side or a failed decryption on the other, and it doesnt hold the private material to do either. The mechanism is now documented in “How MTC Connects You”.

On messages requiring both peers online, yes, that’s structural and intentional. It’s the cost of holding no message content on any server. Briar and Jami make the same trade off for the same reason.

On IP exposure to contacts, also fair, and intrinsic to direct WebRTC peer-to-peer, same as Jami. The mitigations are the TURN relay path (peers see no direct IP, Cloudflare sees encrypted packets only) and, for users who want it, the option to force relay-only. Briar avoids this by routing through Tor, that’s a real architectural alternative with different costs.

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.

Looking forward to your comments!

Thank you for the comment!

Actually it is open source (GPLv3): https://github.com/AndreaVagheggi/mindtheclub

I have tackled the Cloudflare dependency implementing a “sealed sender” feature, the wake-up/signalling payload is encrypted to the recipient’s public key, and the sender’s identity is inside that envelope. The push/signalling layer sees who’s receiving, not who’s sending.

I use the standard webRTC approach for hostile networks, which is TURN, also with Cloudflare.

Not quite, SimpleX runs on a client-server architecture, messages route through relay servers that hold them temporarily until delivered, then delete them. MTC messages go device to device with nothing storing them in between, not even temporarily.

It’s mostly about positioning.

MTC aims for a balance between standard rich-media real-time messaging, including audio/video calls (WhatsApp-like), and privacy (full peer-to-peer, no registration, no phone number).

The target is a standard messaging-app user who wants more privacy for their conversations without giving up the features they’re used to.

Jami uses a very similar set of protocols, the main difference is how peers are discovered, Jami uses a distributed hash table (OpenDHT) where every device is a node on the network, which can mean more setup friction and a more technical experience, aimed at a more tech-savvy audience. One side effect is that your IP is visible to DHT nodes, in MTC it’s only ever exposed to your actual contact and the TURN relay.

This is my plan, currently the App is in beta testing, I’m in a phase of trying to find people to stress test it, once the code is properly debugged I will make my GitHub public.

This is a very open question, there are a lot out there.

In a nutshell, MTC is a balance between standard rich multimedia real-time messaging, including audio/video calls (WhatsApp like), and privacy (full peer-to-peer, no registration, no phone number).

MTC’s target users would be standard messaging app users with some more attention and concern about protecting their private conversations, without giving up all the standard messaging features they’re used to.

Other apps have different balances, (e.g Briar optimizes for metadata-hiding, less rich chat capabilities, Signal requires your phone number to register, etc…).

Briar is good, it has just has a different positioning.

MTC is a balance between standard rich multimedia real-time messaging, including audio/video calls, and privacy (full peer-to-peer).

Briar’s design, based on Tor, limits the possibility of a full messaging experience (WhatsApp-like), but it’s strong on metadata hiding, and its target users are different (activists and journalists in hostile or censored environments, etc.)

MTC’s target users would be standard messaging app users with some more attention and concern about protecting their private conversations, without giving up all the standard messaging features they’re used to.

I agree, is actually quite high level, describing the main architecture and functionality`. What I intend to do, once the code is fully debugged, is to make my GitHub public, and upload a more detailed technical doc there. I thought not to make a public landing page, that targets a broader audience, too technical. In the meantime I’m happy to respond to any kind of technical question.

Currently the App is in beta testing, I’m in the phase of trying to find people willing to stress-test it. Once the App is fully debugged my plan is to open-source it, making my GitHub public, and this is a pre-requisite for uploading the App on F-Droid.

That is correct, but it works well for 1 to 1 messages.

There’s no relay in between, but you don’t have to wait to send, you hit send normally and the message just queues locally on your device, then goes out automatically the moment a direct connection re-establishes. Nothing sits on a server in the meantime.

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.

Great, looking forward for your feedback.

There’s nothing wrong with Briar, it just has a different positioning. MTC is a balance between standard rich multimedia real-time messaging, including audio/video calls, and privacy (full peer-to-peer). Briar’s design, Tor when online, Bluetooth/Wi-Fi mesh when offline, limits the possibility of a full messaging experience (WhatsApp-like), but it’s strong on metadata hiding, and its target users are different (activists and journalists in hostile or censored environments, etc.). MTC’s target users would be standard messaging app users with some more attention and concern about protecting their private conversations, without giving up all the standard messaging features they’re used to. By the way, I’m working on implementing the Bluetooth option.

Sorry, I took note

No, you got it right, and is a fair point, I do use firestore for signalling, I can guarantee user messages are only transferred from one peer to the other with nothing in between, but I do not hide metadata.