Make WebRTC usable as a backend for Service Workers to fulfill requests from a peer-to-peer network

[interfect]

This is the other half of the WebRTC spec issue with the same name: w3c/webrtc-pc#2553

People trying to use WebRTC to spin up peer-to-peer network nodes in the browser are running into trouble attaching the peer-to-peer capabilities of WebRTC to the request-handling capabilities of ServiceWorker.

In addition to making the API available to the Service Worker context, as tracked by the issue on the WebRTC spec, the section of the Service Worker spec on worker lifetime would need to be revised. It currently says:

The lifetime of a service worker is tied to the execution lifetime of events and not references held by service worker clients to the ServiceWorker object.
A user agent may terminate service workers at any time it:

• Has no event to handle.
• Detects abnormal operation: such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events.

Since receiving events from peers isn't exactly abnormal operation (in the same way that repeated setTimeout() would be), but we'd still want to allow the worker to shut down while other peers are talking to it, this section would need to be revised to allow the user agent to kill the worker in more circumstances.

Additionally, to make the peer-to-peer-node-in-service-worker use case really work well, the Service Worker needs to be able to expect to have a longer lifetime than just that required to handle a single request (because a peer-to-peer network is no good if nobody can seed data back after downloading it). I would recommend that the spec suggest that a service worker instance be allowed to persist as long as any of its controlled tabs are open, and as long as it is serving a request for any file being downloaded to disk by the user agent. This buys the site very little it couldn't get by just embedding JS on the page in terms of the ability to use memory and drain battery, but provides the nice ergonomic Service Worker interface for handling requests.

It's unclear right now how a service worker fulfilling a very long running request ought to be handled. When fulfilling a request with another HTTP request, the service worker sets up the download and gets out of the way. With WebRTC in the mix, the Service Worker might want to, say, spend an hour constructing a large download from pieces from peers and stream it piece by piece into the response. There may be other parts of the spec that need to be revised to contemplate gigabyte-scale requests moving through nontrivial processing in the Service Worker before being saved to disk by the user agent.

[interfect]

It looks like the WebRTC people want to bump exposing the API to Service Workers to the next major version. But as I describe in w3c/webrtc-nv-use-cases#60 the next major version looks like it might already have decided to expose the API to Service Workers, which does raise the question of what that should mean for worker lifetimes.

[jimmywarting]

I suppose this new issue #1566 is tackling the workers lifetime. Guess it will mean that browser will respectfully so honer the use of waitUntil promises are resolved and not forcefully terminate the worker as long as there is any open tab to that origin who owns it. will basically mean that we will now have two kind of keepalive handles - one that we can control as long as there is any open window and the other that browser will use when there is no controlling window that takes priority over the first one.

if i have understood it correctly