published 12/22/2025

You Don’t Need It

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

• Do you need to adopt it?
• Is it an existential threat?
• How do you even pronounce it?

Don’t worry, I’ll answer most of your hypothetical sockpuppet questions. For context, I’m the idiot that quit my job to work on MoQ open source. I’m at the forefront of peddling promoting this new protocol. I’m the most invested person in the world.

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

Like everything in life, there might be a better alternative. You need to take a step back and evaluate the problems that you’re trying to solve.

Problem Driven Development

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 exist and which solutions are worth evaluating. My road to MoQ took years of trial and error.

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. It doesn’t matter how the media is transmitted, the user experience will be identical.

Your problems are specific to your product. There are no universal solutions.

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 are 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. Don’t get me started about AI. 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, but without solving any of the problems with HTTP. Without diving into the details, it’s a huge waste of time.

Just use HTTP. You don’t need MoQ for your VOD content. It’s not solving a problem, it’s only creating a solution.

Production Driven Development

In a previous blog post, I ranted about how critical it is to focus on the application.

I think you should always have a production plan, even for a prototype. It makes our monkey brains think about the boring problems that still need to be solved. Stuff like authentication, backwards compatibility, and other stuff that nobody has fun thinking about.

Of course, you can always live a hermit lifestyle like guest271314. Programming should be fun. Your code never needs to leave localhost. Just don’t spam the MoQ discord pretending to be an expert.

You Should Not Use This

Enough philosophizing, let’s get to the point.

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 delivery over the internet. It has universal adoption and has been hyper-optimized for decades. There are massive CDN companies eager 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) give you the ability to sacrifice reliability, opting to skip data 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.

So if you’re delivering “high-quality content”, you have to ask yourself:

• 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.

Twitch chat is why MoQ exists. OMEGALUL

Some users want to have a real-time chat with their favorite streamer. Some users want to sacrifice quality for latency.

Our first attempt used WebRTC. For the highly engaged users, this was great product. They don’t care if some video is skipped, they’re too busy typing OMEGALUL in chat.

But most users don’t want their live stream served via Google Meet. The quality of the broadcast is worse for no discernible reason. Some people just want to watch TV in their underwear.

So you, roleplaying as Bob the Builder, need to decide what 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.

Live Sports: Use HLS/DASH for mass distribution. Consider MoQ when some users want 1s latency for gambling or interactivity.

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

Production Studio: Use SRT because that’s what your expensive hardware supports. Consider MoQ when you need to save bandwidth.

AI Voice Chat: Use WebSockets and WebCodecs. Please don’t use WebRTC, otherwise you’ll spend so much money/time running the model, only to drop the output. Consider MoQ when models get much faster.

Look you get the idea. You can and should use whatever protocol best solves your problems. You don’t need to use MoQ just because it’s new and cool.

(but I don’t blame you)

FIN

Join the Discord already and help me troll guest271314. Just make sure to read the #rules first.

Written by @kixelated.