For many, that’s too much of jargon right there in the title. So to a bit of basics first. I would not go into the history or setup of this website. TL;DR this site is was at one time build with a static site generator Hugo themed by a custom port of Ghostwriter theme. In this post, I want to focus mainly on why and how of IndieWeb.

Ever since I built this site, I had grown pretty determined to styling this exactly to my liking. Every section in here is thought through and has a purpose. When I was happy with what I had at the core, I started exploring how to make this my primary identity online. I had realised that thanks to all the silos of Facebook, Twitter, Medium, et al., my online presence was scattered across multiple sites. IndieWeb calls it sharecropping your content.

Our online content and identities are becoming more important and sometimes even critical to our lives. Neither are secure in the hands of random ephemeral startups or big silos. We should be the holders of our online presence.

When you post something on the web, it should belong to you, not a corporation. Too many companies have gone out of business and lost all of their users’ data. By joining the IndieWeb, your content stays yours and in your control.

Yes, absolutely. I just couldn’t stop nodding my head in agreement as I read along. I want this site to be the primary place where my content exists. And I hope everyone spending time online, doing as basic a task as consuming content on social media and liking stuff there, should do so first primarily on a place he controls. Post on your website, syndicate it everywhere else1.

And it doesn’t take much to enable this. The steps I mention below can be incorporated on any platform you base your site on. Here I specifically jot down the steps I did for my site. It’s just a set of principles, many of them already W3C Recommendations.

Hugo Basics

Hugo allows you to completely define how your website is structured and styled. It allows you to even define the behaviour of the pages across. Typically a user chooses a theme from a varied selection and lets it handle everything. However, you always have access to the theme files and the code — just some Go snippets spread across HTML pages, making it fairly simple to modify the same.

  1. Familiarise yourself with your theme, typically present in /themes/
  2. Identify the customisations made
  3. Make changes to the code, typically present either in layouts folder of your site or the theme

Web Sign-in via IndieAuth

The first step in owning your identity online is allowing your site to be your identity online. All these needs is to declare openly your social network profiles as rel-me links and link those profiles back to your site. This allows you to log in to any IndieAuth enabled websites using just your website homepage, no need to create an account or maintain more passwords.

For me, I already had links to my social network profiles in my /layouts/partials/header.html file. All I had to do was add a rel-me tag to it — a sample snippet to Twitter profile below.

<a data-hint="Twitter" title="Twitter" href="{{ . }}" target="_blank" rel="me"> 
      ... 
</a>

I have selected Twitter and Github as the social network profiles to be used for identification.

You also need to declare the service which will act as an authorization endpoint when needed. This is used by other services, mostly IndieAuth clients, to validate your identity. To configure this, just add the below link to your site’s head.

<pre class="wp-block-code"><code><link rel="authorization_endpoint" href="https://indieauth.com/auth">

Identity via h-card

Of course, once you decide your site will be your identity, your profile online, you need to make sure it clearly declares your basic information, i.e. define that identity. This allows other sites and services to know more about you. This is done via an h-card, a part of the microformats2 specification.

I added an h-card with my name, nickname, email and photo in /layouts/partials/footer.html

<pre class="wp-block-code"><code><p class="h-card vcard"> 
   <a style="text-decoration: none" href={{ .Site.BaseURL }} class="p-name u-url url author metatag" rel="me"> {{ .Site.Author.name }} </a> / 
   <a class="p-nickname u-email email metatag" rel="me" href="mailto:{{ .Site.Author.email }}"> {{ .Site.Author.nick }} </a> 
   <img class="u-photo" src="img/headshot.png" alt="" /> 
</p> 

This way your social networks are not ones that define your identity, rather it is you who declare and control it.

Content definition with microformats

After defining yourself, the next step is to define your content. It is important for other sites and services to not just identify you, but your content too. Just add an h-entry markup (again part of microformats2 specification) to the posts template. This is possible by identifying the layouts that handle your posts and adding some markups to it.

I had to modify the /layouts/partials/post-header.html, /layouts/partials/post-content.html and /layouts/post/single.html. The information I declare is post title (p-name), post URL (u-url), author (p-author), date (dt-published) and, of course, the content (e-content). Finally, a typical post template looks as below.

<article class="h-entry"> 
    <h1 class="post-title p-name" itemprop="name headline">{{ .Title }}</h1>
    <span>Published <a class="u-url" href="{{ .Permalink }}"> 
        <time class="dt-published">{{ .Date }}</time>
    </a> </span> 
    <span>by</span> <span class="p-author">{{ .Params.author | default .Site.Author.name }}</span> 
    <div class="post-content clearfix e-content" itemprop="articleBody"> {{ .Content }} </div> 
</article>

Cross-site conversations via Webmentions

All the steps done till now allow defining your and your content’s identity for external websites. However, how do you enable conservations with them? If enabled, every time you or your website is referenced online, if they are IndieWeb Level 2 enabled, you are notified by Webmentions, another W3C Recommendation.

Webmention is a simple way to automatically notify any URL when you link to it on your site. From the receivers perspective, it’s a way to request notification when other sites link to it.

In short, it is a modern alternative to erstwhile Pingback mechanism in prime blogging days. Of course, you have to enable your site to both send and receive web mentions.

To send a webmention to the page you have referenced, you can notify by

  • using a form made available on the referenced page
  • using curl or one of the many open-source clients

If the referenced site can receive webmentions, they would be notified that you have linked to them. But how do you enable your site to receive web mention?

Again, it involves hosting and declaring a webmention endpoint. Of course, the active community already has a ready solution for this - webmention.io by Pelle Wessman. It is a hosted service created to easily handle webmentions”. All you have to do is sign in with your domain (i.e. validate your identity) and let webmention.io receive all mentions to your site. Once that’s done, just declare the web mention endpoint as below in your head.

<link rel="webmention" href="https://webmention.io/username/webmention" />

Webmention.io also provides APIs for you to fetch the webmentions to your content/site. You can implement your own solution for fetching and displaying these mentions along with posts. I have a simple Javascript to fetch and display them with posts — this is still a work in progress.

Interactions from Social Media

Though references to your posts from IndieWeb sites are handled, what about the references made on Twitter or Facebook? It can be in any form of response (i.e. likes, retweets/reposts) to the syndicated post. Of course, they do not send webmentions (wish they did).

One option is to implement your own backfeed to poll for such interactions and handle them as a response. Well, of course, the community has made sure there is a simpler hosted option. Enter Bridgy.

Bridgy is an open source project and proxy that implements backfeed and POSSE as a service. Bridgy sends webmentions for comments, likes, etc. on Facebook, Twitter, Google+, Instagram, and Flickr.

I was set — now, every time there is interaction about my post on a service, bridgy captures that and sends a webmention to my endpoint.

One More Thing - Micropub

At this point, I had completely IndieWebified this site. I understand it might get overwhelming if you read it as a long sequence of steps. But trust me, the changes to be made are neither too many nor too complicated. It is just setting your site with appropriate markups and endpoints. There is also a really helpful guide in IndieWebify.me that walks you through every step, and also validates if you have everything set up correctly. But if you still do not want to go through the trouble, I have open sourced the changes I made to the theme I was using. You can use this theme, style it as per your liking, if needed, and get going.

For me though, there was one more thing pending. At the same time I was doing setting this up, micro.blog had caught my attention. I already had a section dedicated for the microposts. I configured a feed for these posts, the microblogs, to syndicate to my micro.blog timeline too. I was enjoying the interactions I was being part of with the community there2.

There was just one issue, I could not use it to post to my site. My process to post to this site still involved text editors and git commits. I wish it was simpler
 — at least for such microblogs. I wish I could just post from micro.blog and have an entry made. Enter Micropub, again another W3C Recommendation.

It is the trickiest part of the puzzle. Again it involves creating an endpoint which can accept a request to post, verify that it is coming from an authorised source and finally create the post file in required structure for Hugo to build and deploy. I have enabled the support for Micropub on this site, thanks again to Paul.

I would like to detail out the solution I have running. But that would be a topic for another detailed post. In short, I hosted Paul’s open-source micropub endpoint3, configured it to generate the post in the format I need, configured it to commit to my website source at GitHub, declared it as my site’s micropub endpoint and then let Netlify handle the rest.

You bet I would say it was all simple. I won’t.


I have realised that the idea of owning your identity online is a crucial facet of protecting yourself and your content in this fragile, siloed world of internet. It may be perceived as ostentatious by many, but it is rather humble, driven by a virtuous intent. There is nothing wrong in attempting to control what you post online, to make sure it stays online till you want it to. IndieWeb project allows that.

I do also realise that it is naive to think no one getting online will find this process irksome. Even though well defined, the principles are not for all. The simplicity of using and posting on social media services will continue to attract regular users4. However, here’s wishing that at least a part of these users are inspired to get their own personal domain. After all, it’s the first step in getting started on this IndieWeb journey.

Update (23rd September 2020): Updated the post to clarify the site has been moved recently to WordPress.


  1. IndieWeb terms it POSSE - Post on Site, Syndicate Elsewhere

  2. It really is a great community. I would urge every one with a blog or a site of there own to join the platform. It is open, stays focused on letting you own your content and makes you be part of a wonderful set of people, all with some varied talent. With an open mind, there is so much to learn.

  3. Though it’s primarily created for Jekyll, it does work with Hugo too.

  4. In a way, this simplicity brought more people online, gave them a platform to create and publish their content. Gave them a voice. It would be pretentious to only blame them for their frailties and not appreciate what they have fostered.