InterPlanetary File System

Content-addressed, peer-to-peer protocol that enables data to be identified, discovered and retrieved independently of where it is stored

Amiar

9/29/20266 min read

When we open a file on the Web, we usually think about where that file is.

For example:

https://example.com/photo.jpg

The address tells our browser where to go.

The InterPlanetary File System — IPFS — starts from a different question:

What content am I looking for?

That small change in perspective has important consequences.

From location to content

Traditional Web addresses are mainly location-based.

If the server moves the file, the address may stop working. If the domain disappears, the address may become useless. If the same file is copied somewhere else, the new copy has a different URL.

IPFS uses content addressing instead.

Instead of identifying content by where it is stored, IPFS gives it an identifier derived from the content itself.

This identifier is called a CID — Content Identifier.

Conceptually:

Traditional Web:
Address → where to find something

IPFS:
CID → what the content is

The same content can therefore be retrieved from different providers without changing its CID.

Cryptography makes this possible

The foundation is cryptographic hashing.

A hash function takes data and produces a short value derived from the data:

Content → Hash

If even a small part of the content changes, the resulting hash changes.

So, conceptually:

A → H(A)

but:

A → B

means:

H(A) ≠ H(B)

This gives us a way to identify content through properties of the content itself.

A CID is more than a file hash. IPFS can represent content using blocks and different data formats, and the CID also carries information about how the referenced content should be interpreted.

The essential idea is simple:

the CID identifies the content itself.

But where is the file?

A CID tells us what content we want. It does not tell us which computer currently has a copy.

IPFS therefore needs a way to discover providers.

Its peer-to-peer network can discover peers able to provide particular content. One mechanism involved in this process is the Distributed Hash Table (DHT).

Conceptually:

CID → find a provider → retrieve the content

Different peers can provide the same content, so no single computer has to be treated as its permanent home.

This is one of the defining characteristics of IPFS: the network can locate available providers based on the content being requested.

Finding content is not the same as searching the Web

IPFS is not a search engine.

If you know the CID, you can ask the network for that specific content.

But IPFS does not automatically answer questions such as:

“Find me the best photographs of Lisbon.”

That is a different problem.

Search engines organise information so that humans can discover things they do not already know how to identify.

IPFS is primarily concerned with retrieving known content by its identifier.

IPFS does not magically create permanence

Putting something on IPFS does not automatically mean that it will remain available forever.

A CID can continue to identify content even if nobody is currently providing it.

For content to remain retrievable, someone or something has to keep a copy available.

That can involve:

nodes operated by individuals or organisations;
pinning services;
distributed storage systems;
applications that keep their own content available;
multiple independent providers.

A useful distinction follows:

The CID identifies the content.
Infrastructure keeps it available.

A content identifier can therefore remain valid even when the content itself is temporarily unavailable.

IPFS is not a cloud drive

IPFS is not a decentralised version of Dropbox or Google Drive.

A cloud storage service normally gives you:

an account;
a place to store files;
a company operating the infrastructure;
access controls;
a service responsible for keeping your files available.

IPFS provides open protocols for:

identifying content;
discovering providers;
retrieving content;
distributing it across a network.

Applications can build storage services on top of IPFS, but the protocol itself does not require one company to be the permanent home of your files.

IPFS is not a blockchain

IPFS also solves a different problem from a blockchain.

A blockchain maintains shared state between participants who need to agree on it.

IPFS provides a way to identify and distribute content.

The two can nevertheless work together.

A blockchain might record a transaction or ownership state while an IPFS CID points to an image, document or other associated content.

For example:

Blockchain → records a reference

IPFS → provides the referenced content

This allows the two systems to complement each other without making the blockchain a general-purpose storage system.

Names, locations and content: DNS and IPFS

There is still a practical problem.

CIDs are useful for machines and applications, but they are not particularly memorable.

Try remembering:

bafybeigdyrzt5...

A human-readable domain name is much easier.

This is where DNS — the Domain Name System — becomes relevant.

DNS gives human-readable names to Internet resources and services.

For example:

example.com

can resolve to information that helps a computer find the corresponding Internet service.

IPFS provides DNSLink, which allows a DNS name to be associated with an IPFS address or an IPNS name through DNS records.

Conceptually:

example.com → IPFS → content

The domain provides a familiar name, while the IPFS reference identifies the content being served.

This creates a bridge between the conventional Web and IPFS without requiring the human-readable name to become the content identifier.

What about IPNS?

Content addressing has an interesting consequence: changing the content changes its CID.

That is useful when we want each version to have its own identity.

But websites and applications often need a stable reference that can point to the latest version.

IPFS provides IPNS — the InterPlanetary Name System — for this purpose.

An IPNS name can point to an IPFS CID and later be updated to point to a newer CID while the IPNS name remains the same.

A useful way to think about the three mechanisms is:

DNS → human-readable name

IPNS → stable, updateable reference

CID → specific content

They can therefore be combined without serving the same purpose.

IPFS and Nostr

This becomes particularly interesting alongside Nostr.

Nostr is primarily concerned with signed communication.

IPFS is concerned with content addressing and distribution.

Imagine someone publishing an article with several photographs.

The photographs can be stored on IPFS, each identified by its own CID.

A Nostr event can reference those CIDs and be signed by the author's key.

The two systems complement each other:

IPFS identifies the content.

Nostr identifies the actor making the statement about it.

The same photograph can therefore be referenced by many different publications, while each publication remains attributable to its own author.

This separation becomes useful when information starts to acquire relationships beyond simple storage and retrieval.

From content to relationships

Once statements can be attributed to identifiable actors, other relationships become possible.

Someone can publish a document.

Someone else can reference it.

Another person can verify its signature or provenance.

Another can recommend it.

And another can endorse it.

These are different actions, even though they may concern the same content.

Identity establishes who is acting.

A statement establishes what that identity says.

An endorsement expresses that an identified actor chooses to stand behind something.

Endorsement therefore builds on identity rather than existing independently of it.

These relationships do not have to belong to one protocol. They can be represented by different systems and connected where useful.

The bigger picture

IPFS is one part of a broader shift in how information can be organised.

A name can help us find something.

A CID can identify the exact content.

A network can provide it.

An IPNS name can point to changing content.

A cryptographic key can identify the actor behind a statement.

And relationships between identities, statements and content can be represented separately.

Nostr adds a social and communicative layer to this picture: not just what content exists, but who is making a statement about it.

From there, other relationships become possible:

DNS:
“Where should I go?”

IPFS:
“What exactly is this content?”

Nostr:
“Who signed this statement?”

None of these questions needs to be answered by the same system.

That is perhaps the most useful way to think about Web3.

It does not attempt to replace every part of the Internet.

It provides a different way to identify and retrieve content — one where the content can be addressed independently of the particular providers that make it available.