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?
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
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.
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"
"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 1 in in size.
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
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?
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?
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?
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
I'm a fan of "face to face mutual qr code key exchange." I should implement that someday.
QR code key exchange is convenient, but I did not plan phone support.
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.
How does one find large DHTs? Is there anything connecting them all?
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"
"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 1 in in size.
https://en.wikipedia.org/wiki/Mainline_DHT
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
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?
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?