IPFS Glossary: Key IPFS and libp2p Terms Explained A to Z

This IPFS glossary defines 115 IPFS terms from A to Z, from Amino DHT to x-ipfs-path, in plain language. Each entry gives you a short definition checked against the IPFS docs, the specs or the AIOZ Pin docs, and links to our deeper post when one exists.

TL;DR:

• Jump to a letter, read the one to three sentence definition, then follow the link if you want the full explanation.
• The terms span the whole stack: content addressing, routing, libp2p networking, gateways, naming, pinning and NFT metadata.
• 79 of the 115 entries link to a deeper post today; the others get their link as new posts go live.
• Product terms such as pin status and the public and premium gateways describe only what the AIOZ Pin docs state.

How do you use this IPFS glossary?

You can read it top to bottom, but most people land here with one word in mind. Find its letter below, and each term heading has its own anchor, so you can link straight to it, for example #bitswap or #unixfs.

The diagram groups the most common terms by the job they do. When a word confuses you, its layer usually tells you which neighboring terms to read next. A CID question leads to multihash and multibase, while a slow download leads to the DHT, provider records and Bitswap.

Which IPFS terms should you learn first?

If you are new to IPFS, these eleven terms carry most of the weight, in roughly the order you meet them:

1. CID: the address of any piece of content.
2. Block and Merkle DAG: how a file becomes a tree of hashed pieces.
3. UnixFS: the format that turns that tree back into files and folders.
4. DHT and provider record: how your node learns who has a CID.
5. Bitswap: how blocks move between peers.
6. Gateway: how a normal browser reaches IPFS content.
7. IPNS: how you get a stable name for content that changes.
8. Pinning and garbage collection: how data stays on a node, or leaves it.

A

Amino DHT

Amino is the name of the public IPFS distributed hash table, the one Kubo and most other implementations join by default. It used to be called the "public DHT", and peers on it speak the /ipfs/kad/1.0.0 protocol. Our guide to how IPFS finds and retrieves files follows a lookup through it.

Announcing (providing)

Announcing is how your node tells other peers that it holds certain blocks, so they can find you as a source. On the Amino DHT this means publishing provider records, which your node must refresh on a schedule, as explained in why IPFS nodes keep reproviding their DHT records.

AutoNAT

AutoNAT is the libp2p protocol a peer uses to find out whether it sits behind a NAT and so cannot be dialed directly. The answer decides whether your node needs relays and hole punching, covered in the libp2p networking layer under IPFS.

AutoTLS

AutoTLS is a service from Interplanetary Shipyard, announced in February 2025, that gets libp2p nodes a Let's Encrypt wildcard TLS certificate automatically. Your node receives a certificate for *.<PeerID>.libp2p.direct, which lets browsers reach it over Secure WebSockets. It does not work with private networks.

B

Base32

Base32 is a case-insensitive multibase encoding used to write CIDv1 as text, and a base32 CID starts with the prefix letter b. Because case does not matter, you can use it in places like subdomains (see what each part of a CID means).

Base36

Base36 is another case-insensitive multibase encoding for CIDv1 text, and it produces shorter strings than base32. AutoTLS, for example, writes Peer IDs in base36 to keep each DNS label under 63 characters. The CID anatomy guide shows how the prefix tells you which base you are reading.

Base58btc

Base58btc is the case-sensitive encoding used for CIDv0 strings and plain multihashes. Every CIDv0 you see, starting with "Qm", is base58btc text, as the byte-by-byte CID walkthrough shows.

Bitswap

Bitswap is the main block exchange protocol of IPFS. Your node sends want-lists of CIDs to peers, and peers send back any blocks they hold, which the DHT and Bitswap guide explains step by step.

Bitswap ledger

A Bitswap ledger is the record a node keeps, per partner, of the bytes it has sent and received. The original IPFS paper uses ledgers to decide how freely to serve a peer. It also lets a node refuse to trade with a peer that drops its ledger (more in how Bitswap ledgers keep block trading fair).

BitTorrent

BitTorrent is a peer-to-peer file sharing protocol, and also the name of the first app that used it. The IPFS paper calls Bitswap a "BitTorrent inspired protocol", but Bitswap is not limited to the blocks of one torrent.

Block

