Who gets to build with MOQ

MOQ is the opposite of democratizing media access. It might not seem like that, but that’s how things are moving forward with MOQ.

If you’ve been around here, you probably know what I think about MOQ - it is a solution looking for a problem that will redefine streaming. An interesting combination to say the least. 3 more months of problem-seeking for MOQ turned up a couple more candidates, along with some more insights on where MOQ is at the moment - the hype versus reality. And then, we’ll get to the heart of it - MOQ takes the total opposite shape of WebRTC.

Before we begin - know this - I think MOQ will succeed. The engineering focus behind it is there. The success will come from sheer force of will. Less from a real technical gap.

Let’s dive into it to better understand this.

Key takeaways: TL;DR

• WebRTC democratized media access by shipping a complete, opinionated media engine into every browser, free and maintained
• MOQ is built the other way around: the CDN must know nothing about your application, which pushes media logic into your own client code
• That includes the hardest parts, and congestion control is the clearest example - MOQT simply does not specify one
• No browser vendor is planning a libWebRTC equivalent for MOQ, and every team shipping MOQ today already came in with deep media streaming experience
• Four years in there are zero end-user services running on MOQ, so the question to ask is whether you have the people to build the half it does not ship

What WebRTC actually gave you

To understand MOQ, let's start with the topic closest to my heart - WebRTC.

WebRTC came to our world around 2011. I remember watching it and getting a warm fuzzy feeling that my world is about to turn upside down. I’ve been doing signaling and video conferencing for 13 years up until that point. WebRTC pulled the rug below my feet, with a solution that made my work redundant and unnecessary.

What WebRTC did was sidestep the question of signaling and provide a rock solid implementation of a modern media engine in the form of libWebRTC. The SRTP piece was nice, but never the deciding factor. What you actually got was a complete opinionated package: jitter buffer, congestion control, echo cancellation, packet loss concealment, A/V sync, device handling. None of it is written in any specification. Someone else made every one of those calls, and you might well have made them differently. It came free and maintained.

Not only that - it was all already embedded and shipped with every modern web browser. What more could you ask?

All this goodness democratized real time communications and video conferencing.

It took a vocation that required a certain skillset and opened it up for the masses.

I remember in the first few years, collecting and curating a dataset of vendors making use of WebRTC. Most had no VoIP background. Most tackled the thing called video conferencing in weird and innovative ways that I couldn’t fathom in the beginning - after 13 years in VoIP and video conferencing I just knew this isn’t how you do things. Seems I was wrong.

That democratization? It got us telehealth startups. CRM vendors who added calling directly in their platform - no third party call center needed. Web agencies who started shipping WebRTC applications.

Democratization.

WebRTC removes barriers of entry.

What MOQ gives you

MOQ is different. It may have started as a streaming specification. Since then it has turned into a catch-all monstrosity.

MOQ gives you transport with a publish/subscribe model. Something generic enough to be able to route it via generic CDNs. That was the whole point of it. Oh - and we want it to do that for both live and cached content.

The first rule of MOQ based on its biggest fan? Just read it at moq-dev/moq:

Rule 1: The CDN MUST NOT know anything about your application, media codecs, or even the available tracks. [...]. No business logic allowed.

The bolded words are in the source - not my additions.

No business logic allowed on the transport itself, and all them relay servers (=CDN) must be generic, the result is that every piece of that media control and processing logic implementation takes place on the edge in YOUR application. Not the browser’s own implementation. You. That thing is written in JavaScript and WASM.

This isn’t something that will be resolved next year or the following. It isn’t something the standards people will get to as the specification of MOQ matures. It is like this by design.

It is MOQ’s biggest advantage - having generic CDNs deployed en masse - and its weakest link - not being able to optimize or run as business logic in the network at all - the client-side implementation needs to work around the limits of its generic relay counterpart.

Here are the keys. Now go build the engine for the shiny new car we’ve given you.

What you end up writing yourself

This one is rich. And the answer is quite a lot. And not the type of writing you expect to do in a web application. More like the low nitty gritty things you expect a solid media engine would do. But… MOQ isn’t that.

There are challenges. Quite a lot. Here are two that are embarrassing for a specification pretending to displace WebRTC for live media streaming.

