Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/ipfs/service-worker-gateway
Experimental IPFS Gateway implemented in Service Worker
https://github.com/ipfs/service-worker-gateway
helia ipfs ipfs-gateway ipfs-helia service-worker typescript
Last synced: 4 days ago
JSON representation
Experimental IPFS Gateway implemented in Service Worker
- Host: GitHub
- URL: https://github.com/ipfs/service-worker-gateway
- Owner: ipfs
- License: other
- Created: 2023-03-31T18:34:49.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2024-05-22T10:34:55.000Z (5 months ago)
- Last Synced: 2024-05-22T14:22:12.200Z (5 months ago)
- Topics: helia, ipfs, ipfs-gateway, ipfs-helia, service-worker, typescript
- Language: TypeScript
- Homepage: https://inbrowser.dev
- Size: 9.29 MB
- Stars: 16
- Watchers: 9
- Forks: 7
- Open Issues: 36
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- License: LICENSE
Awesome Lists containing this project
README
Service Worker IPFS Gateway
Decentralizing IPFS Gateways by verifying hashes in the user's browser.
## About
This project demonstrates
the use of [Helia](https://github.com/ipfs/helia) (IPFS implementation in JS)
and the [`verified-fetch` library](https://github.com/ipfs/helia-verified-fetch)
([Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API) for IPFS)
within a [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API)
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`](https://developer.mozilla.org/en-US/docs/Web/API/Response) objects
to the browser.
It functions as an IPFS gateway within the browser, offering enhanced security
([hash verification](https://docs.ipfs.tech/concepts/content-addressing/)
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.
### 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
- 🚧 **WIP:** Web interface for adjusting routing and retrieval settings.
- 🚧 **WIP:** [Trustless](https://docs.ipfs.tech/reference/http/gateway/#trustless-verifiable-retrieval) content retrieval from multiple HTTP gateways.
- 🚧 **WIP:** Support for [Web Gateway](https://specs.ipfs.tech/http-gateways/) feature set for website hosting (`index.html`, [web pathing](https://github.com/ipfs/specs/issues/432), `_redirects`).
- 🚧 **Future:** [HTTP Routing V1](https://specs.ipfs.tech/routing/http-routing-v1/) (`/routing/v1`) client for discovering additional direct content providers.
- 🚧 **Future:** [Denylist](https://specs.ipfs.tech/compact-denylist-format/) support for operators of public nodes.
## Usage
### Running locally
You can build and run the project locally:
```console
> npm ci
> npm start
```
Now open your browser at `http://sw.localhost:3000`
As you type in a content path, you will be redirected to appropriate URL (typically that means [subdomain style resolution](https://docs.ipfs.tech/how-to/gateway-best-practices/#use-subdomain-gateway-resolution-for-origin-isolation)).
For more information about local development setup, see [/docs/DEVELOPMENT.md](/docs/DEVELOPMENT.md).
### Try hosted instance
We provide a public good instance of this projct configured to run in [subdomain mode](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#subdomain-gateway),
aiming to be a drop-in replacement for `dweb.link`:
- 🚧 **WIP: alpha quality** https://inbrowser.link hosts the `release` branch, with a stable [release](https://github.com/ipfs/service-worker-gateway/releases)
- 🚧 **WIP: alpha quality** https://inbrowser.dev hosts the `staging` branch with development / testing version
There is also an instance running in [path mode](https://docs.ipfs.tech/how-to/address-ipfs-on-web/#path-gateway),
aiming to be a drop-in replacement for `ipfs.io`:
- 🚧 **WIP: alpha quality** https://ipfs-service-worker-gateway.pages.dev hosts the `release` branch, with a stable [release](https://github.com/ipfs/service-worker-gateway/releases)
- 🚧 **WIP: alpha quality** https://staging.ipfs-service-worker-gateway.pages.dev hosts the `staging` branch with development / testing version
#### Updating `production` and `staging`
Make a PR to the respective branch. Once it is merged, new version will be
deployed. The process takes between 1 and 5 minutes.
## License
This project is dual-licensed under
`SPDX-License-Identifier: Apache-2.0 OR MIT`
See [LICENSE](./LICENSE) for more details.