Add support for WebRTC Data Channel in Workers

[feross]

Proposal

Support WebRTC Data Channel in Workers (WebWorker, ServiceWorker, etc.)

WebRTC DataChannel is basically a drop-in replacement for WebSocket, except it's peer-to-peer. For all the same reasons that WebSocket was added to the Worker spec, we should add WebRTC DataChannel.

Use Cases

DataChannel in a ServiceWorker would support the use case of "peer assisted delivery" a la WebTorrent, CDN/P2P CDN video streaming delivery, file transfer, etc.

DataChannel in a WebWorker would support offloading CPU intensive data transfer/processing to another thread.

What about security?

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

[silverbucket]

+1

[feross]

Another use case for using WebRTC in a SharedWorker is a DHT, a decentralized/distributed lookup service (similar to a hash table). Useful for routing to nodes in decentralized applications.

[dennismartensson]

This would be fantastic! It will really make the WebRTC Data Channel even more powerful.

[stefhak]

Hi! You should push for this feature on the WebRTC WG's mailing list, public-webrtc at w3.org.
That is where the community discuss and decide on added functionality and features.

[gaperik]

Hi.
+1 to Stefans comment. Bringing it to the W3C WebRTC-list will make it more likely we'll see some work on it in a not-to-distant future. Of course, pushing for features in Chrome, FF and Edge developer communities never hurts (https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer), :-).

[feross]

I made a proposal on the mailing list: https://lists.w3.org/Archives/Public/public-webrtc/2015May/0157.html

[feross]

Here are the relevant issues in the various developer communities:

• Chrome webrtc.org
• Firefox
• Microsoft Edge

[shumy]

+11 Access WebRTC API in Workers and support transfer of MediaStream objects through the Message API.

[stefhak]

