sorted by: new top controversial old
-1
Browser-based WebLLM Chatbot (programming.dev)
 

To help users of my app, it was important to document the details around the “how it works”. the docs were easy enough using docusaurus + AI. i can then index that data (like used in the docusaurus search). i framed this as like a chatbot so that it can be intuitive for users who have questions. at this point it was really just a fancy autocomplete.

i started to investigate running a local LLM to perhaps offer a more conversational experienced (and hopefully better suggestions)? im using WebLLM on a browser and it seems to work “reasonably” well. i wired it up and set it up so users could select an LLM down download for offline use. the experience varies between devices and models used. there are models that are 19mb… they are unsable as far as i can tell. there are some ~1gb models which are better but understandable slow.

its great that the 1gb model can “show me the bubble-sort in rust”, but i want something “dumber” and smaller. something can can take advantage the data ive already indexed. something that can respond “quickly enough” for a conversational flow. perhaps better i should make a verbose set of reponse templates to perhaps add fancier autocomplete capabilities.

are there any models out there you can suggest for me to investigate and compare?

note: the project is unstable, experiemental and there will be breaking changes. its far from finished. im just trying things out and this approach with LLM’s might just be a waste of time. if you want to test it out, you can try: https://app.glitr.io/ai

7
Reverse engineering should be part of the threat model (glitr.io)
 

https://glitr.io/blog/reverse-engineering-my-own-project

TLDR; i thought my project would have been harder to chew up. it was surprisingly low-effort. I don't think it completely undermines my project being close source, but it does seem trivial enough for it to be a factor in the threat model.

i wanted to learn more about this reverse engineering trend myself on my project, so i can see what can be done to defend against it.

my app is aiming to be fully client-side. An implementation in javascript seems like it would relatively easy for an AI to swallow. my latest project is in rust, which would make it harder for a person, but AI can now digest binaries.

i created a fairly unique p2p messaging app. a rust-based frontend with a git-server backend, which can be used to establish a p2p connection. while this version remains close-source, i aimed to create comprehensive technical documentation (formal-verification and security audits too).

  1. https://glitr.io/
  2. https://app.glitr.io/

a core detail to my project is the focus on client-side cryptography and storage. i think my older iteration as a javascript webapp would be relatively easy for AI, so i thought id put a spin-on-things by having a rust wasm frontend. In practice, i dont think AI broke a sweat.

i know nothing about decompiling, but i think the TUI would be the easiest for it to decompile... and given its largly one codebase for all the platforms, it can be used to trace and see what is going on in the builds for the other platforms.

it might be that all close source is obselete. i tried asking here, and the responses there are polar opposites, so i decided to get some first-hand experience.

i used cursor's "auto" agent (in contrast to the frontier models available). i used https://github.com/morluto/rea and tried to make it easier by proving it with a few binaries of my project (tui, apk, web, desktop) and pointed it to the documentation as a website.

after a few prompts, it seems to have done a decent job decompiling the project here:

https://github.com/positive-intentions/glitr-decompiled (note: this is basically AI-slop output of the deco pilation process)

like with many projects, i see AI lacks taste in architecture. it consolidates a lot of complexity into one repo, when in my project it's split into multiple repos. it also seems to lack a bunch of bells-and-whistles i added for my own benefit like formal-verification and rigorous unit-tests. having done it myself before, i dont think that it's a large gap to close for somone who knows what they're doing.

i think the overhead to keep up with new changes may become trivial if you can automate the process of ingesting new binaries. i kinda offer the base in the repo above (maybe it saves you a few tokens?), but its for my own research and i dont plan to maintain it given it undermines the actual project.

in general, im impressed considering how fast and low effort this was. it seems this may push forward my timeline for when i open source my project, i wasnt expecting client-side close-source being so easy to undemine. while the project can be decompiled, in a project like this, its important to consider the countless nuances there are in software development and cybersecurity. the code is only a fraction of the project.

i think people should try this in their own code. while the decompiled output is not the same codebase, it seems trivial for me to take some unfamiliar app and rebuild a protocol-compatible version with some new button, feature... or auto-installing malware.

