GradleSurvivor

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.

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.

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.

Not quite, with XEP-0174 you can only reach peers on the same LAN. I use standard WebRTC signalling to establish the connection, so peers on different networks can reach each other across the internet. Discovery itself is out of band, you add a contact via QR code or a profile link, then signalling just brokers the connection to that known peer.