I previously was in a situation where I was trying to bridge js and rust.
Perhaps you can do something with rust to wasm?
xoron
joined 2 years ago
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.
Lemmy isnt ready for this project and so deleting the post
I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.
This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.
This is intended to demonstrate client-side managed secure cryptography.
I know the project above is going to be tricky to understand. It might help to understand with an open-source version of the concept for educational purposes. Its's important to note, i have since deprecated it in favour of the version linked above.
PS. Im calling it a "Signal Messenger Clone"... that's just a matter of how to frame it for users getting started. It doesnt work in a way thats comparable to the signal architecture. This project is fairly complicated and the links above are likely not going to be enough, so feel free to reach out for clarity on the details.
PPS. I made a similar post on Reddit and it seems to be reasonably well recieved and so branching out to Lemmy here. It might help to take a look there if questions are asked/answered already.
Lemmy isnt ready for this project and so deleting the post
I hope this project has reached a level i can share the following details. I've made a genuine effort towards documentation and transparancy. I dont think it'll ever be enough and so im still concerned it isnt ready to share. While im using AI throughout. This is not a vibecoded project. There is attention throughout for unit tests and formal-verification. With your feedback, id like to make improvements for clarity throughout.
This version of the app demonstrates a fairly unique approach using a browser-based, local-only and webrtc approach. I know it's impossible for any system to be the "world's most secure", but that isnt a reason to not try. By rigorously implementing an exhaustive list of security features and practices, the aim is to get as close as possible.
This is intended to demonstrate client-side managed secure cryptography.
I know the project above is going to be tricky to understand. It might help to understand with an open-source version of the concept for educational purposes. Its's important to note, i have since deprecated it in favour of the version linked above.
PS. Im calling it a "Signal Messenger Clone"... that's just a matter of how to frame it for users getting started. It doesnt work in a way thats comparable to the signal architecture. This project is fairly complicated and the links above are likely not going to be enough, so feel free to reach out for clarity on the details.
PPS. I made a similar post on Reddit and it seems to be reasonably well recieved and so branching out to Lemmy here. It might help to take a look there if questions are asked/answered already. https://www.reddit.com/r/BuyFromEU/comments/1v8cx0s/europeanbased_signal_messenger_alternative/
Thanks!
It sounds promising if you chose it for a similar reason.
I'll plan something and see if I can get all the core parts working.
Thanks. I'm a JavaScript developer. To create a webapp is relatively easy for me because I'm familiar with the tooling.
I see there are things like UI component libraries like dioxus-material... I suspect there will be things I might have to create myself. Are there nuances that might stand out?
What are your thoughts on the ecosystem with dioxus?
My core reason to consider dioxus over JavaScript is the ability to use more mature tooling for formal verification.
Those are useful hooks for their own purpose. My approach might be more comparable to redux.
In contrast to redux, in this approach, we can update a state value and all other components listening will receive and update accordingly. Redux does this in a deterministic render and compares the vdom for what to update.
The origins on my approach is from trying to create it for webcomponents where components between different shadow-roots need to share an update.
It's all my code. I don't have to open source all my work. By using module federation, i can be selective about what I open source.
Some open source versions of the core concepts.
- Chat
- File
- Crypto
The main app itself is not open source even though it consumes exports from several open source repos. The core reason around the main core being close-source is that after creating open source versions, it only seems to put me at a competitive disadvantage.
https://www.reddit.com/r/VeraCrypt/comments/1r9qdxg/veracrypt_clone_in_javascript
(The demo there isn't open source.)
The key details that sets my approach apart is the zero-setup approach. There no need to install or register when there are no databases.
There would be much to consider when introducing collaborative editing, but that's also on the roadmap. Many useful features seen in cryptpad are missing in my approach at the moment. The features on my project are not as mature as what you see in cryptpad, but it's something I'm working towards.
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.)
view more: next ›
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.