Intent to Implement & Ship: Transferable RTCDataChannel to dedicated workers

[Thomas Guilbert]

Contact emails

tgui...@chromium.org

Explainer

None

Specification

https://w3c.github.io/webrtc-extensions/#rtcdatachannel-transferable

Summary

The RTCDataChannel interface is part of the WebRTC standard, and represents a network channel which can be used for bidirectional peer-to-peer transfers of arbitrary data. This feature tracks exposing RTCDataChannel in dedicated workers, and allowing the transfer of RTCDataChannels to them workers. This will help reduce main thread contention and lead to smoother and more reliable WebRTC applications.

Blink component

Blink>WebRTC>DataChannel

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

There is an interoperability risk when it comes to which types of workers are supported by which browser. - Safari/WebKit supports transfers to DedicatedWorkers and to ServiceWorkers. - Chromium is only looking to add transfers to DedicatedWorkers; supporting transfers to ServiceWorkers would require significant architectural changes (across processes, rather than across threads) and might never be supported. - Firefox/Gecko supports neither, but might support transfers to both DedicatedWorkers and ServiceWorkers, if/when they choose to support this feature. Regardless of whether or not Chromium supports transfers to ServiceWorkers, enabling transfers to DedicatedWorkers addresses current developer needs, and improves interoperability.

Gecko: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1209163) Mozilla is aware of the issue, but has not allocated resources to it as of yet.

WebKit: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=222965)

Web developers: Positive This has been a longstanding request from developers. E.g: https://bugzilla.mozilla.org/show_bug.cgi?id=1209163#c4 https://issues.chromium.org/issues/40787712#comment21

Other signals:

Ergonomics

This feature improves the ergonomics of existing Worker exposed APIs. For example, it allows developers to use WebCodecs and Offscreen canvas from workers, without having to repeatedly transfer data from the main thread.

Activation

N/A

Security

This feature should not introduce any new security risks. Existing risks can be found in the WebRTC API specification: https://w3c.github.io/webrtc-pc/#privacy-and-security-considerations

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

N/A

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

DedicatedWorkers: https://wpt.fyi/results/webrtc-extensions/transfer-datachannel.html?label=experimental&label=master&aligned ServiceWorkers (out of scope for this feature): https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

TransferableRTCDataChannel

Requires code in //chrome?

False

Sample links

https://tguilbert-google.github.io/RTCDataChannel/index.html

Estimated milestones

Shipping on desktop	130
DevTrial on desktop	129
Shipping on Android	130
DevTrial on Android	129

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6612726584180736?gate=4885503741263872

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dab53bcd-e51d-41bc-a312-4bd3e08322f0n%40chromium.org

This intent message was generated by Chrome Platform Status.

[Daniel Bratell]

LGTM1

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoba%2B6EuYDdfxKF8ZXn%3DXmzt6vd1tZ53yTS9-CEdUBXTzw%40mail.gmail.com.

[Vladimir Levin]

Can this API be feature detected? IOW, do developers have an easy way to figure if RTCDataChannel can be transferred?

Thanks,

Vlad

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2d9e822-092f-4ad3-b595-7fa0044062cc%40gmail.com.

[Thomas Guilbert]

Using structuredClone(), developers can feature detect. See this demo failing gracefully on Stable (but it should work on Canary):
https://tguilbert-google.github.io/RTCDataChannel/index.html

Source code: https://github.com/tguilbert-google/tguilbert-google.github.io/blob/main/RTCDataChannel/index.html#L158

[Domenic Denicola]

LGTM2.

On Fri, Aug 9, 2024 at 8:22 AM Thomas Guilbert <tgui...@chromium.org> wrote:

Contact emails

tgui...@chromium.org

Explainer

None

Specification

https://w3c.github.io/webrtc-extensions/#rtcdatachannel-transferable

This is a fine specification for shipping the feature. But it's a bit sad that it's a monkey patch specification for a feature that it sounds like everyone agrees on.

The Web RTC Extensions specification says "As extensions mature and gain implementation experience, they may move from this document to the base specification if WG consensus emerges to do so." Do you know if there's any effort to merge this monkey patch into the base specification?

 

--

[Vladimir Levin]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_MUXCsrpODkCarYj%3DY7%2BDipq0mX_dcY44auGzV-QZ7Qw%40mail.gmail.com.

[Thomas Guilbert]

Thank you all! I will wait on the security review to finish, and will turn on the feature by default on M130.

> Do you know if there's any effort to merge this monkey patch into the base specification?

There was none that I knew of, so I opened an issue to start a discussion. Thanks for the suggestion!

[Thomas Guilbert]

The security review concluded last week. The change to enable this by default has landed, and will be available starting in M130:
https://chromium.googlesource.com/chromium/src.git/+/1f5f2853635ab7a43d3507f02e1de903d2703019

Thank you!