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?
  • CameronDev@programming.dev
    8·
    7 days ago

    This is definitely not the most secure messaging app.

    This vibe coded slop by someone who doesnt know what they are doing, and doesnt understand the basics of security.

    Don’t fall for it.

    Xoron: Please, have some humility. There is no problem asking for feedback, but you need to take that feedback on board, and you need to stop pretending this project is anything other than a learning experience. Maybe if you listen to feedback and learn from it, your next version might be passable, but you are years of learning away from that point.

    • xoron@programming.devOP
      13·
      7 days ago

      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.

  • WhatAmLemmy@lemmy.worldEnglish
    8·
    7 days ago

    So unnecessary and recklessly incompetent. Git is a version control system. There is no good reason to use it as a messenger db. Dangerous vibe-coded nonsense.

    • xoron@programming.devOP
      1·
      7 days ago

      a directed acyclic graph as a backend for a messaging app makes sense, it’s what matrix does.

      In the older version of the project I was using a blockchain-like approach to help me keep ordering. But it’s was basically clunky and over engineered linked-list. It isn’t worth you time to look at but for reference:

      https://github.com/positive-intentions/chat/blob/staging/src/components/blockchain/Blockchain.js

      I used that approach because using git didn’t occur to me. Like you seem to have done, I associated git as only for version control of software, when it was a decentralised database. Git is also established well enough to offered multi-platform cross-compatability.

      I was searching for an approach to a “decentralised database” and I didn’t want to use an actual blockchain (because yuck).

      • WhatAmLemmy@lemmy.worldEnglish
        2·
        7 days ago

        I’m not gonna put effort into responding because I can see you’ve already been told.

        I will add: Don’t bother posting again unless you’ve fully open sourced the code base. All of your marketing and comments so far show an extreme lack of experience and congruity with privacy and security, and I have little faith that your intentions are genuine.

  • BetterDev@programming.dev
    6·
    7 days ago

    I think the primary issue here, and the underlying cause of a lot of the negative feedback you’re getting is: you’re making some very bold claims right off the bat that aren’t substantive but present this project as something its not even close to being yet, and probably won’t ever be, unless you get some serious buy-in and help from some of the smartest people on the planet.

    “This might become the worlds most secure messaging app.”

    Really? Do you have any basis for such an assertion? My NAS might become the world largest repository of half-finished side projects. Do I have any reason to believe that it will be though? I do have a lot of unfinished side projects on there, but the only reason I’d ever make such an assertion is if I thought that it had a real shot at being the case.

    “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.”

    Yeah, it sure does demonstrate a unique approach alright. Does that make it incomparable to (what is widely considered to be) the worlds actual most secure messaging app?

    Look, man, I like fucking around with tools in hacky, weird ways as much as the next guy. I even built a self-hosted, federated, zero-knowledge multi-user file storage platform, but you don’t see me out here saying “this may be the most secure file storage system in the world”. You’re advertising what is at this point a hobby project, and trying to pass it off as something worthy of other people’s time, to give you feedback and ideas.

    You want some real feedback? OK here’s why I wouldn’t use this:

    1. I don’t know you, and so far, you’re not inspiring confidence I should trust you with data I’d like to keep private.
    2. regardless of if all data that lands on the actual repository is encrypted, you’re still leaking a ton of metadata to to anybody who can read the repo in ways that other services don’t.
    3. you brush off the AI coding concerns as if they’re unimportant. Look man, I don’t care, you do you, but you’re claiming this is a secure messaging platform. I’m not the guy who will tell you not to use AI for coding. I use it for coding too at work; but while coding with AI, you still have to be hypervigilant if you’re going to end up with anything even remotely approaching good code. I’ve been around the block a few times, I’ve vibe coded, and I’ve built good code with it. But when other people are trusting me to do a good job, I understand their concerns, and I use AI for what its good at: typing fast and language fluency. I use it like a fancy keyboard that talks back. If it has made decisions for you (and it doesn’t always tell you when it does), that’s not a keyboard anymore. Thats a million monkeys pressing keys on a keyboard, and you’re hoping you get Shakespeare.

    I wish you the best of luck on this project. If you want serious feedback from people, show them your effort. I see someone that wants to be important utilizing the tools at their disposal to shoot their shot at getting some useful feedback. That’s not a bad thing to be. But I think the particular audience you’re aiming this at, and the type of thing you’re making, and the way you describe it, need reconsideration, by you, the human.