Move bootstrap logic to DHT

Stebalien commented 5 years ago

Really, each service should maintain a list of bootstrap peers for that service. The point of bootstrapping isn't to connect to some random nodes, it's to join the DHT.

Motivation: more and more peers are using the DHT in client mode. That means we need to re-bootstrap even if we have connections because we need to maintain at least one connection to at least one DHT node.

P0 because my node is falling off the network.

Stebalien commented 5 years ago

See: https://github.com/libp2p/go-libp2p-kad-dht/issues/193

meyer9 commented 4 years ago

It seems like we should even have a minimum number of peers per protocol. For example, we might want to connect to at least one node providing a specific service.

Stebalien commented 4 years ago

Status: https://github.com/libp2p/go-libp2p-kad-dht/issues/387, https://github.com/libp2p/go-libp2p-kad-dht/pull/383.

Stebalien commented 4 years ago

@meyer9 that really depends on the service, but not usually.

Bitswap: we want to connect to peers with the content we're looking for. We use the DHT to find these peers.
Pubsub: we want to connect to peers interested in the same topics. Again, we use the DHT.
Relay: we need some relay node that's willing to act as a relay. We don't want a random node that speaks the relay protocol. We currently use the DHT to find these nodes.
AutoNAT: Anyone who speaks the AutoNAT protocol is fine. We passively discover these nodes (e.g., our bootstrap nodes are "AutoNAT" nodes).
DHT: we need to connect to some peer. In this case, we need a set of known DHT nodes.

ipfs / kubo

Move bootstrap logic to DHT #6287