-13
Secure and Private Decentralized P2P Encrypted Messaging over Git and WebRTC (programming.dev)
submitted 1 month ago by to c/privacy@programming.dev
11 comments fedilink hide all child comments
 

Edit for clarity:

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 testing, feedback and demo purposes only. If you are unsure, this isn't for you (you safely can move away from this post before it ruins your day). Feel free to reach out for clarity on any of the details instead of diving into the documentation. Pease use responsibly.

This project demonstates a unique approach and architecture in contrast to mainstream messaging apps.

The core philosophy around secure messaging here is that it can work in a way that avoids installation and registration by enabling users to host their own data (and user incompetence will be one of many nuanced vulnerabilities in this approach)

The project is unstable and experimental. It's far from finished, but im putting together some docs for "how it works". It's pretty outside-the-box thinking (and that shouldn't inspire confidence!), so it's worth repeating: Pease use responsibly.

Website/Docs: glitr.io

Demo

Features:

  • WebApp
  • P2P / WebRTC
  • Local-first / Local-only
  • No installation
  • TURN server
  • Encrypted-at-rest
  • Signal protocol
  • Post Quantum cryptography
  • Video calls
  • TOR / anonymous via Git
  • Serverless over WebRTC

Some of the core concepts:

FAQ:

  • Why git?
    • When it comes to secure messaging, self-hosting is generally encouraged. While not quite nessesarily self hosted, it would make it easier for the majority of users to get started. Users can choose a git storage provider of their choice (GitHub, Gitlab, etc), or host their own git server.
  • Serverless WebRTC?
  • Ready for production?
    • No. While this is aiming to provide a secure experience, it cannot be audited or reviewed. Shared for testing, feedback and demo purposes only.
  • EU Chat Control?
  • Threat model?
    • It's a work in progress. There are many details still to be implemented before I can share the initial draft.
    • It's close source and unaudited so the best I can offer is "trust me bro"... And you shouldn't need to. The app doesn't require sensitive details, so don't use any when testing it out.
  • Open source?
    • Open source from the onset is not something I can support at this stage. Hopefully I can work towards that goal. I'm aware this goes against the cybersecurity rhetoric. There are open source versions of various ideas linked above, but it's important to be clear, that glitr.io is close source in contrast to my other work.
  • Where can I find out more?

I hope my wording here wasn't too negative. When working in cybersecurity, there are countless nuances to consider and I would prefer to be discouraging than inspire undue confidence in the project.

Original post:

This might become the worlds most secure messaging app.

This project demonstates a unique approach to secure messaging. The approach is different enough that it can't be easily compared to Signal or SimpleX.

The core philosophy around secure messaging here is that it can work in a way that avoids installation and registration by enabling users to host their own data.

The project is far from finished, but im putting together some docs for the "how it works". It's pretty outside-the-box thinking (and that doesnt make it a good idea), so it would be great if you could share your thoughts on the approach.

Website: Glitr.io

Demo

Features:

  • WebApp
  • P2P / WebRTC
  • Local-first / Local-only
  • No installation
  • TURN server
  • Encrypted-at-rest
  • Signal protocol
  • Post Quantum cryptography
  • Video calls
  • TOR / anonymous via Git
  • Serverless over WebRTC

Some of the core concepts:

FAQ:

  • Why git?
    • When it comes to secure messaging, self-hosting is generally encouraged. While not quite nessesarily self hosted, it would make it easier for the majority of users to get started. Users can choose a git storage provider of their choice (GitHub, Gitlab, etc), or host their own git server.
  • Ready for production?
    • No. While this is aiming to provide a secure experience, it cannot be audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.
  • Where can I find out more?
you are viewing a single comment's thread
view the rest of the comments
[–] [S] -2 points 1 month ago* (1 child)

Calling it vibe coded slop without further details is just an insult. I'm clearly using AI, so let's get that out of the way (welcome to 2026 software development). You immediately assume that I don't know what I'm doing, so I typically don't feel the need to answer... But you called for my humility so let's proceed.

In the post I ask for you reach out for clarity on the details. But you don't do that and that's the basis of this "conversation".

Let's talk further about the approach with git. I started with a pure webrtc approach. A details I didn't like about that approach is that you couldn't send messages offline. I could create a more traditional database for messaging, I specifically wanted git because it allows for decentralised backups. While GitHub isn't decentralised, the app allows for multiple remotes. Ideally for security, users would self host... The majority of users are not going to go for that option (even if they know how). so being able to use an existing service would make things easier for getting started.

When using git, I'm breaking all the rules. My use of git is explicitly not the traditional use-case.

  • not using for version control
  • I'm publishing encrypted sensitive messages - as per kerkhoffs principles
  • I'm truncating history - so the storage doesn't retain redundant details
  • git with a combination of polling and syncing can be used to establish a webrtc connection without a dedicated backend. Something like this: https://github.com/positive-intentions/chat/issues/6

I'm up front about it on the docs that you won't read. I've had feedback and questions as I've worked on this project. I've iterated and improved on the project while maintaining docs. I created loads of documentation for transparency. If your going to call that slop too, then I don't want to pretend I'm having a conversation. The details around this project in the best best is still not going to be easy to read for most.

As always; feel free to reach out for clarity on any of the details.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •