this is following a previous post as seen here: https://programming.dev/post/51866250
apps like Whatsapp, Signal and SimpleXChat are great for secure messaging and far more mature than this project, but this approach is yet distict in the market. 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.
docs: https://glitr.io/
note: feel free to ask for clarity on any of the details around how the project works.
FAQ:
-
but why? - git over https adds an additional capability i had previously oerlooked https. webrtc cannot work over TOR and similar networks. this way, you can take advantage of the "gold standard" for onion routing while being able to avoid IP leaking from webrtc.
-
when is it ready for production? - not any time soon. standby for updates.
-
audit/review? - no, niether is possible/available. its simply too expensive. this project is close-source so you cannot verify it either. DO NOT "trust me bro"... this demo is proided for testing and demo purposes only. use responsibly.
-
the abridged version of how its put together: https://www.reddit.com/r/VibeCodeDevs/comments/1vme48q/refactor_js_to_rust/
12 Comments
canpolat@programming.dev · 5 pts · 2d
If the project was FOSS, it would have been interesting to follow the development and learn from it. But it being proprietary, I don't see why anybody would be interested in it, TBH.
xoron@programming.dev · 1 pts · 2d
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.
moonpiedumplings@programming.dev · 1 pts · 16h
There are organizations that audit software for free, for smaller developers.
But they only do so if it is FOSS.
You have now essentially killed your project, since you will not be able to afford an audit, and nobody who knows what they are doing will look at an encryption protocol or app that hasn't been audited.
xoron@programming.dev · 1 pts · 11h
(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.
moonpiedumplings@programming.dev · 1 pts · 5h
Have you investigated the open source security audit organizations?
xoron@programming.dev · 1 pts · 3h
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.
moonpiedumplings@programming.dev · 1 pts · 1h
https://ostif.org/get-an-audit/
But by making yourself closed source, you kill any chances of getting access.
It's not enough for the cryptography to secure. An unverified, unsigned, unhashed index.html that the user still has the same issues outlined in the article above. The supply chain has to be secure as well.
terabyterex@lemmy.world · 5 pts · 2d
"git as a backend" doesnt make sense at all. you didnt answer why this is a better option than signal. it sounds vibe coded.
moonpiedumplings@programming.dev · 1 pts · 16h
No, using a directed acyclic graph as a backend for a messaging app makes perfect sense, it's what matrix does!
A significant portion of matrix's problems stem from the fact that it was originally a blockchain research project that somehow turned into a messaging app.
xoron@programming.dev · -1 pts · 2d
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.
enchanted@lemmy.world · 2 pts · 17h
GIT tracks changes, which doesn't strike me as something that often happens with messaging. Unless you just always replace your last message with the new one, I guess, then sure!
xoron@programming.dev · 1 pts · 16h
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.