By doing tests with ipfs setup, I wonder what are the differences between config.Bootstrap, config.Addresses.Delegates, and preload.addresses. The three are used to setup distant nodes, but what is the purpose and differences of those addresses ?
This is a great question and a common source of confusion.
The first thing to note is that you can use a single Kubo node with a TLS certificate for Bootstrap, Delegates, and preload.
So here’s what they are for:
Bootstrap is list is a list of peers with which the IPFS daemon learns about other peers on the network. IPFS comes with a default list of trusted peers, but you are free to modify the list.
Delegates are nodes that expose the /api/v0/dht/* endpoints of the Kubo RPC API for delegated routing. Because js-ipfs nodes don’t have the DHT enabled by default (and wouldn’t make good DHT servers in browsers anyways), they need the help of delegates nodes to resolve DHT queries. [^1]
Preload are nodes that expose the /api/v0/refs endpoint which can be called so that the remote node will fetch CIDs (but not pin). This is necessary to ensure that blocks that are added in the browser are preloaded onto a long-running IPFS node so that it’s made available to the rest of the network. Important to note that preload nodes will garbage collect those blocks after a period.
And is it possible to have ‘root’ nodes used as bootstraps, delegates and preload simultaneously?
Yes – a single Kubo node can serve all three purposes.
[^1] As far as I understand, in the long run, the idea is to replace this part of the API with Reframe.
Thanks a lot for this detailed and very clear answer.
In my project, we use js-ipfs in a node+ssr or electron application in the main.js process, so it is not in browser, which I hope should allow to setup some nodes with Bootstrap+Delegates+Preload services, without browser limitations.
Does it sound possible to develop such nodes only with js-ipfs and is it relevant ?
I would try to avoid to have to launch external Kubo nodes to make the project run, by having all services embedded in the same application.
Electron as far as I can remember is node.js which for js-ipfs means that you are in a better place because you can establish TCP connections and have requirements for TLS certificates.
For your nodes to be able to successfully exchange blocks/CIDs at least some of them need to be dialable. Circuit relay v2 helps with hole punching NAT, but it’s still not available in the JS stack.
That’s it : all the jsipfs code runs only in a server-side in a Quasar+node project, for both SSR and Electron so we are not limited to websockets and webrtc channels. And some nodes will be publicly available without NAT or firewall.
So, it should be possible to have Kubo like services in a node/jsipfs project ? This is I think exactly what I am looking for. Is the default jsipfs setup sufficient , or is a specific setup required for those ‘kubo like js’ nodes ? If it helps, I will make a public repo with this kind of setup, when I have it work.