Mirrors

This site is deliberately hard to take offline. The same pages are served from more than one independent host, and the source that builds them is mirrored across several code forges, so if any single provider disappears, both the live site and its source survive. The approach follows the Privacy Guides mirror model: one source of truth, many mirrors.

Live site

Independent hosts serving the same site. The first three follow every push; the 4EVERLAND copy serves from IPFS and moves only at each release, like the permanent mirrors further down.

Tor

The same pages as an onion service, reachable only through the Tor network. It runs on a server I control and is not published in DNS, so it keeps working if the domain, Cloudflare, or Netlify does not. Open it in Tor Browser; an ordinary browser cannot resolve it.

One caveat: the minted editions on essentialism are fetched live from tzkt.io and bootloader.art, so that gallery stays empty over Tor if those services refuse Tor traffic. The generator itself runs locally and works either way.

I2P

The same pages again on I2P, a different anonymity network from Tor and served by the same machine. Two networks rather than one means neither being blocked takes the site with it. You need an I2P router to open it.

Names

The same site under blockchain name systems. Each name is set once and follows every release on its own, so none of them can quietly go stale. Brave resolves the .eth and .sol names natively.

The Ethereum, Tezos, and Solana names all point at the same IPFS name, ipns://k51qzi5uqu5dkx54ehvkna983zjtfn04eu4sklgx2ag1tozh9js5p9cn5jwqmy, published from this site's own IPFS nodes. The Arweave name points at a permanent copy of each release; some ar.io gateways are still catching up to it.

The domain is a content name as well. A DNSLink record at _dnslink.thebenmeadows.com carries the hash of the current build, so a client that speaks IPFS can open ipfs://thebenmeadows.com and fetch the pages from the network instead of from this server. No blockchain and no gateway: a DNS lookup answers it.

Six machines hold that copy, five of mine and one pinning service. One publishes the name; the rest read the hash it published and fetch the blocks that match. A copy can lag, but it cannot disagree, because only one machine ever writes.

Nostr

The site is also published as an nsite: every file lives as a signed blob on Blossom servers, with a manifest event on Nostr relays under the same key this site publishes at /.well-known/nostr.json. No conventional host involved.

Part of that machinery is mine. The manifest rides four relays, two of them run under this roof: relay.mdws.me on Cloudflare Workers and relay2.mdws.me, a strfry on my own hardware that only I can write to. The files sit on five Blossom servers, and one of them, blossom.mdws.me, is also mine: uploads locked to my key, blobs never pruned. If every third-party relay and blob host disappeared, the nsite would still resolve from machines I control.

Small web

The same pages on five pre-web protocols, generated from the site's own search index at each release. You need a Gemini client (Lagrange, Amfora) or a gopher client (lynx works) - ordinary browsers speak neither. The last three need nothing but a terminal.

No login for any of them: SSH takes the user text with no password and drops you straight into a read-only pager. FTP is plain, deliberately: these pages are public, so there is nothing to encrypt, and clients this old predate TLS. When you want the encrypted path, that is what HTTPS, the onion service and Gemini are for.

BitTorrent

The whole site as a torrent, rebuilt on every push. It is the one copy where readers become mirrors: every client left seeding is capacity nobody had to provision. It carries no tracker, so peers find each other over the DHT and no third party sits in the middle of a download.

An empty swarm would normally make a torrent useless, so this one names this site as a webseed: with no peers at all your client just downloads over HTTPS from here, and with peers it takes the pieces from them instead. The worst case is an ordinary download. Each release is a different torrent with its own magnet link, held inside the file above, because the content it names has changed.

Offline

Every mirror above answers "can I still reach it". This one answers "can I hold it": the whole site as a single ZIM file, attached to each release. It opens in Kiwix on a phone or from a USB stick, with no network at all, and the format needs no cooperation from this site to stay readable.

Feeds

One entry per release, in both syndication formats, with WebSub pings on deploy so subscribed readers hear about releases without polling. Listed in the I ♥︎ RSS directory.

Source code

The repository, mirrored to independent forges and kept in sync automatically - each holds the full history.

The last two have no host. On Radicle the repository is replicated between peer-to-peer nodes, so it stays reachable for as long as any one node still seeds it: rad clone rad:z3vBEjEJAvd3CjciS1JBiFzHda3KA fetches it from whichever node answers first. On Nostr, signed GRASP events are the authority and git servers are interchangeable relays: with the ngit plugin installed, git clone nostr://npub1wldqfuy0yge4fvxukdm43gze2ral9dnp5avlps5a6t8q0vyv2nds84nq29/tbm pulls from any server carrying it. No forge, no account, nothing to take down.

Archived

Point-in-time snapshots held by a third party, outside any host above.

Three of these keep the pages and one keeps the source. A web archive and a code archive fail for different reasons and hold different things, so neither can restore what the other has: Software Heritage takes the repository with its full history, which is what rebuilds the site, while the page archives take the site as a reader saw it on a given day, which is what survives the repository being wrong.

Verify

Every build publishes manifest.json, listing the SHA-256 of every file it shipped. Hash the files you received and compare. That catches a mirror that has gone stale, and it catches a gateway that rewrote the page on its way to you: some public IPFS gateways do inject their own script, so the copy you are handed is not always the copy that was stored.

Each release's manifest hash is signed with my Nostr key and timestamped into the Bitcoin blockchain with OpenTimestamps, so the signature says who published it and the anchor says roughly when. The signature covers the newest release, and this site deploys ahead of releases by design, so the live manifest usually hashes differently than the signed one; the release-pinned mirrors (Arweave, the nsite, 4EVERLAND) are the copies it matches exactly. Proofs are served at commitments/<hash>.ots here and on every mirror, one per release, named for the hash they attest, and browsable in commitments/ in the repository.

To fetch the signature itself, ask any of the relays for my latest release event with nak:

nak req -k 30078 -a 77da04f08f223354b0dcb37758a05950fbf2b661a759f0c29dd2ce07b08c54db \
    -d thebenmeadows.com wss://relay2.mdws.me

The event's content names the manifest hash, the commit, the Arweave transaction and the proof path; kind 30078 is replaceable, so relays keep only the newest release's signature. Older releases keep their Bitcoin proofs in commitments/, but their Nostr signatures are replaced with each new release.

The manifest also carries this mirror list itself, as a mirrors array. This page dies with the site that serves it; the manifest is replicated to IPFS, Arweave and Nostr with everything else. Whichever copy you are reading, its manifest names every other copy, and the signature tells you nobody edited the list on the way.

Curious how it's put together? See the tech stack.