WebRTC and getUserMedia within Service Worker

[lewispham]

I wonder why WebRTC and getUserMedia can not be used inside Service Worker. Is this a matter of time? Or are there any unsolvable technical problems?

[feross]

👍

[wanderview]

As far as I can tell, neither of these is spec'd on workers of any kind, let alone SW. Also, having access to these in the background without a window open would seem to be something of a security/privacy issue for the user.

[feross]

neither of these is spec'd on workers of any kind

Which is what this issue is about :)

having access to these in the background without a window open would seem to be something of a security/privacy issue

Using WebRTC data channels in a worker is no different from a security/privacy perspective than using Websockets. There's no user permission prompt to open a WebRTC data channel.

[feross]

I'm not sure what @Tresdin meant by using getUserMedia in a worker – maybe he can clarify? It seems less useful than WebRTC data channels.

Data channels are basically drop-in replacements for Websockets, except they're peer-to-peer. Being able to open a WebRTC data channel would support the use case of "peer assisted delivery" for apps like PeerCDN.

[auchenberg]

👍

We need it to make functionality like this possible: https://twitter.com/auchenberg/status/602648208158756864

[wanderview]

I think you need to discuss this with the webrtc folks first. I'm not familiar enough with webrtc to know if there are reasons data channels are not exposed on workers. If they are willing to spec it then I think the ServiceWorkers would get it automatically by virtue of extending the Worker interface. (It might take some time to implement, of course.)

You can open a webrtc issue here:

https://github.com/w3c/webrtc-pc/issues

Or you could email their mailing list:

https://lists.w3.org/Archives/Public/public-webrtc/

[feross]

Issue opened: w3c/webrtc-pc#230

[lewispham]

@feross I agreed with your point that getUserMedia is less useful. But it is still mandatory for establishing a video/audio call.

@ALL Unfortunately, though using WebRTC data channels or WebSocket within Web Workers is a great idea, I still recommend not to use these APIs inside ServiceWorker due to its temporarily activated lifetime.

[wanderview]

@feross I agreed with your point that getUserMedia is less useful. But it is still mandatory for establishing a video/audio call.

How are you going to have a video call without a window to show the video in?

Is there a reason you can't use .openWindow() from the service worker and then do the video call in the window as you would normally?

[lewispham]

How are you going to have a video call without a window to show the video in?

I did not say that video calls can be established without a window. I just meant that handling MediaStream within workers is needed.

Is there a reason you can't use .openWindow() from the service worker and then do the video call in the window as you would normally?

There will be no reason for not using your suggestion if WebRTC is unavailable within ServiceWorker.

[eligrey]

I would love to work on implementing something using @feross's WebTorrent + ServiceWorkers where users can simply click a button to "donate bandwidth" for large files for open source groups websites. Easy user-friendly seeding for people who don't want to download a torrent client would be amazing.

As soon as this becomes possible, I intend to start working on such a thing.

[jakearchibald]

I'm going to close this since there's nothing for us to do here, all the work is in w3c/webrtc-pc#230

If the usage being discussed here requires the service worker to be constantly running, that seems like an abuse of SW, which is built to handle events, then shut down.

Shared workers are the ones that stick around.