published 4/16/2026

Here’s my MoQ copy of Twitch Plays Pokemon. But there’s a dilemma: I don’t want to get sued by Nintendo. So enjoy homebrew games instead lul.

The emulators are running on VMs in Texas, so don’t flame me if the latency is high. And remember to scroll down and read the actual blog post once you’re done GAMING.

The Arch

There are N emulator workers. There are M human players.

They use a single connection to a generic MoQ CDN for EVERYTHING.

But how??

On-Demand

But I want to first gloat about a secret feature. A feature so secret, I gloat about it first. SAVING MOOLAH.

When a viewer wants audio and/or video, they issue a SUBSCRIBE request to a MoQ CDN. The MoQ CDN slurps up all SUBSCRIBE requests for the same track and combines them. The end result: the underpowered cloud VM running the emulator gets at most one SUBSCRIBE request per track, regardless of viewer count.

By default, a MoQ publisher will only transmit a track if there’s an active subscription. Our emulator would encode media, but those precious pixels would sit in RAM until there’s a viewer.

But we big brain. That not good enough. Instead we turn the encoder on/off if there’s an active subscription:

• If there’s no audio subscription, the Opus encoder sleep.
• If there’s no video subscription, the H.264 encoder sleep.

But we even bigger brain than that:

• If there’s no audio AND video subscription, the emulator sleep.

We’re not burning through the CPU/GPU unless some eye balls or ear holes will benefit! Try scrolling back up to the demos and you might see a brief black screen. The player automatically UNSUBSCRIBEs when out of view, and if everybody does it, then no more Mr. Emulation.

Saving bandwidth/CPU is obviously not a huge deal for a gameboy emulator. The screen is 160x144 after all, even your vape pen could run it.

But it does start to matter for anybody running expensive subscriptions.

• If nobody wants captions, then don’t run Whisper lul.
• If nobody wants H265, then don’t transcode it lul.
• If nobody wants to watch your shitty Lets Play, then send it to /dev/null lul.

And it’s all built into MoQ baybee.

Discovery

A boring person would have hard-coded the list of available games. But I’m HYPER-C00l, so MoqBoy instead uses MoQ’s ability to live discover available broadcasts.

There’s a separate binary for ROM. Right now they’re all running in Texas (yeehaw). They connect to the closest cdn.moq.dev node and:

• Worker 1 publishes demo/boy/big2small.
• Worker 2 publishes demo/boy/opossum.

The first thing a player does is ask the MoQ CDN for every broadcast with the prefix demo/boy/. It will get a live notification when games come online and go offline. Like a city planner, we throw them in a grid.

Also I can’t let this slide. “opossum” is a made up word. It can’t be spelled like that. It can’t be real. Who took a look at that thing and decided, that right there is an “opossum”.

Anyway, this is also how hang.live discovers other users. It’s as easy as “tell me when somebody publishes a broadcast starting with room123/”. You don’t need a separate “room” service that manages membership.

Just use MoQ lul.

Controls

MoQ is a one-directional protocol. Broadcasters broadcast, viewers view. But how do players play?

Psst, I’ll tell you a secret. Viewers can be broadcasters too!

Each player publishes a broadcast called demo/viewer/big2small/<id>, with a random ID. They produce a single controls track, and when a button is pressed, writes a JSON blob to it:

{
  "a": true,
  "up": true
}

The MoqBoy publisher uses the same DISCOVERY mechanism listed above to find all players. It subscribes to the controls track for any broadcasts with the prefix demo/viewer/big2small/.

Bada bing, bada boom. We now have a “bidirectional” stream by using two unidirectional streams.

But why not build bidirectional streams into MoQ proper? Well it’s because of business logic you nerd.

• MoqBoy uses anarchy, where the broadcaster chooses to SUBSCRIBE to ALL players.
• Your flesh mangling robot might want enforce lockout, where the broadcaster chooses to SUBSCRIBE to ONE player.
• Or your flesh mangling robot has reached AGI (Sam be proud) and doesn’t want to SUBSCRIBE to ANY pathetic humans any longer.

One perk of unidirectional streams is that they easily fan out. Multiple robots can subscribe to the same killswitch track. They obviously will ignore it, but the thought counts.

It’s also just easier to scale a protocol that ALWAYS fans out. We’re not in the business of adding business logic to the relay to merge JSON blobs or some other nonsense. Your application is responsible for implementing fan in.

Open Source

Oh right and you can run it yourself. Setup the mono repo, then run just boy.

It’s fun to type. Just boy. Just boy.

If you’re too lazy to ask AI, here’s the relevant folders:

• Rust publisher
• JS player.
• Web/ROM stuff.

The Software Mansion folks are hard at work on React Native bindings. Here’s a sneak peak of this MOQ BOY demo running on a real phone!

Definitely hit them up if you want MoQ on phone. Or use the open source Rust -> C/Kotlin/Swift/Python bindings yourself!

A Real Demo

So I know this looks like a fun emulator side project, but I swear it’s not. This is meant to be a DEMO of how you should use MoQ for robots, drones, and other murder machines. Just replace the GameBoy emulation with REAL LIFE via a camera feed, nobody will be the wiser.

Also, I’ve started contracting as a way of getting MoQ pilots off the ground (literally and figuratively). My primary goal is expand the MoQ ecosystem, even if it means signing NDAs.

Email me at me@kixel.me, or DM on Discord if you want:

• some advice on how to use MoQ.
• to sponsor some open source contributions.
• a MoQ pilot to replace your crummy setup.

Written by @kixelated.