IPFS

What IPFS actually does here.

Vidra can mirror media to IPFS — a public tier for delivery, a private tier for replication. Both are off by default, and neither one means strangers host your videos — though anyone who wants to can pin a copy. Here is the mechanism, without the folklore.

The mechanism

The mirror, not the master.

The authoritative copy of every video stays in your storage — local disk or S3. IPFS is a mirror running beside it, and the compose file says so outright: an IPFS outage never blocks uploads or playback. Turning the mirror off costs you nothing but the mirror.

Step one of five

Two copies, both yours

The authoritative copy of every video stays in your storage — local disk or S3. The mirror is a second copy, pinned on your own IPFS node. Only public, published media is even eligible — the fence is default-deny — and the whole tier is off until you turn it on.

The filled nodes are yours: your object store, your IPFS node, and any cluster replicas you run. Hollow rings are other people's nodes — dashed while pinning is only a possibility, solid once someone has chosen to run a node and pin. Gateways pass content through and verify it by hash — they do not keep it. The sealed loop is the private tier; nothing crosses out of it.

Eligibility

The privacy fence decides first.

Before anything is mirrored, an eligibility check runs — and its default answer is no. Only public, published videos (plus public playlist covers and active accounts' identity images) can reach the public tier. Unlisted is treated as private. Direct-message attachments, exports, upload chunks, the live edge and anything the check does not recognise are refused on both tiers.

The public tier

Delivery, addressed.

For eligible media, a durable queue streams the bytes from your storage into your own IPFS node, which computes the content address — the CID — and pins it. A full HLS ladder becomes one addressed directory with a single root, so every rendition and segment resolves as a path under one hash. From there, the gateway you configure serves it: small media redirects there automatically, and the watch page offers viewers an opt-in IPFS source for full videos. Gateway delivery takes those bytes off your application entirely. At rest you now hold two copies, both yours: the canonical object, and the pinned blocks on your node.

The viral case

When a video takes off.

On its own: nothing changes.

A video of yours goes viral and every viewer is an ordinary browser: nothing automatic happens. Browsers fetch; they cannot serve — the routing interface they use has no way to announce a provider — and Vidra adds no peer-to-peer in the player, deliberately, so watching a video never exposes a viewer's IP address to other viewers. The bytes still come from the gateway you configured, and if that gateway is your own node, every byte still crosses your uplink.

When people pin it: the sources multiply.

What changes it is a viewer who runs a node. Every public, published video already publishes its content addresses — the original file's CID and the HLS ladder's root — in its API response, and anyone can pin one: ipfs pin add, on any machine they control. Each pinned copy is a complete, independent source. Fetches that travel over IPFS — a fan's node, another instance, a gateway warming its cache — then split across every node that has the bytes, so your node's share of the serving divides roughly with the number of copies. And if your server dies, every copy that anyone pinned keeps the video reachable at the same content address. What replication does not buy is speed: it moves egress and availability, not latency, and no latency figure has ever been measured here.

What Vidra ships for that day.

Vidra's half of this is shipped, not roadmap. The addresses are in the public API today, for public, published videos only — the privacy fence above decides what exists to pin. Public-network announcing is its own switch, off by default: turn it on and your node announces every public CID to the global IPFS DHT, which the config scripts treat as a permanent public-disclosure decision. And an operator who wants guaranteed copies rather than volunteered ones can attach an IPFS Cluster, so every pin replicates across peers they run, to a replication factor they choose. What does not exist yet: a pin-this-video button, or a channel pinset to follow. Today a fan brings a node and a copied address — the surface is shipped; the ceremony is not.

Popularity recruits servers only when the audience includes people who run one.

The private tier

Replication, not distribution.

Private media may mirror only to a separate, swarm-keyed node — a private network with no gateway, whose content addresses never appear in any API response. Its job is durability: your private media replicated across machines you run, a backup fabric rather than a delivery layer. The two tiers cannot share a node; routing between them fails closed.

Content addressing

What it buys, and what it does not.

Three things, and IPFS's own documentation is precise about them (docs.ipfs.tech, “Content addressing” and “Gateways”, 2026). Integrity: the address is a hash of the content, so anything served under it can be verified byte for byte, whoever serves it. Location-independence: the same address resolves through any gateway or peer that can reach a copy — the URL is not welded to one host. Survivability, if pinned: if someone pins your public video, it outlives your server. That last word is doing the work — persistence on IPFS requires pinning, and caches are garbage-collected.

Nobody hosts your files automatically. Pinning happens on your node and, if you run one, your cluster. Anyone holding a public CID may choose to pin it — that is a choice other people make, not a service the network performs, and it is also why joining the public network is treated as a permanent decision in the config: once another peer has fetched your blocks, switching the network off cannot recall them. No speed claim either: gateway latency has never been measured here, and the public gateway fleet has thinned — Cloudflare's closed in 2024, Infura's in August 2026, and ipfs.io rate-limits video. And no permanence: unpinned content is not guaranteed anywhere, including by us. Both switches — the mirror itself, and the public network — default to off.

Your video, stored where you put it, addressed so that anyone — including future mirrors you do not control — can serve it and verify it. Not: your video, hosted by the crowd.

Off by default. Yours to enable.

Get started Federation and delivery, in the docs