Why IPFS?

Why this site is hosted on IPFS

Most websites are files parked on someone else's computer. That someone (eg a hosting provider, a cloud company, a platform) has final authority over the data. They can move it, alter it, take it down, or lose it when they fold.

For a research site about the cultural commons, that arrangement is a problem. A site that makes claims about provenance and the commons shouldn't sit on infrastructure that contradicts the argument. So, for these reasons, I built this one on the InterPlanetary File System (IPFS). What follows are the technical decisions behind the site and the reasoning for them.

Content addressing

IPFS addresses content by what it is rather than where it sits. A file's address (ie its Content Identifier, or CID) is a cryptographic hash of the file's contents. Two files with the same contents have the same CID, wherever they are in the world. Change one character and the CID changes completely.

The consequence is that the identity of a file is intrinsic to it, not stored in a database that could be altered later. A CID is a verifiable claim: this is what the file was. Anyone holding a copy can check it, without needing to trust me or my host.

The name and the version

A CID is immutable. In contratst, a website changes over time. So the site runs on two layers. The first is the CID: a fixed address for a fixed set of files. Every time I update the site, a new CID is generated, and the old one persists— it is still addressable and still describes exactly what the site was at that moment.The second is a mutable pointer. A DNSLink record (or an ENS name's contenthash) says: the current version of this site is CID X. When I update the site, I change the pointer. The old CIDs don't disappear.

This is a different structure from a normal website. A normal site updates by replacement: the old version disappears and the new one takes its place. Here, updating adds a version, and the old CIDs remain.What that doesn't give you is legibility. A reader landing today sees the current version. They can't see what changed last week, or whether a claim was softened. Content addressing preserves the record, but it doesn't present it as a version history you can read. Verifiability and legibility are different properties, and IPFS only supplies one of them.

What this site runs on

The site is pinned through Filebase and reached via a CNAME from amykellam.com. The name-to-version mapping is a DNSLink record. Fonts are self-hosted from the same content-addressed directory, so there are no requests to Google. There is no third-party JavaScript, no analytics, and no cookies.

Pinning

IPFS distributes content, but it doesn't guarantee that content stays available. Files persist only if someone actively chooses to keep them, a process called pinning, similar to seeding a torrent. If nobody pins a file, it disappears from the network.

I use a pinning service. This means I have not escaped centralisation; I have moved it. The pinning service can change its terms, raise its prices, or fold. If it does, the content it holds may become unreachable until it's re-pinned somewhere else.

But IPFS makes content verifiable even when it doesn't make it available. If the pinning service disappeared tomorrow, the CID would still describe exactly what the site was. Anyone holding a copy of the files could recompute the hash and confirm they were the same ones. The content might need re-hosting, but the record of what it was would not need to be trusted.

The heartbeat

Because the site updates, its CID changes. Because the DNSLink record is mutable, the pointer can change too. So how do you know what the CID was on a given day, without trusting me to tell you?

I set up a small non-human agent—the heartbeat—to answer this. Every day, it resolves the site's DNSLink, signs an attestation recording the CID and the date, and publishes it to a public log. The log is verifiable by anyone with the agent's address.

It's a small thing, and the design is deliberately minimal. But it's also a working demonstration of a wider idea: that a content-addressed resource can be vouched for, over time, by an unowned steward rather than by a platform.

What IPFS does not do

  • Availability. Content persists only as long as someone pins it. Pinning services are a point of centralisation.
  • Legibility. The version record is preserved, but not presented. Old CIDs are addressable, not browsable.
  • Discovery. IPFS is a storage and addressing layer, not a discovery layer. You find a site because something points to it, not by browsing.
  • TLS. Most readers reach IPFS content through a gateway—a centralised HTTP service. Convenient, but it's the same kind of intermediary IPFS was meant to reduce dependence on.
  • Speed. Gateways are often slower than a CDN.

This site uses IPFS for a specific purpose—content addressability and version integrity—and accepts the current limits of the protocol for everything else. Every technical decision here is provisional. I treat it as an ongoing experiment. I fully expect it to change, break, and be revised as I go.