Dealing with Congestion Control. A discussion from 2022 around how to handle congestion control. Dealing with bufferbloat and other nastiness that lurks in our modern networks. Ideas like Reno, CUBIC, BBR, GCC, etc all raised as potential suggestions. WebRTC obviously does that for free - and quite good - with ever improving and well tuned algorithms. And yet… what was the decision for MOQ?

"MOQT does not specify a congestion controller, but there are important attributes to consider when selecting a congestion controller for use with an application built on top of MOQT."

Black ink written over standard.

You take the hardest part of the implementation, and instead of solving it for your target users - you let them deal with that headache - why should you? It isn’t as if you’re here to solve real problems (just find problems for your preexisting solution).

(WebRTC did the same with signaling, but that was never the hardest part - it freed the developers and further democratized the potential solutions and availability of WebRTC to a larger audience)

This one truly left me speechless.

I’ll leave you here with another one. The great MOQ specification is the gift that keeps on giving - once you scratch its polished surface a bit.

Enabling Low Latency Adaptive Bitrate Live Streaming of Scalable Video Encoding (SVC) encoded media using MOQT

Let's say you want to do complex video conferencing. Or just place a bit more onus on the publisher by having it handle layering with SVC. How do you do it with MOQ?

Well… based on the person suggesting it - this is about “scenarios where the MOQT implementation had to deviate from the draft”.

You’ve got a draft that can’t keep up with all the scenarios people try to build on top of it. It is just too generic for its own good.

Here’s how the two specifications line up:

Yes. MOQ is truly the best thing after sliced bread. They just forgot to put the flour in there. And the yeast. But sliced it is. Chopped into thin bits and pieces of nothingness.

Look at who is actually building it

The same companies pushing MOQ are the ones building it. These engineering-heavy teams with experience in media streaming: Cloudflare, Meta, Google, Red5, nanocosmos, WINK Streaming, Software Mansion, ….

There is no team anywhere that has shipped a MOQ application that isn’t coming with a strong foundation of media streaming background. Not one.

In WebRTC? The generalists outgrew the video conferencing and VoIP crowds from day one.

Welcome back to 1998!

Is that how we want the future to look like?

The layer that would fix this does not exist

No browser vendor is planning a higher-level MOQ API. The browser gives you WebTransport and WebCodecs. Now go build the thing yourself.

Here’s what’s missing: a libWebRTC like thing for MOQ. we’ve got multiple transport toolkits for MOQ already: moq-rs, red5-moqpub, moq-kit, moqtail, aiomoqt, moqtransport.

Look at Meetecho, the company behind Janus, a media server for WebRTC and one of its earliest adopters. Lorenzo Miniero, the lead developer behind it, just streamed the IETF’s own MOQ working group sessions over MOQ - by gatewaying WebRTC into it and hand-writing the browser player. Here’s what he had to say about the experience itself:

"In fact, while browsers are basically the ideal MoQ participant (using WebTransport and WebCodecs), we cannot rely on the media stack browsers make available out of the box for WebRTC, and we have to write one from scratch, with all the pain and misery that this brings."

Oops.

And here I was, thinking MOQ would free me from all the pain and misery of WebRTC, just to fall into more pain and misery. The type that WebRTC solves.

Meanwhile MOQ is being proposed for everything

Go read about the suggested uses of MOQ. It is the silver bullet for EVERYTHING on the internet. This won't get it far. It will end up like IPv6, in 30 years most of us still won't use it. I wrote exactly that in WebRTC Insights in January. Eight weeks later, Cisco, Google and Five9 filed a draft putting JSON-RPC on a media transport.

This is the Internet’s snake oil in 2026. And I’ve got a bottle of it for you, to cure all your pains.

What is MOQ for exactly? I thought the purpose was to decommission HLS and MPEG-DASH with it, while offering low latency streaming.

Now it is the everything-transport.

Voice. Video. Data. Everything.

Want some interesting uses?

Communicate with MCPs (because WebSockets are so 2025). draft-jennings-ai-mcp-over-moq-00. Authored by Cullen Jennings (Cisco), Ian Swett (Google), Jonathan Rosenberg (Five9) and Suhas Nandakumar (Cisco). This one puts MCP resources, tools, prompts and Agent Skills on MOQT objects. This one has no audio. No voice, No WebRTC. No SIP. No VoIP. No streaming. It is JSON-RPC borrowing a media transport because WebSocket has no prioritization or relays.

