published 12/21/2025

You Don’t Need It

MoQ is a neato new live media protocol. It’s backed by some of the biggest companies in the world, some big and some small. It’s easy to get caught up in the momentum:

• Should you use MoQ?
• Is it an existential threat?
• Do you adopt it ASAP?

I’m the idiot that quit their job to work on MoQ open source. I’m at the forefront of peddling this new protocol. The most invested person in the world.

But I’m obligated to say: you don’t need it.

There are often better alternatives. You need to take a step back and evaluate the problems that you’re trying to solve.

Problem Driven Development

I need to preach like a LinkedIn influencer for a bit.

You are Bob. You are a builder. You build software, hopefully for money, and hopefully to solve a problem.

• You should use technologies that solve problems: an AI editor.
• You should try technologies that might solve problems: an AI fridge.
• You should not use technologies that do not solve problems: an AI toaster.

The hardest part of the job is figuring out what problems are real. There are plenty of solutions to evaluate, and you need to figure out if they could solve your problems. My road to MoQ took years of trial and error. There are no shortcuts.

guest271314 is wrong about virtually everything, but one of his turds of wisdom has stuck with me:

He’s right unfortunately, but on a technicality. guest271314 only has one user and all his media is served via localhost. Virtually any technology will work for him and they all behave the same. Your problems are scoped to your users.

Solution Driven Development

We are creative animals, always striving to resolve problems in new and “interesting” ways. “Not invented here”. “Rewrite it in Rust”. “DOOM on a pregnancy test”.

That’s why I love programming; it’s a puzzle with an infinite number of solutions. But there’s only a finite number of problems to solve, so sometimes we invent new ones. Build a solution, and then try to find a problem.

Virtually every Javascript framework ever created has fallen into this trap. The entire blockchain industry is built on this principle. Unfortunately, I think the IETF working group has also fallen into this trap.

My go-to example is FETCH, a mandatory to implement verb in moq-transport. It’s trying to reinvent HTTP… without trying to solve any of the problems with HTTP. It’s a huge waste of time even if the design was perfect (it’s not).

Just use HTTP. There is no problem to solve here. As a bonus, you fix a real problem and support “old” clients still using HLS/DASH. You don’t need MoQ for your VOD content.

Production Driven Development

Okay, last LinkedIn influencer moment and then we can get to actual hot takes. In a previous blog post, I ranted about how critical it is to focus on the application.

You should always plan for production because it makes our monkey brains think about problems. Otherwise, the boring problems get punted in favor of building cool solutions. Authentication is boring, backwards compatibility is boring, etc.

Vibe coding a cool prototype is fun, but soon enough you’re in too deep. There’s no turning back now to readdress these boring problems. You ship a shit product rather than declare bankruptcy. And everybody laughs at you.

Of course, you can always live a hermit lifestyle like guest271314. Programming is fun, and sometimes your code never needs to leave localhost. You just have to leave a big disclaimer that “you should not use this”… instead of spamming the MoQ discord pretending to be an expert.

You Should Not Use This

Enough blabbing, let’s get to some concrete examples already:

You should not use MoQ for high-quality content.

Wow I bet you didn’t expect something so blunt. There’s a lot of nuance of course.

TCP vs QUIC

Unequivocally, TCP is the best protocol for reliable content delivery. It has universal adoption and has been hyper-optimized for decades. There are massive CDN companies fighting to charge you pennies to serve your funny cat videos over HTTP.

The problem with TCP, of course, is that its reliability comes at the expense of latency. Specifically, TCP will queue data during network congestion. QUIC (and UDP in general) gives you the option to sacrifice reliability instead.

And that’s all it provides. QUIC can’t move more bytes, or move them faster. Your 100MB cat video will take just as long to download over QUIC as it does over TCP. QUIC only offers a way to drop old data instead of blocking on it, which is why we use it for MoQ.

So if you’re delivering “high-quality content”:

• Do you want to sacrifice quality for latency?
• Do you want viewers to skip chunks of the sportsball game?
• Can viewers even discern the difference between 200 milliseconds or 5 seconds of latency?

If the answer is NO, then you should not use MoQ. You should instead use HTTP or maybe even WebSockets (for 1:1 stuff).

But What About “Maybe”?

Here’s the promised nuance. One of the selling points of MoQ is the flexibility. The same protocol can serve a variety of different use-cases.

For example, I initially built MoQ for Twitch. In theory it falls under the “high-quality content” category above, even though most of the content consists of loading screens and bathroom breaks.

However, Twitch chat is why MoQ exists. OMEGALUL

The project initially started with WebRTC, giving users the ability to have real-time chats with their favorite streamers. Some users want to sacrifice quality for latency. It’s a really cool experience that I wish we got to ship.

But most users don’t want their live stream served with Google Meet quality. They don’t care about latency if they’re not engaged with chat. They don’t want video to be skipped, and dare I suggest it, they might even want buffering. Constant micro-stutters can be more jarring than a one time buffering event.

So you, roleplaying as Bob the Builder, can choose to build:

• two separate stacks, one for HLS and one for WebRTC?
• or a single MoQ stack and let viewers can choose their experience?

There’s no right answer. I chose the latter and look where I ended up.

What about my Use-Case?

Unless you work for a Twitch clone, your use-case will be different. I can’t pretend to understand what you’re building, but that’s not going to stop me from giving unsolicited advice.

AI Voice Chat: Don’t use WebRTC. Otherwise you’ll spend so much money/time running the model only to drop the output at the network layer. Use WebSockets until models get much faster, then consider MoQ.

Live Sports: Use HLS/DASH. Consider MoQ if some users want gambling or “interactive” content.

Conferencing: Use WebRTC if you want a Google Meet clone. Consider MoQ if you want to do dumb custom shit.

Production Studio: Use SRT because that’s what your expensive hardware supports. Consider MoQ if you’re doing cloud compositing and to avoid pushing all feeds.

Look you get the idea. Consider MoQ if there are problems with the usual suspects. It’s a green field with its own set of problems, but you can help chip away at them.

FIN

Join the Discord already and help me troll guest271314.

Just make sure to read the #rules first.

Written by @kixelated.