I have been working on a desktop P2P messenger called Kiyeovo for the last ~8 months, and I just published its beta version.
Quick backstory: It started out as a CLI application for my Graduate Thesis, where I tried to make the most secure and private messenger application possible. Then, I transformed it into a desktop application, gave it "clearnet" support and added a bunch of features.
Short summary:
The app runs in 2 completely isolated modes:
- fast mode: relay/DCUtR -> lower latency, calls support
- anonymous mode: Tor message routing -> slower, anonymous
These modes use different protocol IDs, DHT namespaces, pubsub topics and storage scopes so there’s no data crossover between them.
Messaging works peer-to-peer when both parties are online, but falls back to DHT "offline buckets" when one of them is not. To ensure robustness, messages are ACK-ed and deleted after being read.
Group chats use GossipSub for realtime messaging. Group messages are also saved to offline buckets in order for offline users to be able to read them upon logging in. Kick/Join/Leave events are also propagated using the DHT. Group metadata and all offline data is of course encrypted.
Other features: Chats are E2E, file sharing is supported, 1:1 audio/video calls are supported (only in fast mode though, using WebRTC)
Tradeoffs: Tor has noticeable latency, offline delivery is not immediately guaranteed, but rather "eventually consistent"; beta version does not have group calls yet.
I’d appreciate feedback, that's why I posted this as a beta version
What I REALLY want is an app that builds a big bank of nonces between you and your peers over short range radio or QR codes and then lets you use a 1-time pad.
Ultimately, I'm only offering criticism because I have spent a lot of time working on exactly this problem, but I am not in a position to actually implement it. This is awesome and you should be proud of it.
DHTs of trusted participants are great.
You can reliably use it to store arbitrary key-value pairs up to 1kb in in size.
The "break point" is when a DHT gets big enough I can't realistically MITM all the links with nodes "closer to the target" than existing ones.
This means big networks are great, small ones are cheap to just break. Its hard to skip the messy bootstrapping phase.
I'd encourage protocols to only rely on DHTs for small key-value stores if there isn't a trust mechanism in place to validate new peers.
Otherwise, all I have to do is mine for O(n^2) dht keys that cover the network. Figure out what your key mining difficulty is and you can identify what the cost would be.