ServiceWorker-like protocol handlers for WebExtensions

[lidel]

(this is placeholder issue, will be updated as we work on spec prototypes, discuss with vendors etc)

Problem

Currently (2023Q3):

1. The web platform supports registering custom protocol handlers via navigator.registerProtocolHandler.
2. WebExtensions in Firefox automate this and support registering custom protocol handlers via manifest.json/protocol_handlers
3. (somehow related) PWA manifest (at least in Firefox?) also automates this via protocol_handlers field

The downside in all the three cases above is that foo:// registered this way can ONLY do HTTP redirect to some other HTTP URL. There is no built-in way to return bytes to the renderer process directly.

Web platform has a way to return a synthetic byte response with custom headers: register a ServiceWorker to resolve requests for specific scope and create Response objects.

Problem? Currently there is no way to leverage ServiceWorker for resolving protocols registered via manifest.json/protocol_handlers. Only redirect-based handlers are supported. ServiceWorker support is missing.

Prototyping Solution

There is an opportunity to streamline the UX/DX around registering protocol handlers via manifest of extension (2) or PWA (3).

Both PWAs and WebExtensions (with Manifest V3) already have ServiceWorker capabilities, but we could focus on WebExtensions as it is safer environment with more clear boundary and UX around installation.

What is missing, is the ability for a protocol handler foo:// to be a scope for a ServiceWorker that takes care of fullfiling all requests sent to the foo:// scheme.

If we had that, browser extensions or PWAs would be able to fetch content-addressed content from ipfs:// and perform hash verification on the client, the way that benefits user the most.

IPFS Use Case is for WebExtension

• ipfs-companion WebExtension being able to use in-memory Helia (JS implementation of IPFS node) for resolving requests for IPFS content

References

• wip spec work https://darobin.github.io/proto-handler-reqs/
  • Mentioned during WECG at TPAC 2023 (notes)
  • W3C discussion: https://github.com/w3c/webextensions/issues/451

[lidel]

An important prerequisite for this work landed: automated testing of registerProtocolHandler Web API is now possible as part of Web Platform Tests (WPT):

• https://github.com/web-platform-tests/wpt/pull/35792 [ LANDED ]
• https://bugs.chromium.org/p/chromium/issues/detail?id=1359103#c11 [ FIXED ]

"Real" WebExtension handler will be built as improvement on top of abstractions like registerProtocolHandler Web API, and having solid testing setup for these early foundations enables future work to be protected with regression-tests too.

[SgtPooki]

Problem? Currently there is no way to leverage ServiceWorker for resolving protocols registered via manifest.json/protocol_handlers. Only redirect-based handlers are supported. ServiceWorker support is missing.

If we can handle redirects, then with https://github.com/ipfs-shipyard/service-worker-gateway we could simply redirect to inbrowser.tld

[lidel]

Yes, until we have better APIs, IPFS Companion will likely have a mode where it is using ServiceWorker on some public https:// server (with ability to self-host on own domain).