How the anarchive's files persist — a ring of free-tier remote pinning services in front of a Homebase pin of last resort, every file addressed by its CID so any node or gateway can serve it. Part of the Anarchive Media Plan.
## Three Tiers
**The Ring** — the free-tier remote pinning services that still allow pin-by-CID (in 2026, effectively just Filebase), holding fair-use clips and sidecars.
## Transparent to Read, Deliberate to Pin
Content addressing makes *retrieval* transparent: any gateway serving the CID works, regardless of which service pinned it. *Pin placement* is not transparent. Kubo registers many remote services, but `ipfs pin remote add` targets one `--service` at a time — there is no fan-out. The ring therefore needs a small wrapper, which later becomes the Outpost's `/media/pin`.
## The Ring
Members must speak the standard IPFS Pinning Service API **and** allow **pin-by-CID on the free tier** — our Homebase holds the blocks and asks the service to pin them by CID. As of 2026 that test is brutal: - **Filebase** — 5 GB, 1,000 pins, pin-by-CID on the free tier. **The one friction-free free member.** - **Pinata** — free tier **paywalls pin-by-CID** (`PAID_FEATURE_ONLY`); it accepts direct uploads only. Out unless paid. - **4EVERLAND** — free/trial tier **gates pin-by-CID behind on-chain identity registration** (a wallet transaction). Out unless you register on-chain. So the commercial free ring is, in practice, **Filebase alone**. That is not a failure of the design — it is the reason the design never trusted a single service. Real redundancy comes from the IPFS Cluster federation below: a friend's Raspberry Pi cannot paywall you or demand a wallet.
# tokens live in the environment, never inline on a wiki page ipfs pin remote service add filebase \ https://api.filebase.io/v1/ipfs "$FILEBASE_TOKEN" ipfs pin remote service add pinata \ https://api.pinata.cloud/psa "$PINATA_TOKEN" ipfs pin remote service add forever \ https://api.4everland.dev "$FOREVER_TOKEN" ipfs pin remote service ls # all three should answer
## Four Modes
Pinning runs under one of four named modes, set in `~/.config/anarchive/preference` on the Homebase (the Outpost's `/media/pin` reads the same file from Phase 3; override per-call with `$PIN_PREF`):
**local** — Homebase pin only. Nothing leaves the machine — for private and `*.localhost` content.
**p2p** — the group IPFS Cluster (see below). Replicated across trusted HomeLab peers, no commercial service. For the Mice and the working group of 42.
**public** — one public service, chosen by `hash(CID) % N` across the registered ring members. A CID always maps to the same service, so its home is recomputable without a stored map.
**redundant** — Homebase + *every* public service. Reliability first; the default while the corpus is small.
In `public` and `redundant`, low-res 420px files never remote-pin (wiki assets + Homebase carry them). The wider network model — how each HomeLab's own Pi and free tiers add to the pool — is Federated Pinning Service 
.
#!/usr/bin/env bash # pin-ring — pin a CID under the configured mode. usage: pin-ring <CID> [NAME] [CLASS] # mode: ~/.config/anarchive/preference = local | p2p | public | redundant set -euo pipefail; export IPFS_PATH=/mnt/wikimedia/ipfs CID=$1; NAME=${2:-$CID}; CLASS=${3:-clip} PREF=${PIN_PREF:-$(cat ~/.config/anarchive/preference)} ring() { ipfs pin remote service ls | awk '{print $1}'; } case "$PREF" in local) ipfs pin add "$CID" ;; # Homebase only p2p) ipfs-cluster-ctl pin add --name "$NAME" "$CID" ;; # group cluster public) [ "$CLASS" = lowres ] && exit 0 mapfile -t R < <(ring) i=$(( 0x$(printf %s "$CID" | sha1sum | cut -c1-6) % ${#R[@]} )) ipfs pin remote add --service="${R[$i]}" --name="$NAME" "$CID" ;; redundant) [ "$CLASS" = lowres ] && exit 0 for s in $(ring); do ipfs pin remote add --service="$s" --name="$NAME" "$CID"; done ;; esac
## What Pins Where
Under **redundant**: - fair-use clips and sidecars → every ring member + Homebase - full 420px videos → Homebase only, served from the wiki assets folder - high-resolution originals → Homebase only, CID recorded Under **economic**: - fair-use clips and sidecars → one ring member each (`hash % N`) + Homebase - full 420px low-res videos → wiki assets folder + Homebase, never the ring - high-resolution originals → one ring member each + Homebase — the ring becomes an offsite copy of the masters, not just the citations Every CID is recorded per IPFS Pinning and carried in the file's own name per the Filename Convention.
## The Cluster
The `p2p` mode pins into an IPFS Cluster — the pinset-orchestration layer that lets trusted HomeLab peers replicate one shared set of pins. The Anarchive seed peer runs on the Pi5 Homebase; other HomeLabs join as followers with `ipfs-cluster-follow` and the shared cluster secret (passed out-of-band, never on a page). The cluster's `replication_factor` is the dial: −1 pins everything on every node; a positive N spreads each pin across N nodes — the same allocation idea as `hash % N`, but across the federation's own machines rather than commercial services. This is the storage layer of Federated Pinning Service .
## Budget
A two-minute clip on the house recipe runs 5–8 MB; a clip bundle — clip, transcript, poster, metadata — about 9 MB across four pins. Under **redundant** the binding constraint is Pinata: 1 GB and 500 files covers roughly the first 110 bundles, fully triple-pinned, free. Under **economic** the same ring stretches to about 7 GB combined and 1,500+ pins — but note the arithmetic for originals: a single high-res talk runs hundreds of megabytes, so free tiers hold only a handful. Economic mode earns its keep when a larger member joins the ring — a paid tier (Filebase at about $5 per TB-month) or a second Homebase. Free tiers are a budget, not a promise — the ring exists so no single service's failure or policy change matters.
## Homebase
The pin of last resort. Today the Homebase is the Pi5 with its repo on the X9 drive; node mechanics live on IPFS Pinning. The aim is follower nodes across Hitchhiker Homelabs.
## Open Questions
- Storacha: still standard Pinning-Service-API, or UCAN-only? verify before admitting - 4EVERLAND's exact endpoint and tier limits — confirm at registration - the graduation trigger: at what fill level does the ring switch to `hash(CID) % N`, and who re-pins the backlog - gateway preference in the playback ladder: Pinata's bandwidth versus Filebase's egress - do high-resolution originals ever earn a paid remote tier, or is Homebase-plus-Homelabs the permanent answer - Cluster topology: is the Pi5 the trusted peer that publishes the pinset
## Links
- Filebase — 5 GB free, standard pinning API
- Pinata — 1 GB free, endpoint api.pinata.cloud/psa
- 4EVERLAND — 4EVER Pin
- IPFS Pinning Service API spec
- IPFS Cluster collaborative clusters — the Homelabs growth path
## See
- Anarchive Media Plan — the architecture this persists - Homebase and IPFS Pinning — the pin of last resort and its mechanics - Filename Convention and Media Commons — self-naming files and their public pages - Media Plugin and Fair Use Clip — what gets pinned and the discipline that keeps it free
# Assets
anarchive-pinning