MOQ is lacking a compelling adoption reason

MOQ has the consortium, the demos and the press releases. It does not yet have a single flagship customer asking for it.

MOQ is the prom queen these days. Everyone’s talking about it and seem to be interested in it. A lot of noise and hype that it feels as if not doing it means missing the boat. As my role as the ruiner of dreams, it is time to take a close hard look at MOQ and why I believe it is a solution looking for a problem.

This isn’t to say it won’t succeed – just that important missing pieces of this puzzle are making it incomplete. Here’s why…

Why another MOQ article?

In January 2026 I predicted that 2025 was the year of talking about MOQ and 2026 would be the year we start seeing real POCs of it. We are now five months into 2026. The vendor announcements have continued. The POCs have not.

That article followed a deeper explainer of MOQ for streaming use cases. I had some conversations since then about MOQ, and there were quite a few announcements made in NAB 2026 last month. One specific conversation resonated with me – a person working in the industry on live streaming, wondering if it was the right time to invest in MOQ. He was quite skeptical and seemed to want his opinion validated. During that conversation it dawned on me – the issue with MOQ isn’t a technical problem. It is a market problem.

MOQ is still at its infancy with lots of vendor noise:

• Red5 announced “Playa” MOQ player and a CacheFly-powered MOQ relay network, claiming consortium consensus across six independent player projects
• Cloudflare’s MOQ relay is live across 330+ data centers, still in beta, with no flagship customer named
• NAB 2026 had MOQ demos from Wowza, Ant Media, AWS, Broadpeak, Nomad Media, Oracle, Norsk and others. Most were lab-grade
• The IETF MOQT draft hit version 17 in March 2026. Sergio Garcia Murillo flagged that the control plane was redesigned from a single bidirectional stream to a pair of unidirectional ones – a foundational architecture change three drafts in a row
• Luke Curley, who left Discord to work on MOQ and is listed as a draft editor on the IETF MOQT spec, wrote on his own blog that “you should not use MOQ for high-quality content

When someone working on MOQ publicly tells you what not to use it for, that is worth pausing on.

Customers do ask about MOQ. The framing is always the same: “should we start looking at this now, or is it still too early?” That is not pull. That is people seeking validation that their own skepticism is warranted.

That gap is what this article is about.

What MOQ actually is

MOQ is about sending arbitrary data over QUIC, doing so with CDNs and media streams in mind. It maps nicely to similar/same internet architecture as other web streaming technologies out there such as HLS and MPEG-DASH.

This going over QUIC gives it huge benefits as to parallelizing streams and fitting both low latency versus high quality data.

The end result though is two distinct protocols/techniques crammed into one. If you want something that is sub-second in latency, you use a certain set of directives in MOQ. if you care less about latency and more about quality, you’re in the second lane.

The stars seem to arrange themselves nicely for MOQ, as the transport layer (WebTransport) is getting support natively across all modern browsers. For the browser use case – it is getting covered these days.

These two distinct protocols/techniques? They are fighting over the attention of two other protocols in two different markets:

Real time – WebRTC already won

If you are in the sub-second realm of interactive video, then WebRTC is the main game in town. As a protocol, it can’t even wait in order to get better quality – its main directive is to get you the lowest possible latency at a decent enough media quality. That’s it – it prioritizes latency over quality almost always.

WebRTC has been with us for more than 10 years now, solving technical challenges of video calling, conferencing, watch parties, cloud gaming, public safety, drone teleoperations, call centers, telehealth… the list goes on.

The market has made its choice. Some are grumbling, but all in all – WebRTC has been solid. So much so that OpenAI openly stated its use of it at a huge scale for Voice AI workloads.

There is a reason why WebRTC is there and MOQ is but a distant pipe dream. MOQ lacks all the built-in bidirectional tooling that WebRTC has – NACK and jitter buffer for example. The nuances that make WebRTC tick all the relevant boxes of interactivity in real-time communications. All of it is free, whereas with MOQ, you are left to build it on your own.

That building it on your own? You’ll find out that it brings with it a lot of the baggage people grumble about with WebRTC.

Even the vendors openly supporting MOQ, state the boundaries of its purpose and usefulness as streaming and live streaming. WebRTC is bidirectional. MOQ is one to many delivery only.

What everyone fails to mention is that WebRTC already does live streaming as well, with vendors offering solid solutions for it – and where the complaints about it (mostly price points) are going to stay the same for MOQ as well – that’s because pricing here is highly dependent on bandwidth costs – not caching optimizations that are close to none for live streaming – and there, MOQ sends over the network just as many bits as WebRTC for the same quality.

Who is going to fund that additional R&D costs?

Streaming – HLS and DASH got you covered already

Streaming then. MOQ can replace HLS and DASH for streaming things above a few seconds of latency.

The thing is that all these acronyms – HLS, LL-HLS, DASH and LL-DASH are entrenched. CDNs, ABR ladders, DRM, ad insertion, captioning, analytics. Every piece is solved and monetized.

Apple, Google, Netflix, every major broadcaster runs on these. The infrastructure is paid off. The tooling is mature. The hires are easy to find.

MOQ does not just need to be technically good. It needs to be good enough to displace something that already works at planet scale. That bar is much higher than the bar to publish an RFC.

And in order to displace these, there’s this minor need for users to actually need it. What will replacing HLS with MOQ give the consumer? The broadcaster? The CDN? What is the compelling event for THEM to choose MOQ over HLS?

