How you're protected

What Earthseed can and cannot see when you broadcast — and the parts we can't protect you from, stated as plainly as the parts we can.

We cannot watch your broadcast. Not as a policy we promise to keep, but because the key doesn't exist on our side. Your browser encrypts every frame — video and audio — before it leaves, using a key derived from a secret that lives only in the part of your share link after the #. Browsers never send that part to a server.

So it never reaches our servers, our database, our logs, the broker that places you, or the relay that carries your video. If we were asked for your stream, by anyone, we would have nothing to give.

What each party sees

Who	Sees	Cannot see
Us	That a broadcast happened, when, and how long	Your video, your audio, your location
The broker	The stream's name, that it was placed, your IP address, coarse geography	Your key, and anything inside the bytes
The relay	Encrypted bytes, your IP address, timing, the codec and resolution	Anything inside those bytes
Your viewers	The stream, if you gave them the link — and the passcode, if you set one	Anything else; they cannot publish as you
Everyone else	Nothing at all	Even encrypted bytes are out of reach without the link

You are not an account

There is no sign-up, no email address, no password, and no profile. Broadcasting needs a publish key, which you can request in about a minute without telling us anything about yourself. We don't store the key, so there is no record connecting you to anything you broadcast — nothing for us to look up, and nothing for anyone to compel from us.

Each broadcast also identifies itself with a cryptographic key created in your browser, whose private half is not extractable — script on the page can ask it to sign, but cannot read it out. So nobody can publish under your stream's name from somewhere else, and "New ID" discards that identity permanently.

We collect no location data

None — not country, not city, not coordinates, for broadcasters or viewers. Earlier versions of this site did record broadcaster location, in a database table belonging to a client that has since been deleted. That table, and a column that had held content keys, were dropped in August 2026 rather than left sitting behind an app nobody runs.

Controlling who watches

The link is the key

Anyone holding your complete share link can watch. Anyone without it cannot — not even someone who knows your stream's name, and not us. Treat the link the way you'd treat a door key, and send it through a channel you trust.

Knowing the name is genuinely not enough, and that is enforced rather than assumed: a viewer has to present a tag derived from the link before a relay will be assigned to them. The tag is derived so that it proves possession of the link and reveals nothing that helps decrypt it.

Add a passcode for a second lock

Turn on a passcode and the link alone stops being enough. The passcode is deliberately not part of the link, so send it separately — a different app, or out loud. It is never stored on, sent to, or checked by any server: it is mixed into the content key, so a wrong one simply fails to decrypt in the viewer's own browser. Regenerating it locks out everyone holding the old one without changing your link.

Two ways to revoke

New link mints a fresh key, so links you have already sent stop decrypting — though they still name you, and whoever holds one can still tell when you are live. New ID goes further: a new identity, so old links point at nobody. It cannot be undone.

The relays are unikernels, not containers

A relay never holds a key, so this is not what protects your video — the encryption is. It decides something else: how much an attacker gets if a relay falls. Each relay is a single program in a single address space under a hardware-virtualisation boundary, with no shell to reach — not disabled, absent — no package manager, no filesystem and no persistent disk. One relay carries exactly one broadcast, so a compromised relay is confined by a machine boundary rather than by a setting. The fleet holds only the public half of our signing key: it can check a token, it cannot forge one.

Moderation, and what it costs

Because we can't see what anyone broadcasts, we can't police content. What we can do is stop a stream: a viewer can report one, and an operator can terminate it. Terminating means no further relay placement and no further token for that name; browsers running our client stop within seconds, and a session already open ends when its relay token expires and is not reissued.

We still cannot say what a terminated stream contained, produce a recording of it, or tell a complainant what they were shown. Stopping is the whole of what we can do — and a report tells us a stream's name, never who reported it.

The limits

These are real. A page that only listed strengths wouldn't be worth reading.

A link can't be recalled. Once you've sent it, anyone who receives it — or is forwarded it — can watch. We can't revoke it for one person, because we can't decrypt it either. A passcode, or a new link, is how you cut someone off.

Anyone watching can record. A viewer's own device necessarily decodes your video to display it, so it can also save it. No system that shows people video can prevent this, and we don't claim to. This is not DRM.

Your IP address is visible to the network. The relay that carries your stream sees the address you connect from, and so do the broker and Cloudflare, which serves this site. We don't store it — but we can't hide it from them. If being located matters to you, use a VPN or Tor. That's the one protection we can't provide for you, and the encryption is unchanged by it.

We can see that you broadcast, even if not what. Times, durations and how much data moved are visible to us, to the broker and to the relay. Encryption hides content, not the fact that something happened.

"Read exactly what runs" is a goal, not a proof. Our client is one unminified file with no build step, so it is readable — but verifying the bytes this site actually served you is on you. INTEGRITY.md publishes their hashes in a different place, under a different party, so substitution becomes detectable rather than impossible. Self-hosting is the answer for anyone who cannot accept that.

How to know this is true

Our whole client is one file you can read: earthseed.js. The transport underneath it is @moq/net, which we did not write and did not change — we serve our own copy of it so nobody else can push code onto the page that holds your content key, and the build is reproducible so you can confirm that.

The claims above that can be checked mechanically are, and the ones that matter most are the negative ones — checks that try to break a promise and must fail:

Open a live stream without the # part of the link — the position we're in — and nothing decodes.
Ask for a relay placement knowing only the stream's name, and be refused.
Terminate a stream while someone is watching, and confirm it stops.
Read the database directly after a report is filed, and confirm no key is in it.

The longer engineering version, including the comparison against ordinary container hosting and every known weakness, is in TRUST.md.

This describes Earthseed as it runs today; it will be rewritten when that changes rather than quietly left standing. Questions: erik@vivoh.com