Secure live streaming,
with maximum privacy protection

A relay never holds a key, so this isn't what protects your video — the encryption is. It decides something else: how much an attacker gets if a relay falls, and how much has to keep going right for that to stay true.

The ordinary way to run this is containers on Kubernetes, and Kubernetes can be locked down well. The trouble is that its security is a set of policies someone has to choose, apply, and keep applying — and each one has an off switch. kubectl exec hands you a shell inside a running workload, gated only by a permission someone can grant. Containers share one kernel, so a kernel bug is an escape, and the settings that stop a container mounting the host are enforced only if an admission policy says so. Without a network policy, every workload can reach every other. The container image itself ships a package manager and a shell, so the post-exploitation toolkit arrives with the app.

Our relays are Hermit unikernels: a single program in a single address space, booted directly under a hardware-virtualisation boundary. There is no shell to reach — not disabled, absent. No package manager, no filesystem, no users, no second program to pivot to, and no persistent disk; idle relays are reaped and the machine stops existing. None of that is a policy anyone can relax later, which is the whole point: a hardened cluster is a state you must maintain against drift and deadlines, while a unikernel's hardening is a property of the artifact.

One relay carries exactly one stream. Many viewers of that stream share it — that's what a relay is for — but two different broadcasts are never put on the same machine, anywhere. So a compromised relay is confined to a single broadcast by a machine boundary rather than by a setting. Your access token names one broadcast as well, which means even sharing a relay would grant nothing: two independent barriers, not one. And the fleet is given only the public half of the signing key — it can check a token, it cannot forge one.

Where the argument stops. The machine hosting those unikernels is still an ordinary Linux box running a fleet manager — "nothing to log to" is true of the relay, not of the system around it, and that host is the real target. A smaller ecosystem also means fewer eyes and slower patching than the Linux container world. And a unikernel bounds the damage from a bug in the relay — it doesn't make the relay correct. TRUST.md has the full comparison.

Why we serve our own copy instead of linking to a CDN

The transport runs on the same page as your content key. Whoever serves that code could swap it for something that reads your key straight out of the link and mails it elsewhere — no bug on our side required. So the only version of it we're willing to run is one we serve ourselves, fixed at deploy time and reviewable in the repo.

Pinning a version on someone else's CDN is not the same thing, which is easy to miss. A pin names a version, not the bytes behind it — and it only covers the package you named. @moq/net pulls in four more (@moq/qmux, @moq/signals, async-mutex, zod) as version ranges, which a CDN resolves fresh on every request. Pin the top package and a new release of any of the four still starts running on this page, unchanged on your side.

So we build it once from exact versions and serve it from this origin. Nothing about it is modified, and you shouldn't take our word for that — the build is reproducible. The recipe is four commands; run them and you should get a file whose SHA-256 matches the one we ship, which you can also compare against Luke's upstream source. It's left unminified so it stays readable. Full reasoning and the honest limits are in TRUST.md.

Host your own client code

Six files, no build step. Download a copy and serve it from your own domain. HOSTING.md covers verifying it, and what it doesn't change.