# IPFS glossary
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
# A
# ACL
In computer security, an access-control list (ACL) is a list of permissions associated with a system resource, also known as an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. More about ACL (opens new window)
# ADL
ADL is short for Advanced Data Layout, a concept in IPLD. See IPLD docs (opens new window).
# Amino
Formerly referred to as the "public DHT", Amino is the public Kademlia-based DHT that Kubo and other implementations default to bootstrapping into with the libp2p protocol /ipfs/kad/1.0.0. See the blog post (opens new window) for more info.
# Announcing
Announcing is a function of the IPFS networking layer in libp2p, wherein a peer can tell other peers that it has data blocks available.
# AutoNAT
The libp2p protocol that allows a peer to determine if it is located behind a Network address translator (NAT). More about AutoNAT (opens new window).
# B
# Base32
Case-insensitive Multibase encoding used for text representation of CIDv1.
# Base36
Case-insensitive Multibase used for text representation of CIDv1.
# Base58btc
Case-sensitive Multibase used for text representation Multihashes and CIDv0.
# Base64url
Case-sensitive Multibase, uses modified Base64 with URL and filename safe alphabet (RFC 4648 (opens new window)), where the + and / are respectively replaced by - and _.
# Bitswap
Bitswap is IPFS's central block exchange protocol. Its purpose is to request blocks from and send blocks to other peers in the network. More about Bitswap
# BitTorrent
BitTorrent is a communication protocol for peer-to-peer file sharing, which is used to distribute data and electronic files over the Internet. Also, the first file-sharing application to use the protocol. More about BitTorrent protocol (opens new window) and BitTorrent app (opens new window)
# Blockchain
A Blockchain is a growing list of records, known as blocks, that are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a Merkle tree). More about Blockchain (opens new window)
# Block
A Block is a binary blob of data identified by a CID. It could be raw bytes of arbitrary data or a chunk of serialized binary data encoded with IPLD codec.
# Bootstrap node
A Bootstrap Node is a trusted peer on the IPFS network through which an IPFS node learns about other peers on the network. Both Kubo and js-ipfs use bootstrap nodes to enter the Distributed Hash Table (DHT). See Bootstrap
# C
# CAR
The CAR (Content Addressable aRchives) is a format for serialized representation of any IPLD DAG. The CAR format is a way of packaging up content-addressed data into archive files that can be easily stored and transferred. Typically in a file with a .car filename extension or a byte stream marked as application/vnd.ipld.car (opens new window) media type. More about CAR (opens new window)
# CAR v1
Version 1 of the CAR format, a concatenation of DAG blocks, plus a header that describes the graphs in the file (via root CIDs). More about CAR v1 (opens new window)
# CAR v2
A minimal upgrade to the CAR v1 format with the primary aim of adding an optional index within the format for fast random-access to blocks. More about CAR v2 (opens new window)
# CBOR
The Concise Binary Object Representation (CBOR) is a data format based on JSON, featuring small code and message size, and extensibility. Used within IPLD. More about CBOR (opens new window)
# CID
A Content Identifier (CID) is a self-describing content-addressed label used to point to the data stored in IPFS. It is the core identifier used for IPFS and IPLD. More about CID
# CID v0
Version 0 (v0) of the IPFS content identifier. This CID is 46 characters in length, starting with "Qm". Uses a base 58-encoded multihash, very simple but much less flexible than newer CIDs. More about CID v0
# CID v1
Version 1 (v1) of the IPFS content identifier. This CID version contains some leading identifiers which provide for forward-compatibility. Able to support different formats for future versions of CID. More about CID v1
# Circuit relay
A libp2p term for transport protocol that routes traffic between two peers over a third-party relay peer. More about Circuit Relay (opens new window).
# Circuit relay v1
Unlimited relay that requires some external ACL to control resource usage. See specification (opens new window).
# Circuit relay v2
Truly decentralized relay implementation that provides a limited relay for things like hole punching. Support for this type of relay was introduced in Kubo 0.11. See specification (opens new window).
# Codec
A function that encodes or decodes serial data into and from some data model. In IPFS, we use an agreed-upon codec table implemented as part of Multicodec.
# Content addressing
A way to store information so a device can retrieve the data based on its content, not its location. Learn how IPFS uses content addressing.
# CRDT
A Conflict-Free Replicated Data Type (CRDT) is a type of specially-designed data structure used to achieve strong eventual consistency (SEC) and monotonicity (absence of rollbacks). More about CRDT (opens new window)
# D
# Daemon
A Daemon is a computer program that typically runs in the background. The IPFS daemon is how you take your node online to the IPFS network. More about IPFS Daemon
# DAG
A Directed Acyclic Graph (DAG) is a computer science data structure adapted for use with versioned file systems, blockchains, and for modeling many different kinds of information. IPLD data in IPFS is naturally a DAG. More about DAG on Wikipedia (opens new window).
# DAG-JSON
DAG-JSON is a codec that implements the IPLD Data Model (opens new window) as JSON, plus some additional conventions for encoding links, which it does by claiming certain specific structures of map and assigning them this meaning. DAG-CBOR also adds a "link" type using a CBOR tag, to bring it in line with the IPLD Data Model. More about DAG-JSON (opens new window)
# DAG-JOSE
DAG-JOSE is a codec that defines CBOR serialization for JOSE, a standard for signing and encrypting objects. More in DAG-JOSE specification (opens new window)
# DAG-CBOR
DAG-CBOR is a codec that implements the IPLD Data Model (opens new window) as a subset of CBOR, plus some additional constraints for hash consistent representations. DAG-CBOR also adds a "link" type using a CBOR tag, to bring it in line with the IPLD Data Model. More about DAG-CBOR (opens new window)
# DAG-PB
DAG-PB is a codec that implements a very small subset of the IPLD Data Model (opens new window) in a particular set of Protobuf messages used in IPFS for defining how UnixFSv1 data is serialized. More about DAG-PB (opens new window)
# Data model
Did you mean IPLD Data Model (opens new window)?
# DataStore
The Datastore is the on-disk storage system used by an IPFS node. Configuration parameters control the location, size, construction, and operation of the datastore. More about Datastore (opens new window)
# DCUtR
Direct Connection Upgrade through Relay (DCUtR) protocol enables hole punching for NAT traversal when port forwarding is not possible. A peer will coordinate with the counterparty using a relayed connection, to upgrade to a direct connection through a NAT/firewall whenever possible. More about DCUtR (opens new window)
# Delegated routing
Delegated routing is a mechanism by which IPFS implementations can offload content routing, peer routing, and naming (IPNS) to another process/server. The most widely adopted vendor-agnostic spec for delegated routing is the Delegated Routing V1 HTTP API (opens new window) with public utility instance at delegated-ipfs.dev/routing/v1.
Delegated routing is useful in browsers and other constrained environments where it's infeasible to be a DHT client/server. More broadly, it enables experimentation and innovation in content routing while maintaining interoperability and modularity.
# DHT
A Distributed Hash Table (DHT) is a distributed key-value store where keys are cryptographic hashes. In IPFS, each peer is responsible for a subset of the IPFS DHT. More about DHT
# DMT
Short for Data Model Tree, a term coined by the IPLD team. More about DMT in IPLD docs (opens new window)
# Dialing
Dialing is a function of the IPFS networking layer in libp2p, wherein a connection is opened to another peer. Together, an implementation of dialing and listening forms a transport.
# DNSAddr
DNSAddr is a protocol for publishing multiple Multiaddrs on DNS name. DNSAddr itself is a valid Multiaddr that looks like /dnsaddr/bootstrap.libp2p.io. Can be used for scaling, dynamic bootstrapping, or act as an additional content routing hint for DNSLink websites. More about DNSAddr (opens new window)
# DNSLink
DNSLink is a protocol to link content and services directly from DNS. A DNSLink address looks like an IPNS address, but it uses a domain name instead of a hashed public key, like /ipns/en.wikipedia-on-ipfs.org. More about DNSLink (opens new window)
# DWeb
The Decentralized Web (DWeb) looks like today's World Wide Web, but it is built with new underlying technologies that support decentralization. It is much harder for any single entity (like a government or terrorist group) to take down any single webpage, website, or service, either by accident or on purpose.
# E
# F
# Filestore
An experimental data store in Kubo. Used when --nocopy is passed to ipfs add. It stores the UnixFS data components of blocks as files on the file system instead of as blocks. This allows adding content to IPFS without duplicating the content in the IPFS datastore. More about Filestore experiment (opens new window)
# G
# Gateway
An IPFS Gateway is an HTTP server that acts as a bridge between web browsers and IPFS. Through a gateway, users can browse files and websites stored in IPFS as if they were stored on a HTTP web server. Most commonly, an IPFS Gateway is an IPFS node that also exposes an HTTP IPFS Gateway endpoint. See more about Gateway, addressing IPFS on the web, and HTTP Gateway specifications (opens new window)
# Garbage Collection
Garbage Collection (GC) is the process within each IPFS node of clearing out cached files and blocks. Nodes need to clear out previously cached resources to make room for new resources. Pinned resources are never deleted.
# GO-IPFS
Old name of Kubo.
# Graph
In computer science, a Graph is an abstract data type from the field of graph theory within mathematics. The Merkle-DAG used in IPFS is a specialized graph.
# Graphsync
Graphsync is a legacy content replication protocol, similar to Bitswap, but focusing on graphs rather than blocks. It is not supported by Kubo due to protocol complexity, and IPIP-402 (opens new window) providing a simpler way of synchronizing partial DAGs. More about Graphsync (opens new window)
# H
# HAMT-sharding
The sharding technique used for sharding big UnixFS directories. It leverages properties of hash array mapped tries (HAMT). More about HAMT (opens new window).
# Hash
A Cryptographic Hash is a function that takes some arbitrary input (content) and returns a fixed-length value. The exact same input data will always generate the same hash as output. There are numerous hash algorithms. More about Hash
# Helia
A lean, modular, and modern implementation of IPFS for the JS and browser environments that supersedes js-ipfs. Learn more at https://github.com/ipfs/helia (opens new window).
# Hole punching
A technique for NAT or firewall traversal that relies on coordinated simultaneous connections. Used when port forwarding is not possible. See DCUtR
# I
# Information Space
Information Space is the set of concepts, and relations among them, held by an information system. This can be thought of as a conceptual framework or tool for studying how knowledge and information are codified, abstracted, and diffused through a social system. More about Information Space (opens new window)
# IPFS Desktop
An unobtrusive and user-friendly desktop application for IPFS on Windows, macOS and Linux. Uses Kubo implementation as IPFS backend. See: Install the IPFS Desktop App.
# IPFS Mainnet
See Mainnet.
# IPLD
The InterPlanetary Linked Data (IPLD) model is a set of specifications in support of decentralized data structures for the content-addressable web. Key features are interoperable protocols, easily upgradeable, backward compatible. A single namespace for all hash-based protocols. More about IPLD (opens new window)
# IPNI
The InterPlanetary Network Indexer (IPNI), also referred to as Network Indexer, indexer and IPNI, enables quick and efficient search of content-addressable data. IPNI is designed to improve the performance and efficiency of IPFS by providing an alternate method of content routing to the Amino DHT. More about IPNI
# IPNS
The InterPlanetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. IPNS allows for publishing the latest version of any IPFS content, even though the underlying IPFS hash has changed. More about IPNS
# J
# JS-IPFS
A legacy implementation of IPFS written entirely in JavaScript. The js-ipfs is deprecated (opens new window) and superseded by Helia.
# JSON
JavaScript Object Notation (JSON) is a lightweight data-interchange format. JSON is a text format that is completely language independent, human-readable, and easy to parse and generate. More about JSON (opens new window)
# K
# Kubo
Kubo (previously known as go-ipfs) is the earliest and most widely used implementation of IPFS, written in Go. It runs on servers and user machines with full IPFS capabilities. Install IPFS Kubo or see Kubo README (opens new window).
# L
# LAN
Local Area Network (LAN) is a type of (usually private) computer network that covers a limited area. More about LAN (opens new window)
# Leaf
A Leaf is a node of a graph that doesn't link to any other node. This is opposed to a root.
# libp2p
The libp2p project is a modular system of protocols, specifications, and libraries that enable the development of peer-to-peer network applications. It is an essential component of IPFS. More about libp2p (opens new window)
# Listening
Listening is a function of the IPFS networking layer in libp2p, wherein an incoming connection is accepted from another peer. Together, an implementation of dialing and listening forms a transport.
# Link
In IPFS and IPLD, a link usually means a pointer to some CID.
# M
# Mainnet
IPFS Mainnet is a term used to describe the default or "main" public network that most IPFS implementations connect to by default. Most IPFS implementations (opens new window) were designed to work with Mainnet (but some can be configured instead to form a private swarm). Mainnet IPFS nodes typically join the Amino DHT for content routing with the help of the Bootstrap nodes, rely on Bitswap for data transfer, UnixFS for encoding files and directories, and typically expose an IPFS Gateway. This has mostly been assumed for the IPFS network. Nonetheless, IPFS Mainnet is a useful distinction in a world of many IPFS implementations with varying degrees of interoperability.
# Merkle-DAG
The Merkle-DAG is a computer science data structure used at the core of IPFS files/block storage. Merkle-DAGs create a hash to their content, known as a Content Identifier. More about Merkle-DAG
# Merkle Forest
Merkle Forest is a phrase coined to describe the distributed, authenticated, hash-linked data structures (Merkle trees) running technologies like Bitcoin, Ethereum, git, and BitTorrent. In this way, IPFS is a forest of linked Merkle trees. More about Merkle Forest (opens new window)
# Merkle Tree
A Merkle Tree is a specific type of hash tree used in cryptography and computer science, allowing efficient and secure verification of the contents of large data structures. Named after Ralph Merkle, who patented it in 1979. More about Merkle Tree (opens new window)
# MFS
The Mutable File System (MFS) is a tool built into IPFS that lets you treat files like a normal name-based filesystem. You may add, edit, and remove MFS files while all link updates and hashes are taken care of for you. More about MFS
# Multiaddr
Multiaddr is a way to create self-describing, composable and future-proof network addresses. In libp2p, it is used in peer addressing. To learn more read Addressing in libp2p → (opens new window) and Multiaddr Specification → (opens new window)
# Multibase
Multibase is a protocol for disambiguating the encoding of base-encoded (e.g. base32, base36, base64, base58, etc.) binary appearing in text. In IPFS, it is used as a prefix specifying the encoding used for the remainder of the CID. More about Multibase (opens new window)
# Multicodec
Multicodec is an identifier indicating the format of the target content. It helps people and software know how to interpret that content after it has been fetched. In IPFS, it is backed by an agreed-upon codec table. Multicodecs are designed for use in binary representations, such as keys or identifiers (i.e. CIDv1). More about Multicodec (opens new window)
# Multihash
Multihash is a protocol for differentiating outputs from various well-established hash functions, addressing size and encoding considerations. It is useful to write applications that future-proof their use of hashes, and it allows multiple hash functions to coexist. More about Multihash (opens new window).
# Multiformats
The Multiformats project is a collection of protocols that aim to future-proof systems today. A key element is enhancing format values with self-description. This allows for interoperability, protocol agility, and promotes extensibility. More about Multiformats (opens new window) and Multihash (opens new window)
# Multiplexer
Multiplexing allows for the creation of multiple “virtual” connections within a single libp2p connection. More about Stream Multiplexing in libp2p docs (opens new window)
# Mplex
mplex is a deprecated stream multiplexer that was designed in the early days of libp2p. More about mplex (opens new window)
# N
# NAT
Network Address Translation (NAT) enables communication between two networks by mapping IP addresses from one to another. Many consumer routers provide NAT service to allow multiple devices in local network (LAN) to access the internet (WAN) through a single public IP address. More about NAT (opens new window)
# Node
In IPFS, a node or peer is the IPFS program that you run on your local computer to store files and then connect to the IPFS network. See Nodes.
# Node (in graphs)
In an IPLD graph context, a node is a point that may be linked to by other nodes using edges or links.
For example, in a family tree each person is a node, while each branch connecting one person to another is an edge.
# O
# P
# Path/Address
A Path/Address is the method within IPFS of referencing content on the web. Addresses for content are path-like; they are components separated by slashes. More about Path/Address
# Peer
In system architecture, a Peer is an equal player in the peer-to-peer model of decentralization, as opposed to the client-server model of centralization. See also Peer as Node
# Peer routing
Peer routing is the process of discovering the network route or address for a network peer using various methods. The primary peer routing mechanism in IPFS is a distributed hash table that uses the Kademlia routing algorithm to efficiently locate peers. However, other methods, like local discovery, are also used. Learn more in the libp2p documentation (opens new window).
# Peer ID
A Peer ID is how each unique IPFS node is identified on the network. The Peer ID is created when the IPFS node is initialized and is essentially a cryptographic hash of the node's public key. More about Peer ID
# Pinning
Pinning is the method of telling an IPFS node that particular data is important and so it will never be removed from that node's cache. To learn more, start by understanding persistence, permanence, and pinning; then, see how to add local pin and read what remote pins are.
# Pinning Service API
A vendor-agnostic API specification (opens new window) that anyone can implement to provide a service for remote pinning.
# Preload node
Part of the process of making a UnixFS DAG publicly available via the preload node's wantlist, causing it to fetch data. Other nodes requesting the content can then resolve it from the preload node using Bitswap, as the data is now present in the preload node’s blockstore. See Nodes > Preload.
# Protobuf
Protocol Buffers (Protobuf) is a free and open-source cross-platform data format used to serialize structured data. IPFS uses it in DAG-PB. More about Protocol Buffers (opens new window)
# Pubsub
Publish-subscribe (Pubsub) is an experimental feature in IPFS. Publishers send messages classified by topic or content, and subscribers receive only the messages they are interested in. More about Pubsub (opens new window)
# Q
# QUIC
QUIC (/quic-v1) is one of libp2p transport protocols. It provides an always-encrypted, stream-multiplexed connection built on top of UDP. More about QUIC in libp2p (opens new window)
# R
# Relay node
A means to establish connectivity between libp2p nodes (e.g., IPFS nodes) that wouldn't otherwise be able to establish a direct connection to each other. This may be due to nodes that are behind NAT (Network Address Translation), reverse proxies, firewalls, etc. See Nodes > Relay and libp2p docs about Circuit Relay (opens new window).
# Remote Pinning
A variant of pinning that uses a third-party service to ensure that data persists on IPFS, even when your local node goes offline or your local copy of data is deleted during garbage collection. More about working with remote pinning services.
# Repo
The Repository (Repo) is a directory where IPFS stores all its settings and internal data. In Kubo it is created with the ipfs init command. More about Repo in Kubo
# Root
A root is a node in a graph that links to at least one other node. In an IPLD graph, roots are used to aggregate multiple chunks of a file together.
If you have a 600 KiB file A, it can be split into 3 chunks B, C, and D since the default block size of IPFS is 256 KiB. The node A that links to each of these three chunks is the root. The CID of this root is what IPFS shows you as the CID of the file.
A
|
-------------
| | |
B C D
# S
# Schemas
In IPFS, IPLD Schemas are a system for describing data with structural types. More about IPLD Schemas (opens new window)
# Selectors
IPLD selectors are a form of graph query over IPLD data. They can also be thought of as a way to specify a traversal. More about IPLD Selectors (opens new window)
# SFS
A Self-certifying File System (SFS) is a distributed file system that doesn't require special permissions for data exchange. It is self-certifying because data served to a client is authenticated by the file name (which is signed by the server). More about SFS (opens new window)
# Sharding
An introduction of horizontal partition of data in a database or a data structure. The main purpose is to spread load and improve performance. An example of sharding in IPFS is HAMT-sharding of big UnixFS directories.
# Signing (Cryptographic)
The signing of data cryptographically allows for trusting of data from untrusted sources. Cryptographically signed values can be passed through an untrusted channel, and any tampering of the data can be detected. More about Digital signature (opens new window)
# Substrate
A vocabulary term in IPLD, related to ADLs. More in IPLD glossary (opens new window)
# Swarm
Swarm is a term for the network of IPFS peers with which your local node has connections. Swarm addresses are addresses that your local node will listen on for connections from other IPFS peers.
# Switch
In libp2p, a switch is a component responsible for composing multiple transports into a single interface, allowing application code to dial peers without having to specify which transport to use.
Switches also coordinate the connection upgrade process, which promotes a raw connection from the transport layer into one that supports protocol negotiation (opens new window), stream multiplexing, and secure communications.
Sometimes called swarm for historical reasons.
# T
# Transport
In libp2p, transport refers to the technology that lets us move data from one machine to another. This may be a TCP, UDP (QUIC) network, a WebSocket connection in a browser, or anything else capable of implementing the transport interface. More about libp2p transports (opens new window)
# Traversal
In IPLD, the act of walking across the Data Model. More in IPLD glossary (opens new window)
# U
# UnixFS
The Unix File System (UnixFS) is the data format used to represent files and all their links and metadata in IPFS. It is loosely based on how files work in Unix. Adding a file to IPFS creates a block, or a tree of blocks, in the UnixFS format and protects it from being garbage-collected. More about UnixFS
# Urlstore
An experimental data store in Kubo similar to filestore, but it retrieves blocks contents via a HTTP URL instead of a local filesystem. More about urlstore experiment (opens new window)
# V
# W
# WAN
Wide Area Network (WAN) is a type of (usually public) computer network that spans over a large geographic area. More about WAN (opens new window)
# WebRTC
WebRTC (Web Real-Time Communications) is a framework for real-time communication and in libp2p is used to establish browser-to-server and browser-to-browser connections between applications. Libp2p supports WebRTC as multiple transports (/webrtc, /webrtc-direct). More about WebRTC in libp2p (opens new window)
# WebSocket
WebSockets are a way for web applications to maintain bidirectional communications with server-side processes, and are one of transports supported by libp2p (/ws). More about libp2p WebSockets support (opens new window)
# WebTransport
WebTransport is a new specification that uses QUIC to offer an alternative to WebSocket. Conceptually, it can be considered WebSocket over QUIC. Libp2p supports is indicated by /webtransport Multiaddr. More about WebTransport in libp2p (opens new window)
# X
# Y
# Yamux
Yamux (Yet another Multiplexer) is a powerful stream multiplexer used in libp2p. More about Yamux in libp2p docs (opens new window)