Rust WebTransport library for native and WASM
See the code
WebTransport is a new web API that allows for low-level, bidirectional communication between a client and a server. It's available in the browser as an alternative to HTTP and WebSockets.
WebTransport is layered on top of HTTP/3 which is then layered on top of QUIC. This library hides that detail and tries to expose only the QUIC API, delegating as much as possible to the underlying QUIC implementation.
QUIC provides two primary APIs:
QUIC streams are ordered, reliable, flow-controlled, and optionally bidirectional. Both endpoints can create and close streams (including an error code) with no overhead. You can think of them as TCP connections, but shared over a single QUIC connection.
QUIC datagrams are unordered, unreliable, and not flow-controlled. Both endpoints can send datagrams below the MTU size (~1.2kb minimum) and they might arrive out of order or not at all. They are basically UDP packets, except they are encrypted and congestion controlled.
This project is broken up into quite a few different crates:
Built from rs/web-transport-ffi via UniFFI; all three release workflows fire from a single web-transport-ffi-v* tag.
| Language | Package | Source |
|---|---|---|
| Python | web-transport-rs (PyPI) | py/web-transport |
| Kotlin | dev.moq:web-transport (Maven Central) | kt/ |
| Swift | WebTransportFFI.xcframework.zip (attached to GitHub Releases) | swift/ |
Development plans live in quest/. Enter nix develop to
use the pinned Quest CLI, then run quest guide for the workflow. Without
entering the shell, use nix run .#quest -- guide.
Restart your agent session after setup to load the quest skills. Use
$quest-plan in Codex or /quest-plan in Claude Code to plan work, and
$quest-import or /quest-import to bring in GitHub issues. quest check
validates the tree and runs as part of just check and CI.
Rust WebTransport library for native and WASM
See the code
WebTransport is a new web API that allows for low-level, bidirectional communication between a client and a server. It's available in the browser as an alternative to HTTP and WebSockets.
WebTransport is layered on top of HTTP/3 which is then layered on top of QUIC. This library hides that detail and tries to expose only the QUIC API, delegating as much as possible to the underlying QUIC implementation.
QUIC provides two primary APIs:
QUIC streams are ordered, reliable, flow-controlled, and optionally bidirectional. Both endpoints can create and close streams (including an error code) with no overhead. You can think of them as TCP connections, but shared over a single QUIC connection.
QUIC datagrams are unordered, unreliable, and not flow-controlled. Both endpoints can send datagrams below the MTU size (~1.2kb minimum) and they might arrive out of order or not at all. They are basically UDP packets, except they are encrypted and congestion controlled.
This project is broken up into quite a few different crates:
Built from rs/web-transport-ffi via UniFFI; all three release workflows fire from a single web-transport-ffi-v* tag.
| Language | Package | Source |
|---|---|---|
| Python | web-transport-rs (PyPI) | py/web-transport |
| Kotlin | dev.moq:web-transport (Maven Central) | kt/ |
| Swift | WebTransportFFI.xcframework.zip (attached to GitHub Releases) | swift/ |
Development plans live in quest/. Enter nix develop to
use the pinned Quest CLI, then run quest guide for the workflow. Without
entering the shell, use nix run .#quest -- guide.
Restart your agent session after setup to load the quest skills. Use
$quest-plan in Codex or /quest-plan in Claude Code to plan work, and
$quest-import or /quest-import to bring in GitHub issues. quest check
validates the tree and runs as part of just check and CI.
