4 ms·

You'd need to scan for random hosts on the Internet and hope they're running a client to do that, no?

colejohnson66 6y ago
Even BitTorrent’s DHT requires somewhat hardcoded IPs for nodes to assist in bootstraping IIRC.
jlokier 6y ago
Only if you have no way of bootstrapping. There are numerous ways to get hold of some initial likely IPs. You only need one well-connected peer to start with, because they will tell you where to look next. - Hard-code some bootstrap IPs of contributors who agreed to that in the shipped software. The list can be updated with each new release. Even if the list has some wrong entries, it doesn't matter. - Hard-code some bootstrap DNS names of contributors who agreed to host IP lists. Even if the DNS list has some wrong entries, it doesn't matter. - Multicast locally in search of neighbours. Not available on all networks, but works on some. - Encourage users with active, long-lived nodes, to register themselves on some well known service belonging to someone else, for example any of the free DNS services, DynDNS etc. and hard-code these well-known locations in the software. - Encourage users with active, long-lived nodes, to publish endpoint information somewhere that will be indexed by Google, Bing, Duck Duck Go etc. such that a search by a client with the right string will find these in results. - Have people publish long-lived node info to Freenode IRC, Discord, Slack, Google Groups, etc. - Don't hard-code or encourage anything, just tell the users "find someone with an active peer" and leave users to find someone by whatever means works for them. This seems best for robustness, in places where the internet might be blocked or you depend entirely on a mesh network, even if it's more work for individuals. To ensure this route is always available, make sure your software has an option to specify bootstrap addresses, even if it has something hard-coded as well. - You can also, as you say, scan random IPs, and also random DNS names. This is not as heavyweight as it sounds. Once the network has a good number of peers, the number of random IPs you need to try to find just one active peer diminishes. You would improve on that by using topological information, reverse DNS hints, try to detect when you are probing a whole block of IPs that are all behind NAT (so skip the whole block), and ideally have encouraged the best connected peers to publish a DNS record indicating availability. At some level there is always infrastructure. But it doesn't have to by your own infrastructure.

Even BitTorrent’s DHT requires somewhat hardcoded IPs for nodes to assist in bootstraping IIRC.

Only if you have no way of bootstrapping. There are numerous ways to get hold of some initial likely IPs. You only need one well-connected peer to start with, because they will tell you where to look next. - Hard-code some bootstrap IPs of contributors who agreed to that in the shipped software. The list can be updated with each new release. Even if the list has some wrong entries, it doesn't matter. - Hard-code some bootstrap DNS names of contributors who agreed to host IP lists. Even if the DNS list has some wrong entries, it doesn't matter. - Multicast locally in search of neighbours. Not available on all networks, but works on some. - Encourage users with active, long-lived nodes, to register themselves on some well known service belonging to someone else, for example any of the free DNS services, DynDNS etc. and hard-code these well-known locations in the software. - Encourage users with active, long-lived nodes, to publish endpoint information somewhere that will be indexed by Google, Bing, Duck Duck Go etc. such that a search by a client with the right string will find these in results. - Have people publish long-lived node info to Freenode IRC, Discord, Slack, Google Groups, etc. - Don't hard-code or encourage anything, just tell the users "find someone with an active peer" and leave users to find someone by whatever means works for them. This seems best for robustness, in places where the internet might be blocked or you depend entirely on a mesh network, even if it's more work for individuals. To ensure this route is always available, make sure your software has an option to specify bootstrap addresses, even if it has something hard-coded as well. - You can also, as you say, scan random IPs, and also random DNS names. This is not as heavyweight as it sounds. Once the network has a good number of peers, the number of random IPs you need to try to find just one active peer diminishes. You would improve on that by using topological information, reverse DNS hints, try to detect when you are probing a whole block of IPs that are all behind NAT (so skip the whole block), and ideally have encouraged the best connected peers to publish a DNS record indicating availability. At some level there is always infrastructure. But it doesn't have to by your own infrastructure.