None.

What MOQ actually changes. And what it doesn’t

Here’s a reality check.

MOQ is a great protocol, but is it solving a real problem for real people? One painful enough to invest in.

Tunable latency on a single transport and protocol is a nice solution. MOQ does that by marrying two protocols internally. The jury is out there as to which CDNs will end up implementing both, versus specializing in one over the other.

Sliding between 200ms and 5s in the same protocol and session is something HLS/DASH cannot do. Per-session sliding is rare. Most products pick one latency target and stay there. The portfolio case is more interesting. An operator running both interactive (sub-2s) and live (5s) experiences today runs two stacks. MOQ promises one. Whether one stack with two modes is meaningfully cheaper to operate than two specialized stacks is an open question. I have not seen anyone publish numbers on this. I would read that post.

The truth is that over the wire, these are the same bits with similar CPUs moving these bits around. Optimized slightly less or slightly more. Nothing to write home about.

The cleanest theoretical advantage is that TURN isn’t needed and signaling fuses with media transport, because MOQ rides on WebTransport, which is QUIC with a JS API on top. In time, as HTTP/3 reaches across networks, NATs and firewalls, MOQ does the same. Less moving parts is always great.

The catch: the operator gets that win. The end user already does not see TURN. Network behavior gains accrue to whoever runs the infrastructure, not to whoever generates the demand. That is one more reason vendors are excited and customers are not.

But is this enough for a technology shift?

Push or pull?

MOQ is aggressively being pushed in the market these days.

This is done by vendors that are loud about it and credible: Akamai, Cisco, YouTube, Cloudflare, Google (Shaka), Bitmovin, Synamedia, Red5, CacheFly. That is real engineering investment. It is not the same as users asking for it.

The pull side is missing.

Who is this for? Who ends up enjoying it? Would they pay for the technology upgrade, directly or indirectly? The standards process seems to be driven by vendors hunting for an opening, not by use cases hunting for a protocol.

Cloudflare is the cleanest example. They deployed MOQ to 330+ data centers and still cannot name a flagship customer. Infrastructure without traffic is the loudest possible signal that the protocol is being shipped before the use case is found.

This is the WebRTC playbook in reverse. WebRTC arrived because the browsers and the use case (video calling at zero install cost) showed up at the same moment. Application developers needed it badly to be able to support their use cases inside web browsers. They ignore the fact that the spec wasn’t fully standardized, that browsers had a variation of the spec implemented, that they had interoperability issues across web browser implementations. Code and applications were shipped to production at scale.

But HTTP/3 was also vendor-pushed

A reasonable counter at this point is HTTP/3. Browsers and CDNs pushed it for years. End users never asked. Today it carries a meaningful share of web traffic. Why is MOQ different?

Mechanism. HTTP/3 succeeded because the upgrade was invisible to applications. Browsers, CDNs and origin servers handled it. Application developers shipped no code. End users never noticed. It still served a purpose beyond being technically nicer – it was a solution to a problem. It had actual benefits that were lacking in the existing solutions available in HTTP/2.

MOQ is not invisible. MOQ requires application-layer changes. A player rewrite. An encoder rework. A media format choice (WARP vs LOC vs CMSF vs MSF, currently fragmenting in the IETF working group). A pub/sub model. Namespace design. Six independent player implementations exist precisely because that surface area is large enough to disagree on.

HTTP/3 was a transport upgrade. MOQ is an application protocol. Different shape. Different adoption curve.

MOQ has the vendors. The use case is still being searched for.

What would change my mind

Here is the strongest version of the counter argument I hear from MOQ supporters. Of course end users have not pulled MOQ yet. The protocol is not RFC-published. Vendors build infrastructure ahead of demand because that is how internet protocols always roll out. Check back in 18 months.

It is a fair argument. It is also not the argument that fits MOQ specifically.

WebRTC won because it had a use case that did not exist before the protocol – in-browser video calling at zero install cost. MOQ is being proposed for use cases that already exist and already have working solutions. That is a different category. “Pre-deployment” assumes the use case is waiting for the rails. It is not clear what use case is waiting for MOQ specifically.

Also, the 18-month bet works only if RFC publication unblocks adoption. The IETF MOQ working group’s own milestones target MOQT for IESG submission by December 2026. Add IESG, IETF Last Call and the RFC Editor queue, and the realistic published RFC date is late 2027 to mid-2028. WARP and LOC are targeted for 2027. Even granting the wait, the user-pull problem is independent of standardization timing.

I love technology. I think MOQ is ingenious in its own way. With the vendors pushing it, it is likely to succeed eventually. There won’t be anything else to purchase besides MOQ for streaming services a few years down the road. That will end up being the compelling event needed.

Can it happen sooner and faster? Sure. Three things would do it.

• A flagship consumer service announcing MOQ delivery at scale – 30 to 50% of their traffic. YouTube Live, Twitch, Some other service. Pick one, ship it, prove the latency story matters at consumer scale
• A real production cost or performance number that beats HLS/LL-HLS for the same content, or beats WebRTC for the same interactivity. Not a benchmark from a vendor’s blog. Real numbers. Hard cost savings for a streaming service that cannot be achieved with existing technologies. I doubt these surface any time soon
• A use case that breaks both WebRTC and HLS/DASH cleanly enough that MOQ is the only sane answer. I cannot name one today. If you can, that is the post I want to read

Until then? MOQ is a solution looking for a problem.