moq-dev/moq: Media over QUIC, the moq-lite relay and its Rust and TypeScript libraries

What moq-dev/moq solves, and for whom

The repository is an implementation of Media over QUIC, shortened to MoQ throughout the README and the docs. The stated goal is real-time latency at massive scale: WebRTC-like latency without WebRTC's constraints. That framing tells you who the intended reader is. If you have ever tried to scale a WebRTC fan-out, the constraint is not the codec, it is that the transport and the media logic are welded together, so every participant in the path has to understand your session. MoQ moves the media logic out of the network and into the endpoints.

The project is not only for video. The README describes it as generic for any live data, not just media, and points at text chat as both an example and a core feature. That matters for evaluation: the transport layer, moq-lite, carries broadcasts, tracks, groups and frames, and a chat message is just another track. If your problem is a live control channel with the same latency profile as your video, the same relay carries it.

The audience is narrower than the tagline suggests. You need to be willing to run a relay, and the production guide assumes a real domain with TLS. This is infrastructure for people who already accept that they operate media servers, not a drop-in replacement for a hosted video API.

The layered stack: moq-lite under hang under your application

The architecture section is the most useful part of the README because it states a rule rather than a feature. Rule 1: the CDN must not know anything about your application, media codecs, or even the available tracks. No business logic allowed. moq-relay operates only on rules encoded in the moq-net header, and those rules are based on video encoding but generic enough for any live data.

The stack has four layers. WebTransport over QUIC handles the HTTP/3 handshake and multiplexing. moq-lite above it is a generic pub/sub transport with broadcasts, tracks, groups and frames. hang above that is media-specific: codecs, containers, catalog. Your application sits on top with authentication, non-media tracks, and everything else.

The README's own analogy is worth quoting because it fixes the mental model: hang is like HLS/DASH, while moq-lite is like HTTP. That is the design bet. The relay stays dumb, so it can fan out and cluster across regions without being redeployed every time you add a codec. The cost is that anything the relay cannot infer from the header has to be handled by clients or media servers, and the README says plainly that if you want something more custom, you can extend hang or replace it entirely. Replacing it means you own the media layer.

moq-lite versus moq-transport, and what that means for a CDN

The note under the feature list is the one to read twice. The project implements moq-lite, described as a forwards-compatible subset of the IETF moq-transport draft. It works with any moq-transport CDN, and Cloudflare is named as an example. The focus is narrower, prioritizing simplicity and deployability.

That is a real trade-off, not a marketing line. A subset means some of what the draft defines is not implemented here, and the repository says the focus is narrower. If your deployment plan depends on a feature that exists in the draft but not in moq-lite, the README will not tell you which one, because it does not enumerate the difference. The doc site is the place to check, and moq-net is documented as negotiating either the moq-lite or the moq-transport wire protocol, which suggests the negotiation path is deliberate rather than incidental.

For a CDN operator the subset is attractive: fewer moving parts to implement, and forwards compatibility means a client speaking the subset should keep working against a fuller implementation. For an application developer the question is inverted. You want to know whether the CDN you picked speaks the subset, and the README's answer is that it works with any moq-transport CDN, with one named example.

Running the demo locally and publishing a first track

The README's quickest path requires Nix with flakes enabled. One command starts a relay, demo media, and the web server together.

# Runs a relay, demo media, and the web server
nix develop -c just

After that you visit https://localhost:8080. The README notes that if you do not have Nix, the demo guide at doc.moq.dev/setup/demo/web covers manual setup. That is the honest boundary: the one-liner is a Nix convenience, and the manual route is documented separately rather than reproduced in the README.

For a real relay, the README points at the production setup page, which covers deploying a relay with a real domain and TLS. On Linux there is a package route: the relay and the GStreamer plugin are installable from apt.moq.dev and rpm.moq.dev. The GStreamer plugin is worth flagging before you plan around it. The crate table states that moq-gst is not built by default and requires GStreamer dev libraries, and the workspace Cargo.toml comments it out of default-members with the same reason. The same applies to libmoq, which requires a C toolchain, and moq-ffi, which requires Python and maturin. A plain cargo build at the workspace root will not produce any of them.

