What if IPFS's public DHT bootstrap shutdown?

Ecosystem
, ,
1

I have many questions about default IPFS DHT peers (bootstrap) :

1. What would happen if default bootstrap peers provided by ProtocolLabs shut down ?

I know we can specify manually new bootstrap address to the client, but this question remains important to me as any new daemon with default configuration won’t be able to know other peers easily. It sounds like a real subject to me. Maybe am I over-estimating this question ?

2. Could this really happen ?

3. According to this situation, what are the “backup” plans to reach the public DHT ?

Is there any known initiative(s) to thwart that issue ?

4. How a DHT peer can became a “trusted” DHT peer ?

I have read that it should be “an active peer”, but I looking for any “official documentation” about that point. It is not clear if it is a intrinsic DHT process or an initiative from ProtocolLabs ?

1 Like
2

When your node boot, it tries to connect to them, fail and your DHT routing table is empty and you cannot request / serve any content via internet.

Yes it has already happen because of configuration issues in the infra.

  1. MDNS (discovering other nodes on your local network)
    You just need already bootstrapped nodes running on your LAN.

  2. Using other nodes, the best way is to save some peers you are connected to ipfs swarm peers > backup-bootstrap and pick a few (like 50, you just need one of them to be online and integrated into the DHT) and use that for bootstrapping.

Right now we are using the bootstrap nodes on each boot of the node, because it’s an easy thing to write and enginer time is precious.

We want to save nodes you connect to while running and use them for next bootstrapping.
So you would only need to do so on the first install of IPFS, not each restart.

It will then be really easy to share you peerstore (or whatever) file to someone else online. Making bootstrap nodes just a convinience thing for people that don’t want to download a second file when installing.
It’s how some other DHT networks (like i2p) do it.

The important thing is that joinning that list is not a good solution. Yes it’s better if there is more diversity but ideally you don’t really on some magic list (multicast over WAN is sadly not accessible in enough places).

Anyway if you want to join that list see this: Kicking off the Content Addressed Alliance Working Group, Intro yourself (afaik it’s meant for organisations not individuals)

3 Likes
3

Hi Jorropo, thanks for your quick answer ! I have still questions about trusted DHT peer.

How can a DHT peer became trusted if it is NOT in the bootstrap list provided by ProtocolLabs ?

How does it works exactly ? Is it another list setup by ProtocolLabs also ? Or a DHT peer became trusted “automatically” according peer’s confidence toward that peer ?

4

AFAIK there’s nothing special about the bootstrap list provided by Protocol Labs other than the fact it’s included by default. If you explicitly add a peer to peer with on start, that’s the same level of “trust” as the default list.

Hopefully that clears things up :slight_smile:.

1 Like
5

Like @Discordian said there is no particular trust given to bootstrap peers, the one we ship by default is PL runned one because we don’t want to send bunch of traffic to random peoples on internet but it could be anything.
All you need:

  • At least one of your bootstrap node must be online (and run the dht server, which is default if you are publicly reachable)
  • At least one of your bootstrap node must send you reliable routing information.

Using lots (40~100) of randomly picked bootstrap nodes is probably good enough.
A bootstrap node doesn’t even need special software, just DHT server.

2 Likes