A Short Explainer on IPFS
IPFS stands for InterPlanetary File System.
The name sounds dramatic, but the idea is simple:
IPFS is a way to store and load files by what they are, not where they live.
On the normal web, a URL usually points to a location:
https://example.com/image.png
That means: “go to this server and ask for this file.”
IPFS works differently. When you add a file or folder to IPFS, it gets a CID: a Content Identifier.
A CID is generated from the content itself. If the content changes, the CID changes too.
So instead of saying:
get this file from this server
IPFS says:
get the content with this CID
Why that matters
Location-based links can break.
A server can go offline. A company can shut down. A file can move. A domain can expire. The URL might still exist, but the thing it pointed to is gone.
IPFS tries to make content more portable.
If multiple nodes have the same content, they can all help serve it. You do not need to trust one exact server as the only place the file can come from. The CID lets you verify that the content you received is the content you asked for.
That makes IPFS useful for things like:
- static websites
- NFT metadata
- public datasets
- archives
- app assets
- decentralized apps
What “pinning” means
IPFS does not magically guarantee that every file stays online forever.
Someone still needs to store the data.
When people say they “pin” something to IPFS, they mean they are telling an IPFS node or pinning service to keep that content available and not garbage-collect it.
That is why apps often use services like Pinata, Filebase, or other IPFS pinning providers. They help keep uploaded content online.
So the practical model is:
upload file/folder → get CID → pin CID → share CID
How IPFS works with websites
A static website is just files:
index.html
styles.css
script.js
logo.png
If you upload that folder to IPFS, the folder gets a CID.
Then a gateway can serve it in a normal browser:
https://ipfs.io/ipfs/<CID>
or through a subdomain gateway:
https://<CID>.ipfs.<gateway>
Gateways are useful because most browsers do not load ipfs:// links natively yet. A gateway translates normal HTTP requests into IPFS retrieval behind the scenes.
How this connects to ENS
ENS names can store a contenthash record.
That record can point to an IPFS CID.
So if your ENS name points to an IPFS site, an ENS-aware gateway like eth.limo can resolve:
chrismg.eth.limo
into:
ENS name → contenthash → IPFS CID → website files
That is why IPFS is a natural fit for ENS websites.
Your .eth name becomes the human-readable name, and IPFS stores the site content.
The short version
IPFS is content-addressed storage for the web.
Instead of depending on one server location, content is identified by a CID derived from the content itself. If the content changes, the CID changes. If other nodes pin or cache the content, it can be retrieved from them too.
For static websites, IPFS gives you a simple primitive:
folder of files → CID → decentralized website
And when paired with ENS:
CID → contenthash → yourname.eth.limo
