Add ServiceWorker support to plugin protocols about beaker HOT 16 CLOSED

@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-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)

from beaker.

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.

from beaker.

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

from beaker.

We can certainly look into that

from beaker.

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..

from beaker.

Waiting on electron issue 9663 I guess...

from beaker.

Yes, unfortunately.

from beaker.

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://

from beaker.

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

from beaker.

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

from beaker.

@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.

from beaker.

(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.)

from beaker.

@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!

from beaker.

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?

from beaker.

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.

from beaker.

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

from beaker.