Using WebRTC peer-to-peer networks to back Service Workers

[interfect]

Currently all the use case document says about WebRTC-NV and workers is:

https://github.com/w3c/webrtc-nv-use-cases/blob/d053ca91165f9f522f6fc39ba3c10c5ce011b30e/index.html#L204-L208

https://github.com/w3c/webrtc-nv-use-cases/blob/d053ca91165f9f522f6fc39ba3c10c5ce011b30e/index.html#L310-L319

A lot of people over at https://github.com/w3c/webrtc-pc/issues/230 and related PRs have been asking for the machinery needed to effectively use WebRTC to build peer-to-peer networks in Service Workers specifically. The point of this is being able to fulfill requests for URLs by pulling them from a peer to peer network instead of going over HTTP. This would involve revising WebRTC so that the API is usable in Service Workers, and also revising Service Workers to clarify what the expected worker lifetime semantics should be for Service Workers that are maintaining WebRTC connections, so requests don't generally have to try and reconnect to the peer-to-peer network from scratch.

I opened an issue over on the current WebRTC spec recommending that the API be exposed to all forms of worker (https://github.com/w3c/webrtc-pc/issues/2553), but it seems like people are reluctant to revise 1.0 to have this feature, and sent it over here.

Making WebRTC work in Service Workers kind of fits into the "File Sharing" use case, especially this line:

https://github.com/w3c/webrtc-nv-use-cases/blob/d053ca91165f9f522f6fc39ba3c10c5ce011b30e/index.html#L175

But I think the part of N13 about supporting data exchange in "a worker" might need to change to list the types of workers that need access to the API explicitly, and include Service Workers.

There might also be room for an entire new use case focusing on peer-to-peer content distribution used to back a page or web application, instead of just on file sharing within the context of a video/voice conference between a few users (where an ordinary Web Worker would do).

Is it clear that N13 would require WebRTC to be available in Service Workers already? If not, should it be added there? Or should backing Service Worker fetches with a peer-to-peer network become an entire new use case section?

[ivelin]

Thanks for opening this issue, @interfect .

Another use case that can benefit from allowing webrtc access in service workers is enabling frontend frameworks like Vue/Vuetify to access remote IoT edge devices via standard html fetch() without worrying about all the mechanics of p2p connectivity.

https://webrtchacks.com/private-home-surveillance-with-the-webrtc-datachannel/

Additional benefit would be enabling service worker background sync over webrtc/http layer (as illustrated in the blog above). A PWA can asynchronously pull edge device data and make it available to users on demand. That would be better UX than the user having to wait for a remote edge device data pull when they open the app page.

[jimmywarting]

new semantic to the service worker allows for website to extend the lifetime of a service worker with a promise to live indefinitely (as long as there is any owning tab open to that service workers scope) it's similar to waitUntil i suppose...

anyhow, the (new?) waitUntil will therefor be respectful of the developers decision so folks don't have to abuse the lifetime with pinging a service worker with postMessages all the time. the hard (30s - 5m) time-to-live timer will kick in when all the tabs are closed

this makes it potentially very useful for us to have a WebRTC + DataChannel inside of a Service Worker that isn't terminated after a hard timeout