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.
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.
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.
all understandable questions.
group messaging
this is very complex as im sure you can imagine. im using a p2p and the approach im using is that a “group” is basically a “room with ID”. when sending a message to a group, you send the message to the peers individually and they know to store the payload within the context of the “room with ID”. scaling something like that is limited by how many webrtc connections are possible by the hardware.
i have some research relating to using MLS, but without some central store to keep the mls keys per-epoch, its very unstable as peers can go offline unexpectedly. another approach im investigating is to be able to ping connected peers to create a kind of mesh-graph that i could use to relay messages. this approach could also be better resiliant to peers going offline in the sense, that the graph could heal from peers going offline.
im sure there are many details i havent considered, but i have buggy group messaging on the WIP version here: https://enkrypted.chat/ (go to chat-thread page > 3-dot menu on top-right > invite peer)
offline delivery
ive mulled over it enough to at least try using an approach to use git as a CRDT. it seems overkill for application data, but it would also allow use git as an offline message cache. https://programming.dev/post/51866250 . i havent implemented anything for this yet. im still mulling it over to make sure i dont overlook important details.
alternative networks
webrtc isnt the bit that make this app secure, its the local-first. no need to register anywhere when you have local-first crypto-random IDs. im open to considering other networks. tor has limitations around webrtc. this is perhaps where the git-based offline cache can come in useful in a tor network. i2p is also good as are many others like nostr. i’ll see what setup works best. i think it would be great to be able to support multiple.
if you want to know more about “how it works”, you can take a look at the roadmap here: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown
feel free to reach out for clarity instead of reading all that.
thanks. ive had that feedback before. its also not the easiest thing to type out. many are probably unable to find it again because the name wasnt memorable enough.
im in the process of rebranding to “http://enkrypted.chat/”. talking about it to others could still lead to some confusion, but i think could be a bit more memorable to say “encrypted.chat, but with a ‘K’.”
I’ve come across it before. That one is good and easy to get started.
I also have another version to the approach where im refining details: https://enkrypted.chat/ . (It’s far from finished and not open source yet.)
Thanks! I haven’t come across chatmail before. I’ll take a look there and see how it works.
With git, I like that there are many providers with a free-tier. It’ll make it easier to get started. Although it seems this way of using git could be against ToS.
Ideally I can advise people to self-host. I’m hoping to make something generic so it it can work with any git backend lit gitlab, codeberg, etc.
thanks. i’ll aim to do that. i’ll see if i can figure out who to reach out to from github and etc to ask.
feel free to reach out. im reluctant to waste your time on reading through all that draft. its fairly unique and more going against the grain… not typically a good sign.
my project is far from finished including all the spec and docs.
That’s right. Git as an offline cache. When you read a peers message, you can also update you own git repo to say you read it, and so when the peer comes online they can update their side to delete the messages (keeping the size small)… Going further against the grain, the app doesn’t care about the history of messages deleted, so I expect to add things for purging history.
I considered the Blockchain, but i think the git approach is better. It’s hard to describe what I’m imagining. I’d like to put together a demo when I get time.
I have a full-ish description of the protocol.
https://positive-intentions.com/docs/technical/whitepaper/complete-protocol-spec
Instead of reading that, if you really want to know more, I would suggest you ask me for clarity. (Nothing about this git approach is mentioned there.)
In my app I’m aiming for minimal steps to get started. The frontend is a pwa which works out the box as a webapp.
There is a focus on local-first storage. When connected over webrtc, no backend storage is needed.
This approach with git would be optional. Users have frequently asked about the ability to send messages offline (a completely normal expectation for messaging app). It seemed like a hard limit until this idea with git. My app works without this feature, but with nuanced tradeoffs.
If I host a git-sever myself, but that would be centralising my project.
In any case it wouldn’t be on my account. It would be great for users to self-host. Things like GitHub would only make it easier to get started to test things out.
Why would they ban my account? That would be unsettling. I’m a developer. The code itself is fairly basic git stuff.
My project is hardly popular, but if it gets there, I’m sure it would impact githubs performance. Would the concern be that my app ddos GitHub? I can explicitly prevent remotes like GitHub if necessary.
I’m happy to advise people to self-host a git server. That would be ideal. The ability to do it on GitHub or codeberg would only make it easier to get started. I can put logic there to prevent using a remote with from GitHub if necessary.
In any case, it wouldn’t be on my git account.
This is all ultimately for my project which is a fairly unique approach to secure messaging. I’m trying things out.
That would be acceptable. I can limit it to only text messages.
The aim would be for it to be able to use a generic git backend. Perhaps the advice I give should be to self-host a git server.
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.