Chat - Decentralized P2P Messenging
1d 9h ago by programming.dev/u/xoron in opensource@programming.dev
"Secure and private" is the general aim.
This is a technical/concept demo of a fairly unique approach using a browser-based, local-first and webrtc.
This is intended to demonstrate client-side managed cryptography. We can avoid registration of any sort.
App: https://chat.positive-intentions.com/
Code: https://github.com/positive-intentions/chat
Features:
- P2P
- End to end encryption
- File transfer
- Local-first
- No registration
- No installation
- No database
Feel free to reach out for clarity instead of diving into the docs/code.
IMPORTANT: While this is aiming to provide a secure experience, it isnt audited or reviewed. Shared for testing, feedback and demo purposes only. Please use responsibly.
I urge you to consider changing the apps name sometime, it seems really nice but talking about it to others will lead to some confusion
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.)
Hi, I do think this is a very cool idea. I appreciate using the WebRTC stack, and see that there are even AR/VR integrated too. I do have some questions about this project:
- How do you see groups to be implemented (if that's on your roadmap)? IIRC webrtc mesh topology doesn't scale really well with many nodes, and how does a group handle netsplits between participants when some are offline?
- Will you address offline delivery of messages, and how? Afaict, maybe something like a P2P relay with limited retention can help, although it must be in semitrusted/trusted territory
- Do you see any chance this technology may be used in alternative networks (TOR, I2P, etc)? I guess that deviates from the webRTC model by a lot, but could there be any technical developments for it to become a possibility?
Thanks in advance for any responses :)
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.