Summary

  • W3C’s WebTransport Working Group began a new charter on 1 September 2026, running through 31 August 2028. Its history says the recharter added potential work on peer-to-peer interactions.
  • The charter puts P2P in scope as something the group is “considering incubating”. Its normative-deliverables section still names only WebTransport and says the initial version is limited to client-server connections.
  • An open issue groups several unsolved problems under P2P: communication on one local network, reaching a server behind NAT, and possible use of mDNS, ICE, NAT-PMP, UPnP or peer-to-peer QUIC. No approach has been selected.
  • A late, non-blocking security comment asked for high-level review. The public response promised early review and anticipated a TPAC breakout; it did not approve a design or create a deliverable.
  • W3C Process makes the later classification consequential. A new Recommendation-track deliverable outside an existing deliverable’s scope is a major charter change, while restructuring in-scope work can be minor.
  • The next public record should say whether P2P enters the next WebTransport version, becomes a separate deliverable, moves elsewhere, stays non-normative or ends—and identify the decision and review evidence behind that change.

One sentence opens a lane

The most consequential new sentence in the WebTransport Working Group charter is deliberately tentative: the group is considering incubating mechanisms for peer-to-peer capability.

“Considering” and “incubating” do real work. They give the group room to formulate use cases, compare designs and expose problems. They do not say that WebTransport now provides browser-to-browser transport, that W3C has selected a NAT-traversal technique, or that implementers have a stable target.

The surrounding charter confirms the separation. Its mission remains APIs for data transfer between browsers and servers. Under normative specifications it lists one deliverable, WebTransport, defined as ECMAScript APIs for data sent between a browser and server. The initial version is expressly limited to client-server connections. The history describes the recharter as adding potential work on peer-to-peer interactions.

This is not an inconsistency. It is a state machine. Scope defines what the group may investigate. The deliverables table identifies the standards output for which the charter currently supplies a named home. A Working Draft, Candidate Recommendation and Recommendation then mark later stages. Implementations and adoption are different evidence again.

The governance problem begins only if those states are allowed to blur.

“P2P” currently names several problems

The public technical issue that motivated the charter language does not present one finished proposal. WebTransport issue 590 asks how the technology might work with a server on a local network or behind NAT. It mentions discovery with mDNS, traversal with ICE, NAT-PMP or UPnP, and IETF discussion of NAT traversal and peer-to-peer QUIC without ICE.

Those are materially different operating conditions. A browser finding a service on the same managed network is not identical to arbitrary peers crossing consumer routers. A server behind NAT does not necessarily imply a browser-to-browser API. Each design reveals different network information, changes who can initiate contact and creates a different surface for consent, abuse and enterprise controls.

Issue 590 does the right thing for its present state: it asks a question. It remains open and records no chosen route. Turning its inventory into a list of “planned features” would convert exploration into a false roadmap.

A separate W3C TAG review demonstrates why the distinction matters. The Local Peer-to-Peer API was incubated in WICG and initially had no settled standardization venue. A TAG commenter asked for a specific threat model covering abuse, discovery, device fingerprinting, user profiling and similarities to UPnP. That proposal is not WebTransport P2P; the security reviewer on the WebTransport charter said so explicitly. Its questions are useful as comparators, not inherited findings.

Conflating the two would create a second governance error. Similar risks may deserve similar scrutiny, but a concern raised against one design is not automatically a disposition for another. WebTransport needs its own use cases, threat model and review trace once there is enough design to review.

A review promise is not a design decision

The charter review did notice the new scope. On 29 July, a security participant posted a late, explicitly non-blocking comment connecting it to issue 590 and asking whether P2P incubation would receive at least high-level review. On 24 August, the public reply said that any new capability would receive early review and that a breakout should take place at TPAC.

That exchange is meaningful. It places review upstream, before a feature arrives as a mature text with high switching costs. It also leaves the important questions open. The sources checked here do not show that the breakout occurred, that a threat model was accepted, that reviewers agreed on a transport or that the Working Group adopted a proposal.

Strategy issue 537 closed on 1 September with a short notice that the charter had been announced and a link to a Member-only archive. The final charter and current group page now provide the public authority state: 1 September 2026 through 31 August 2028. The issue’s short-lived ballot label and closure timing disclose nothing reliable about vote counts, objections or confidential reasoning, so this article draws no conclusion from them.

The public result is narrower and sufficient. The group is authorized to explore P2P. The design and its standards identity remain undecided.

The February 2027 slot is not an answer

The charter’s timeline anticipates a First Public Working Draft for the next version of WebTransport in February 2027. It may be tempting to treat that slot as P2P’s destination. The text does not do so.

The next version could carry P2P work, exclude it, or contain other additions. P2P could become a separate Recommendation-track deliverable, produce only non-normative use cases, be coordinated into another group, or never mature. A date beside “next version” cannot replace an adoption decision and document diff.

W3C Process explains why the classification matters without predetermining it. A charter must separately state its scope and the nature of its deliverables. A new Recommendation-track deliverable outside an existing deliverable’s scope is a major change. Renaming or restructuring existing in-scope deliverables can be minor. Whether a particular P2P design belongs inside the existing WebTransport deliverable is a later fact, not something the word “incubation” settles today.

It would therefore be inaccurate to demand a new charter in advance. It would be equally inaccurate to say the present scope sentence authorizes any future P2P specification automatically. The process route depends on what the group eventually proposes and where it fits.

Record the transition, not just the destination

The useful governance artifact is a small public state receipt joined to the incubation issue. It should identify the problem statement and repository; the actor responsible for the next classification; security, privacy, architecture and IETF coordination records; the group resolution or W3C act that changes status; the target specification or group; and the event that supersedes or closes the incubation item.

Five outcomes should be distinguishable without institutional archaeology:

  1. P2P enters the next version of the existing WebTransport deliverable.
  2. It becomes a separately named Recommendation-track deliverable.
  3. It is transferred or divided among other W3C or IETF workstreams.
  4. It remains an experiment, use-case note or other non-normative output.
  5. It is deferred or closed.

None of those labels should be assigned now. The receipt matters precisely because the answer is not yet known. It preserves the branch point so a later editor’s draft, meeting resolution or implementation experiment cannot quietly masquerade as the authority-bearing transition.

This is the useful application of Lu Heng’s Running-Code Primacy. A document can establish a bounded place for technical work. Running implementations can reveal whether a design works. Neither fact alone should be inflated into institutional approval, interoperability or mandatory adoption. The evidence must remain ordered: problem, incubation, public decision, specification state, testable implementation and actual use.

WebTransport’s new charter has made the first boundary unusually visible. P2P is no longer outside the group’s authorized search space. It is not yet a separately named standards product. W3C’s next test is not whether engineers can experiment. It is whether everyone can see the exact public act by which an experiment changes identity.

Sources

  1. W3C — WebTransport Working Group Charter, effective 1 September 2026
  2. W3C — WebTransport Working Group
  3. W3C — WebTransport charter history
  4. W3C Strategy issue 537 — WebTransport Group Charter
  5. Late, non-blocking security request for high-level P2P review
  6. Public response promising early review and anticipating a TPAC breakout
  7. WebTransport issue 590 — servers behind NAT or on a local network
  8. W3C TAG design review 932 — Local Peer-to-Peer API
  9. W3C TAG security comment on the separate Local Peer-to-Peer API
  10. W3C Process Document, 18 August 2025
  11. W3C — public Advisory Committee review notice, 17 July 2026
  12. W3C — WebTransport Candidate Recommendation Snapshot, 30 July 2026
  13. Draft-charter commit that introduced P2P scope
  14. Lu Heng — Running-Code Primacy