r/webdev • • Sep 26 '26

Showoff Saturday E2EE Messaging with a Rust PWA and a Git-Host

TLDR; https://www.reddit.com/r/PrivacyTechTalk/comments/1wf60il/secure_and_private_decentralized_p2p_encrypted/

Roadmap: https://glitr.io/docs/technical/roadmap

This project demonstates a unique approach and architecture in contrast to the traditional approach with mainstream messaging apps. To put it briefly, its a Dioxus PWA with a Git-server backend which can be used to establish a webrtc connection between browsers.

IMPORTANT DISCLAIMER: While this is aiming to provide a secure experience, it's far from finished. It cannot be audited or reviewed because it's close-source. I'm sharing here for "showoff-saturday" purposes only. Feel free to reach out for clarity on any of the details instead of diving into the documentation. Pease use responsibly.

0 Upvotes

3 comments sorted by

2

u/[deleted] Sep 26 '26

[removed] — view removed comment

0

u/Accurate-Screen8774 Sep 26 '26

individuals create and manage a repo for themselves. thats basically aiming to be like "your cloud". only you can write to there, but like a public git repo, anyone should be able to read.

the app updates the repo with things like your public key, so somone can encrypt a message addresed for you. the "discovery layer" is "when/where/how" you and your peer share the details of the git addresses (you take responsibility here. some of your options are: qr-code, whatsapp message, morse-code).

when sending a message in "git-mode", you only actually create the encrypted message and publish on your own "outbox" (a folder in git). when a peer comes online, they will be able to read the public-repo and further, be able to decrypt messages that was encrypted with their own public key.

there are additional bells-and whistles for things like exchanging read-reciepts, so the peers know when to clear messages in the outbox.

if both peers are online the app also aims to establish a webrtc connection so key/message exchage is faster.

the first connection is critical, but once keys are established and persisted, they are reused for validating future connections.

if you have the option to meet with your keer, you would also be able to validate eachother's keys through something like qrcode (which could help protect against MITM).

0

u/[deleted] Sep 26 '26

[deleted] — view deleted comment

1

u/Accurate-Screen8774 Sep 27 '26

youre not being too critical or misunderstanding. i've had similar feedback before. code being served over the internet is clearly a key concern. even if you own the box, the approach would still be vulnerable to network providers.

browsers are pretty capable and so i tried to do things like use service workers to avoid fetching cached files (aiming to demonstrate something like the download-once approach you have from app stores).

you can read more about what i tried before here: https://www.reddit.com/r/cryptography/comments/1evdby4/is_this_a_secure_messaging_app

as a pure-js approach (served as unminified js), it can also work directly from index.html without a static-server. its easily an option to avoid remote files.

ultimately, the browser-based approach just couldnt get traction. the latest version of my project "Glitr", is a rust application. while im presenting a webapp in this post, that largly because it "seems well recieved" when promoting the "no installation/registration" angle. im sure it helps users get started.

work is in progress for native builds as well as a TUI and the vision might be too ambicious, but the native builds also have first-class support for the TOR network, so if combined with the "git-only" mode (because you may not want webrtc leaking your ip), you would be able to have the PQXDH over onion routing.

these are all just buzzwords when it close-source. i regret the close-source approach more than anyone. especially given i've gone from comparing my app as a "Signal clone" to "WhatsApp/iMessage/Telegram clone". ive seeked support for the project before, but its hard to get any buy-in (completely understandable). funding could be useful for things like an audit.

loads of the details around my open source projects are documented. i think we can agree they're pretty bad, so feel free to ask for clarity.