Nodes

Participants in the IPFS network are called nodes. A node is a program or process implementing IPFS that you run on your local computer (directly or via a browser) to store files and connect to the IPFS network. They're the most crucial aspect of IPFS. Without nodes running as an IPFS daemon (explained below), there would be no IPFS Network.

You're likely to see the term node throughout the IPFS docs, issues, and related code. It's a very general term, so its meaning depends on the context. There are three main categories of nodes: IPFS nodes, data nodes, and libp2p nodes for applications.

• IPFS Nodes are programs that run on a computer that can exchange data with other IPFS nodes. They go by several different names, but we refer to them by a different term, depending on the context:

  • node: Use node when you're referring to an individual point on the network. It's a very general term. For example, when you open IPFS Desktop, you establish yourself as a node with the potential to interact with other nodes. See Configure a node.
  • peer: Use peer when you're talking about the relationship of one node (even your own) to other nodes. It refers to their relationship as equals, with no central authority, so your node is a peer to other peers. See Observe peers and Peering with content providers.
  • daemon: Use daemon when talking about a node's activity status. When a node is online and running in the background, listening for requests for its data, it's called a daemon. See Take your node online. Note that an IPFS Helia node in the browser is not generally referred to as a daemon. However, in the context of this document, we will refer to a Helia instance acting as a node in the browser as a daemon . For more information, see the Helia documentation (opens new window).
  • instance: Use instance when talking about a library or program, such as a Go or JS version, running on as an IPFS node at a particular point in time. The peer ID is the same, so it's still the same node as far as the IPFS network is concerned. See Kubo and Helia.

• Data nodes, Use data nodes when talking about actual pieces of data on IPFS, such as DAG nodes, UnixFS nodes, and IPLD nodes. When you add a file with the ipfs add myfile.txt command, IPFS breaks them up into several nodes that each contain a chunk of the file and are linked to each other. See Merkle Directed Acyclic Graphs (DAGs), Unix File System (UnixFS), and stay tuned for InterPlanetary Linked Data (IPLD) model docs, which is in progress.

• libp2p peer Use libp2p peer when talking about libp2p nodes on which you can build applications. They're usually referred to as peers in libp2p, because it provides solutions for essential peer-to-peer elements like transport, security, peer routing, and content discovery. See concepts

Types

There are different types of IPFS nodes. And depending on the use-case, a single IPFS node can serve one of many functions:

• Relay
• Bootstrap
• Delegate routing

Relay

If an IPFS node deems itself unreachable by the public internet, IPFS nodes may choose to use a relay node as a kind of VPN in an attempt to reach the unreachable node.

Features of a relay node

• Implements v2 (opens new window) of the Circuit Relay protocol.
• Can be either Kubo or Helia nodes; however there are standalone implementations as well:
  • js-libp2p/circuit-relay (opens new window)
  • go-libp2p-relay-daemon (opens new window)
• They're used by both Kubo and Helia nodes.
  • A Helia node in the browser can't talk TCP, so a relay can help increase the number of peers that can be communicated with. A Helia node with browser-supported transports (opens new window) can talk with a Kubo peer with no overlapping transports using a relay peer if that relay supports one transport from each other peer:
    1. At least one browser-supported transport (appropriate transports are enabled by default in Helia browser nodes (opens new window))
    2. At least one Kubo peer supported transport.

Limitations of relay nodes:

• v2 relays are "limited relays" that are designed to be used for Direct Connection Upgrade through Relay (opens new window) (aka hole punching).
• Not configurable in Kubo; uses a preset list of relays

See p2p-circuit relay (opens new window)

Bootstrap

Both Kubo and Helia nodes use bootstrap nodes to initially enter the DHT.

Features of a bootstrap node:

• All default bootstrap nodes are part of the public DHT.
• The list of bootstrap nodes a Helia node connects to is controlled by configuring libp2p's peerDiscovery option (opens new window).

Limitations of a bootstrap node:

• If an IPFS node only has one bootstrap node listed in that configuration and that bootstrap node goes offline, the IPFS node will lose access to the public DHT if it were to restart.
  • Note that you should be able to configure your peer store in your implementation to cache healthy connectable peers so you can connect to them again after a restart, instead of bootstrap nodes. Kubo recently added support for this (opens new window).

More about Bootstrapping

Delegate routing node

When IPFS nodes are unable to run Distributed Hash Table (DHT) logic on their own, they delegate the task to a delegate routing node. Publishing works with arbitrary CID codecs (compression/decompression technology), as the js-libp2p-delegated-content-routing module (opens new window) publishes CIDs at the block level rather than the IPLD or DAG level.

Features of a delegate routing node:

• They are IPFS nodes with their API ports exposed and some Kubo RPC API commands accessible at path /api/v0.
• Usable by both Kubo and Helia nodes.
• Helia nodes can use them to query the DHT and also publish content without having to actually run DHT logic on their own.
  • The libp2p node configured for a Helia node can be configured for delegate routing by following instructions at in the js-libp2p configuration doc (opens new window)

Limitations of a delegate routing node:

• On default delegate nodes provided by Protocol Labs, the garbage collection happens every hour, so provided content only survives for that long.
• Only Kubo is known to implement the Kubo RPC API at the time of writing.
  • There is a successor to the delegated routing functionality of the Kubo RPC API called Routing V1 HTTP API (opens new window)

Implementations

Protocol Labs manages two implementations of the IPFS spec: Kubo and Helia. These implementations use specific types of nodes to perform server, browser, and other client functions.

Read more about our implementations