IPFS (InterPlanetary File System)

How IPFS works

The core innovation is content addressing. Traditional web URLs point to specific servers ("the file at server X, path /Y/Z"). IPFS addresses point to content directly via its hash:

• A file's address is its hash — a fingerprint of the content itself.
• Anyone with the file can serve it; the network doesn't care which server.
• Identical content has identical addresses, regardless of where it's stored.
• If the file changes, the hash changes; the new version has a new address.

This "content-addressable" model is fundamentally different from "location-addressable" HTTP. It enables several useful properties: deduplication, integrity verification, decentralized hosting.

How IPFS handles requests

When you request a file by its IPFS hash:

1. Your IPFS client checks if it has the file locally.
2. If not, it asks connected peers if they have it.
3. Peers either provide the file directly or relay the request further.
4. Once located, the file streams to your client and is cached.
5. The file's hash is verified against the request, ensuring you got what you asked for.

The peer-to-peer model means there's no single point of failure. As long as someone, somewhere has the file pinned and online, anyone can retrieve it.

Pinning and persistence

A common confusion: IPFS doesn't automatically host files forever.

• Pinning — explicitly keeping a file available on your node. Pinned content stays cached; unpinned content can be garbage-collected.
• Without pinning — files are temporary. They might be available on the network through whoever happens to have a recent copy, but no guarantee.

For NFT projects and dApps, pinning services are essential:

• Pinata — most popular pinning-as-a-service.
• Filebase, Web3.Storage, NFT.Storage — alternative pinning services.
• Self-hosted IPFS nodes — run your own pinning infrastructure.

Without proper pinning, "stored on IPFS" content can disappear over time as initial seeders go offline.

Where IPFS is used

Common applications:

• NFT metadata. Most NFTs store their metadata (image, traits, description) on IPFS, with the smart contract storing only the IPFS hash. Critical for NFT permanence.
• Decentralized website hosting. Some censorship-resistant projects host their frontends on IPFS.
• Content distribution. Large files distributed peer-to-peer.
• Distributed databases and indexers. Some systems use IPFS for content storage.

IPFS vs. Filecoin

Filecoin and IPFS are complementary:

• IPFS — the protocol for content-addressable storage. Free to use.
• Filecoin — incentive layer that pays storage providers to keep content available long-term. Paid economic guarantees.

Most IPFS use cases that need persistence eventually integrate with Filecoin or similar paid storage. The combined model is "store on IPFS for retrievability + Filecoin for persistence guarantees."

IPFS gateways

Most users don't run IPFS clients directly. They access IPFS through gateways:

• ipfs.io — public gateway run by Protocol Labs (IPFS's primary developer organization).
• Cloudflare IPFS gateway (cloudflare-ipfs.com) — high-performance gateway.
• Service-specific gateways — Pinata, NFT.Storage, others run their own.

Gateways expose IPFS content via regular HTTP URLs (https://ipfs.io/ipfs/QmHASH). This is convenient but reintroduces some centralization — if the gateway goes down, that specific URL becomes unavailable, though the content remains on IPFS itself.

Limitations

Several real issues:

• Performance. IPFS retrieval can be slow compared to centralized CDNs, especially for less-popular content.
• Reliability without pinning. Content can disappear if the original pinners go offline.
• Discovery. Finding specific content by hash works; finding "similar" or "related" content is hard.
• Mutable content. IPFS is fundamentally for immutable content. Mutable references require IPNS or external resolution layers.
• Privacy. Content stored on IPFS is publicly accessible; "private" data needs encryption before storage.

NFT metadata permanence

A specific concern for NFT collectors: not all "stored on IPFS" claims are equal.

• Properly pinned — content is held by reliable pinning services with redundancy.
• Pinned by the project only — depends on the project staying solvent and committed.
• Centralized fallback — many "IPFS" NFT collections actually serve metadata through centralized servers, with IPFS as a backup. If the centralized server goes down, the metadata may not actually be retrievable.

Sophisticated NFT collectors verify that pinning is genuinely robust before treating "IPFS storage" as permanent.

Alternatives

A few other content-addressable storage systems:

• Arweave — pay-once-store-forever model. Single payment endows perpetual storage. More expensive per byte but simpler operationally.
• Storj, Sia — competing decentralized storage networks.
• Web3.Storage — abstracted layer over IPFS and Filecoin.

For NFTs specifically, Arweave is increasingly preferred for true permanence — no ongoing pinning concerns. IPFS remains more flexible and broadly used.

Why IPFS matters

Despite limitations, IPFS represents a significant pattern:

• Content-addressable storage is genuinely useful for verifying integrity and decentralizing hosting.
• Most NFT and crypto-native infrastructure depends on it in some form.
• Censorship-resistant content distribution has working examples through IPFS.

The protocol isn't perfect, but it's the most widely-used decentralized storage layer in crypto and a meaningful part of the broader Web3 stack.

Practical advice

For NFT creators and collectors:

• Use established pinning services (Pinata, NFT.Storage, Filebase) rather than self-hosting alone.
• Verify metadata accessibility through multiple gateways periodically.
• For long-term preservation, consider Arweave or similar permanent-storage alternatives.
• Don't rely solely on project-team pinning — projects can fail or abandon their hosting.

For developers building on IPFS:

• Plan for pinning costs. Free tiers of services don't scale.
• Use multiple pinning providers for redundancy.
• Implement IPNS or similar mutable references if your application needs updateable content.
• Cache aggressively to reduce latency.

The honest assessment: IPFS works for many use cases when properly configured, but it requires more infrastructure thought than centralized storage. For applications where decentralization and content addressability matter, the trade-offs are usually worth it.