Concepts

A content identifier, or CID, is a label used to point to material in IPFS. It doesn’t indicate where the content is stored, but it forms a kind of address based on the content itself. CIDs are short, regardless of the size of their underlying content. CIDs are based on the content’s cryptographic hash. That means: Any difference in content will produce a different CID and The same piece of content added to two different IPFS nodes using the same settings will produce exactly the same CID.

DHTs What is a DHT? Distributed Hash Tables (DHTs) are distributed key-value stores where keys are cryptographic hashes. DHTs are distributed. Each “peer” (or “node”) is responsible for a subset of the DHT. When a peer receives a request, it either answers it, or the request is passed to another peer until a peer that can answer it is found. Depending on the implementation, a request not answered by the first node contacted can be: - forwarded from peer to peer, with the last peer contacting the requesting peer - forwarded from peer to peer, with the answer forwarded following the same path - answered with the contact information of a node that has better chances to be able to answer.

NOTE: The info below is a quick guide to DNSLink. For a more complete guide, including tutorials, usage examples and FAQs, check out dnslink.io. About DNSLink DNSLink uses DNS TXT records to map a domain name (like ipfs.io) to an IPFS address. Because you can edit your DNS records, you can use them to always point to the latest version of an object in IPFS (remember that an IPFS object’s address changes if you modify the object).

Hashes are functions that take some arbitrary input and return a fixed-length value. The particular value depends on the given hash algorithm in use, such as SHA-1 (used by Git), SHA-256, or BLAKE2, but a given hash algorithm always returns the same value for a given input. Have a look at the full list of hash functions for more. As an example, the input: Hello world would be represented by SHA-1 as:

Inter-Planetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. Since objects in IPFS are content-addressed, their address changes every time their content does. That’s useful for a variety of things, but it makes it hard to get the latest version of something. A name in IPNS is the hash of a public key. It is associated with a record containing information about the hash it links to that is signed by the corresponding private key.

A Direct Acyclic Graph (DAG)is a type of graph in which edges have direction and cycles are not allowed. For example, a linked list like A→B→C is an instance of a DAG where A references B and so on. We say that B is a child or a descendant of A, and that node A has a link to B. Conversely A is a parent of B. We call nodes that are not children to any other node in the DAG root nodes.

Because files in IPFS are content-addressed and immutable, they can be complicated to edit. Mutable File System (MFS) is a tool built into IPFS that lets you treat files like you would a normal name-based filesystem — you can add, remove, move, and edit MFS files and have all the work of updating links and hashes taken care of for you. MFS is accessed through the files commands in the IPFS CLI and API.

IPFS nodes treat the data they store like a cache, meaning that there is no guarantee that the data will continue to be stored. Pinning a CID tells an IPFS server that the data is important and mustn’t be thrown away. You should pin any content you consider important, to ensure that content is retained long-term. Since data important to someone else may not be important to you, pinning lets you have control over the disk space and data retention you need.

A file in IPFS isn’t just content. It might be too big to fit in a single block, so it needs metadata to link all its blocks together. It might be a symlink or a directory, so it needs metadata to link to other files. UnixFS is the data format used to represent files and all their links and metadata in IPFS, and is loosely based on how files work in Unix.