nova Networked Object
Versatile Archive

Go to the upload page, pick a file, and copy the link you get back. That is the whole procedure. There is no account to make and no email to give, and the link is an ordinary HTTPS URL you can put in an <img> tag anywhere.

Uploads here are public: anyone holding the link can view the file. Limits are 100 MiB per file and 100 files per batch.

This is the case Nova was built for, and it does not require anything from me. The software is Apache-2.0, the coordinator is one Go binary plus Postgres, and the deployment is documented end to end in the docs.

You run the coordinator, you hold the master key, you decide the replication factor, which jurisdictions may hold a copy, and who is allowed to donate. Your community's members can then run donor nodes for you the same way they would run one here.

A donor node is a container that pins encrypted blocks the coordinator assigns to it. It needs disk, some upstream bandwidth, and a person who answers email within a few days when an upgrade is due.

You never generate your own federation identity — I issue the certificates and send you a bundle plus the image digest to pin. From there it is a compose file and about ten minutes before the first assignments arrive. See the beta questions and the donor guidance.

Tell me the hosting provider, the rough region, and whether you already run another donor on the same provider or account.

Replicas are only as independent as the machines underneath them. Three donors in one datacenter share a power feed, a transit provider and an abuse desk: durability on paper, one failure domain in practice. Knowing your provider lets me place your node where it adds a dimension the federation is short of. There is no wrong answer — it only changes what your node is asked to hold.

There is no minimum size and no minimum commitment period. An honest horizon is worth more than a generous one: six months you actually mean beats a theoretical forever.

Leaving is a supported operation. 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 just makes the federation rebuild from the other copies, which works but costs everyone more traffic than it needed to.

Your node enforces its own outbound cap and you choose the number, so this is a knob that protects your bill and your ISP relationship rather than a quota I impose. Tell me the host's monthly transfer allowance too, so the daily figure and the plan agree.

A small budget does not shut you out. Steady-state placement is driven by capacity and failure-domain diversity, not by how much bandwidth you offer; the cap governs how often your node is picked as the source for a repair. A modest donor is a useful donor.

The name goes on your certificate and into the federation's health view. Lowercase, no spaces, something you will recognise later.

Upgrades mean verifying and redeploying a new pinned image digest, and drains are coordinated, so I need a channel you actually monitor. Use an email address or another channel you check regularly; routine notices expect a reply within a few days, and there is no on-call expectation.

Usually the answer is being used as somebody else's CDN: your forum's images get hotlinked, and you quietly pay the bandwidth for their traffic. Sometimes it is that a collection should only render inside your own pages. Either is fine — knowing which tells me what expiry and what collection to set up.

An origin is scheme plus host plus any non-default port, and the match is exact. All four of these are different origins:

https://forum.example · https://www.forum.example · http://forum.example · https://forum.example:8443

Paths do not matter, so /thread/123 is irrelevant. List production and staging separately if you have both.

A signed URL is time-limited as well as origin-bound. Short lifetimes suit pages that mint links as they render; longer ones suit content pasted into posts that stay up. Tell me the shape of your page and I will suggest a window.

An order of magnitude is enough. It sets the replication class the collection lands in and tells me whether the coordinator's hot cache needs resizing before you start.

Worth raising before you build against it: ordinary uploaders cannot mint signed URLs themselves yet — the operator does it. If your plan involves your application minting links on the fly, say so, because that changes what I need to give you.

What a signed URL does: the coordinator checks the requesting page's Origin (falling back to Referer) against the origin the link was minted for, and refuses anything else. A normal browser embedding it on another site gets nothing. It is not download prevention — a recipient can save the file, a server can proxy it, and a non-browser client can send whatever headers it likes.

• The published image, pinned by digest, with its cosign signature, SBOM attestation and build provenance verified before first start.
• Operator-issued Nebula and federation identities. You do not mint your own.
• Persistent storage, and a locally enforced cap on outbound transfer.
• A contact address you monitor.
• No public ports, no public DHT participation, no Bitswap. The node is reachable only inside the private mesh.
• Certificates, keys and the swarm key kept where other people are not.

• How much disk you commit, and how much daily outbound you allow.
• Which provider and region you run on, residential line or datacenter alike.
• How long you intend to participate. There is no minimum, and draining is a normal, supported exit.
• When your maintenance window is.

Residential connections work and plenty of good donors use them. Some residential ISP terms restrict servers or sustained upstream traffic, which is the only reason the recommended cap is lower there. Tell me which you are on and I will suggest a starting number.

