Built to outlast its authors.

The unvarnished version is more useful than the impressive one. Nova suits some jobs badly: it is not a hot cache, not a CDN, and not a place to park something you will regenerate next week. It suits archives — things you intend to still have in ten years.

Knowing what you would store tells me which replication class you belong in and whether I should talk you out of it.

A donor pins encrypted blocks on behalf of the federation. You never hold a key, never see a filename, and open no public ports — the node dials out over a Nebula mesh and nothing dials in.

What you are volunteering is disk, upstream bandwidth, and a small amount of attention when something needs upgrading. What you are not volunteering is any ability to know what you are storing.

Replicas are only as independent as the machines underneath them. Three donors in one datacenter share one power feed, one transit provider, and one abuse desk: durability on paper, a single failure domain in practice.

Jurisdiction matters for the same reason. I would rather place your node where it adds a dimension the federation does not have yet than where it adds a fourth copy of one it already has.

Leaving is a supported operation, not a betrayal — but it is a coordinated one. When you drain, your node keeps serving as a repair source until your replicas exist elsewhere, and then you are done. Pulling the plug instead makes the federation rebuild from every other copy rather than from yours.

So give me the horizon you actually believe in rather than the one that sounds generous. Six honest months beats a theoretical forever.

Your node caps its own outbound transfer, and you set the cap. The orchestrator does not penalise a small budget — it hands out work in proportion, so a modest donor is useful rather than tolerated.

Residential works, and plenty of good donors run that way. It also means an ISP with opinions about sustained upstream traffic, so the recommended budget is lower — not because your bytes are worth less, but because a terminated connection helps nobody.

Tell me which one you are on and I will suggest a starting budget rather than letting you discover the limit the hard way.

Donor images are published by digest and signed with cosign keyless signatures. Before you run one, three things must verify: the signature, the SBOM attestation, and the build provenance. If any of the three fails, the correct response is to stop and tell me, not to shrug and continue.

If that sentence was unfamiliar, say so — it is a twenty-minute thing to learn and I would rather teach it than have you skip it. Pretending to have checked is the only wrong answer.

A signed URL is a time-limited read link for content that is otherwise private, bound to a single embedding origin. The coordinator checks the request's Origin against the one the link was minted for, so a link lifted from your page stops working when it is pasted onto someone else's.

They are minted by the coordinator because signing needs a key only the coordinator holds. If you want them, tell me which origin would embed them.

Worth knowing before you rely on it: Origin is set by browsers and forgeable with curl. This stops your images being embedded elsewhere. It does not stop a determined person downloading them — the same limit CORS has.

The name goes on your certificate and into the federation's health view, so pick something you will recognise at 2am. Lowercase, no spaces.

Upgrades are a digest re-pin and drains are coordinated, so I need a channel that reaches you within a few days. Email is fine. Anything I have to remember to check is not.

Nothing. That is what donor-blind means and what it does not: the volunteers cannot read your file, the coordinator can. Transforms and plain image tags both need plaintext, and plaintext needs the master key.

If that is unacceptable for what you are storing, encrypt it before it reaches me. The federation will happily replicate bytes it cannot make sense of.

A fair question to ask anyone running infrastructure alone. The software is Apache-2.0 with no copyleft dependencies, self-hostable, and documented well enough that someone else can stand up a coordinator without me.

Your URLs are hashes of your own content, so nothing about recovering them depends on this domain still existing.

Yes. Mail the address above with the URL. There is a takedown path with quarantine as its default, and a documented DMCA procedure for the cases that need one.

Content addressing means an identical file uploaded twice is one blob, so removal applies to the blob rather than to your copy of the link.

Use one, if it fits. A hosted bucket is cheaper, faster, and someone else's problem at 3am.

What it does not give you is a URL that proves its own contents, storage spread across machines with no common owner, or terms that cannot be rewritten next quarter. Nova trades convenience for those three things. If you do not want the trade, the object store is the right answer.