IPFS Gateway implemented in Service Worker
  • Cython 85%
  • TypeScript 14.2%
  • JavaScript 0.5%
  • HTML 0.2%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-09-01 15:42:29 +01:00
.github chore: use .net gw for fallback (#1193) 2026-08-20 18:50:20 +01:00
benchmark chore: fix benchmarks (#1174) 2026-07-28 12:15:59 +02:00
docs fix: reduce initial bundle size and improve load order (#1006) 2026-03-05 13:32:24 +01:00
img fix: restore logo (#1012) 2026-03-18 11:18:52 +01:00
public fix: cyclic reload from a poisoned cdn cache (#1156) 2026-07-10 14:03:20 +02:00
src fix: use ipfs-uri where available (#1194) 2026-08-27 16:13:15 +01:00
test fix: use ipfs-uri where available (#1194) 2026-08-27 16:13:15 +01:00
test-conformance fix: use ipfs-uri where available (#1194) 2026-08-27 16:13:15 +01:00
test-e2e chore: fix benchmarks (#1174) 2026-07-28 12:15:59 +02:00
types feat: Implement service worker and main-thread demo (#3) 2023-03-24 17:38:49 -07:00
.aegir.js fix: reduce initial bundle size and improve load order (#1006) 2026-03-05 13:32:24 +01:00
.gitattributes fix: dynamic subdomain gateway detection (#53) 2024-02-26 13:20:50 -08:00
.gitignore chore: add conformance testing (#924) 2025-12-17 12:56:30 +02:00
.nvmrc chore: update nvmrc 2026-02-20 15:28:03 +02:00
babel.config.json chore: fix build - runtime is broken 2023-03-17 15:58:03 -07:00
build.js fix: use iife instead of esm bundle (#1176) 2026-07-29 15:00:34 +02:00
CHANGELOG.md chore(main): release 3.4.15 (#1195) 2026-09-01 15:42:29 +01:00
eslint.config.js chore: add eslint config file (#1138) 2026-06-24 16:23:21 +02:00
FUNDING.json chore: Create FUNDING.json for OP RPF (#599) 2025-02-26 09:38:05 +01:00
LICENSE docs: readme revamp (#164) 2024-04-03 17:13:24 +02:00
LICENSE-APACHE chore: add permissive LICENSE.md (#154) 2024-03-27 15:16:56 +01:00
LICENSE-MIT chore: add permissive LICENSE.md (#154) 2024-03-27 15:16:56 +01:00
main.go fix: cyclic reload from a poisoned cdn cache (#1156) 2026-07-10 14:03:20 +02:00
package.json chore(main): release 3.4.15 (#1195) 2026-09-01 15:42:29 +01:00
playwright.config.js fix!: remove config page (#963) 2026-01-27 10:36:00 +01:00
README.md chore: use .net gw for fallback (#1193) 2026-08-20 18:50:20 +01:00
SECURITY.md chore: refresh issue templates and docs links 2026-08-06 16:38:54 +02:00
serve.ts deps: bump execa from 9.6.1 to 10.0.1 (#1180) 2026-08-16 15:39:21 +01:00
tsconfig.json deps: update to helia@7.x.x (#1145) 2026-07-03 15:48:46 +02:00


logo
Service Worker IPFS Gateway

Decentralizing IPFS Gateways by verifying hashes in the user's browser.

Official Part of IPFS Project Discourse Forum ci GitHub release


About

This project demonstrates the use of Helia (IPFS implementation in JS) and the verified-fetch library (Fetch API for IPFS) within a Service Worker to facilitate direct verified retrieval of content-addressed data.

A Service Worker is registered on the initial page load, and then intercepts HTTP requests for content stored on IPFS paths such as /ipfs/* (immutable) and /ipns/* (mutable) and returns Response objects to the browser.

It functions as an IPFS gateway within the browser, offering enhanced security (hash verification happens on end user's machine) and reliability (ability to use multiple sources of content-addressed blocks) without reliance on a single HTTP server for IPFS tasks.

This project was brought to you by the Shipyard team.

Goals

The main goals of this project are:

  • Enhancing the robustness of IPFS-based web hosting by eliminating reliance on a single HTTP backend.
    • Tasks such as fetching blocks from IPFS content providers (both peer-to-peer and HTTP), verifying that block hashes match the expected CID, and re-assembling blocks into deserialized bytes that can be rendered by the browser, all happens within the end user's machine.
  • Reducing the operational costs associated with running an HTTP backend.
    • By shifting the majority of data retrieval tasks to the user's browser, the backend hosting a website no longer needs to serve as a conduit for all of its data. This means that a gateway operator could potentially run a simple HTTP server on a Raspberry Pi, serving only small static HTML+JS files (<10MiB), while allowing all other operations to occur within the user's browser, with data fetched either peer-to-peer or from remote HTTP trustless gateways.
  • Improving JS tooling, IPFS specifications, and gateway-conformance tests.
    • By having to implement gateway semantics end-to-end we identify bugs and gaps, and improve quality of libraries, specifications, and interop tests.

Feature Set

  • 🔒 Trustless Retrieval client that fetches content directly from providers over HTTPS, Secure WebSockets, and other browser-compatible transports, using a fallback trustless gateway when direct retrieval is not possible.
  • 🌐 Service Worker running as a Web Gateway for website hosting (index.html, web pathing, _redirects).
  • 🧭 HTTP Routing V1 (/routing/v1) client for discovering content providers (via delegated-ipfs.dev).
  • 📡 DNSLink resolution via DNS-over-HTTPS (DoH).

Compliance with IPFS HTTP Gateway specifications is tested using the gateway-conformance test suite (the same suite used by Kubo and Rainbow).

Browser support

The gateway supports recent versions of all major web browsers.

It is built using modern Web APIs so needs a web browser kept up to date with the latest features and security patches.

If you see a notice asking you to update your browser, please do so.

Usage

Running locally

You can run the project locally:

> npm install
> npm start

Now open your browser and go to http://localhost:3000

The gateway runs exclusively in subdomain mode -- as you type in a content path, you will be redirected to an appropriate subdomain URL with Origin isolation.

For more information about local development setup, see ./docs/DEVELOPMENT.md.

Try hosted instance

We provide a public good instance of this project configured to run in subdomain mode, aiming to be a drop-in replacement for dweb.link:

For deployment details, see docs/DEVELOPMENT.md.

Manual Service Worker Deregistration

In some cases, you might want to manually unregister or remove the Helia service worker from your browser. This can be useful for debugging purposes or to ensure a clean state.

You can instruct the service worker to unregister itself by appending the ?ipfs-sw-unregister=true query parameter to the URL of any page controlled by the service worker.

For example, if the service worker is active for https://example.com, navigating to https://example.com/?ipfs-sw-unregister=true will cause the service worker to unregister itself and attempt to reload all controlled clients (browser tabs).

License

This project is dual-licensed under SPDX-License-Identifier: Apache-2.0 OR MIT

See LICENSE for more details.