• 94 Posts
  • 142 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2024

help-circle


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




  • xoron@programming.devOPtoSecurity@programming.dev•Git as a messaging app
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    2
    ·
    edit-2
    1 month ago

    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.


  • xoron@programming.devOPtoSecurity@programming.dev•Git as a messaging app
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 month ago

    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.








  • Thanks for tips! i really appriciate the thoughts and advice. id like to drill into the feedback further.

    For learning purposes?

    sure. as would be the persuit of creating anything worthwhile. i consider myself an expert in javascript. there are countless learnings i had in the approach when i was working with js. rust certainly carries a learning overhead to pull of properly.

    use something that already exists like Matrix or Signal

    agreed. my project isnt at all compable or as stable as those tried-and-tested implementation. my project is far from comparable, but its not for lack of trying. the key detail that sets this apart from all other apps is the browser based client-side philosophy. no need to install anything. your ID is crypto-random and so the app doesnt need to rely on any central registration system like phone numbers. your ID is unguessable and to connect to someone, you have to explicitly share it. webrtc has other nuances like being to route through a shared network for secure/faster transfer. my approach to “secure messaging” in this project is fundamentally different to signal and matrix and has tradeoffs and capabilities that make a direct comparison nuanced.

    No encryption is secure if it isn’t peer reviewed and extensively tested

    correct. i am also looking to create something people can use. youre not the first to advise things like peer-review, but its also important to have context?/perspective?. as a unfunded-side-project, things like third-party audit are prohibitively expensive. the best i can offer is to mention the caveats (as is the first thing mentioned in the post and throughout my documentation). its clear and understandable nobody is going to take their own time to review my code/docs. i have tried for various open source funding/grants… all rejections. Kerkhoff’s principles are met, but its clearly too specialized and complicated to review for most… again, its not for lack of trying.

    You can do formal verification in any language

    i was previsouly investigating what could be done in JS. i couldnt find anything that i liked. perhaps you have any suggestions? i wanted to avoid creating AI-slop to address this and so i though rust would be more suitable with existing “reasonably mature” tooling. i was separately working on the signal-protocol, where i added things like formal-verification… it seems to work well, but there is a bit of a diconnect when bridging js to wasm… and thus this approach for a more pure rust approach. thanks for pointing me to Ferrocene. i’ll take a look. note: im aiming to avoid costs where possible.

    This can help defend against timing attacks.

    the signal-protocol there aims to address this, like all of my projects, it lacks third-part reviews, but i hope its comprehensively documented (https://positive-intentions.com/docs/technical/p2p-signal-protocol/). there is an unfortunate AI-stink to it that is difficult to remove from my docs, but i hope it doesnt come across as low-effort. i remember the days before AI. without it, i wouldnt be creating docs. i would still encourage you to ask me for clarity on details instead of wasting your time on the docs.

    Rust also has a great crypto ecosystem

    yes. it was needed for the signal protocol because i needed certain primitives that were not provided by the browser.

    thanks again for all the advice. i really appriciate it. id like to avoid having a backend as part of the “philosophy” of the app. it revolves around a webrtc connection and local-only storage.



  • im switching to the rust stack mainly because i think it has better tooling formal-verification. formal verification is particuarly important in my project because it relates to cryptography.

    i assume i can get something comparable to what i already did with JS… but with rust, i may be able to break out of the browser environment.

    i not only want to be able to offer a native gui version, but with rust i think im on track for also being able to create a cli tool too.





  • I think my approach is yet different from others in the browser-based approach. In the open source version as described here, I don’t add anything like a login. I’m able to avoid installation and registration entirely.

    Simplex has nice ideas around routing messages. Im open to feedback about comparing the webrtc approach to simplex in the post here. it would be a stretch to call it onion-routing, but is 2 peers use different turn relay servers while on VPN, I think that’s that most network hops you can do in my app. simplex has their own cool approach… but you’d be comparing apples and oranges.

    as for contributing, I’m sure other projects have “got it” without my help. I’m just doing my own approach which I think is distinct from others.