(note: feel free to try decompile this yourself or offer tips on how i can improve. id be keen to see what can be done. feel free to reach out for clarity about how it works if the docs are not clear)

0
The Signal Protocol in Rust (programming.dev)
 

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 libraries don't offer browser based capabilities and so I created this to target web aswell as native.

I wanted to implement the Signal protocol for a series of secure messaging apps I’m working on, so I built this project to test and use in my own work. It’s still far from finished, but I think it’s at a stage where it’s worth sharing with the community.

IMPORTANT DISCLAIMER: This project is not professionally audited and is not production-ready. I do not recommend anyone use this in their own code yet. It is provided strictly for testing, experimentation, and demo purposes. I used AI as an assistant to help build this, so double-check everything before taking it seriously.

Project Links:

Current Status & Development:

  • Spec Alignment: The goal is to fully align with the official Signal protocol spec.
  • Testing: It includes unit tests, but due to WASM testing limitations, I also added a Storybook-like UI to run and test it directly within a browser environment.

The impementation here is being used in a few experimental messaging apps (similarly unaudited and unreviewed):

I am also working towards adding it to an open source project soon as seen at: https://github.com/positive-intentions/chat for e2e open-source transparency in the implementation.

Signal Protocol in Rust in c/rust@programming.dev
Signal Protocol in Rust in c/rust@programming.dev
[–] [S] 2 points 2 weeks ago*

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

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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Signal Protocol in Rust in c/rust@programming.dev
    [–] [S] 2 points 2 weeks ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • 10
    The Signal Protocol in Rust (programming.dev)
     

    I wanted to implement the Signal protocol for a series of secure messaging apps I’m working on, so I built this project to test and use in my own work. It’s still far from finished, but I think it’s at a stage where it’s worth sharing with the community.

    IMPORTANT DISCLAIMER: This project is not professionally audited and is not production-ready. I do not recommend anyone use this in their own code yet. It is provided strictly for testing, experimentation, and demo purposes. I used AI as an assistant to help build this, so double-check everything before taking it seriously.

    Project Links:

    Current Status & Development:

    • Spec Alignment: The goal is to fully align with the official Signal protocol spec.
    • Testing: It includes unit tests, but due to WASM testing limitations, I also added a Storybook-like UI to run and test it directly within a browser environment.
    The Signal Protocol in Rust in c/signal@lemmy.ml
    [–] [S] 5 points 2 weeks ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • 3
    Signal Protocol in Rust (programming.dev)
     

    I wanted to implement the Signal protocol for a series of secure messaging apps I’m working on, so I built this project to test and use in my own work. It’s still far from finished, but I think it’s at a stage where it’s worth sharing with the community.

    IMPORTANT DISCLAIMER: This project is not professionally audited and is not production-ready. I do not recommend anyone use this in their own code yet. It is provided strictly for testing, experimentation, and demo purposes. I used AI as an assistant to help build this, so double-check everything before taking it seriously.

    Project Links:

    Current Status & Development:

    • Spec Alignment: The goal is to fully align with the official Signal protocol spec.
    • Testing: It includes unit tests, but due to WASM testing limitations, I also added a Storybook-like UI to run and test it directly within a browser environment.
    4
    Reverse engineering my own project (programming.dev)
     

    i wanted to red-team myself on my project and id like to know how to reverse engineer so i can see what can be done to defend against it.

    TLDR; I thought my project would have been harder to chew up.

    my app is aiming to be fully client-side. An implementation in javascript seems like it would relatively easy for an AI to swallow. my latest project is in rust, which would make it harder for a person, but AI can now digest binaries.

    i created a fairly unique p2p messaging app. a Rust-based frontend with a Git-server backend, which can be used to establish a P2P connection. while this version remains close-source, i aimed to create comprehensive technical documentation (formal-verification and security audits too (all ai-slop-maxxing at scale under my guidance)).

    1. https://glitr.io/
    2. https://app.glitr.io/

    a core detail to my project is the focus on local-first and client-side cryptography and storage. By reverse engineering, i wanted to learn how vulnerable this project is to decompilation. i think my older iteration as a javascript webapp would be relatively easy for AI, so i thought id put a spin-on-things by having a rust wasm frontend. In practice, i dont think AI broke a sweat.

    i know nothing about decompiling, but i think the TUI would be the easiest for it to decompile... and given its largly one codebase for all the platforms, it can be used to trace and see what is going on in the builds for the other platforms.

    it might be that all close source is obselete. i tried asking here, and the responses there are polar opposites, so i decided to get some first-hand experience.

    i used cursor's "auto" agent (in contrast to the frontier models available). i used https://github.com/morluto/rea and tried to make it easier by proving it with a few binaries of my project (tui, apk, web, desktop) and pointed it to the documentation as a website.

    after a few prompts, it seems to have done a decent job decompiling the project here:

    https://github.com/positive-intentions/glitr-decompiled (note: this is basically AI-slop)

    like with many projects, i see AI lacks taste in architecture. it consolidates a lot of complexity into one repo, when in my project it's split into multiple repos (as documented). it also seems to lack a bunch of bells and whistles i added for my own benefit like formal verification and rigorous unit-tests. having done it myself before, i dont think that it's a large gap to fill for somone who knows what they are doing. i think the overhead to keep up with new changes may become trivial if you can automate the process. i kinda offer the base in the repo above (maybe it saves you a few tokens?), but its for my own research and i dont plan to maintain it given it undermines the actual project.

    in general, im impressed considering how fast and low effort this was. it seems this may push forward my timeline for when i open source my project, i wasnt expecting client-side close-source being so easy to undemine. while the project can be decompiled, in a project like this, its important to consider the countless nuances there are in software development and cybersecurity. the code is only a part of the project.

    (note: feel free to try decompile this yourself or offer tips on how i can improve. id be keen to see what can be done. feel free to reach out for clarity about how it works if the docs are not clear)

    Secure and Private Decentralized P2P Encrypted Messaging over Git and WebRTC in c/privacy@programming.dev
    [–] [S] 2 points 1 month ago (1 child)

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

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Secure and Private Decentralized P2P Encrypted Messaging over Git and WebRTC in c/privacy@programming.dev
    [–] [S] -2 points 1 month ago* (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • -13
    Secure and Private Decentralized P2P Encrypted Messaging over Git and WebRTC (programming.dev)
     

    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?
    Git as the backend for a messaging app in c/git@programming.dev
    [–] [S] 1 point 1 month ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Git as the backend for a messaging app in c/git@programming.dev
    [–] [S] 1 point 1 month ago (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Git as the backend for a messaging app in c/git@programming.dev
    [–] [S] 1 point 1 month ago* (last edited 1 month ago)

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

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Git as the backend for a messaging app in c/git@programming.dev
    [–] [S] 1 point 1 month ago* (last edited 1 month ago) (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Git as the backend for a messaging app in c/git@programming.dev
    [–] [S] 1 point 1 month ago* (last edited 1 month ago) (4 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • context
    • Git as the backend for a messaging app in c/git@programming.dev
    -4
    Git as a messaging app (programming.dev)
     

    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/

    demo

    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 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/

    -7
    Git as the backend for a messaging app (programming.dev)
     

    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/

    demo

    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/

    10
    PWA in Rust - Seeking opinions on approach (programming.dev)
     

    IMPORTANT: i dont reccommend you read through my code here. feel free to reach out for clarity on the details.

    id like to investigate about rewriting my "decentralized p2p encrypted messaging app" in Rust. if you are familiar with any of the details, id like to hear your opnions on the approach.

    my project is complex and would carry a significant overhead to redo in Rust. the core reason behind investigating rust is that it has better tooling for things like formal-verification. in general it seems like a better language for a project like mine. as a webdev, it was easy enough for me to put together and while i can use things like tauri to build for native, i think dioxus's approach for a native build is good.

    im aiming to create something fairly unique for "secure messaging". i created a prototype (without AI) for my project to share and discuss. it demonstrates the core-concept around client-side managed secure cryptography in javascript.

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

    javascript doesnt have a great reputation in the cryptography communities and its always a struggle to promote, so it was important for it to be open source. im proud of the work there, but i see details i overlooked. this led me to creating a new version to fix the outstanding issues. (it was things like handling key-rotation, group-messaging, etc).

    https://positive-intentions.com/blog/introducing-enkrypted-chat

    the MVP version lacked things like unit-tests, while the second-iteration not only had unit-test, but armed with AI, i was able to do things like create audits and formal-verification. the whole project is absurdly complicated and not worth your time to review. things like audits and formal-proofs/verification are fundamentally invalid because i used AI to create it. the attempt is genuine and i found the process educational, but cybersecurity and cryptography is specialized and has countless nuances to consider. it isnt worth your time to debug my code.

    i now i think the project could benefit from being rewritten in Rust. its a much more suitable and respected language for what im trying to do, but i have never used rust to do something of this scale. i expect it will carry a huge learning curve given my background as a webdev.

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

    creating a webapp for me is easy enough, but my project relies on some core technologies which i want supported on all platforms consistently. some core things i need to consider:

    • webrtc - its the core data-channel for my project. im sure that as a webapp it can be done... it might be a stretch to build a wasm to bridge to JS if nessesary, but im sure it can work. i would also like rust to build for other architectures. i think the support is also reasonable for the native build, but i wonder it there could be issues for a CLI version.
    • Module federation - in the browser-based version im using module-federation and its working as exected. it particularly helps to separate functionality, which is generally a good approach for a complex project. in Rust's cargo file, it seems i could add something like `foo_crate = { git = "https://github.com/MyOrg/foo/_crate"}`. that seems like it would also limit how i handle close-source details of the project
    • local-only storage - a core detail to my app is that it works p2p without registration. there are no databases of registered users. in a pwa i can use various forms of storage provided by the browser. i would like to use an approach that is consistent in rust to avoid bespoke code for different platforms (easier maintainance).\
    • ui framework - im using dioxus for far, but its largely AI slop... its could just as easily be leptos (im still investigating comparing the two)... but if i really think outside the box... i wonder how difficult it would be to use webcomponents from rust. i was working on a webcomponent framework and it would be interesting to seem if there would be a performance advantage to using something closer to vanillajs. webcomponents probably are not a good idea if i want better support between platforms.

    maybe there are other details i should keep in mind? i think i will have to create multiple creates for things like UI components library and p2p-framework (similar to how i did it for the javascript version)

    thanks for reading this far. have a nice day.

    11
    New to Dioxus and Rust. Any tips about getting started? (programming.dev)
     

    Hey, I'm a webdev. I previously approached the project with JavaScript. I'm familiar with the js ecosystem.

    I put a fair bit of consideration and in contrast to my JavaScript-approach, I'd like to investigate Dioxus.

    I'm not completely new. I've dabbled in rust before. I have read a lot of the docs and I'm sure there is much more to learn amd practice. I also don't want to downplay that I'm ai-slop-maxxing at scale.

    What advice would you give to getting started with the rust ecosystem approach?

    Similar to a lot of languages there are considerations for things like tests. So it would be useful to see the options there. As well as any other best-practices and nuances.

    In relation to my project, I'm particularly interested in the tooling available in rust for formal verification.

    Just to be clear, im not here to waste your time on my slop, but if you want to see what I've got so far (practically nothing):

    13
    Anybody with experience / insights on Dioxus? I have an idea and want to see if its worth investigating further. (programming.dev)
     

    i am working on a messaging app and created some details in rust. rust is useful because it has tooling for formal verification. my rust code compiles to WASM to be used in a browser.

    my project itself is using cryptography beyond the WASM because browsers provide a crypto api for basic functionality out-of-the-box.

    to work with what i have now (javascript/typescript) i came across this page, but the links lead to 404 pages on github. not sure about the status of the project. i dont know if there are other similar projects.

    https://formal.land/docs/verification/typescript

    i would like to improve the "formal-verification coverage" in my project and wanted to investigate if it could be worth considering rewriting the frontend with dioxus. im happy with an ugly UI (initially) in favour of having formal-verification on a broader scope of my project.

    (context: the project where i have formal verification is found here: https://github.com/positive-intentions/signal-protocol (this isnt the gold-standard implementation and its far from finished)

    view more: next ›