I moved my blog from IPFS to a server

Original Article ↗ Hacker News Discussion ↗

Moving a personal blog from IPFS back to a conventional $10/month server prompts a broader look at why decentralized web hosting still struggles in practice. Commenters describe IPFS and related systems as resource-hungry, fragile to configure, and effectively recentralized around a few pinning and gateway providers, undermining promises of censorship resistance and resilience. Many still see value in p2p storage and naming for specific use cases (scientific data, NFTs, censorship-resistant sites), but argue that for small static websites, traditional hosting or simple CDNs remain more reliable and easier to operate.

IPFS as a web hosting platform

  • Many report the same issues as the article: content often not globally reachable, flaky gateways, and some users randomly unable to load assets.
  • Running a full IPFS node is described as resource‑hungry (CPU, RAM, file descriptors) and operationally fragile.
  • For low‑traffic blogs, needing to keep a pinning node online mostly negates the supposed decentralization benefits; if your node is down, your site is effectively down.
  • Some still use IPFS as a backing store for static assets behind Netlify/Vercel or similar, but availability remains “perplexing.”

Pinning, UX, and ecosystem gaps

  • A recurring complaint is that “add” vs “pin” semantics are confusing; earlier tooling made it easy to think you’d “put something on IPFS” without actually making it available.
  • Even when technically correct (e.g., ipfs add pinning by default), the mental model is considered poor compared to BitTorrent’s “download == seed by default.”
  • Lack of native ipfs:// support in browsers, reliance on a small number of gateways, and association with “Web3/coins” are viewed as adoption blockers.

Decentralization and P2P scalability

  • Several participants argue that “true” fully decentralized networks don’t scale; beyond a certain size, routing, discovery, and moderation all re‑introduce centralization or hierarchy.
  • Others counter with examples (Kademlia, small‑world networks, Freenet) that achieve logarithmic scaling without central servers, while acknowledging trade‑offs and complexity.
  • There’s broad agreement that most “decentralized” systems end up depending on some central services (bootstrapping nodes, trackers, gateways, pinning providers).

Blockchain, naming, and governance

  • Strong skepticism toward using blockchains for name resolution:
    • Blockchains only attest to what’s on‑chain; mapping to real‑world meaning still needs authorities or “oracles.”
    • Practical issues: chain size, need for resolvers, key loss, and handling disputes over names.
  • Proponents emphasize censorship resistance and user‑level sovereignty, seeing the inability to reassign names via courts as a feature, not a bug.
  • ENS/Namecoin/HNS are cited as examples; lack of browser integration and squatting reduce real‑world impact.

Use cases where IPFS‑like tech may fit

  • Better fits mentioned: scientific data DAGs, ML model weights, large shared datasets, and applications where nodes are always on and grid‑powered.
  • For mobile‑heavy, public web use, battery and bandwidth costs, legal exposure, and UX issues make traditional hosting or CDNs more attractive.

Alternatives and derivatives

  • Alternatives raised include BitTorrent/WebTorrent, Peertube, Peergos, Freenet (new and old designs), DAT, Secure Scuttlebutt, and newer projects like Iroh that reuse some ideas but change the model.
  • Some suggest that federation (email, ActivityPub/Mastodon) hits a more workable middle ground than either full centralization or maximalist P2P.