Technical questions regarding bootstrapping

1

Hi, I have a few questions:

  • Do js-ipfs and kubo use the same bootstrapping procedure?
  • Is bootstrapping defined in the protocol spec or is it up to each implementation?
  • When bootstrapping, do nodes use all bootstrap nodes in the bootstrap list or do they only connect to some nodes? If only some nodes, how many, and is it randomly selected? Is this the same in JS and go?
  • If a node is added/removed from the bootstrapping list does this change take effect immediately, or does the node require a restart? (and is this the same across JS/Go)

Thanks!

2

AFAIK it is the same logic in both, but only because js-ipfs inherited many design decisions from go-ipfs/Kubo. Each implementation is free to

Currently, both JS-IPFS and Kubo (<0.18):

  • Will try to connect to all Bootstrap nodes defined in the config. There are default ones maintained by IPFS/libp2p team, and run on infra sponsored by Protocol Labs. It is encouraged to add your own, including ones that do not depend on PKI and DNS, to make it more robust.
  • Not that default bootstrap is more than this, JS-IPFS in NodeJS and Kubo will also leverage libp2p/specs/mDNS to discover peers in LAN (unless you’ve set up server profile, which disables mDNS.
  • Caveat 2: JS-IPFS running in web browser will connect to the same bootstrappers, but use /wss transport instead of raw QUIC/TCP. In the near future, after Kubo 0.18 ship, default bootstrappers will also support for webtransport/ transport.

Right now, all bootstrappers are used, but there is work in progress in Kubo to only use a subset, and also remember a subset of regular peers discovered after the first bootstrap, to make the default bootstrap process more robust and less dependent on PL infra (kubo PR).

I believe you need to restart for most of the config changes to be applied.

3 Likes
3

Thanks! I’m doing some academic work related to censorship resistance of IPFS (and some hardening of IPFS through some utilities that mess about with IPFS peer + bootstrapping lists, add some additional transports [some via adding a libp2p transport and some that use side channels for bootstrapping], and some libraries/utilities built on top of IPFS), and getting this detailed description of expected behavior both currently and in the near future is very useful.

1 Like
4

In the context of censorship resistance, you may want to also look at HTTP Gateways.

Historically, gateways only returned deserialized data, but since last year (see Kubo 0.13 Release Notes) it is possible to request DAG data behind CIDs block-by-block (application/vnd.ipld.raw), or as a bag of blocks (CAR stream, application/vnd.ipld.car).

These opt-in response types allow users to verify all hashes on the client.
See examples at Trustless, verifiable retrieval with HTTP Gateways.

This means every public gateway that supports Block/CAR responses can be used for fetching content-addressed data without risk of MITM and DoS attacks, or having to run full libp2p node (which may not always be possible due to opsec requirements).

1 Like