https://www.reddit.com/r/VeraCrypt/comments/1r9qdxg/veracrypt_clone_in_javascript
(The demo there isn't open source.)
xoron
joined 2 years ago
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.)
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.
Im investigating an idea i had about React-like syntax for webcomponents after some experience with Lit.
Lit is a nice lightweight UI framework, but i didnt like that it was using class-based components.
Vue has a nice approach but i prefer working with the syntax that React uses. I find it more intuitive for debugging and deterministic rendering. I wondered if with webcomponents, i could create a UI framework that didnt need to be transpiled.
(My intentions with this framework is to get to a reasonable level of stability, to then replace React on some of my existing projects.)
IMPORTANT: Dont be misled by it being open-source. Im not trying to push "yet another ui framework", this is an investigation to see what is possible. You should not use this framework in your own code. It is not production-ready. It is intended for myself on my own projects. This project is far from finished. I am sharing because it might be interesting/educational for someone. Feel free to reach out for clarity if you have any questions.
Im investigating an idea i had about JSX for webcomponents after some experience with Lit.
Lit is a nice lightweight UI framework, but i didnt like that it was using class-based components.
Vue has a nice approach but i prefer working with the syntax that React uses. I find it more intuitive for debugging and deterministic rendering. I wondered if with webcomponents, i could create a UI framework that didnt need to be transpiled.
(My intentions with this framework is to get to a reasonable level of stability, to then replace React on some of my existing projects.)
IMPORTANT: Im not trying to push "yet another ui framework", this is an investigation to see what is possible. You should not use this framework in your own code. It is not production-ready. It is intended for myself on my own projects. This project is far from finished. I am sharing because it might be interesting for someone. Feel free to reach out for clarity if you have any questions.
Im investigating an idea i had about JSX for webcomponents after some experience with Lit.
Lit is a nice lightweight UI framework, but i didnt like that it was using class-based components.
Vue has a nice approach but i prefer working with the syntax that React uses. I find it more intuitive for debugging and deterministic rendering. I wondered if with webcomponents, i could create a UI framework that didnt need to be transpiled.
(My intentions with this framework is to get to a reasonable level of stability, to then replace React on some of my existing projects.)
IMPORTANT: Im not trying to push "yet another ui framework", this is an investigation to see what is possible. You should not use this framework in your own code. It is not production-ready. It is intended for myself on my own projects. This project is far from finished. I am sharing because it might be interesting for someone. Feel free to reach out for clarity if you have any questions.
This is hardly an alternative to Signal (or any other secure messaging app). It's a work in progress and "secure and private" is the general goal. Feel free to reach out for clarity instead of diving into the docs/code.
This is a technical/concept demo of a fairly unique approach using a browser-based, local-first and webrtc.
App demo: Enkrypted.Chat
This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort.
Features:
- P2P
- End to end encryption
- Signal protocol
- Post-Quantum cryptography
- File transfer
- Local-first
- No registration
- No installation
- No database
- TURN server
Some open source versions of the core concepts.
| Project | ||
|---|---|---|
| Chat | Repo | Demo |
| File | Repo | Demo |
| Crypto | Repo | Demo |
IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. This isn't ready to replace any app or service. Please use responsibly.
view more: next ›
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.
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.