I joined the IndieWeb, here's what I learned

What is the IndieWeb

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:

1. Own your data: your content, your metadata and your identity live under your domain, and you retain access to them over time.
2. Use and publish visible data: for humans first, machines second. No parallel APIs if the HTML can carry the data.
3. 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."
4. Use what you make: use what you build every day. "If you aren't depending on it, why should anybody else?"
5. 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.
6. Open source your stuff: not mandatory, but it helps others get onto the independent web faster.
7. 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".
8. Modularity: small, loosely coupled pieces, so you don't depend on a specific device, language or platform.
9. 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."
10. Plurality: deliberately encouraging diverse approaches makes the community more resilient than any monoculture.
11. 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. There is a set of standards that helps make your sites more open, interoperable and resistant to disappearing.

The technical part

The IndieWeb does not invent a platform; it defines a handful of small standards that compose with each other. The official index orders them by age and breadth of implementation. Let's go one by one.

The starting point: your domain

It is not a protocol, but it is the prerequisite for everything else: your own domain used as your primary identity online. It is the first step of the Getting Started guide and the bare minimum the community considers necessary to be "on" the IndieWeb. If tomorrow you change hosting or CMS while keeping the domain, all your links, readers and search rankings survive the move.

microformats2: your HTML is your API

microformats2 solves one problem: making your content machine-readable without publishing parallel files or building an API. The implementation is elegant, since it uses CSS classes that you add to the HTML you already have.

The prefixes indicate the data type:

• h-* for roots
• p-* for plain text
• u-* for URLs
• dt-* for dates
• e-* for embedded HTML

The two essential vocabularies:

h-card is your identity: the online equivalent of a business card. With a minimum of name, URL and photo on your homepage, readers show your profile next to your posts and applications recognize you. It works like a domain-based Gravatar instead of an email-based one:

<div class="h-card">
  <a class="u-url p-name" href="https://example.com">Jane Doe</a>
  <img class="u-photo" src="https://example.com/photo.jpg" alt="" />
</div>

h-entry is the unit of content: the markup of a post. The wiki calls it "the key building block for the indieweb":

<article class="h-entry">
  <h1 class="p-name">Article title</h1>
  <p>By <a class="p-author h-card" href="https://example.com">Jane Doe</a>, <time class="dt-published" datetime="2026-07-19">July 19, 2026</time></p>
  <div class="e-content">
    <p>The post content...</p>
  </div>
</article>

There is also h-feed, which groups several h-entry elements to turn your listing page into a feed you can subscribe to straight from the HTML. 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": verified identity without a central authority

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 rel="me" href="https://mastodon.social/@janedoe">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:

1. I write a post that links to an article of yours.
2. My server visits your article and looks for your endpoint: an HTTP header Link: <https://your-site.com/webmention>; rel="webmention" or a <link> in the HTML.
3. 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

4. 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.
5. Once verified, your site decides what to do with it.

And here is where microformats comes in: by parsing the h-entry of the source you know whether it is a reply (u-in-reply-to), a like (u-like-of) or a repost (u-repost-of), and the author's h-card lets you display their name and photo like in any comment section.

If this sounds like a social network to you, that's because it is! Every site is a node in the network, and the links between them form the social graph.

It is not a perfect system, since it suffers from the same problems as any other decentralized network, which is why there are a couple of extensions that attack its weak points:

• Vouch, against spam: the webmention carries a third parameter with the URL of a "voucher", a site you already know that links to the sender's domain. It shifts the filtering cost from the receiver to the sender.
• Salmention, to propagate threads: if someone replies to a comment on my post, the original post finds out by re-sending update webmentions to everyone involved.

You don't escape spam or moderation. However, it is a good foundation for building a distributed comment system.

What if your website has no backend? You are not left out: webmention.io receives webmentions on your behalf. You add a <link> in your HTML pointing to the service and it gives you an API to query and display them. It is exactly what you need if you use a static site generator like Hugo, Jekyll or Eleventy.

IndieAuth: your domain as your login

IndieAuth answers the question: what if your identity for signing in were your URL, instead of "you on Google" or "you on Facebook"? Technically it is OAuth 2.0, the standard for authentication and authorization. Both users and applications are identified by URLs, which removes the need for prior client registration ("IndieAuth uses DNS as a replacement for client registration"), and PKCE is mandatory (a security mechanism that prevents an attacker from stealing the access token).

The flow in a nutshell: you type your domain in the login form, the service fetches your page and discovers your authorization server via rel="indieauth-metadata", redirects you there, you authenticate however you prefer (password, email, RelMeAuth), and the service receives confirmation that you control that URL. It is a living standard that the community considers stable.

Micropub: publish from any client

Micropub, a W3C Recommendation since May 2017, separates the publishing interface from your site's software: any application (web, iOS, Android) can create, edit and delete posts on your domain. It replaces the old MetaWeblog and AtomPub, which depended on sharing your password, with OAuth tokens obtained via IndieAuth.

The beautiful part is its vocabulary: it does not invent one, it is serialized microformats. Creating a post is a POST with h=entry and the same h-entry properties:

curl https://your-site.com/micropub \
  -d h=entry \
  -d "content=Hello world" \
  -H "Authorization: Bearer XXXXXXX"

If you are already used to working with REST APIs, it will feel very natural.

WebSub: real-time feeds

WebSub, formerly known as PubSubHubbub, a W3C Recommendation since January 2018, removes feed polling: instead of a thousand readers asking your server every half hour whether there is something new, you notify a hub when you publish and the hub instantly notifies all subscribers via webhooks. It reduces the load on your server and updates arrive without delay. Many feed readers and aggregators support WebSub, such as Feedly or NewsBlur.

Microsub: the decoupled reader

Microsub is the youngest standard and still a draft. Think of it as the infrastructure that ties everything together.