• Read your provider's acceptable use policy before you commit bandwidth to it.
• Keep the host OS and container runtime patched.
• Back up your identity and configuration material. Do not back up the replicated ciphertext — the federation already has that covered, and it is not yours to restore.
• Tell me if you share a provider, account or failure domain with another donor.
• Drain before a planned departure. After a suspected compromise, do the opposite: shut it down immediately and mail me.

New donors start on probation: the coordinator assigns a small share, audits that the blocks are really held and really servable, and raises the share as the node proves it. This is not a judgement about you. It is how the federation avoids discovering that a replica was notional at the moment it needs it.

Donor nodes are never authorised to change federation state. The only settings you control are your own storage and bandwidth ceilings.

No, and no. Replication protects against losing donors — several of them at once — which is a different job from protecting against your own mistakes, a defect in software this young, or this particular beta federation going away. Nova is built for archives that outlast their hardware, and it is very good at that. It is not a substitute for keeping your original.

Say that plainly to yourself before you rely on it: this instance is a beta. I will carry data through upgrades and any move, but I cannot guarantee this deployment retains and serves a thing forever, so it should not be the only place that thing exists.

Public. Anyone holding the link can read the file, which is what makes an <img> tag work without a login. Do not upload something here that should not be readable by anyone who gets the URL.

Signed URLs narrow where a link works, not who can see the bytes once it renders. If you need real access control, run your own coordinator with a private collection.

The identifier is stable forever, because it is a hash: that address can only ever name that exact content, on this federation or any other, today or in twenty years. Nothing can silently point it somewhere else, which is the failure mode that makes ordinary URLs rot.

What that does not do is promise this specific host will be answering. Continued availability under nova.thebugreport.dev is a property of this deployment, not of the address.

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, the answer is to run your own coordinator rather than to trust mine. It is the same software, it is Apache-2.0, and the setup is documented.

Encrypted blocks, how much space they take, and the network traffic in and out. Not the plaintext, not the filename, not the type, not the key. A donor cannot enumerate what it holds in any meaningful sense, and cannot choose to hold some files and not others — the blocks are opaque, so there is nothing to select on.

The storage is distributed; the authority is not. There is one coordinator holding the index and the keys, and a private mesh of donors underneath it. That is a deliberate trade: a decentralised index costs latency and constant cross-talk, and Nova buys clarity and speed with a single authoritative Postgres instead.

It uses a hardened Kubo node purely as a deterministic content-addressed blockstore. It does not join the public DHT, does not advertise CIDs publicly, and does not use Bitswap. Nothing about your uploads is announced to the public IPFS network.

The coordinator notices the node stopped answering, marks its replicas missing, and schedules repairs: it picks a healthy source and a destination based on liveness, spare capacity, failure-domain diversity and the node's track record, then issues a scoped repair grant so the destination fetches directly from the source. The bytes never travel through the coordinator.

That is also why a coordinated drain is nicer than a plug-pull. A draining node keeps serving as a repair source until its replicas exist elsewhere, so the rebuild reads from the node that is leaving instead of from everyone else.

A fair question to ask anyone running infrastructure alone, and the honest answer has two halves.

The software survives it. Apache-2.0, no copyleft dependencies, self-hostable, documented well enough that somebody else can stand up a coordinator without me. The design has no upstream that can withdraw it and no licence that can be revised out from under you.

This federation is a different object from the software. If it shut down without being handed over, links under this domain would stop resolving: donors hold ciphertext, not the keys or the index, so they cannot take over by themselves. Keep your own copy of anything you care about — which is the same advice I would give you about any host, including the ones with a support contract.

Yes. Mail the address above with the URL. Owner deletion, abuse reports and DMCA notices are three separate paths and are handled as such; the default disposition for a report is quarantine, and there is a documented DMCA procedure for the cases that need one.

One consequence of content addressing worth knowing: an identical file uploaded twice is one blob. Removal therefore applies to the blob, not to your copy of the link.

Sometimes you should. Managed storage is the better answer when you want turnkey operations, a contractual durability figure, someone else's on-call rota, or predictable global delivery. Nova asks you to take on operational responsibility in exchange for control, and that is a real trade.

Take it when the control is what you are short of. With a bucket you rent space from one company, on their terms, at their price, for as long as they feel like offering it — and every one of those can change without you. With Nova the operator spreads the storage across volunteers or their own nodes and ends up with infrastructure rather than a tenancy: you choose the replication factor, the jurisdictions, and who is allowed to hold a copy. Nothing phones home, nothing is mined, and no pricing review touches it. Reads are ordinary cacheable HTTPS, so it is fast in the way that matters.

And uploading here is free, so on this federation the bucket is not even the cheaper option.

100 MiB per file, 100 files per batch, rate-limited per address. This deployment is offered for personal and community use, without an SLA, and on the understanding that fair use means not treating it as your production CDN. The full terms are on the terms page.