Saving previously seen nodes for later bootstrapping

[lidel]

Version: N/A

Type: Enhancement

Severity: Medium

Description:

IPFS Node should persist a list of currently connected peers periodically, so the next time it starts it can use previously working peers in addition to centralized bootstrap nodes.

This is especially important in web browser context, where discovery often relies on centralized signaling servers. Having a ready-to-use cache of known-to-work peers would improve startup performance in those contexts and act as an additional tool for achieving connectivity magic (#1459).

References:

• This is js-ipfs version for original issue from Saving previously seen nodes for later bootstrapping kubo#3926:

  Bootstrap nodes built into ipfs client don't seem to work for me at all. Had to find and add some manually. Generally having so centralized bootstrap system for otherwise decentralized network is its weakness: Censorship resistant bootstrapping (e.g. for wikipedia) kubo#3908
  Should ipfs automatically save all the nodes it seen and the time of last seen, to clean out the list later? That should make the bootstrapping more reliable and truly decentralized.

• Prior art: Torrent clients persist things like DHT routing tables between restarts to improve performance, eg. aria CLI https://linux.die.net/man/1/aria2c:

  By default, the routing table of IPv4 DHT is saved to the path $HOME/.aria2/dht.dat and the routing table of IPv6 DHT is saved to the path $HOME/.aria2/dht6.dat.

[lidel]

Ideas being discussed in libp2p/go-libp2p-kad-dht#254

[lidel]

I think ipfs/kubo#3926 (comment) applies to js-ipfs as well.

[achingbrain]

This sounds a lot like the libp2p persistent peer store, right? It's enabled by default in node and the browser.

libp2p emits all known peers at startup which should trigger auto-dial means we'd connect to them, up to the max connections threshold.

Is it not working as intended?

[SgtPooki]

js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide.

Please feel to reopen with any comments by 2023-06-02. We will do a final pass on reopened issues afterwards (see #4336).

Handing this off to @achingbrain to see how to handle moving forward.

[achingbrain]

libp2p has a persistent peer store, and peers are selected from the store to be dialled on start up so I think this can be closed.

The other issue is reloading the KAD buckets which is tracked here: libp2p/js-libp2p-kad-dht#109