Create an example with many examples of WinterTC API usage

[vados-cosmonic]

The underling componentize-js and StarlingMonkey projects have implemented a lot of the upcoming WinterCG/WinterTC standard, and it would be incredibly useful to have a component that showcases all the functionality therein that is accessible, in one component.

This would serve as a sort of E2E test of the functionality (at least for jco, as we move between componentize-js releases) so should be beneficial for the ecosystem at large.

The recommended approach would be creating one large component -- possible a HTTP server or wasi:cli/run-able that show cases usage of all available WinterTC APIs.

It would be a good idea to also note in this example component the limitations of working with expected patterns in server side javascript (ex. there is no fs/node:fs import, native node modules don't work, etc).

[guest271314]

I've been trying for about a year to implement a WebTransport server in the browser using a QUIC/WebTransport library compiled to WASM.

I found this, which works, and uses wasip1. I still have some work to do to substitute Direct Sockets UDPSocket for the mio socket usage, and get the wasip2 shim in the browser working as intended.

I think such an example would be useful.

[guest271314]

This is what works using wasmtime https://github.com/birneee/quiche-wasm/.

What I need to do next is get rid of mio mio::net::UdpSocket https://github.com/birneee/quiche-wasm/blob/main/apps/src/bin/quiche-server.rs#L75, replace with Direct Sockets UDPSocket https://wicg.github.io/direct-sockets/#udpsocket-interface, and load quiche-server.wasm using WebAssembly.instantiateStreaming(), and import wasip2.

Then I should be able to do new WebTransport() as a client and connect to the QUIC/WebTransport server running in the brower (Chromium).

That should suffice for a WASI socket example.

[vados-cosmonic]

Hey @guest271314 that's a great example/use-case -- not quite what I was thinking with this ticket but that would be fantastic in here. Have you seen tokio-rs/mio#1931 ?

If I understand where you're going properly you might "just" be able to drop in p2-compliant mio and be off to the races. If we write a shim that exposes wasi-sockets via Direct Sockets, we should be able to get support for what you're building and a lot more!

[guest271314]

No, havn't seen that issue. My particular goal is to be able to run the code entirely in the browser, without necessarily needing to use wasmtime or other WASM runtime. Of course, that means using wasmtime should work, too.

I'm thinking

WebTransport client =>
UDPSocket (raw encrypted data over UDP) =>
QUIC/WebTransport WASM: Handle initial encrypted TLS, HTTP/3, specific QUIC and WebTransport expected mechanics (somehow; the tricky part, not sure if Web Cryptography API can handle this alone; timers are evidently involved someway) in WASM (I don't care if it's wasip1 or wasip2, or wasipN) =>
Unencrypted data back to JavaScript via WASM exposed function/interface for reading/processing =>
Raw data (Uint8Array) send back to WASM to prepare for going over the wire back to the client/peer =>
WASM does the QUIC packet encryption bits and sends that encrypted data (Uint8Array) back to the JavaScript context =>
UDPSocket sends QUIC encrypted packets back to client/peer

From my understanding datagrams are simpler to implement than streams. Start with datagrams. Then, do the whole thingamajig.

Piece of cake, right?

[guest271314]

What I've tried so far:

• Can this library be used with WICG Direct Sockets for a WebTransport server? fails-components/webtransport#354
• https://github.com/guest271314/quinn-wasm/tree/direct-sockets
• Help: Putting the pieces together toyobayashi/emnapi#178

[guest271314]

@vados-cosmonic Just found this

• https://github.com/maceip/socket.iwa
• Add Direct Sockets API support for Isolated Web Apps (-sDIRECT_SOCKETS) emscripten-core/emscripten#26374

I havn't tested, yet. @maceip has been busy since we lasted communicated!

[vados-cosmonic]

Yeah interesting -- emscripten is a bit of a different approach but TIL that they've started work on adding support there!

[guest271314]

I don't know if this is "WinterTC API" specific. Nor what is supposedly specific to Winter TC API". It's this. You'll have to "componetize" it if you want WASI P1, WASI P2, WASI P_N... endel/quic-zig@be2b649

Add WASM build: full QUIC+TLS 1.3 state machine running in the browser
Platform abstraction layer (src/quic/platform.zig) decouples core QUIC
from OS-specific types — sockaddr, nanoTimestamp, AF constants delegate
to std.posix on native, provide compatible structs on wasm32-freestanding.

WASM API (src/wasm_api.zig) exposes 14 C-style functions for JS to drive
client/server instances: init, recv_packet, send_packets, on_timeout,
poll_event, stream_send, datagram_send, etc. Uses std.heap.wasm_allocator
for proper free+grow support, heap-allocates Connection (~50KB with TLS
buffers), routes std.log and crypto.random to JS imports.

HTML demo (wasm/index.html) loads quic.wasm as two instances, routes
packets via JS requestAnimationFrame loop. Full TLS 1.3 handshake
completes in-browser with ~19 packets exchanged.
@
Core files updated: posix→platform, std.time→platform.nanoTimestamp()
across connection.zig, packet.zig, tls13.zig, congestion.zig, qlog.zig,
transport_params.zig, connection_manager.zig. Added @intcast for u64→usize
on wasm32 (32-bit pointers) in stream.zig, frame.zig, packet.zig,
crypto_stream.zig, qpack.zig, h3/frame.zig. 5MB WASM stack for deep
P-256 signature verification call chains.

Tested with Zig version 0.15.2

zig build wasm

Output goes to wasm/quic.wasm. Serve the demo with:

cd wasm && python3 -m http.server 8080

Then open http://localhost:8080/.

on Chromium Version 148.0.7735.0 (Developer Build) (64-bit)

Almost getting my my goal, which is a WebTransport server in the browser, in JavaScript. We've got TLS and QUIC though, in WASM. That's a start.

[guest271314]

@vados-cosmonic

Got something going here... WebTransport server entirely in the browser using Direct Sockets UDPSocket https://github.com/guest271314/quic-zig-wasm/blob/wasm-experiment/wasm/README.md

[maceip]

You guys are barking up the wrong tree, most folks in this org & the others im tagged in don't care about the browser runtime for wasm, they care about server side. If you want help / attention and are doggedly keeping browser runtime as a requirement, the webrtc; media over quic; and game engine repos and forums will be more lively. If you want the browser to be the _server_, you will need a companion app ( a native binary) that opens the port for you. Use these : - **HTTP/3:** `nghttp3` - **QUIC transport:** `ngtcp2` - **TLS 1.3:** `wolfSSL`

…

On Sun, Mar 22, 2026, 5:26 PM guest271314 ***@***.***> wrote: *guest271314* left a comment (bytecodealliance/jco#701) <#701 (comment)> @vados-cosmonic <https://github.com/vados-cosmonic> Got something going here... WebTransport server entirely in the browser using Direct Sockets UDPSocket https://github.com/guest271314/quic-zig-wasm/blob/wasm-experiment/wasm/README.md Screenshot_2026-03-22_16-14-00.png (view on web) <https://github.com/user-attachments/assets/e5da5921-dbcd-4839-b40a-63bfb88a5c0b> Screenshot_2026-03-22_16-15-26.png (view on web) <https://github.com/user-attachments/assets/6de04e65-b9e5-4447-a4d2-1591023595f1> — Reply to this email directly, view it on GitHub <#701?email_source=notifications&email_token=AAGEMEH6QUXG3ATBP4A6EJL4SAH35A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJQGY2TINJSHAZ2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4106545283>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEMEGYWPLJVL7DWWIVPC34SAH35AVCNFSM6AAAAACWSQW6CGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMBWGU2DKMRYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vados-cosmonic]

Hey @guest271314 wow, that's fantastic progress, that to see that progress and working code that makes use of WebTransport.

@maceip Thanks for chiming in -- I do think the BCA cares about the browser runtime (I don't speak for the org but generally the BCA drives towards WASM + Component Model + WASI to run everywhere it can).

Maybe there's some context I'm missing here, but rather than being a requirement I was seeing this as a nice to have in the browser -- as that is a place where the wasi:sockets has no immediate analog today. It's much easier to port on the system side (which we have done -- preview2-shim and preview3-shim have sockets support on the system/NodeJS side).

My original intention for this issue was more centered around examples of the minimum common API and fetch but I'm happy to see experimentation with the sockets API (even if it's not not wasi-sockets-ified yet).