MoQ: A Rust and TypeScript protocol stack for live media over QUIC

The problem MoQ solves and who it targets

MoQ addresses a specific pain point: delivering live media with real-time latency, comparable to WebRTC, but without WebRTC's inherent scaling limits and complexity. WebRTC is peer-to-peer and struggles with massive fan-out, requiring complex SFU (Selective Forwarding Unit) infrastructure. MoQ instead delegates core networking to QUIC, a modern transport with built-in multiplexing, prioritization, and partial reliability, while keeping the rest in application space. This gives developers full control over the media pipeline. The target audience is engineers building live streaming platforms, interactive broadcast tools, or any application needing low-latency data distribution at scale. The README explicitly positions MoQ as generic for any live data, not just media, with text chat as a core example. The project is multi-language, offering Rust for native and TypeScript for web, making it relevant for both server-side and browser-based developers.

Layered architecture: moq-lite, hang, and the dumb CDN

The architecture is a layered protocol stack, and the key design rule is that the CDN must not know anything about the application, codecs, or tracks. The relay, moq-relay, operates on rules encoded in the moq-net header, which are based on video encoding but generic enough for any live data. This keeps the server dumb, a deliberate choice to support a wide range of use cases and enable full end-to-end encryption. The stack is split into three layers: the application (your business logic), hang (media-specific encoding and streaming, like HLS/DASH), and moq-lite (a generic pub/sub transport with broadcasts, tracks, groups, and frames). moq-lite is a forwards-compatible subset of the IETF moq-transport draft, so it works with any moq-transport CDN, such as Cloudflare. This separation is a trade-off: it gives you flexibility to replace hang with a custom protocol, but it also means the 'hang' layer is not standardized, and you might need to implement your own if your use case is not media-centric.

Getting started: commands and configuration

The quickest way to run the demo is with Nix and flakes. The README provides a single command: `nix develop -c just`, which runs a relay, demo media, and a web server, then you visit https://localhost:8080. For those without Nix, there is a manual setup guide at doc.moq.dev/setup/demo/web. For production, the docs describe a setup with a real domain and TLS, and Linux packages are available from apt.moq.dev or rpm.moq.dev. The repository includes a moq-cli for publishing media to relays, and a moq-token CLI for authentication. Configuration is largely code-based, using the Rust and TypeScript libraries. The relay is configurable, but the README does not provide specific config keys; you would need to consult the documentation for relay settings like clustering and TLS. The presence of a Nix-based demo suggests a development environment that is reproducible, but also implies a learning curve if you are not familiar with Nix.

The libraries and their roles

The repository provides a set of Rust crates and TypeScript packages with similar APIs. The core crate is moq-net, the networking layer handling real-time pub/sub with caching, fan-out, and prioritization. It negotiates either moq-lite or moq-transport wire protocols, which is important for interoperability. moq-relay is the clusterable relay server. moq-token is an authentication scheme, usable as a library or CLI. moq-native provides opinionated helpers for configuring a Quinn QUIC endpoint, and the README notes 'It's harder than it should be,' indicating that QUIC configuration is non-trivial. libmoq is C bindings for moq-net, useful for integrating with other languages. hang is the media-specific layer. moq-cli is a publishing tool. moq-mux handles muxing and demuxing of fMP4/CMAF and HLS for importing content. moq-gst is a GStreamer plugin, but it is not built by default, requiring GStreamer dev libraries. On the TypeScript side, there is an npm package @moq/net, but the README is truncated before listing all packages. The breadth of libraries is a strength, but the number of components means you need to understand which ones you actually need for your use case.

Limitations and when it is the wrong tool

MoQ is not a drop-in replacement for everything. The most obvious limitation is that it implements moq-lite, a subset of the IETF moq-transport draft, not the full draft. This means you are betting on a protocol that is still evolving, and while it is forwards-compatible, you may miss features or encounter breaking changes as the draft matures. The README states that the focus is narrower, prioritizing simplicity and deployability, but that also means you cannot rely on full moq-transport features. Another limitation is the reliance on WebTransport, which is a browser API that is not universally supported in all environments. For native clients, you use QUIC directly, but the configuration is acknowledged as hard. The project is also heavily Rust-oriented, so if your team is not comfortable with Rust, the learning curve is steep. The relay is clusterable, but the README does not detail the clustering mechanism or its operational complexity, so you would need to dig into the docs. For a simple one-to-one video call, MoQ is overkill; WebRTC would be simpler. For a small live stream with a few hundred viewers, a traditional CDN with HLS might be sufficient. MoQ shines when you need massive fan-out with low latency, but that comes with operational cost.

Alternatives and how they differ

The most direct alternative is WebRTC, which MoQ explicitly aims to supersede. WebRTC provides real-time latency but is peer-to-peer and requires SFUs for scale, adding complexity and cost. MoQ's approach is to use QUIC and a relay, which is designed for fan-out from the start, potentially simplifying scaling. Another alternative is to use HTTP/3 and WebTransport directly with your own protocol, but you would then have to implement the media logic and pub/sub semantics yourself. MoQ provides a ready-made layer (moq-lite and hang) that abstracts that. A more traditional alternative is HLS or DASH with low-latency extensions (LL-HLS, LL-DASH), which work over HTTP/2 and are widely supported by CDNs, but they typically have higher latency (2-5 seconds) compared to MoQ's real-time goal. The difference is in the transport: HLS/DASH use HTTP chunked transfer, which is not optimized for real-time, whereas MoQ uses QUIC's prioritization and partial reliability to deliver frames as they are produced. Each alternative has trade-offs: WebRTC for latency but not scale, HLS for scale but not latency, and MoQ aims for both, but with the cost of a new protocol and ecosystem.

Maintenance, upgrade cost, and licensing

The project is actively maintained, with recent releases in August 2026 for obs-moq, moq-gst, and moq-ffi, indicating ongoing development. The last push is recent, so the project is not abandoned. However, the protocol is still based on a draft, and the moq-lite subset may change as the IETF draft evolves. This means upgrade cost could be significant if the wire protocol changes, requiring updates to both clients and relays. The repository provides a migration path through forwards compatibility, but you should monitor the draft's status. The license is Apache-2.0, which is permissive and allows commercial use, modification, and distribution, with patent grants. This is a positive for adoption, as it avoids copyleft obligations. The maintenance cost is also influenced by the breadth of components: you have multiple crates and packages to track, each with its own release cycle. The moq-gst plugin is not built by default, so you need to manage that separately if you need it. Overall, the project is under active development, but the dependency on a draft protocol introduces a risk that you must factor into your planning.

Editorial conclusion

Adopt MoQ if you need WebRTC-like latency with massive fan-out and want to avoid WebRTC's constraints, especially if you value a dumb CDN and application-space control. Do not adopt it if you require full IETF moq-transport compliance, need a stable production-grade relay with extensive operational tooling, or are not prepared to handle the complexity of the Rust ecosystem and the ongoing draft protocol churn. Before adopting, verify the current state of the moq-lite subset, the stability of the wire protocol, and the maturity of the relay's clustering and authentication features. Also confirm that your target clients support WebTransport and that your CDN can interoperate with moq-lite or moq-transport.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes