earthseed.live

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, or the CDN that carries your video. The same is true of your chat, which is sealed under a key derived from the same link. If we were asked for your stream, by anyone, we would have nothing to give.

What each party sees

WhoSeesCannot see
Us That a broadcast happened, its name, when and how long; roughly how many sessions watched; the panel you chose to show viewers; your chat as ciphertext Your video, your audio, your messages, your location, or who you are
The CDN (cdn.moq.pro) Encrypted bytes, your IP address, timing, the codec and resolution Anything inside those bytes
Your viewers The stream and the chat, if you gave them the link — and the passcode, if you set one. Plus anything you chose to burn into the picture, including your location if you switched that on Anything else; they cannot publish as you or rewrite your settings
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.

Two things this does not mean, said plainly. There is a record of which broadcast names went live and when, and of how many sessions watched each one — that is the price of being able to stop a stream, and it contains nothing about who you are. And there is a sign-in tier in our source code, which is switched off on this site; /api/config reports it, so you can check rather than take our word. If it were ever turned on, a signed-in broadcaster would be identifiable to us, and this page would have to say so.

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.

Where your video actually goes

Through moq.pro, a CDN we do not operate. Our Worker mints a per-broadcast Ed25519 token naming exactly one broadcast path, with an expiry; the CDN holds only the public half of that key, so it can check a token and cannot forge one. A relay never holds a content key, which is why whose machine it is was never what protected your video.

This page used to say something stronger, and it was true then. We ran the relays ourselves — one single-tenant unikernel per broadcast, no shell to reach, no persistent disk, isolated by a hardware boundary rather than by a setting. That no longer describes the infrastructure, so it has been removed rather than left standing. The honest cost: broadcasts are no longer separated by a machine boundary, and we have less to tell you about an operator that is not us. What is unchanged is that only ciphertext ever reaches it.

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 does 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, how many sessions watched and how much data moved are visible to us and to the CDN. Encryption hides content, not the fact that something happened.

"Read exactly what runs" is a goal, not a proof — and it got harder. Our client is unminified with no build step, but it is thirteen files and about 7,500 lines now rather than the one file this page used to point at. 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 client is right here, unminified and unbundled, with a published hash for every file. 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:

The longer engineering version, including 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