A block is a binary blob of data identified by its own CID. It can be raw bytes from a file or a serialized node encoded with an IPLD codec, and it is the unit peers trade (see how IPFS builds files from blocks).

Bootstrap node

A bootstrap node is a trusted peer your node contacts first to learn about other peers on the network. Both Kubo and Helia use bootstrap nodes to enter the DHT (read what bootstrap nodes do and who runs them now).

Boxo

Boxo is a Go component library for building IPFS applications and implementations. It holds reusable parts such as the Kademlia DHT, Bitswap and data encoding, and it is the code that powers Kubo.

C

CAR (Content Archive)

A CAR file (Content Addressable aRchive) packs the blocks of an IPLD DAG into one file or byte stream, usually with a .car extension or the application/vnd.ipld.car media type. You use CARs to move a whole DAG between systems and verify each block on arrival, as covered in IPFS CAR files explained.

CAR v1 / CAR v2

CAR v1 is the original layout: a header that names the root CIDs, followed by the blocks. CAR v2 wraps that payload and adds an optional index, so a reader can jump to one block without scanning the whole file. The CAR files guide covers both.

CBOR

CBOR (Concise Binary Object Representation) is a compact binary data format based on JSON. IPLD uses a strict subset of it, DAG-CBOR, to store structured data that contains links, as the IPLD data model guide explains.

Chunking

Chunking is how IPFS splits a file into blocks before it builds the file's DAG. Fixed-size chunking is the common default, while content-defined methods such as Rabin or Buzhash cut at data-dependent points to find more duplicate blocks (compare both in fixed vs content-defined chunking).

CID (Content Identifier)

A CID is a self-describing label that points to content by its hash instead of by its location. It is the core identifier of IPFS and IPLD, and besides the digest it records the version, the codec and the hash function (start with the anatomy of an IPFS CID).

CID profile

A CID profile is a named set of DAG-building parameters, such as chunk size, DAG width and layout, so that different tools give the same CID for the same input. IPIP-0499 (March 2026) defines unixfs-v1-2025, with CIDv1, 1 MiB chunks and 1,024 links per node, and unixfs-v0-2015 for the legacy Kubo defaults (see why the same file used to get different CIDs).

CID v0

CIDv0 is the original IPFS identifier: a base58btc multihash that is 46 characters long and starts with "Qm". It has no version or codec fields, so it always means dag-pb data hashed with SHA-256. The CID anatomy guide compares it with v1.

CID v1

CIDv1 adds leading fields for the version, the multibase and the codec, so one format can describe many data types and hash functions. The modern unixfs-v1-2025 profile uses it, usually written in base32 (see how a CIDv1 is put together).

Circuit relay (v2)

Circuit relay v2 lets two peers that cannot reach each other talk through a third peer, which offers a limited relay. In IPFS it often serves as the first step toward hole punching, and Kubo has supported it since version 0.11. It is covered in the libp2p networking layer guide.

Codec

A codec is the rule that encodes data into bytes and decodes it back into a data model. IPFS names codecs by number in the shared multicodec table, so a CID can say how its block should be read, as the IPLD data model guide shows.

Content addressing

Content addressing means you fetch data by a hash of what it is, not by where it is stored. If the bytes change, the address changes too, which is what makes IPFS data verifiable (read content addressing vs location addressing for the full contrast).

Contenthash (ENS)

Contenthash is the ENS resolver field that maps a name, such as an .eth domain, to a content address on a network like IPFS or Swarm. It is defined in ENSIP-7, formerly EIP-1577. It replaced the older content and multihash fields.

CRDT

A CRDT (Conflict-Free Replicated Data Type) is a data structure designed so that copies edited separately always merge to the same state. The IPFS docs describe it as a way to reach strong eventual consistency without rollbacks, which suits shared data that many peers update.

D

Daemon

A daemon is a program that runs in the background. The IPFS daemon is how you take your node online: in Kubo you start it with the ipfs daemon command.

DAG (Directed Acyclic Graph)

A DAG is a graph whose links point one way and never loop back. IPLD data in IPFS is a DAG by nature, since each node links to its children by CID, as how IPFS works under the hood shows.

DAG layout (balanced/trickle)

DAG layout is the shape IPFS gives the tree of blocks behind a file. A balanced layout keeps every leaf at the same depth for fast random access, while a trickle layout suits streaming and append-only data such as logs.

DAG-CBOR

