I joined the IndieWeb, here's what I learned | Andros Fenollosa

Driven by curiosity, I decided to find out what the IndieWeb tag that kept showing up on some blogs and Mastodon toots was all about. I quickly discovered it was more than an empty concept or a feeling of nostalgia for the web of the 90s. It was a movement with concrete ideas, protocols and an active community! As I read through their wiki, I understood their position and the intelligence of their proposals more and more. Such was my enthusiasm that I decided to follow their advice and adopt the protocols that made sense for my site. After finishing the tests and adjustments, I can confirm that the experience has been very positive: I have learned a lot, the UX of my website has improved a bit more, and I enjoyed the process. That is why I decided to write this article, cleaning up my notes from these last few months. Maybe it will help someone else discover it, and along the way, improve the health of the web. And for the nosy ones, I will also tell you which pieces I implemented, which ones I discarded and why, and which pieces of advice turned out to be the most useful. But first, we need to answer a fundamental question.

The IndieWeb defines itself as "a people-focused alternative to the corporate web". It does not propose a piece of software or a framework, but an ideological foundation. It deliberately embraces a plurality of approaches and projects. As its homepage says: "we are people-focused instead of project-focused". It all started in 2010, when Aaron Parecki and Tantek Çelik attended the Federated Social Web Summit in Portland. They left with the feeling that a different approach was needed: fewer protocols and more creators. In 2011 the first IndieWebCamp was held in Portland, and they have been celebrated every year around the world ever since, along with the Homebrew Website Club, meetups where people get together to improve their personal websites. The 3 pillars that define it are:

Your content is yours: when you post something on the web, it should belong to you, not a corporation. Too many companies have shut down and taken their users' data with them. You are better connected: your articles can be distributed to any platform, not just one, and responses and likes from other services can come back to your site so you have everything in one place.

You are in control: you can post anything you want, in any format you want, with readable and permanent URLs that will always work.

So we could say it is a community of personal, independent websites that share these commitments. That is also why it does not forbid you from using social networks, but it does fight against walled gardens. The enemy has a name: the silo The entire IndieWeb vocabulary is built in opposition to one concept: the silo, also called a walled garden. The wiki defines it as a centralized website, typically owned by a for-profit corporation, that claims some rights over the content you contribute and restricts access in some way. Its characteristics:

They require you to create a site-specific account to participate. They only let you interact with other accounts on the same site. And they typically add: restrictive terms of service, license claims over what you create inside, walls that prevent indexing, or barriers to importing and exporting your content.

Why is this a problem? Because silos die, and when they die they take your content with them. The site-deaths page ("Where incredible journeys end", a nod to the corporate euphemism our incredible journey) keeps a devastating chronology:

GeoCities: Yahoo shut it down on October 26, 2009. 23 million pages gone. MySpace: in 2019, during a server migration, it lost all the music uploaded during its first 12 years, more than 50 million songs from 14 million artists. Google+: shut down in April 2019. Posterous, FriendFeed, Vine, Yahoo Groups, TinyLetter, Cohost... the list keeps growing, and it even has sections for "upcoming deaths" and for acquisitions, which tend to foreshadow them.

The silo does not even need to die: the web is fragile by default. According to a 2024 Pew Research study, 38% of the web pages that existed in 2013 were no longer accessible a decade later. The IndieWeb's conclusion is not "don't use social networks". It is more subtle: use whatever you want, but make sure the canonical copy of your content lives on a domain you control. That is why it defines a set of principles to fight against the fragility of the network.

The principles The community is guided by 11 principles:

Own your data: your content, your metadata and your identity live under your domain, and you retain access to them over time. Use and publish visible data: for humans first, machines second. No parallel APIs if the HTML can carry the data. Make what you need: build tools for yourself, not for some hypothetical user. "If you design for some hypothetical user, they may not actually exist; if you make for yourself, you actually do exist." Use what you make: use what you build every day. "If you aren't depending on it, why should anybody else?" Document your stuff: you already have a place to speak your mind, use it to document your processes, ideas and code. You help others and your future self. Open source your stuff: not mandatory, but it helps others get onto the independent web faster. UX before protocols: user experience first, and then the simplest, most minimal protocol sufficient to support it, and nothing more. They sum it up as "UX before plumbing". Modularity: small, loosely coupled pieces, so you don't depend on a specific device, language or platform. Longevity: build for the long web. "If human society is able to preserve ancient papyrus, Victorian photographs and dinosaur bones, we should be able to build web technology that doesn't require us to destroy everything we've done every few years in the name of progress." Plurality: deliberately encouraging diverse approaches makes the community more resilient than any monoculture. And above all, have fun: remember the web of the 90s, GeoCities, loud backgrounds and animated GIFs. "It may have been ugly and badly coded but it was fun. Keep the web weird and interesting."

The numbering is just for reference, not a priority. The community does not demand that you fulfill them all, but it does ask you to keep them in mind. But the IndieWeb does not live on principles alone.

The wiki sums it up in a phrase I love:

Your website is your API

For reading, microformats; for writing, Micropub (we'll get there).

rel-me is the simplest piece and the one with the most immediate effect. An attribute on a link that says "the destination of this link represents the same person as the current page": <a href="https://mastodon.social/@jane" rel="me">Mastodon</a> Verification requires reciprocity: your website links to the profile and the profile links back to your website, both with rel="me". With that you get distributed identity verification, with no central authority involved. It is exactly the mechanism behind Mastodon's green verified checkmark: if your page links to your profile with rel-me and your profile links back, Mastodon shows your domain as verified. It is also supported by Threads, PixelFed, GitHub, Keybase and Wikipedia. On top of rel-me sits RelMeAuth: authenticating on services with your personal URL, delegating the identity proof to an OAuth provider (like GitHub) that your homepage links to. It is the foundation of services like IndieLogin. Webmention: conversations between sites Webmention is the star standard, a W3C Recommendation since January 12, 2017, and the modern successor of Pingback. It solves conversations between sites: comments, likes, replies and reposts from web to web, with no platform in between. Many people use it as a replacement for Disqus. The flow is deliberately simple:

I write a post that links to an article of yours. My server visits your article and looks for your endpoint: an HTTP header Link: <...>; rel="webmention" or a <link rel="webmention"> in the HTML. It sends a POST with only two parameters: source (my post) and target (yours).

POST /webmention HTTP/1.1 Host: your-site.com Content-Type: application/x-www-form-urlencoded

source=https://my-site.com/my-post&target=https://your-site.com/your-article

Your server verifies the mention: the specification requires downloading the source and checking that it really contains a link to the target. Without that verification, anyone could fabricate fake mentions. Once verified, your site decides what to do with it.