Given the process on how to determine what is in/out of 1.0 (https://lists.w3.org/Archives/Public/public-webrtc/2015Jul/0060.html) the best thing to do if you'd like to see this feature is probably to create a pull request and try to get some discussion around it.

[shumy]

From the answers, it seems like you have to change the WebRTC API ??
Don't change anything, just extend the availability of WebRTC API on Workers.

[kulicuu]

+1

[pashoo2]

+1

[vsantosu]

+1

[stefhak]

This was discussed at the WebRTC WG meeting during TPAC, and it was decided to add this functionality pending a security review. That security review has been done, and there are active PRs ( #317 and #445 ). However, more work is needed on those PRs.

[silverbucket]

Great news! +1

On Fri, Jan 8, 2016 at 7:42 AM stefan hakansson notifications@github.com
wrote:

This was discussed at the WebRTC WG meeting during TPAC, and it was
decided to add this functionality pending a security review. That security
review has been done, and there are active PRs ( #317
#317 and #445
#445 ). However, more work is
needed on those PRs.

—
Reply to this email directly or view it on GitHub
#230 (comment).

[feross]

Excellent news. Very much looking forward to this!

[stefhak]

The PRs ( #317 and #445 ) have issues/are incomplete. Anyone that is interested/willing to contribute to improve them?

[alvestrand]

Based on the silence, marking this LATER (beyond 1.0).

[eligrey]

Absolutely +1!

[alvestrand]

Closing with intent to reopen "later".

[interfect]

Is it "later" yet?

There are some really cool tricks one would be able to do with, say, ipfs/js-ipfs and a ServiceWorker, to serve assets from the IPFS network and have them appear to the page like normal HTTP-based assets. Currently you have to figure out how to connect a NodeJS-style stream to, say, an <img> tag. Browsers already know how to connect a stream to a tag, and it would be really useful to be able to use that functionality for streams that come in from peers.

[alvestrand]

No, "later" is after webrtc-pc has gone to CR.
If you want to pursue the change as a separate document (with intent to merge), feel free to write up a draft. It turned out in discussion to be non-trivial in its implications (both spec and implementation).

[nkev]

Creating a browser "refresh resistant" WebRTC data channel in a shared worker could potentially change the way web apps are built forever! It's a shame not much has happened here in over 3 years...

[jimmywarting]

It have been quiet for a while now, haven't heard anything new. Some related PR/issues have been closed. So I got some few question.

• Won't service worker get webrtc support?
• What is blocking? is there any other related issues/PR i can follow?

No, "later" is after webrtc-pc has gone to CR.

• Has webrtc-pc gone to CR yet?

[benjamingr]

What is blocking? is there any other related issues/PR i can follow?

Someone actually doing the work and putting in the time and work to spec and then write support for workers.

[aboba]

@jimmywarting @benjamingr The "work" would probably involve implementing the RTCDtlsTransport and RTCDataChannel interfaces from ORTC, in addition to WebRTC-ICE which had an Origin Trial in Chrome last Spring along with WebRTC-QUIC.

The big question is whether there is enough motivation for browser vendors to support RTDataChannel in workers, as opposed to RTCQuicTransport in workers. WebTransport API seems to be garnering interest, the existing WebRTC data channel not so much.

[lgrahl]

WebTransport API seems to be garnering interest [of browser vendors], the existing WebRTC data channel not so much.

Maybe they should focus more on improving what people are actually "stuck with" using right now? Just a thought...

[subins2000]

I was excited today to move the WebTorrent part of my app to a worker for increased performance, but then I saw this issue, a big letdown :/

It's a shame that even after 5 years, this hasn't been implemented :(

[benjamingr]

It's a shame that even after 5 years, this hasn't been implemented :(

You have several options for recourse:

• Put in the work and implement this feature yourself.
• You can pay for it to be implemented for you by another company.
• You can find compelling use cases to get other people to do either of the above two things.

[interfect]

An implementation of a fix to this issue would be making just RTCDataChannel available in just (ordinary, Web, non-Service) Workers, right? Along the lines of #317 or #445, you would be able to send an already open RTCDataChannel to a Web Worker, but a Web Worker would not be able to open any new connections (because of not having RTCPeerConnection) and a Service Worker wouldn't be able to use either. (As pointed out here by @martinthomson, a Service Worker is supposed to only be spun up for a few seconds at a time to handle a request, and giving it a peer to peer connection causes trouble with that model that people did not want to solve at the time.)

I'm not sure a fix to this issue would then really provide what @jimmywarting, @nkev, and others are asking for, which is a way to host a useful peer-to-peer node in a browser in the background (or at least independent of any single tab), in a context where it can idiomatically service requests.

I'm going to open an issue to track providing the whole WebRTC API to all types of workers (including Service Workers) in a way that is useful for p2p content distribution but which doesn't buy you infinite service worker runtime for every site the user ever visits. Actually fixing that bigger issue is where a lot of the hardness is, it seems, and probably shouldn't block a fix for this issue for whoever actually needs exactly the functionality of shipping an RTCDataChannel specifically to a Web Worker specifically.

[nkev]

@interfect Thank you for the useful response and not dismissing this with "build it yourself or pay someone else to build it".

[interfect]

@nkev I'm not actually one of the actual spec group project members either; I want this feature for my use case too. But I can see how it can get on their nerves to have people showing up periodically asking why their pet issue isn't ready yet, so I decided to try to grab a metaphorical shovel to the extent that I can.

Where we might still get stuck is browser implementations. I'm pretty sure I can fiddle with a spec document, but I'm not really a qualified browser dev and even if I were I have no leverage to get an implementation merged. I'm hoping some actual browser devs will come by and implement it for me (which might go better if this is attached to the next version of WebRTC like @alvestrand suggested, which is going to need implementing anyway).

[guest271314]

Can self or globalThis be substituted for all references to window and import() or importScripts() be substituted for document within https://github.com/rustwasm/wasm-bindgen/tree/master/examples/webrtc_datachannel to be able to use the Rust wasm-bindgen version of RTCDataChannel https://rustwasm.github.io/wasm-bindgen/examples/webrtc_datachannel.html in Worker?

All the logs at https://rustwasm.github.io/wasm-bindgen/exbuild/webrtc_datachannel/ are on line 333 in index_bg.js:333.

[guest271314]

@lgrahl FWIW QuicTransport https://github.com/GoogleChrome/samples/blob/gh-pages/quictransport/quic_transport_server.py is defined Worker at Chromium 87.

[lgrahl]

Linking w3c/webrtc-extensions#64
It's time to recite your use cases. At least those that would work with that design. 🙂

[amark]

Hi, I'm a p2p protocol developer with millions of monthly active users.

And unlike the others, I beg and plead you to NOT implement this until

w3c/webappsec-csp#92

Is fixed.

Any WebWorker feature that allows for external communication is a huge data exfiltration and security risk.

Thank you.

[lgrahl]

Transferring to a worker has since been specced in https://github.com/w3c/webrtc-extensions
Only Safari can do it right now but not to service workers. Fear not though, w3c/webappsec-csp#457 is close to get merged and right now you need an active RTCPeerConnection living in the main thread.

[SahilAggarwal2004]

Any updates on this?

[aboba]

The WebRTC-Extensions specification includes support for WebRTC Data Channel in Workers.

However, at least one shipping implementation is required to move the spec into WebRTC-PC.

[Diego-Perez-Botero]

@aboba - doesn't the following mean that Safari has a shipping implementation of WebRTC Data Channel transfer to workers (including service workers)?

https://wpt.fyi/results/webrtc-extensions/transfer-datachannel.html?label=master&label=stable&product=safari&aligned

https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=master&label=stable&product=safari&aligned

[aboba]

Yes. For some reason, the tests have been failing on all browsers recently, so I missed that:
https://wpt.fyi/results/webrtc-extensions?label=experimental&label=master&aligned

[epaterlini]

Any news on this? A growing-in-importance topic and no implementations yet... :-(

[aboba]

WPT.fyi indicates that tests are passing (on Safari TP 192):

https://wpt.fyi/results/webrtc-extensions/transfer-datachannel.html?label=experimental&label=master&aligned
https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=experimental&label=master&aligned