DAG-CBOR is the IPLD codec that stores the IPLD data model as a strict subset of CBOR, with a CBOR tag for links. You would pick it for structured records, such as metadata objects that point to other CIDs. See the IPLD data model guide.

DAG-JOSE

DAG-JOSE is an IPLD codec that serializes JOSE objects, the standard for signed and encrypted JSON, as CBOR. It lets you keep a signature or an encrypted payload inside a content-addressed graph.

DAG-JSON

DAG-JSON is the IPLD codec that writes the data model as JSON, with a fixed convention for encoding links. It is handy when you want IPLD data you can read and debug by eye, as the IPLD data model guide explains.

DAG-PB

DAG-PB is the Protocol Buffers codec (code 0x70) behind classic UnixFS files and directories. Each node holds a list of named links plus a data field, which is how a file's chunks and a folder's entries get tied together (see how UnixFS represents files and directories).

Data model (IPLD)

The IPLD data model is the shared set of kinds, such as maps, lists, strings, bytes and links, that every IPLD codec maps onto. Because codecs share it, you can walk DAG-CBOR and DAG-JSON data the same way (read what the IPLD data model is).

Datastore

The datastore is the on-disk storage system of an IPFS node. Its location, size, construction and behavior are set in the node's configuration.

DCUtR

DCUtR (Direct Connection Upgrade through Relay) is the libp2p protocol for hole punching. Two peers first talk over a relayed connection, then use it to coordinate a direct connection through their NATs or firewalls. The libp2p networking guide walks through the steps.

Delegated routing

Delegated routing lets an IPFS client hand content routing, peer routing and IPNS lookups to another server. The common spec is the Delegated Routing V1 HTTP API, which helps in browsers and other places where you cannot run a DHT node (see delegated routing and the network indexer).

Denylist

A denylist is a list of CIDs that an IPFS node operator chooses not to serve. The compact denylist format lets nodes and gateways filter blocked content efficiently, as covered in how content moderation works on IPFS.

DHT

A DHT (distributed hash table) is a key-value store spread across many peers, where the keys are cryptographic hashes. IPFS uses a modified Kademlia DHT to find which peers provide a CID, as the content routing guide explains.

Dialing

Dialing is the libp2p act of opening a connection to another peer. Together with listening, dialing makes up a transport.

DNSAddr

DNSAddr publishes one or more multiaddrs under a DNS name, written itself as a multiaddr such as /dnsaddr/bootstrap.libp2p.io. It is used for scaling and dynamic bootstrapping, and as a routing hint for DNSLink websites (read how bootstrap nodes are published as DNSAddr names).

DNSLink

DNSLink maps a domain name to IPFS content through a DNS record, so you can use a path like /ipns/docs.ipfs.tech instead of a CID or a key. Change the record and the name points at new content (read how DNSLink gives IPFS content a domain name).

F

Filecoin

Filecoin is a decentralized storage network where you can rent out disk space or pay others to store data, backed by a proof-of-replication mechanism. It is built on IPFS and uses it for data storage and retrieval (see how IPFS and Filecoin relate).

Filestore

The filestore is an experimental Kubo data store that keeps references to your files on disk instead of copying them into the repo. You turn it on per add with ipfs add --nocopy, so your data is not stored twice.

G

Garbage collection

Garbage collection (GC) is the routine in which an IPFS node deletes cached blocks to free up disk space. Pinned content is never removed, which is why pinning is how you protect data (read what unpinning and garbage collection do).

Gateway

An IPFS gateway is an HTTP server that bridges web browsers and IPFS, so you can load content by CID without running a node. Most gateways are IPFS nodes that also expose an HTTP endpoint (start with what an IPFS gateway is).

go-ipfs

go-ipfs is the old name of Kubo, the Go implementation of IPFS. You still meet it in older tutorials and forum threads.

GossipSub

GossipSub is the libp2p publish-subscribe router. Instead of flooding every peer, each peer forwards messages to a bounded mesh of topic members and gossips about the rest, as IPFS PubSub and GossipSub explained describes.

Graphsync

Graphsync is a legacy protocol that replicates graphs rather than single blocks, similar in purpose to Bitswap. Kubo does not support it, and IPIP-402 offers a simpler way to sync partial DAGs.

H

HAMT sharding

