Show HN: A P2P messenger with dual network modes (Fast and Tor)

29 pointsposted 12 hours ago
by Realman78
(github.com)

16 Comments

kvisner

5 hours ago

So most messaging apps rely on a phone number or centralized server to provide a means of making atleast the initial connection. In a purely P2P messaging system, how do I, as a user, find the other person I might want to talk to?

Realman78

4 hours ago

Third party info exchange. I don't see that as an issue though. For example, for discord, you also 100% exchanged usernames via a third party system. I mean, even phone numbers are exchanged via third parties. Now that I think about it, the only place where you can search people somewhat reliably are social media sites

blamestross

4 hours ago

I'm a fan of "face to face mutual qr code key exchange." I should implement that someday.

Realman78

4 hours ago

QR code key exchange is convenient, but I did not plan phone support.

blamestross

3 hours ago

Nobody does "face to face" key exchange like I imagine. Just two phones facing each other spamming QR codes for the other to read.

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.

Realman78

3 hours ago

I appreciate the criticism, really. In the current version users only have to exchange the username or peer ID via third party and then find each other on the DHT...

However, there is also another way, which is already implemented and I am currently writing the how-to on my blog site, and that is using "trusted users". Basically, instead of 2 users trying to find each other on the DHT, they can just export their profiles in the "Profile" section. That prompts them to create a shared secret and exports a ".kiyeovo" file. You send that file to the other party, they click on the "+" in the sidebar header ->"import trusted user", select the ".kiyeovo" file and voila!

I know it's not nearly as convenient as what you're describing, but it's just a more "trustable" way of creating a contact which is also not that inconvenient.

dostick

3 hours ago

Since Tor has become increasingly susceptible to state monitoring of exit nodes, making app rely on Tor is potentially compromising your future users. Look into i2p or other protocol that’s really anonymous.

kopitev174

11 hours ago

I worked on a p2p group chat app for a short time (no central server, same as this), but the group updates were a real problem. how do they get distributed?

Realman78

10 hours ago

The group creator distributes the updates to each group member individually (each pair of users has their own buckets). Of course, if the member is not online for a long time, the update does not just get lost, it gets republished and will continue to republish until the member has read the update. Did I answer your question?

blamestross

5 hours ago

I don't recommend DHTs with public participants being made from scratch. Use mainline bittorrent DHT instead. Small networks are really easy to eclipse and censor.

DHTs of trusted participants are great.

noman-land

5 hours ago

How does one find large DHTs? Is there anything connecting them all?

Realman78

4 hours ago

Good question. The 4 initial bootstrap nodes that I provided (in the README) are all connected to each other. If everyone connects to all of them, we are all basically on the same network instead of on "isolated islands"

blamestross

4 hours ago

"Mainline DHT" is the primary one. It backs magnet links and has resisted censorship for over a decade. Largest most robust group of cooperating computers there is.

You can reliably use it to store arbitrary key-value pairs up to 1kb in in size.

https://en.wikipedia.org/wiki/Mainline_DHT

Realman78

4 hours ago

In theory, if only Kiyeovo nodes were handling Kiyeovo records, then yes, they could kind of behave like their own subnetwork. The problem is that in a public DHT, the nodes responsible for storing keys are those closes to that key, we cannot guarantee it would be a Kiyeovo node. So even if Kiyeovo clients all use the same validation rules locally, the actual nodes that get hit with the queries do not. The chances of the network converging to the same, correct answer are much slimmer this way

blamestross

3 hours ago

So DHT robustness against censorship is superlinear of the number of participants.

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.

Realman78

3 hours ago

You're right in general. The main mitigation here is that Kiyeovo does not trust unsigned DHT data: the important records are signed and validated. That doesn't fully solve censorship nor eclipse attacks, but it does stop record forgery. The remaining risk is mostly availability/partitioning - bootstrap connectivity (topology) matters a lot here