feat: Service worker configuration

[SgtPooki]

Consolidating information from a slack thread:

I’ve been thinking about adding a configuration page to the service worker gateway, so folks can configure their own gateways/routers/etc, similar to ipfs-companion, but it would be accessible via the main page of the service-worker-gateway. any interest in that….?

---

What config?

What should we be able to configure?

The configuration page at deployed-sw-gateway.example.com root should allow the user to

See

• build version

Modify

• trustless gateways
• delegated routing endpoints
• DoH resolvers used
• an option to trigger worker reload on all subdomains (maybe via cookie mentioned below)

Potential solutions

Cookies

We shouldn't allow much control via a cookie because of the damage dApps on other subdomains could cause.

dApps could purposefully override trustless-gateways & other settings. See https://www.rfc-editor.org/rfc/rfc6265#section-8.6:

The foo.example.com server can set a cookie with a Domain attribute of "example.com" (possibly overwriting an existing "example.com" cookie set by bar.example.com), and the user agent will include that cookie in HTTP requests to bar.example.com. In the worst case, bar.example.com will be unable to distinguish this cookie from a cookie it set itself. The foo.example.com server might be able to leverage this ability to mount an attack against bar.example.com.

from @lidel

I think it is better to do things correctly and limit cookie only as a blunt flag, at most for triggering reload, dont pass any sensitive config

iFrame message passing

We should be able to do this since the configuration could be writable only from the root, and would be read-only from subdomains.

### Tasks
- [ ] import/export of config as json file
- [ ] display default providers
- [ ] allow configuring dns resolvers
- [ ] change gateways/routers input from json to input with list items of configured gateways (trash icon - click to remove)
- [ ] reset config to default (to allow users to save themselves if they bork things)

[lidel]

When it comes to UI, would be good to make something that looks good on mobile, so we have less work when we are ready to ship PWA (https://github.com/ipfs-shipyard/helia-service-worker-gateway/issues/21)

[SgtPooki]

w.r.t. a slack thread: https://ipshipyard.slack.com/archives/C046HDAHA13/p1708532852533929

I am having an issue with https://github.com/ipfs-shipyard/helia-service-worker-gateway heliaFetch error: No hasher configured for multihash code 0xb220, please configure one. You can look up which hash this is at https://github.com/multiformats/multicodec/blob/master/table.csv It is the hash blake2b-256 in that tablehow can it be added?

---

would it be a dumb idea to allow hashers to be added via ESM CDN import on the service-worker config page?

Users could add entries similar to how they do on codepen, except in the service-worker configuration page, using esm.sh or other esm providing CDN, and we would load them similar to how we do in ipld-explorer-components at https://github.com/ipfs/ipld-explorer-components/blob/master/src/lib/init-helia.ts#L36 and https://github.com/ipfs/ipld-explorer-components/blob/master/src/lib/hash-importer.ts#L16

It looks like dynamic import is not currently available: https://github.com/w3c/ServiceWorker/issues/1585, but if it were, this could be really interesting.

Regardless, we should have a discussion somewhere about how to decide which default hashers to support with our "blessed" deployment of the service-worker-gateway. Also, we should add some documentation around how users should be able to deploy their own with their own hashers.

If we deployed this as a workbox plugin or ServiceWorker library, users could add hashers fairly easily without forking.

[SgtPooki]

@lidel @aschmahmann a the configuration page is mostly ready other than preferences on how/when we're rendering it: https://github.com/ipfs-shipyard/helia-service-worker-gateway/pull/24#issuecomment-1961908895

[SgtPooki]

The configuration page exists and is working well except for configuring dns resolvers. Do we want to add that in before calling this done?

Also, there was recent talk with @lidel about adding in badbits toggling, but that may be handled by delegated router

[2color]

The configuration page exists and is working well except for configuring dns resolvers. Do we want to add that in before calling this done?

I think so.

Another thing we're missing here is showing the default configuration on the page.

[SgtPooki]

I think we should show the default config too.