Add ServiceWorker support to plugin protocols

[pfrazee]

Service Workers will allow unhosted applications in plugin-protocols to serve pages dynamically. To support them, we need:

• A mechanism for plugin protocols to register support for Service Workers (this is disabled by default)
• A way to inject Web APIs into Service Workers. It's currently not possible, AFAIK, to inject custom APIs into iframes or workers using Electron.

[millette]

Waiting on electron issue 9663 I guess...

[pfrazee]

Yes, unfortunately.

[billiegoose]

Well shucks. I'm guessing this is why I'm getting:

Failed to register a ServiceWorker: No URL is associated with the caller's document.

when trying to use my cool webapp over dat://

[pfrazee]

Yeah it's a total shame. Having this and modules land in electron are going to be huge for dat.

[dcposch]

@pfrazee @feross and i almost got Wikipedia working in dat

currently, we're stuck on:

• we can't serve a Wikipedia dump from a dat directly, because dat itself does not support archives with 1m+ files ( dat share is slow with lots of files dat-ecosystem/dat#915 )
• we can't easily serve a Wikipedia dump from a zip file, because Beaker doesn't have ServiceWorkers yet. (if it did, we would intercept requests in the the SW. we already have a pure-JS ZIP file library working which turns requests for a file--say, wiki/Hypertext.html--into range requests into a giant dat-hosted ZIP file)

[billiegoose]

@dcposch That looks awesome! I want to use ServiceWorker for something similar. (Converting URL requests into git repository lookups.)

[pfrazee]

@dcposch oh clever solution. I've been poking around more in electron lately. I'll take another pass at fixing this. No promises, but I may get lucky.

[pfrazee]

(Even if we can get Service Workers to run on a custom protocol, I'm still unsure whether I'll be able to inject the APIs. We'll see.)

[dcposch]

@pfrazee have you heard of Muon?

It's Brave's fork of Electron. They have similar goals to Beaker--they too are developing their own chromium-based browser.

(They also have lots of developers and Scrooge McDuck-esque piles of money from their recent token sale... point is, Muon is actively developed :) )

issues fixed in Muon

• it tracks upstream Chromium faster than Electron
• it supports ServiceWorkers
• they did some security hardening. (unlike electron, muon is meant for rendering untrusted web content)
• probably other stuff too

as far as i can tell, it's a fork of and (mostly) a drop in replacement for electron. worth considering!

[pfrazee]

Yeah we're going to switch to Muon this year. Gotta get 0.8 out first.

[pfrazee]

AFAIK Electron already supports service workers, it just seems to be failing on custom protocols. Do we know for certain that muon supports service workers on custom protocols?

[pfrazee]

I spent a little more time with it in Electron. Even after I cheated my way around the current issue, SWs would randomly stall in installation and fail to intercept requests.

[dcposch]

Do we know for certain that muon supports service workers on custom protocols?

i'm not sure!

we added torrent support to Brave recently. i think the easiest way to test SW support in Muon would be to turn a ServiceWorker "hello world" app into a torrent, then visit magnet:... in Brave

[RangerMauve]

Once ServiceWorkers are enabled, are there any plans for Dat-specific APIs for them?

I think it would be super useful to have something similar to Push Notifications, but for Dat updates.

[pfrazee]

We can certainly look into that

[ikreymer]

Just wondering if there are any updates on this. Have a very exciting use case for this.
If service workers were supported, could now load and render web archive data directly in the browser from WARC files stored in Dat..