IPFS shifts from centralized gateways to client-side retrieval
IPFS is transitioning from subsidizing centralized public gateways to supporting distributed infrastructure and client-side verification via service workers.
Summary
The IPFS project is changing how its core gateways, ipfs.io and dweb.link, operate by moving toward a service worker model. Instead of acting as central servers that fetch content, these gateways will now provide a service worker to the browser to enable direct peer-to-peer connections and local content verification. This shift aims to reduce re-centralization and focus resources on protocol specifications and interoperability.
Technical transition and migration
- Browser users will be redirected from ipfs.io and dweb.link to the service worker gateway at inbrowser.link.
- App developers using hotlinks for images or metadata are encouraged to migrate to @helia/verified-fetch or the Drop-In Service Worker.
- Backend services are advised to move away from public gateways in favor of self-hosted solutions like Rainbow, Someguy, or Kubo.
- Rate limiting has already begun on public gateways for hotlinked and backend traffic to encourage migration.
Why it matters
The move aims to return IPFS to its original peer-to-peer vision by reducing reliance on a few centralized public gateways and prioritizing protocol interoperability.
Original reference: blog.ipfs.tech →