HAMT sharding splits a very large UnixFS directory across many blocks using a hash array mapped trie. Without it, a directory with thousands of entries would not fit in one reasonably sized block (see how IPFS shards large directories).

Hash

A cryptographic hash function turns any input into a fixed-length value, and the same input always gives the same output. IPFS builds CIDs from such hashes, with SHA-256 in both standard CID profiles. The CID anatomy guide shows where the hash sits.

Helia

Helia is a lean, modular IPFS implementation for JavaScript and the browser, and the successor to js-ipfs. You add only the pieces you need, such as UnixFS support or verified fetch (read what Helia is and how it works).

Hole punching

Hole punching connects two peers behind NATs or firewalls by having both open connections to each other at the same moment. In libp2p it runs through DCUtR when port forwarding is not possible, as covered in the libp2p networking guide.

I

Immutability

Immutability means content cannot change once it is added: change one byte and you get a new CID. To publish updates, you point a mutable name such as IPNS or DNSLink at the newest CID (read why content addresses never change).

IPFS Desktop

IPFS Desktop is a desktop app for Windows, macOS and Linux that runs a Kubo node behind a graphical interface. It gives you a local node without using the command line (see how browsers and desktop apps open ipfs:// links).

IPFS Mainnet

IPFS Mainnet is the default public network that most IPFS implementations join. Mainnet nodes typically use the Amino DHT for routing, Bitswap for transfer and UnixFS for files, while a private swarm is the alternative (see IPFS private networks and swarm keys).

IPIP

An IPIP (InterPlanetary Improvement Proposal) is the design document used to propose and record changes to the IPFS specifications. IPIP-0499 on CID profiles is a recent example, explained in why the same file used to get different CIDs.

IPLD

IPLD (InterPlanetary Linked Data) is the set of specifications for content-addressed data structures that IPFS builds on. It gives all hash-linked formats one namespace, so a link can point from one format into another (start with the IPLD data model).

IPLD selector

An IPLD selector is a graph query over IPLD data that describes which parts of a DAG to walk. Protocols use selectors to fetch one slice of a large graph instead of all of it (see IPLD selectors and DAG traversal).

IPNI

IPNI (InterPlanetary Network Indexer) is a content routing system that indexes which providers hold which CIDs. It gives IPFS an alternative to the Amino DHT for finding content quickly.

IPNS

IPNS (InterPlanetary Name System) creates mutable names tied to a public key. You publish a signed record that points the name at your latest CID, so links stay the same while content changes (read how IPNS gives IPFS mutable pointers).

J

js-ipfs

js-ipfs was the original JavaScript implementation of IPFS. It is deprecated and superseded by Helia, covered in the Helia guide.

K

Kademlia

Kademlia is a peer-to-peer DHT algorithm that measures the distance between IDs with XOR. The IPFS DHT uses buckets of k = 20 peers, and the same k sets how many peers a lookup returns and how widely records are replicated.

Kubo

Kubo, formerly go-ipfs, is the earliest and most widely used IPFS implementation, written in Go. It runs on servers and personal machines with the full set of IPFS features.

L

Leaf

A leaf is a node in a graph that links to no other node, the opposite of a root. In a UnixFS file the leaves hold the chunks of data, as the UnixFS guide shows.

libp2p

libp2p is the modular system of protocols, specs and libraries for peer-to-peer networking that IPFS runs on. It handles peer identity, transports, encryption, multiplexing, NAT traversal and peer discovery (read the libp2p networking layer under IPFS).

Link (IPLD)

In IPFS and IPLD, a link is a pointer to another piece of data by its CID. Links are what turn separate blocks into a Merkle DAG, as the IPLD data model guide explains.

M

Merkle DAG

A Merkle DAG is a DAG in which each node is identified by a hash of its content, including the CIDs of its children. Change any leaf and every CID above it changes, which is why one root CID can verify a whole tree (see how IPFS works with Merkle DAGs).

Merkle tree

A Merkle tree is a hash tree, named after Ralph Merkle who patented it in 1979, that lets you verify large data structures efficiently. In a classic Merkle tree the data sits in the leaves, while a Merkle DAG lets any node carry data and share children.

MFS (Mutable File System)

MFS is a file system built into IPFS that lets you work with files by name, as on a normal disk. You add, edit and remove files, and IPFS updates the links and hashes for you. Our guide to how MFS works in IPFS covers its commands and why it is not a pin.

Multiaddr

A multiaddr is a self-describing network address such as /ip4/198.51.100.7/udp/4001/quic-v1, which stacks protocols from left to right. In libp2p, multiaddrs tell you how to reach a peer. Our guide to multiaddrs and peer IDs shows how to read one in full.

Multibase

Multibase is a one-character prefix that says which base encoding a string uses, such as b for base32 or z for base58btc. In IPFS it tells software how to decode the rest of a CID's text form.

Multicodec

Multicodec is a shared table of numeric codes that say what format some content is in, such as 0x70 for dag-pb or 0x55 for raw bytes. A CIDv1 carries one, so your client knows how to read a block after fetching it.

Multiformats

Multiformats is the project that makes values self-describing, so systems can change formats later without breaking. It covers multihash, multibase, multicodec and multiaddr, the pieces that make up CIDs and peer addresses.

Multihash

A multihash is a hash value prefixed with a code for the hash function and the digest length. A SHA-256 multihash starts with the bytes 0x12 0x20, which lets different hash functions coexist in one system.

Multiplexer (Yamux, mplex)

A stream multiplexer runs many virtual streams over a single libp2p connection. Yamux and mplex are two multiplexers libp2p supports, as the libp2p networking guide explains.

N

NAT

NAT (Network Address Translation) maps devices on a private network onto one public IP address, as most home routers do. It is the main reason home nodes cannot be dialed directly, which libp2p works around with AutoNAT, relays and hole punching (see how libp2p handles NAT).

Noise

Noise is the cryptographic protocol framework libp2p uses to encrypt and authenticate connections between nodes. It is one of the secure channels a connection can negotiate, alongside TLS, as covered in IPFS transports: TCP and QUIC.

O

Optimistic provide

Optimistic provide is a faster way to publish provider records to the Amino DHT. While it walks the DHT, your node stores records with peers that are likely among the 20 closest, then stops early. That cuts publish time from over 13 seconds to under 1 second (read how optimistic provide made publishing faster).

P

Path gateway

A path gateway serves IPFS content at /ipfs/{cid} or /ipns/{name} paths on one domain. It suits files and assets, but every site shares one origin, so websites and web apps belong on a subdomain gateway (see the IPFS gateway guide).

Peer

A peer is an equal participant in a peer-to-peer network, as opposed to a client talking to a server. In IPFS, every node you connect to is a peer, as the libp2p networking guide describes.

Peer ID

A Peer ID is the unique identifier of an IPFS node on the network, derived from a hash of the node's public key. It is created when you initialize the node. Our guide to peer IDs and multiaddrs shows how the ID comes from the key and how it appears in an address.

Peer routing

Peer routing finds the network addresses of a peer when you only know its Peer ID. IPFS mainly uses the Kademlia DHT for this, along with local discovery. The content routing guide covers both kinds of lookup.

Pin status

Pin status tells you where a pin request stands. The AIOZ Pin docs list three states: pinning (in the queue, awaiting processing), pinned (stored and pinned on IPFS) and failed (the upload failed or the graph is incomplete). Their Pinning Service API commands also filter on a fourth state, queued. The docs warn that a very large directory can show pinning indefinitely, as our pin status guide explains.

Pinning

Pinning tells an IPFS node that certain data is important and must never be removed by garbage collection. It is the basic tool for keeping content available (start with what an IPFS pinning service does).

Pinning service

A pinning service is a third party that runs IPFS nodes and pins content for you, so your data stays available when your own node is offline (see how to choose an IPFS pinning service).

Pinning Service API

The Pinning Service API is a vendor-neutral specification that any provider can implement for remote pinning. Kubo speaks it through the ipfs pin remote commands, so one client can work with many services (read the Pinning Service API standard).

Premium (dedicated) gateway

A premium gateway is an AIOZ Pin gateway dedicated to your account. The docs describe unrestricted rate limits and a global network of 200+ edge-caching locations. Free plans get a limited version that serves single files but not HTML or scripts (compare the options in free vs paid dedicated gateways).

Provide sweep

Provide sweep is Kubo's system for announcing large sets of CIDs efficiently. It groups CIDs that belong to the same DHT servers and sweeps through the keyspace region by region. Shipyard reports 97% fewer DHT lookups with it, and it became the default in Kubo v0.39 (see how provide sweep handles large CID sets).

Provider record

A provider record is a DHT entry that maps a CID's multihash to the peers that can serve it. The DHT stores the pointer, not the content, and the spec sets a 48-hour validity with a republish every 22 hours (read why IPFS nodes reprovide their records).

Public gateway (AIOZ Pin)

The AIOZ Pin public gateway lets anyone fetch IPFS content over HTTP without an account. The docs aim it at testing and low-volume use, with limits of 15 requests per minute per CID and 200 requests per minute per IP address (see AIOZ Pin rate limits and gateways).

PubSub

PubSub (publish-subscribe) lets peers send messages on a topic to every peer subscribed to it. The IPFS docs describe it as an experimental feature, and the GossipSub guide covers how messages travel.

Q

QUIC

QUIC is a transport built on UDP that libp2p uses as /quic-v1. It is always encrypted and multiplexes streams on its own, so it skips the extra layers a TCP connection needs (read IPFS transports: TCP and QUIC).

R

Rainbow

Rainbow is an IPFS HTTP gateway written in Go on top of Boxo, using the same gateway code as Kubo but specialized for that one job. It acts only as an Amino DHT and Bitswap client, and it does not pin or permanently store content.

_redirects file

A _redirects file is a config file that defines URL redirects and rewrites for a site served from subdomain and DNSLink gateways. It is how you get single-page app routing and custom 404 pages on an IPFS website.

Relay node

A relay node forwards traffic between two libp2p peers that cannot connect directly, for example because both sit behind NAT or a firewall (see the IPFS node types explained).

Remote pinning

Remote pinning asks a third-party service to keep your data pinned. Your data then persists even if your local node goes offline or garbage collection deletes your local copy (see the Pinning Service API standard).

Repo

The repo is the directory where an IPFS node stores its settings and internal data. In Kubo, the ipfs init command creates it.

Root (CID)

A root is the node of a DAG that links the other nodes together, and its CID is what IPFS shows you as the CID of a file. With 256 KiB blocks, a 600 KiB file splits into three chunks under one root (read how to pin content by its root CID).

S

Schemas (IPLD)

IPLD Schemas are a system for describing IPLD data with structural types. You use them to define, and check, the expected shape of the data in a DAG.

Service worker gateway

The service worker gateway runs an IPFS gateway inside your browser. A service worker intercepts requests for /ipfs/ and /ipns/ paths and uses Helia and verified fetch to retrieve and check the content directly.

Someguy

Someguy is a Delegated Routing V1 HTTP server that proxies lookups to the Amino DHT and other delegated routing servers. It was the backend of delegated-ipfs.dev/routing/v1 until the third quarter of 2026 (see delegated routing and the network indexer).

Subdomain gateway

A subdomain gateway serves each CID on its own subdomain, such as {cid}.ipfs.gateway.example. Each site gets its own browser origin, which makes it safe for websites and web apps, as the IPFS gateway guide explains.

Swarm

The swarm is the set of IPFS peers your node is connected to. Swarm addresses are the addresses your node listens on for incoming connections, as the libp2p networking guide shows.

Swarm key (private network)

A swarm key is a 256-bit pre-shared key, stored in a file named swarm.key in the IPFS repo, that turns a set of nodes into a private network. All traffic between members is encrypted, and nodes from other networks cannot connect (read IPFS private networks and swarm keys).

T

tokenURI / uri(id)

tokenURI is the ERC-721 function that returns the metadata URI for a token, which often points to a JSON file on IPFS. ERC-1155 uses uri(id) instead, where clients replace {id} with the token ID as 64 lowercase hex characters (see how to mint NFTs with persistent metadata).

Transport

A transport is the technology that moves data from one machine to another, such as TCP, QUIC or a WebSocket. In libp2p, an implementation of dialing plus listening makes up a transport, as the transports guide explains.

Trustless gateway

A trustless gateway returns raw blocks or CAR files instead of rendered files, so your client verifies the data against its CID. You do not need to trust the gateway operator (read how IPFS content verification works).

U

UnixFS

UnixFS is the data format IPFS uses to represent files and directories, with their links and metadata. When you add a file, IPFS turns it into a UnixFS block or a tree of blocks (see how UnixFS represents files and directories).

Urlstore

The urlstore is an experimental Kubo data store, similar to the filestore, that reads block contents from an HTTP URL instead of a local file.

V

Verified fetch

Verified fetch (@helia/verified-fetch) is a fetch-like JavaScript API for getting verified, trustless IPFS content on the web. It lets your browser app use IPFS without trusting any single gateway, as the Helia guide explains.

W

WebRTC

WebRTC is the browser framework for real-time communication. In libp2p it comes as two transports, /webrtc and /webrtc-direct, for browser-to-server and browser-to-browser connections.

WebSocket

WebSocket keeps a two-way connection open between a web page and a server process. In libp2p it is the /ws transport, and AutoTLS gives nodes the certificates browsers need for Secure WebSockets.

WebTransport

WebTransport is a newer web specification that runs over QUIC, so you can think of it as WebSocket over QUIC. In libp2p, a /webtransport component in a multiaddr marks support for it.

X

x-ipfs-path

x-ipfs-path is an HTTP response header that some gateways add to tell clients the IPFS path of the content they returned. Today's gateway URL conventions and DNSLink have replaced it for addressing.

How AIOZ Pin handles pinning and gateways

Several terms above meet in one product. AIOZ Pin is a pinning service: it implements the Pinning Service API, reports pin status, and serves your pinned content through a public gateway and premium gateways. If you run Kubo, the docs show how you can pin and check pins with the remote pinning commands (quoted from the docs, not run here):

ipfs pin remote service add pin https://api.aiozpin.network/api/psa/ YOUR_AUTH_JWT
ipfs pin remote add --service=pin --name=my-file YOUR_CID
ipfs pin remote ls --service=pin --status=queued,pinning,failed

The last command lists pins that are still queued, pinning or failed. For the token step and the endpoint details, see the AIOZ Pin Pinning Services API docs.

Frequently Asked Questions

What is a CID in IPFS?
A CID (Content Identifier) is the address of a piece of content in IPFS, built from a hash of that content. It also records the codec and hash function, so any node can check that the data it received matches.

What is the difference between IPFS and IPNS?
IPFS addresses content by CID, so the address changes whenever the content changes. IPNS gives you a stable name, tied to a key, that you can point at the newest CID.

What does pinning mean in IPFS?
Pinning marks data on a node as important so garbage collection never deletes it. A pinning service does this on its own nodes, so your content stays online when your computer is off.

What is an IPFS gateway?
An IPFS gateway is an HTTP server that fetches IPFS content and serves it to ordinary browsers. Path gateways use /ipfs/{cid} URLs, while subdomain gateways give each CID its own origin.

What is the difference between Kubo and Helia?
Kubo is the Go implementation of IPFS that runs as a full node on servers and desktops. Helia is the modular JavaScript implementation for Node.js and browsers, and the successor to js-ipfs.

Related Reading

• What Is IPFS?: the starting point for IPFS fundamentals and why content addressing matters.
• How IPFS works: Merkle DAGs and content routing: the data model behind CIDs, blocks, IPLD and UnixFS.
• How IPFS finds and retrieves files: the DHT, provider records, delegated routing and Bitswap.
• The libp2p networking layer: peers, transports, NAT traversal and relays.
• What is an IPFS gateway?: gateway types, naming and web access.
• What is an IPFS pinning service?: pinning, persistence and garbage collection.
• Minting NFTs with persistent metadata: NFT metadata, tokenURI and ipfs:// links.
• How AIOZ Pin works: the AIOZ Pin platform, from API keys to gateways.

References

• IPFS docs: Glossary, Bitswap, Content addressing and CIDs, Immutability, IPFS comparisons
• IPFS specs: IPFS Kademlia DHT, UnixFS, IPIP-0499: UnixFS CID profiles
• Papers and project blogs: IPFS: Content Addressed, Versioned, P2P File System, Optimistic Provide, Provide Sweep, Announcing AutoTLS
• libp2p: Noise, GossipSub v1.0 spec, Private networks (PSK v1) spec
• IPFS projects on GitHub: Boxo, Rainbow, Someguy, Service Worker Gateway, Helia verified fetch
• Ethereum and ENS: EIP-721, EIP-1155, ENSIP-7: Contenthash
• AIOZ Pin docs: Getting upload status, Pinning Services API, Premium Gateways, The AIOZ Pin Public Gateway, Limit