IPFS has a cornucopia of node types/roles across a plethora of environments, we need a guide!

[autonome]

I had a running list, and then asked the team to fill in the details of what these things were, it's here: https://hackmd.io/j1PQOmB3ReKEoMoQuN-tEg

Copying content here for sakekeeping

IPFS nodes

go-ipfs node

• runs on servers and user machines with the full set of capabilities
  • tcp and quic transports enabled by default
  • /ws/ transport disabled by default
  • http gateway with subdomain support for origin isolation between content roots

js-ipfs node

• runs in the browser with a limited set of capabilities
  • can connect to server nodes (go/js-ipfs) only via secure websockets (/wss/ requires manual setup of TLS at the server)
  • can connect to browser nodes via webrtc (with help of centralized ws-webrtc-star signaling service)
  • no http gateway (can't open TCP port)
• runs on servers and user machines with (in theory) the full set of capabilities
  • DHT not in par with go-ipfs (is this still the case?)
  • http gateway present, but has no subdomain support

Preload node

• are go-ipfs nodes with their API ports exposed, some HTTP API commands accessible, and a patch applied
• used by js-ipfs nodes, both in browser and not
• js-ipfs nodes remain connected to the libp2p swarm ports of all preload nodes by having preload nodes on the bootstrap list
• when users want to make some UnixFS DAG publicly available they call ipfs refs -r <CID> on a randomly chosen preload node's HTTP API which puts the CID in the preload nodes' wantlist which then causes it to fetch the data from the user
• Other js-ipfs nodes requesting the content can then resolve it from the preload node via bitswap as the data is now present in the preload node's blockstore
• Only works with dag-pb CIDs because that's all the refs command understands
  • Q: What are the net effects of this? Bad perf or broken js-ipfs for non-dag-pb CIDs? Are there mitigations?
  • A: Harder to find non-dag-pb content - e.g. you need a connection to the publishing js-ipfs instance or it needs to be put on the DHT by a delegate node. We could do this at the block level and use block stat in the same way as js-delegate-content module
• Preload nodes garbage collect every hour so preloaded content only survives for that long
  • Q: Is this configurable?
  • A: Yes? Infra would be able to tell you more
• TODO: Is there anything about pubsub topic bootstrapping here?

Relay node

• are go-ipfs nodes
  • Q: or are they custom go-libp2p nodes?
• can also be js-libp2p nodes properly configured, or the out of the box js relay
• are used by go-ipfs nodes to serve as relays/VPNs for nodes who deem themselves to be unreachable by the public internet
  • Q: Used by js-ipfs too?
  • A: Yes. They can also be used to overcome lack of transport compatibility. For instance, a browser node with websockets/webRTC transports can talk with a go-ipfs node that only talks TCP, via a relay that support both transports. This is not enabled by default and needs to be setup.
• not configurable in go-ipfs and uses a preset list of relays

Bootstrap node

• are go-ipfs nodes
• used by go and js-ipfs nodes to enter the DHT
• if they go offline a go-ipfs node that restarts will not by default be able to join the public DHT
  • Q: SO MANY QUESTIONS... to start, do you mean if all configured bootstrap nodes go offline this happens?
• configurable in go and js-ipfs config files

Delegate routing node

• are go-ipfs nodes with their API ports exposed and some HTTP API commands accessible
• used by js-ipfs nodes to query the DHT and also publish content without having to actually run DHT logic on their own
• publishing works with arbitrary CID codecs as the js-delegate-content module publishes CIDs at the block level rather than the ipld/dag level
• Delegate nodes garbage collect every hour so provided content only survives for that long - unless the uploading js-ipfs node is still running, in which case it will issue periodic re-provides via the same publising mechanic which extends the life of the content on the DHT

Addenda

1. Preload and delegate routing nodes are the same servers (go-ipfs nodes) though they are addressed independently so do not need to be - we have the choice to make them stand-alone processes in the future if we wish.
   • Q: "addressed independently" - what does this mean? a different place in config? or where the network communication happens in the stack/codepath?
   • A: different multiaddrs that resolve to the same physical (virtual?) machine - e.g. preload config, delegate config
2. Preload, delegate and bootstrap nodes are all in the js-ipfs configuration as bootstrap nodes so it will maintain libp2p swarm connections to them at all times.
   • Q: Are they distinguished in the js-ipfs config, or just look like a regular bootrap node there?
   • A: They are configured as regular bootstrap nodes but have the string 'preload' in their multiaddrs
   • Q: Is there documentation for how to add these nodes to config, and what they do?
   • A: https://github.com/ipfs/js-ipfs/blob/master/docs/CONFIG.md#addresses

[johnnymatthews]

This is pretty similar to #683. I'm gonna close this one in favour of that.