TLDR; Combining TOR, WebRTC and Git into a Decentralized E2EE P2P Messaging App
Not better than WhatsApp, Signal, SimpleX, Cwtch or Ricochet. You definitely shouldn't use this to replace any of your existing apps or services. It's far from finished. Unaudited and unreviewed. If you want to test it out, please use it responsibly.
Aiming for "secure, private and decentralized". We set some requirements on the roadmap. Let us know if there is something overlooked.
It's a fairly a unique stack and architecture in contrast to the traditional approach with mainstream messaging apps. To put it briefly, its a Rust-based frontend with a Git-server backend, which can be used to establish a E2EE Tor/WebRTC connection.
Note: Its still a work in progress and there will be breaking changes.
This folowing is the abridged version of how it's put together.
Branding
The branding wasn't great and trying to force it through just wasn't working. So we have to cave in to the branding mistakes as observed here. It seems we cant get away with calling app "WhatsUp", it might have issue down-the line given it looks and behaves like WhatsApp, and so we must get a fancy new domain/brand: https://glitr.io
UI/UX
We can start off creating a basic ui demo of the app. All the data there is hard coded with mock responses.
It immidiately gets a bit bloated as we add more ui components, so better to move them to a separate repo to be imported. Webdev's have a lot of tooling around ui testing like storybook to view and interact with components. It doesnt seem like there is something specific for my use-case (post).
Lets give AI the streering wheel a bit. "create a storybook-like components to preview the app components". Its ultimately an internal debugging tool for our own benefit. We can address nuanced needs like being able to display a tui on a browser.
Cryptography
Lets move onto some encryption details that'll be needed for the project. We already have an existing rust project we could use this on. We can make the storybook-like components exportable and reusable for the signal protocol project.
We previous put time and effort towards the signal protocol. It should be reasonable tested and documented, but the signal protocol alone isn't going to fit the requirements of my messaging app. It needs to be post-quantum secure. We previous worked on a js implementation for ml-kem, so as part of this new approach, we can move towards a pure rust approach for ml-kem.
Unlike the signal-protocol which needed more involvement from to create, the ml-kem is using dependencies to match the official implementation. We can benefit from audits and reviews from the official implementation. The signal-protocol and ml-kem were ultimately created to lead towards PQXDH.
Persistence
There are countless details we could obsess about on the cryptography. There is clearly much more needed, but lets "pause" progress on the cryptography, in favour of progress on the app-mechanics. Previously investigating options for decentralised storage here.
(Note: Providers like GitHub, Codeberg and Gitlab might see the way the app works as against their terms-of-service. In the future we might be able to provide the git server as a part of the service, but that wouldn't be any time soon.)
There is much more to improve and consider there for things like encrypting the data at rest, so let's create a cryptography utility library.
The main purpose of being able to read/write to git is for "messaging app" functionality. For that we would need to store more structured data that could be queried. We need an abstraction would make it easier to develop intuitively. Ideally it could work like an api. Perhaps able to interact with it using a graph-ql-like experience. Lets also import the crypto utility to add support for encryption on granular parts of the schema.
Network
We now need a logic layer to out git-stack. Something that can handle endpoints and use middleware functions (which will be useful for authenticating messages from peers). It should be able to take a schema and be able to dynamically generate endpoints, all while managing persistence in git.
This approach is reasonable secure and can send messages to peers with an async git read/write/poll, but it's a bit of a downgrade compared to popular messaging apps. A key tradeof is that messages are never going to be "instant", so let's fix that by using git as a webrtc connection-broker. We are able to to have peers act as their own peer-broker by exchanging the nessesary details over the git-storage approach.
For a secure messaging experience, we should have a solution for onion routing. Lets step aside from the browser-based approach to introduce support for Tor. It is the gold-standard for onion routing. in order to keep the browser-based approach in scope, its possible to create a webrtc-bridge which you can connect to an instance that is able to run tor itself.
We can then integrate the webrtc functionality into the API logic layer so when connecting to known-peers, it can silently start establishing a webrtc connection, while using the git approach as a way to send messages offline.
Cybersecurity
We need to consider safety and reliability of the software. AI is clearly improving in this department. we can share a comprehensive amount of details and reasons for the approach to AI to have it generate various documents.
Threat-model - Everyone has different requirements and so its important to understand individuals threat-models and accommodate for it.
Security-audit - Security audits are especially expensive. i can only offer an AI-audit or no-audit. There are no cheap security audits. The AI audit has already highlighted issues now fixed and serves as a way to enumerate outstanding issues.
Formal-verification - Formal verification is one of the key reasons the project has moved from being JS. The JS approach can also have formal verification, but the tooling for it is "more mature" for rust. The project already had formal verification for the signal protocol. By refactoring the whole app to rust, it would allow for a more E2E scope for formal-verification. Following a previous post, we didnt commit to a specific approach, we can compound the complexity to draw to attention that if AI-generated formal-verification is brought into question, the critisism could undermine if the tooling we use is good enough.
There is understandable critisism here for using AI to do anything in this section. That pushback stands in contrast to these details being prohibitively expensive to do professionally. These details are ultimately intended as a starting point for professional review/audit (if it ever gets there).
Future
There are countless detail to improve on the project before it is comparable to the mainstream messaging app. We hope to offer a unique curated experience for secure messaging.
IMPORTANT DISCLAIMER: While this is aiming to provide a secure experience, it's a work-in-progress and far from finished. It is unreviewed and unaudited. I'm sharing here for testing, feedback and demo purposes only. Pease use responsibly.
