Series: openweb

Owning Your Output

By John Hardy

I keep returning to the early web’s ideas because they offered a clean technical answer to an ordinary human problem: publishing something and knowing it will still be there tomorrow. You could put a document on a server and give it a URL, and that link would mean something. The page lived on your server, and the link stayed stable because it pointed to a file you controlled.

Tim Berners-Lee at the London 2012 Olympics with the words "This is for everyone."
This is for everyone — London 2012 Olympics.

The web’s original promise rested on open protocols and a light technical burden. HTTP and HTML were open enough for anyone to implement and small enough to understand. If you wanted to publish, you bought a domain and wrote a page. Then you put it online yourself and shared the link.

For a long time, I drifted away from that. Social platforms made publishing effortless by removing hosting work and day-to-day site upkeep. They also bundled identity with distribution and comments while the feed carried the rest. The friction was low and the audience was already there, so the trade felt reasonable even as I gave up control. That convenience has a cost because the platform controls the surface where your work appears and how long it stays visible. Your writing lasts only while it fits inside someone else’s system.

Self-publishing, for me, is a technical choice. Owning a domain and shipping plain HTML means I decide what appears and how long it stays online, with presentation under the same control. A piece of writing stays available while I keep it there, and a page I host will still exist tomorrow if I decide it should.

This way of working also changes how I think about the archive. When everything lives on my own site, I set the rules of what matters and how it surfaces. It is a collection of files and links that I am responsible for. That makes the archive legible and inspectable. It becomes something I can maintain for years without renting it from a platform.

This series is about that choice and treats publishing as infrastructure. I want to write in a space that I control, using tools that do not disappear when a service shuts down. Plain HTML still exists alongside stable URLs and open protocols. I am building with those constraints because they keep the writing mine and keep the system open to anyone who wants to read it or take it elsewhere. This is why I build this system and publish here.

Your Address Is Your Domain

By John Hardy

When you publish on a platform, you are borrowing an address. Your writing lives under someone else’s name on someone else’s domain, and it stays there only as long as that company allows. You can share the link, but you do not control the address it points to.

Medieval labourers working the land.
Toiling on someone else's domain

Publishing on someone else’s domain is like working on someone else’s plantation. You may do the labour and produce the value, and you may be visible while you are useful. Someone else owns the ground beneath your work and decides what stays or goes, along with what it allows to exist.

Owning a domain changes that relationship in practice. It gives you your own name on the internet and a place where your writing is not conditional on a platform’s rules. Hosting providers and publishing tools can change, but the address that holds your work remains under your control.

That matters because URLs are promises about where something can be found. When you publish a page, you are telling the world that something lives at a particular location. If that location belongs to someone else, the promise belongs to them. If you own the domain, the promise is yours to keep.

That is why self-publishing on your own domain is about freedom as much as technology. A site on an address you control cannot be quietly erased or buried, and another party cannot reshape it. It becomes a place where your writing can exist on its own terms and persist for as long as you decide it should.

Years