- cross-posted to:
- android@lemmy.world
- cross-posted to:
- android@lemmy.world
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 must log in or # to comment.
Is this just a clone of SimpleX?
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.
Am I not seeing the actual white paper or is the “white paper” just a short blog post? Usually a white paper is a ~50 pages technical PDF, but you said detailed so I expected at least 100.
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.
Awesome work! Just curious as to how different your product is from Briar? From what I understand, it is used by quite a few activists and journalists and seems to do exactly what you have tried (and more).
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.
so it sounds like this is more for group chats, to ensure at least one member is online at all times. Otherwise, if it were just 1-1 messaging, and one person’s phone went offline, the other person would have to wait until it was back online to send a message, right?
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.
Okay, this sounds good, but why is the app on google play and not F-Droid? Whenever I download an app from Aurora Store I immediately assume that the source code has been modified by google and that the app isn’t trustable. I know 99% of the time this won’t happen, but it’s absolutely something that could happen.
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.
Another issue I have with it is the AI-generated images on your home page. Please don’t enslave yourself to the environmental destruction machine.
just use session, threema, sessionx, they solve this
SimpleX*
yep that, thnx
Wait, did you not know that Session will die soon?
i do, but i donated, so i had hope
I personally wouldn’t use it because of the firebase signalling. I don’t want to share meta data like that, which is associated with every message transmission unless I’m misunderstanding your architecture.
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.
Like XEP-0174 from the XMPP protocol set but using a server for making the connection?
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.
What I’d like is something that doesn’t use Firestore, but uses either XEP-0174 or proximity handshaking to establish the initial shared secret between two devices, after which something like TOR or I2P could be used fir signalling against the shared secret.
That way, interception gets you nowhere and nobody’s able to follow the signal back to host to gain connection metadata.
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.
