feat(bootstrap): save connected peers as backup bootstrap peers

[schomatis]

This PR aims to close #3926.

Every 1 hour (DefaultBootstrapConfig.BackupBootstrapInterval, can override via Internal.BackupBootstrapInterval) we save a number of peers we're connected to in Kubo's datastore. If we can't connect to our "official" bootstrap peers defined in the Bootstrap config (if we don't hit the target in DefaultBootstrapConfig.MinPeerThreshold, again hardcoded, why is this not in the config file?) we resort to connecting to some of the peers from the above list.

How To Manually Test

export IPFS_LOGGING="bootstrap=debug"
ipfs daemon

Running a few seconds we'll see the log:

DEBUG	bootstrap	bootstrap/bootstrap.go:210	saved 8 connected peers (of 8 target) as bootstrap backup in the config

Stop the daemon.

Backup and remove the official bootstrap peers, CAREFUL:

ipfs config --json Bootstrap | tee bootstrap-peers.back
# List of hardcoded bootstrap peers, like: "/dnsaddr/bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN"

ipfs config --json Bootstrap []

At this point, the version in master should not be able to connect to the network:

ipfs daemon
# WARN	bootstrap	bootstrap/bootstrap.go:103	no bootstrap nodes configured: go-ipfs may have difficulty connecting to the network

ipfs swarm peers
# nothing

With this PR:

ipfs daemon
# DEBUG	bootstrap	bootstrap/bootstrap.go:242	not enough bootstrap peers to fill the remaining target of 4 connections, trying backup list

ipfs swarm peers
# normal amount of peers, connected to the network

Restore bootstrap with

ipfs config --json Bootstrap "$(cat bootstrap-peers.back)"

[guseggert]

@schomatis: let's put this in the repo datastore for now, so that we are free to change/remove it later without breaking folks.

[schomatis]

@guseggert Moved to datastore. Ready for review. Will need help with tests if required to land this.

[BigLep]

@guseggert : this is a mental note that I'd like to flag this one for code review Friday so we get it over the line.

[Winterhuman]

@BigLep Any update on this? I've read into the issue and it seems the end goal is to move this functionality into go-libp2p (libp2p/go-libp2p-kad-dht#254), is this still the plan?

[guillaumemichel]

This feature would be great to have. It enables:

• less load on bootstrap nodes
• faster bootstrap (finding self from the known closest peer still online)
• more balanced RT buckets. Currently empty buckets are filled by querying a random key belonging to this bucket. Hence all the peers inside this bucket will all be very close from this random key, and will not be distributed uniformly in the bucket keyspace, which is desired as it reduces the number of hop during the lookup process.
• less dependence on central bootstrap nodes, more dependence on known peers. Makes the network more decentralized

[BigLep]

Thanks for the flags. This has gotten lost amongst all the other priorities that have emerged so far in 2023. I have in the list for 0.20. A key thing we're missing is what is remaining to land this.

[hacdias]

I just rebased this and I will try taking a look at it during this week or the next week. This would be a great addition.

@Jorropo it would be great if you could take a look since you've reviewed it before.

[hacdias]

I went over the code, cleaned up some comments and pushed a fix. Also updated the main PR description with how to test manually. The code looks good to me and works well for me. What I think is left to review:

• Decide if new variable names are fine, as well as defaults. I have no problems with them.
• I would like to test this, but I don't see how we'd do it.

cc @ipfs/kubo-maintainers

[lidel]

Some nits below, but it does not have to be perfect, anything here is better than nothing.
Important part here is to have regression tests that ensure backup bootstrappers are used.

@hacdias I think testing would live in https://github.com/ipfs/kubo/tree/master/test/cli and be similar to swarm_test.go or dht_legacy_test.go:

1. configure node to have ipfs config --json Bootstrap [] and Discovery.MDNS.Enabled: false (we want it to boot and have no peers)
2. set bootstrap backup interval to to something small, like 250ms (could be config proposed below inline, or could be env override via os.LookupEnv)
3. start the daemon, confirm it has no peers (expected)
4. start the second peer (with default config and Discovery.MDNS.Enabled: false, we want it to be a member of public swarm, but not connect to the first one) and confirm it has some peers
5. manually connect first one to the second one
6. confirm the first one learned about other peers (ipfs swarm peers longer than 1)
7. shut down both daemons, and then start first one again
8. it should be connected to something thanks to the backed up peers (ipfs swarm peers longer than 1)

(to make this test work offline we could introduce a third node )

[hacdias]

@lidel I added a test that runs completely separately from the rest of the network. I made a slight change compared to what you suggested. We have 0, 1 and 2. They all have the same config (no bootstrap nodes, no MDNS enabled, 250ms for backup bootstrap interval). The following happens:

• Start all daemons.
• 0 and 1 connect to each other. Wait for 0 to save 1 as backup bootstrap.
• Ensure 0 and 1 are connected to 1 peer (each other). 2 is connected to none.
• Stop all daemons.
• Start 1 and 2. Connect both and ensure they're not connected.
• Connect 1 and 2 and ensure they are connected.
• Start 0. Ensure it connects automatically to 1 and discovers 2 via 1. They're all connected.

[hacdias]

I'm approving this. I will wait for one more approval since I wrote the test 😃

[lidel]

ℹ️ We can expose these later under Internal.* if needed (in future PRs).

For now, only Internal.BackupBootstrapInterval is exposed for use in the test/cli/backup_bootstrap_test.go test. Not documenting it, as we may change the name/location later.

[lidel]

I think this one baked for long enough -- does the basic thing, we can refine in follow-up PRs, but is already way better than nothing.

Thank you all for pushing on this. Added changelog entry, merging when CI passes.

[BigLep]

@lidel : Awesome! I wanted to confirm that the default bootstrap peers will still stay in the list, but not now the list is augmented with additional peers based on past discovery.

The reason I'm asking is because of probelab's measurements that try and ascertain the DHT network node size based on the number of peerids that connect to it.

[hacdias]

@BigLep the default bootstrap peers stays. We add additional backup peers based on our connections. Those will be dialed if the default bootstrap list does not work.