LGTM2 On Tue, Oct 27, 2026 at 7:05 PM Alex Russell <[email protected]> wrote:
> LGTM1; we've had intermittent feedback over the years about how > WebTransport wasn't well suited to latency-sensitive work, and it's great > to see these additions. > > On Thursday, October 22, 2026 at 3:11:29 PM UTC-7 Monica Chintala wrote: > >> FYI, this feature depends on WebTransport send groups and stream >> prioritization - Chrome Platform Status >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeature%2F5235261159112704&data=05%7C02%7Cmonicach%40microsoft.com%7C9e0b9f4149a541fafafe08df307d863d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639282987879917270%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fMplyzw4jssGTpxdGq0wgG5zQ2s6HhhTQI6b1Zm6cps%3D&reserved=0>, >> which is currently in progress for I2S. I'm working on getting the >> necessary approvals now so we're ready to proceed, while ensuring this >> feature ships only after the dependent feature has shipped. >> >> On Thursday, October 22, 2026 at 2:24:42 PM UTC-7 Chromestatus wrote: >> >>> *Contact emails* >>> [email protected], [email protected] >> >> >>> >>> *Explainer* >>> >>> https://github.com/w3c/webtransport/blob/main/explainer.md#5-sending-and-receiving-datagrams >>> >>> *Specification* >>> https://www.w3.org/TR/webtransport/#datagram-writable >>> >>> *Summary* >>> Adds the modern WebTransport Datagram sending API. >>> WebTransportDatagramDuplexStream.createWritable() creates independent >>> WebTransportDatagramsWritable streams. Each writable has mutable sendGroup >>> and sendOrder attributes for expressing relative priority among queued >>> WebTransport data in the same send group. Chromium currently applies this >>> ordering among Datagram writables. The implementation also reports the >>> negotiated maximum outgoing Datagram payload size and discards oversized >>> writes as required by the WebTransport specification. >>> >>> *Blink component* >>> Blink>Network>WebTransport >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> >>> >>> *Web Feature ID* >>> webtransport <https://webstatus.dev/features/webtransport> >>> >>> *Motivation* >>> The original WebTransport Datagram API exposes only a single writable >>> stream, preventing applications from independently scheduling different >>> classes of latency-sensitive messages. The newer API allows applications >>> such as games, remote-interaction systems, and real-time media applications >>> to create multiple Datagram writables and prioritize urgent data over less >>> time-sensitive data while preserving FIFO ordering within each writable. >>> Implementing this API also resolves WebTransport Datagram interoperability >>> failures included in Interop 2026. >>> >>> *Initial public proposal* >>> https://github.com/w3c/webtransport/issues/451 >>> >>> *TAG review* >>> This is an incremental API addition within the existing WebTransport >>> specification and does not introduce a new architectural primitive. A >>> separate feature-level TAG review is not planned. >>> >>> *TAG review status* >>> Not applicable >>> >>> *Goals for experimentation* >>> None >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> Interoperability risk Medium. The API is defined in the WebTransport >>> Candidate Recommendation and covered by WPT. Implementations may >>> nevertheless differ in scheduling boundaries, particularly priority >>> interaction between streams and Datagrams. Chromium currently implements >>> ordering among Datagram writables; unified stream-and-Datagram arbitration >>> may require additional implementation work and specification clarification. >>> Compatibility risk Low. The API adds createWritable() and >>> WebTransportDatagramsWritable without removing datagrams.writable. Existing >>> applications continue to work. The negotiated maxDatagramSize and >>> oversized-write behavior are intentional conformance improvements but could >>> expose applications that assumed a fixed outgoing Datagram limit. >>> >>> *Gecko*: Shipped/Shipping ( >>> https://bugzilla.mozilla.org/show_bug.cgi?id=2007174) Firefox >>> implemented and related wpt tests are passing >>> >>> *WebKit*: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/53733) >>> WebKit >>> implemented and related wpt tests are passing >>> >>> *Web developers*: Positive ( >>> https://github.com/web-platform-tests/interop/issues/1121) The Interop >>> 2026 WebTransport proposal received 28 👍 reactions and explicitly >>> requested coverage of prioritization features and Datagram >>> interoperability. Developers also reported active WebTransport use and >>> significant cross-browser differences in Datagram behavior. >>> >>> *Other signals*: Consensus to add this feature was achieved at the W3C >>> TPAC conference in November 2025: >>> https://www.w3.org/wiki/WebTransport/Meetings2023#2025_W3C_TPAC_Meeting_-_Kobe,_Japan >>> >>> *Ergonomics* >>> Low to medium. Multiple writable streams and mutable sendGroup and >>> sendOrder attributes provide useful scheduling control but introduce >>> concepts developers must understand. Higher sendOrder values take >>> precedence within a send group, so badly chosen priorities can starve >>> lower-priority data or produce unexpected ordering. FIFO behavior within >>> each writable and standardized defaults preserve straightforward behavior >>> for applications that do not need advanced prioritization. >>> >>> *Activation* >>> Low. This is an additive API behind the WebTransportDatagramsWritable >>> runtime feature. It does not remove or replace the existing >>> datagrams.writable API. Enabling the feature also makes maxDatagramSize >>> reflect the negotiated outgoing payload limit and discards writes that >>> exceed that limit, as required by the specification. The main activation >>> risk is inconsistent priority scheduling across browsers, particularly >>> around the boundary between streams and Datagrams. Rollout should follow >>> WPT and interoperability validation. >>> >>> *Security* >>> Low. The API does not grant new network access, expose additional data, >>> or weaken WebTransport's secure-context requirements. The primary >>> implementation concern is renderer-driven resource exhaustion through >>> excessive writable registrations or queued Datagram payloads. Chromium >>> mitigates this through network-service validation and limits on writable >>> registrations, queued Datagram counts, retained bytes, expiration, and >>> scheduling batch sizes. Invalid renderer-provided identifiers and priority >>> updates are rejected. >>> >>> *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? >>> Low. This is an additive WebTransport API implemented in cross-platform >>> Blink and network-service code. It does not remove or change the >>> availability of the existing datagrams.writable API and requires no >>> WebView-specific integration. Behavior follows the existing availability of >>> WebTransport in WebView. >>> >>> >>> *Debuggability* >>> Chrome DevTools does not currently provide feature-specific inspection >>> for Datagram writable queues or priorities. Existing WebTransport >>> diagnostics, NetLog, network-service logging, and QUIC logging can be used >>> to diagnose connection and scheduling behavior >>> >>> *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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> Yes >>> >>> https://wpt.fyi/results/webtransport/idlharness.https.sub.any.html?label=experimental&label=master&aligned >>> https://wpt.fyi/results/webtransport/datagrams.https.any.html?label=experimental&label=master&aligned >>> https://wpt.fyi/results/webtransport/datagrams-writable.https.any.html?label=experimental&label=master&aligned >>> https://wpt.fyi/results/webtransport/sendgroup.https.any.html?label=experimental&label=master&aligned >>> >>> *Flag name on about://flags* >>> enable-experimental-web-platform-features >>> >>> *Finch feature name* >>> WebTransportDatagramsWritable >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/547572475 >>> >>> *Availability expectation* >>> The feature is expected to be available across major browsers as part of >>> the W3C WebTransport specification. Firefox implements the Datagram >>> writable and prioritization APIs, and WebKit has landed an implementation >>> that is currently in development. >>> >>> *Adoption expectation* >>> Adoption is expected primarily among latency-sensitive WebTransport >>> applications, including games, remote-interaction systems, and real-time >>> media. Applications that need multiple independently prioritized Datagram >>> queues are expected to begin adopting the API within 12 months of broad >>> browser availability. >>> >>> *Adoption plan* >>> Adoption is expected to happen organically through WebTransport >>> documentation, examples, and Interop 2026 visibility. Existing applications >>> do not need to migrate because the existing datagrams.writable API remains >>> available. >>> >>> *Estimated milestones* >>> Shipping on desktop 159 >>> DevTrial on desktop 155 >>> Shipping on Android 159 >>> DevTrial on Android 155 >>> Shipping on WebView 159 >>> >>> *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). >>> No API-shape changes are currently anticipated. The WebTransport Working >>> Group may further clarify scheduling boundaries and priority arbitration >>> between streams and Datagrams in the same send group. Such clarification is >>> expected to affect scheduling behavior only, not the exposed API. >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5183354944225280?gate=6105683064913920 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a920d86.e8a51b51.6abb3.0299.GAE%40google.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b8eda2b-f976-4b29-9614-60378180f13cn%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1b8eda2b-f976-4b29-9614-60378180f13cn%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-wss4zhBBJcM0s1-EYhgDHs0a3zm8yPjB_gtLDTf6Pmw%40mail.gmail.com.