The Rust crates are published on crates.io, with moq-net listed there, and the TypeScript packages on npm, with @moq/net listed. The README also points at an agent setup page that teaches a coding agent how to build with MoQ, which is an unusual but concrete onboarding path if you would rather have tooling read the docs than read them yourself.

Where the dumb-relay design pushes work back onto you

The rule that the CDN knows nothing about your codecs is what makes cross-region clustering plausible, and it is also the source of the main limitation. Anything that requires knowledge of the media has to live in the client or the media server. hang is the layer that carries that knowledge, and the README describes it as pretty simple and only intended to be used by clients or media servers. Simple is a stated design property, but it also means hang is not a full media framework, and the escape hatch is to extend or replace it.

The relay's ignorance has a second consequence. If the server cannot see your tracks, it cannot make application-level decisions about them, and the README's own framing is that everything could be fully E2EE and the CDN would not care. That is a strong property for privacy and a weak one for any feature that assumes server-side awareness.

There is also a packaging limitation that will bite before any of this. The workspace splits crates that need extra toolchains out of the default build, so the parts of the repository most likely to interest a media engineer, the GStreamer plugin, the FFI bindings, and the C bindings, are exactly the parts you have to opt into with the right system dependencies installed. If you evaluate by cloning and running cargo build, you will conclude the project does not ship them.

How MoQ differs from WebRTC in practice

The comparison the README invites is with WebRTC, and the difference is structural rather than a matter of degree. WebRTC bundles transport, session negotiation and media handling into a stack that every peer must implement. MoQ delegates the core networking to a QUIC library and keeps the rest in application space, which the README says gives you full control over your media pipeline.

The practical difference shows up in the middle of the path. A WebRTC fan-out requires the infrastructure between publisher and viewer to participate in the session. A MoQ relay fans out without understanding what it is forwarding, which is what makes the massive scale claim coherent: the relay's job does not grow with the number of codecs or track types.

If you already have an HLS or DASH pipeline, the README's analogy gives you a second comparison. hang plays the role of the segmented delivery format, and moq-lite plays the role of the transport underneath it. The difference is latency: segmented delivery is built around buffering, and MoQ is built around QUIC prioritization and partial reliability. If your viewers tolerate a few seconds of delay, HLS and DASH remain simpler, better-supported choices, and MoQ is the wrong tool for that job.

Maintenance, licences and what upgrades cost

The repository is not archived, and the last push was on 2026-08-27. Three releases landed that day: obs-moq v0.5.11, moq-gst v0.3.7, and moq-ffi v0.3.14. The version numbers are the useful signal here. obs-moq and moq-gst are below 1.0, and the crates are versioned independently rather than as one product, so an upgrade is a per-crate decision rather than a single bump.

The repository is licensed Apache-2.0, and it also carries a LICENSE-MIT file at the top level, which is the usual dual-licence arrangement for Rust projects. The README does not spell out the terms of that arrangement, and this is not legal advice: if the distinction matters to you, read both files rather than assuming which one applies to which crate.

The release tooling is visible in the repository layout. There is a .release-plz.toml at the top level, and a release-plz configuration typically automates version bumps and changelog generation per crate. That is consistent with the independent versioning of obs-moq, moq-gst and moq-ffi, and it means the upgrade surface is the crates you actually depend on. The Rust workspace also sets a toolchain floor, with a comment stating that the floor for the library surface is 1.91 because iroh 1.0 via moq-native needs it, and that moq-relay overrides it to 1.95. If you consume moq-net, hang or moq-native, that 1.91 floor is part of your build environment, and bumping a single crate can move it.

Editorial conclusion

Adopt it if you are building a live media path where WebRTC's coupling of transport and media logic is the obstacle, and you are comfortable working against a draft protocol with a narrower moq-lite subset. Do not adopt it if you need a stable wire format with long-term compatibility guarantees, or if you cannot run a relay with TLS on a real domain. Before committing, verify which of the two wire protocols your target CDN negotiates, confirm the Rust toolchain floor your crates pull in, and check that obs-moq or moq-gst actually exposes the codecs you publish.

Frequently asked questions

Official sources

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