- 3 Posts
- 8 Comments
GradleSurvivor@lemmy.mlOPto
Open Source@lemmy.ml•WebRTC messenger architecture, sealed-sender push, encrypted signalling, looking for threat-model critique. Open Source GPLv3
2·22 days agoYou 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.
GradleSurvivor@lemmy.mlOPto
Open Source@lemmy.ml•WebRTC messenger architecture, sealed-sender push, encrypted signalling, looking for threat-model critique. Open Source GPLv3
2·22 days agoDiscovery 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.
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…).
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.



It’s already open source, you can find the link to GitHub on the landing page