Thanks! This is very helpful! I'll take a look and fix it.

the typical software development approach: unit tests, reviewing PR changes, documenting details and CI/CD (to mention a few steps). its not something i can easily enumerate because in cybersecurity there are countless nuances to consider, which is how we end up with formal verification documents and security audits. all the internal documents are useful for me, but essentially geared toward being a starting point for a third-party reviewer.

the impementation here is being used in a couple functional messaging apps (similarly unaudited and unreviewed):

• https://enkrypted.chat/ - javascript based approach
• https://glitr.io/ - rust based approach

i will also be adding it to an open source project soon as seen at: https://github.com/positive-intentions/chat to give that e2e open-source transparency in the implementation.

thats right. i used LLM's. i reviewed this thoroughly myself. there are some in-house documents published on the website. for exmples threat-models, formal-verification and security audits. they are good for internal review but fundamentally invalid because its like "trust me bro"... and you shouldnt need to.

i would like to aim for a third-party review from an org like ROS or NLNet, but open source support isnt easy to come by on project as complicated as this. im sure many orgs are overwhelmed by AI slop and i've failed to make the cut several times, so im not expecting a professiona audit any time soon.

feel free to reach out for clarity on the details if you would like to investigate it further.

There are a few nuances to my approach, but the key detail is that I wanted it to also work in a browser so I needed the ability to build to a wasm to be used in js.

Signal doesnt offer browser based capabilities and so I created this to target web aswell as native.

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).

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.

when it comes to secure messaging, self-hosting is generally encouraged... while not quite 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.

for self hosting it’s overkill but makes deployment easier. You can choose any git provider.

I introduced git as an replacement for peerjs in my project. I describe my app as a "decentralised P2P messaging app"... Using peerjs introduces a centralisation in an otherwise decentralised architecture. It also has the additional advantage of allowing users to send messages when peers are offline. Previously not possible with the pure webrtc approach.

I'm genuinely curious. Can you elaborate?

I've seen vibecoded slop too. To avoid it being mistaken for slop I created documentation, tests, etc.

Perhaps individuals shouldn't be allowed to make cybersecurity software. You may understandably want this done by a group of experts.

Getting traction on any project can be hard and I'm curious what nuances I might be overlooking.

I've approached OSTIF.

"Sadly at this time, OSTIF is unable to provide you with security work. We wish you and your project the best of luck and much success to come."

They suggested to take a look at opentech.fund ... Similarly rejected.

"We very much appreciate your submission to the Open Technology Fund (OTF) for consideration. Upon evaluation, we have decided that OTF is not able to provide financial support for your project at this time."

Going close source is a fairly recent change in direction for my project. I hope it's more clear why Im not going to bet on support by open sourcing my project.

It certainly isn't enough for the cryptography alone to be secure. Cybersecurity is full of nuances when it comes to the supply chain. Concerns around apps like mine running on untrusted browsers sits in contrast to something like the Signal app running on untrusted hardware/OS/networks.

When talking about the supply chain vulnerabilities, security can be easily undermined if you have screen sharing malware on your device. Neither browser or native app can protect against that. As a browser app, you have more flexibility in choice of browser and OS compared to something like Signal.

The rust approach is intended to further break out of that limitation (albeit close-source, unaudited, etc).

I didn't mean to confuse audits and funding. I meant grant funding could be used to get a security audit.

Ive applied to several. I got an email the other day from NLNet to say they had a record breaking number of applications which is why they are taking so long to evaluate... It's not my first time applying there. I expect they will reject the project (it's for the signal protocol project).

JavaScript has a lot of rhetoric against it being used for cryptography. I've tried to justify the approach, but it was an uphill battle from the onset. My approach is still unique in that it can run locally from index.html without a static server. It's further explained here: https://www.reddit.com/r/CyberSecurityAdvice/comments/1ev5kqn/is_this_a_secure_messaging_app ... That version of the project is deprecated.

Glitr as seen in the main post above, is written in Rust. Not only avoids concerns around web crypto, but also being able to build for multiple platforms. I'm aiming for native build as well as a TUI. (I'm only promoting the webapp because I want to focus on that version first). The main reason for Rust is that there is more mature tooling around cryptography and formal verification.