Voice AI components (here’s the problem we knew we needed). Draft-liu-moq-live-agent-interaction-01. This one from Alibaba. It maps ASR transcripts, LLM tokens and TTS audio to MOQT objects with turn-taking and barge-in. Because WebRTC data channels are so yesterday. One wonders… how would this fare against the path taken by OpenAI with WebRTC and its continuous streaming approach…

Did anyone mention a solution looking for a problem?

The new problem for the solution

We now see another problem set finding a home in MOQ. Or maybe it is MOQ finding its next problem to try and solve. Teleoperation and robotics. The thing that links and lends itself strongly to the surveillance market.

There’s some merit here. A notion that this somehow needs to be faster and at a lower latency than WebRTC. No voice path means no need for lip synchronization. A need for a more aggressive jitter buffer that is impatient compared to the one in WebRTC.

The thing is that to get there, we’re building the whole stack from scratch. The same one with minor tweaks. Wouldn’t it make more sense to go through the standardization and implementation processes for WebRTC and get it into libWebRTC? OpenAI did just that when what they needed was faster setup time with less round trips.

Inventing the wheel all over again is much more satisfying.

So where does this leave you

MOQ is a challenging technology. Seemingly simple, with no moving parts.

A promise of CDNs installed and operated by third parties for you (hello Cloudflare). The rest work out of the box with no moving parts. Shed that ugly piece of WebRTC machinery and infrastructure and leave it behind.

And yet…

Four years in and there’s still zero end-user-facing services running on top of MOQ. Nothing consumer related. Nothing enterprise. Just a few vendors within the same clique authoring and showing off demos to one another. Claiming things about WebRTC that are not true.

The numbers? MoQ in Chrome requires WebTransport so this is a subset of what we see on the graph here:

Compared to WebRTC that is noise.

MOQ is at draft-19, 148 pages. The wire format still isn’t settled.

Red5, Cloudflare, nanocosmos and others have all shipped MOQ. Red5 went GA in April, which I doubted out loud a few months back. And at NAB 2026 they showed the thing interoperating: Bitmovin’s Player Web X pulling a live stream off Cloudflare’s relay network, Ateme encoding into Oracle’s relay fabric, with more than a dozen vendors on the floor running some flavor of MOQ.

So much for my dare.

Except someone outside the clique took it. Nimble Ape live-streamed CommCon 2026 over MOQ in June: OBS with the moq-obs plugin, into Cloudflare’s relay, into a browser player they wrote themselves. The plugin targets draft 15 and up. Cloudflare’s relay was on draft 14. No FETCH, no SUBSCRIBE_NAMESPACE, which killed VOD and replay and made debugging harder. A/V sync drifted and needed stream restarts. Audio stalled. Chrome only, because MediaStreamTrackGenerator is the only way to feed decoded frames into a video element and Safari does not have it. Their own verdict: "a proof of concept, not a production-ready player".

And the line that belongs on the inside cover of every MOQ pitch deck: “These are things that every streaming stack does internally, and which we usually take for granted... With MOQ at this stage, you ship it yourself”.

More than a dozen vendors showed their demos on a show floor in April. In June, one competent engineer wiring OBS to a public Cloudflare relay hit a draft-version wall.

The biggest MOQ adoption question

I think what is changing is the adoption question for vendors.

We shouldn’t ask “should I use MOQ for my service? Does it fit my interactive piece of the application? Can it fit the distribution path, replacing HLS?”

What needs to be asked is this: “Do we have the people to build the half that MOQ does not ship?”

And no. Vibe coding won’t get you there. Not in 2026. Asking Claude to read WebRTC’s spec and implement it in WebAssembly for you so you can use it on top of the browser has a nice sound to it, but it will fail miserably. Most of the challenges today aren’t in re-implementing the spec verbatim. It is understanding how network, device and user behavior shapes an interaction. Especially in edge cases. Particularly in the real world.

What you will be trading here is the vast real life experience poured into the implementations of WebRTC for a shiny new tool.

In 2026, we’re going away from democratizing media access to the masses, handing the keys to this domain to the hands of the few. Is that really what we want to do? Is that called progress?

Going with MOQ? Ask yourself these two questions:

• How unique is your use case?
• How experienced is your team in live media processing?