Entity Church Foundation

Publishing on ordinary hosting

A peer goes on the public internet as a set of static files. That means the cheapest, most commoditised hosting there is will serve it: object storage plus a CDN, a static site host, or a directory on a web server you already have.

To be precise about what that does and does not mean — there is still a web server involved, and someone still runs it. It just isn't you, and it isn't doing anything specialised. It returns files it was handed, which is the one thing every hosting service on the market already does well and cheaply.

What you avoid is running your own infrastructure for it: no dedicated peer online to answer requests, no application server, no database, no process to keep alive, and no runtime of yours for anyone to attack or for you to patch. The publishing side is a peer you control; the serving side is a commodity you rent.

That is the ordinary way to put a peer on the public internet, not a reduced mode.

Why a commodity host is enough

Because the host is not the authority. The signatures are.

A reader who fetches your content verifies it against a peer identity they already hold — the bytes hash to what the tree says they hash to, and the root is signed by the key they expect. A host that alters a file produces a verification failure rather than a different page. A host that swaps one file for another one you legitimately published produces a failure too.

So the host has no security role to play, and that is what collapses the requirements on it. All it has to do is return the bytes it was given — which is why a plain static hosting plan is sufficient, and why nothing has to be built or maintained on top of one. Every property that usually requires trusting an origin — authenticity, integrity, knowing you got the thing you asked for — is established on the reader's side by arithmetic.

This is also why the hosting is interchangeable. Move your tree to a different provider and nothing about its identity changes, because its identity was never the hostname.

The peer that publishes does not have to be online

This is the part that surprises people, and it is the most useful consequence.

Publishing is a push. Your peer assembles the set of things it wants public, signs the root, uploads the result, and is done. Afterwards it can be shut down, disconnected, closed for the weekend, or live on a laptop that is only occasionally awake. Readers continue to fetch and verify the whole time, because they are reading files, not talking to you.

Two things follow that are worth stating plainly:

What it costs

Storage for the bytes, plus egress when someone reads them. That is the whole cost structure, and both halves are small for anything text-shaped.

Content addressing helps more than it might sound like it does. A file's name is its hash, so a file never changes — which means a CDN can cache it indefinitely rather than revalidating, and a republish only uploads what actually differs. Reads scale the way static file reads scale, which is to say they are somebody else's solved problem.

The one thing that costs real thought is not money. It is the identity, below.

Your own domain — and the address that is not your domain

You can serve all of this from a domain you own, and it will look like an ordinary website, because it is one.

But your peer's identity is its permanent address, and it is not the domain. The identity is derived from your keypair, it appears in the URLs your content is fetched at, and it is what a reader pins to verify you. The domain is where the bytes happen to live today.

This has one sharp edge, and it is the single most expensive mistake available here: changing the key changes the address. A new key is a new peer, with new URLs, that nobody's existing pin verifies. Links people saved stop resolving to you. It is not a migration, and there is no redirect that fixes it — the old address was a hash of the old key, which is exactly why it could be trusted in the first place.

Practically: generate the key once, keep it somewhere you will still have it in five years, and back it up before you publish anything you would be sad to orphan. Naming — so that people can hold a name rather than an identity string — is what a registry is for, and it is a layer above this one.

More than one peer, and more than one host

Nothing here assumes a single peer or a single origin.

A tree's location is described by three separate prefixes — where its tree paths are served, where its content bytes are served, and where its signed root is served. They can all sit on one host, or on three, and the split is a normal thing to do rather than an exotic one. Content is addressed purely by hash, so several peers can share one content store and identical bytes are stored once across all of them.

That composes upward. A person or an organisation can run many peers — one per project, per site, per role, per audience, some public and some not — publishing into shared or separate infrastructure, all verifiable independently, none of them needing anything of yours online to serve them. The unit that gets deployed is a peer, and peers are cheap, so the shape of a deployment can follow the shape of the work rather than the shape of a hosting bill.

Where a deployment does eventually need something running, it is for capabilities that genuinely require a live party — helping two online peers find each other directly, or holding messages for a peer that is offline. Those are separate, optional, and bounded. Publishing is not one of them.

Static is a shape, not a requirement

Everything above describes files on a host, because that is the cheapest shape and the one that makes the point. It is not the only one.

A live peer can serve the same routes directly out of its own store — one process that is both a running peer and a content origin. The consumer's code path is identical; it fetches and verifies exactly as it would against a CDN, and cannot tell the difference, because there is no difference that matters to it. That is useful while developing, for embedded deployments, and for anyone who wants a live peer without a separate mirror.

The mechanism is the signed tree. Static hosting is one way to deliver it.

What a verified page proves — and what it does not

Worth being precise about, because this is where a good security property is easiest to oversell.

When a reader verifies your published root, they have proved the bytes are authentic — signed by the identity they pinned — and that they are not being rolled back to something older than what they already accepted.

They have not proved they are seeing your newest content. There is no way for them to prove that from the artifact, and the reason is structural: a publisher who simply hasn't republished in a while, and an origin quietly withholding a newer root, look identical at the reader's end. Same signature, same version counter, same everything. There is no field to check.

So the honest states are three, not two — not verified, verification failed, and verified with a known age — and collapsing them into a green tick is how a real property becomes a claim that isn't true. Freshness is bounded by things above this layer, not by the signature.

Where to go next