(Sorry for this being so long... Feel free to reach out for clarity on the details. Long-story-short. Sure those orgs exist... But they aren't rushing to fund projects that are simply open source)

You're over simplifying. So let's add some context relative to this project.

I have several open source projects. This project started off open source and I keep the version open source because it demonstrates a fairly unique concept around avoiding installation and registration.

https://github.com/positive-intentions/chat

I handcrafted that version. It's open source with the commit history. It was before the days of agentic AI. I spent countless hours considering countless details. I could spend countless more on improving the quality there for things like unit tests.

I had something reasonably unique and so I tried to apply for funding. I tried very hard, several places, several times. All rejections.

Grant applications are a horrible experience. It's not something I had experience in before and it carried a exhausting learning overhead... But if I could get funding, it would be worth it. As AI become more prominent, I'm sure these organisations are overwhelmed with how many submissions they have.

My conclusion is clear; if it's been this hard to only receive rejections, I'm no longer going to bet on open source. It's clearly not a good business plan.

I consider myself a seasoned developer. So as I'm working on my project, I'm taking on feedback and made improvements throughout.

I still believe in things like kerkhoffs principles. So as part of the continued development, I created a version of the signal protocol.

https://github.com/positive-intentions/signal-protocol

I aim for it to be for production use, but without a third party audit, open source is worthless. When sharing it online, the conversation cannot move past that it's created with AI. It undermines all the time and effort I put into it. I created things like formal proofs/verification and security audits. I kept all the documentation honest that it was created by myself with AI. I think the approach is honest and transparent.

I see the project is well received in various subs, but the cryptography subs that can actually understand what I created, I just risk being banned for sharing AI slop... And thus this close source approach.

Going close source is particularly ambitious because there is an element of "trust me" to it (I don't like it either)... but it appears to be the only way to proceed at the moment.

I don't need it open source so people can debug my code. I open sourced it previously for discussion... I now realise my project is simply too complicated to discuss. It's not for lack of trying.

The git usecase here is not version control. The repo size would swell to a large size easily if people exchange large files. The app flattens and truncates the history.

I hope the documentation helps to understand how it works, but as a work in progress, there are countless details to consider before it can be comparable to the mainstream messaging apps.

For similar open source projects, you can take a look at: https://positive-intentions.com/

i started on this project as open source and ive tried to be transparent about some reasonably unique features and approach for secure messaging as seen here. its reasonably documented, but feel free to reach out for clarity.

the key changes between the open and close source versions is the closed version introduces git-as-a-backend and removes peerjs.

im not new to open source. i simply dont see the benefit to open sourcing this particular project if unit-tests, formal-verification, documentation were so easily dismissed. cybersecurity has countless nuances and open source without an audit is simply not going to work... i've already concluded that an audit isnt going to be possible. i dont see the benefit of open soucing the project when it puts me at a competative disadvantage against any modern AI.

It doesn't work like that. There is only the static server. Browsers can create a direct P2P connection by exchanging a few details as described here:

https://github.com/positive-intentions/chat/issues/6

You can reduce the complexity to exchanging 2 payloads to establish a webrtc connection without any backend (the exchange there is up to users. You can scan a qr code or share it over something like signal).

https://positive-intentions.github.io/webrtc/demo/gui/app/webrtc-meet?fullscreen=1

In this project I was looking for an approach for a decentralized backend and landed on git. While GitHub isn't decentralised, git can have multiple remotes and in the app, it will support multiple remotes which can act as encrypted backups.

Git makes for a horrible real-time messaging experience, but it tries to establish the webrtc in the background where supported.

Ultimately, there is no registration of users or messaging servers. The app stores data locally on your device. Connection details have to be shared by you through a channel you trust. You can optionally use a git provider of your choice if you want offline messaging.

You right. It's slow and unoptimized for it. There is a clear reason this isn't a popular approach.

In the messaging app, I started off by making it so it worked with local-only data. It works over webrtc. I added bells and whistles like the signal protocol and multimedia messaging, but it lacks the ability to send messages offline (because webrtc).

The git approach can allow to publish encrypted messages for peers so when they come and online and your aren't there, it can decrypt a payload specific to them.

With git, it's hardly instant messaging, but I'm working on a feature where git can act as a peer-broker to establish a webrtc connection.

The git approach also would mean that it could work over tor with the signal protocol encryption (albeit hardly instant messaging).

It's a fairly unique approach and there are countless details to consider like how group-messaging would work. So I'll confirm it isn't ready to replace signal or any other app/service.

"Vibecoded" doesn't quite have the bite these days. I've clearly used AI, so let's get that out of the way. In my open source projects I tried to provide code, documentation, live examples. You can find out more about the open source projects at: https://positive-intentions.com/

Feel free to reach out for specifics. While this project is not open source (yet?), I am still trying to make some comprehensive docs.

feel free to reach out for clarity on the details and i can share how it works. while the app isnt open source, a lot my my work is and i can shared more examples with code demos. a good place to start might by the projects subreddit.

https://www.reddit.com/r/positive_intentions/comments/1tq1u62/introducing_enkrypted_chat

regarding connecting a git repo... its important to connect it to a blank repo. with scoped permissions to just that repo. DO NOT use an existing repo of a project you care about.

i was unable to get traction on my project as FOSS. in fact, it only seems to put me at a competative disadvantage.

https://www.reddit.com/r/positive_intentions/comments/1tq1u62/introducing_enkrypted_chat

i sweated to get the project to that point. the key pushback was that it didnt have an audit. cybersecurity has a paywall nobody seems to talk about. a security audit that is worth respecting is prohibitively expensive. as someone feeling the hit of AI (im unemployed), im especially not investigating options for a security audit when i cant pay myself.

it isnt for lack of trying either i have countless rejections from providers of funding for open source projects. i have several open source examples if youre really curious to discuss details.

it says it right there in the FAQ. im not alleging its secure at all; "this demo is provided for testing and demo purposes only. use responsibly."

Thanks. Ive started doing that. With the signal protocol. https://github.com/positive-intentions/signal-protocol

I have a demo of the JavaScript version. The UI there is reasonably mature. https://ui.positive-intentions.com/ . Tauri would be good to package it up into a native app with a web-view, the rust approach would allow for a better native build. I see that native build is only about a couple megabytes (in contrast to a whole functional web-view as the base).

I wonder if there could be architectural benefits to having it all in rust. In particular I'm interested in the idea of "end-to-end formal verification" (I just made that term up. Not sure how to describe it).