Incremental IndieWeb

July 4, 2024

As I evolve this site incrementally, I find I'm aligning with several IndieWeb principles. The incremental approach suits my software development instincts. But my taste for abstraction, information hiding, and modularity has also guided the way I've developed this site.

I'll list the principles in turn and explain what they mean for this site. Not all the IndieWeb principles are covered here, just those that seem most applicable.

Own my content

My initial motivation for building my own website was so that, rather than posting extended threads on social media (Mastodon in my case), I could write a post and then publish a link to the post via email, social media, etc. This is often summarised as POSSE: Publish (on your) Own Site, Syndicate Elsewhere. The post remains my data, under my preferred license, and with the access control I choose.

I started with a chronological blog, with posts like this one. That was sufficient for a while, but I soon needed a file server so I could embed images (and the occasional video) in posts.

At first I used links to files hosted by my cloud storage provider, but I decided to abstract that using a file server. This avoids vendor lock-in: I can switch cloud providers without changing links to files. In the spirit of openness, most diagrams on the file server are accompanied by their Graphviz source files.

Next I added a notes server, separate from the blog. This is for reference articles which aren't time-dependent and which I can incrementally improve.

Lastly (for now), I wanted a pastebin-like site with revision history, i.e. a gist server. This reduces my dependency on github gists and is a more convenient way of creating certain (groups of) files than using the file server.

Own my metadata

The IndieWeb principles also talk about owning your own content in the form of metadata. There are two kinds of metadata on my site: <link> elements in HTML and WebFinger documents which are accessed via URIs. Both these kinds of metadata use link relations.

The <link> elements in the HTML header of my blog implement IndieAuth. So I can log into any site that supports IndieAuth using https://underlap.org as my identity. Here are the relevant headers:

<head>
    ...
    <link rel="me" href="https://github.com/glyn" />
    <link rel="me" href="https://fosstodon.org/@underlap" />
</head>

The site supports two WebFinger documents. One is accessed via the URI acct:glyn@underlap.org and consists of human-readable information about me. The other is accessed via the URI acct:mastodon@underlap.org. This is an alias for my mastodon account which abstracts the mastodon instance I'm currently using. From a desktop browser¹, you can see the WebFinger documents via these links: acct:glyn@underlap.org and acct:mastodon@underlap.org, but here are their current values at the time of writing:

{
  "subject": "acct:glyn@underlap.org",
  "aliases": [
    "acct:mastodon@underlap.org",
    "https://github.com/glyn"
  ],
  "links": [
    {
      "rel": "http://webfinger.net/rel/profile-page",
      "type": "text/html",
      "href": "https://underlap.org/about"
    },
    {
      "rel": "http://webfinger.net/rel/avatar",
      "type": "image/jpeg",
      "href": "https://underlap.org/data/glyn-avatar.jpeg"
    }
  ]
}

and:

{
  "subject": "acct:mastodon@underlap.org",
  "aliases": [
    "https://fosstodon.org/@underlap",
    "https://fosstodon.org/users/underlap",
    "acct:glyn@underlap.org"
  ],
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://fosstodon.org/users/underlap"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe"
    }
  ]
}

From a modularity point of view, I much prefer WebFinger over including <link> elements in HTML content. The WebFinger server can then operate independently of the web server delivering the HTML content. It's just unfortunate that IndieAuth does not fall back to WebFinger if the <link> element it is expecting is absent, so to support IndieAuth my site needs to support both kinds of link relations.

Own my identity

The site's domain name is owned by me and is a good way of identifying resources associated with me, including via IndieAuth as described above.

I have a couple of email addresses glyn@underlap.org for general email and work@underlap.org for mailing list and issue tracker subscriptions and the like. I have the mastodon identity @mastodon@underlap.org as mentioned above.

Document my stuff

I've written a number of blog posts on how I set up this site. See #colophon. Apart from possibly being interesting to others, this is a good way of me capturing some details I'm likely to forget. I often refer to these posts when doing maintenance on the site.

Make the tools I need

I've written a couple of tools, both in Rust, open sourced, and described on this site (see #colophon). The first was a NGINX robot access module which enforces robots.txt rules. The second was a WebFinger server, which I use to serve the WebFinger metadata mentioned earlier.

Use the tools I make

Since I'm retired, I'm not about to write tools for anyone else (unless I have a very good reason).

Have fun

I've really enjoyed putting together this site. I love the sense of ownership it gives me. I always enjoy coding in Rust. I find writing absorbing and therapeutic. Plus fiddling around with a Linux VPS is a pleasure.

Modularity

Rather than install some monolithic piece of software that provides multiple features of IndieWeb, I've chosen to install several small servers behind a NGINX reverse proxy. I can then upgrade or swap out these servers while keeping most of the site unchanged.

Here's the current set of servers:

All resources on the site are accessed over TLS connections through the https URI scheme, covered by a single robots.txt file enforced by my nginx_robot_access NGINX module, and are automatically backed up to a common location by a nightly cron job.

Conclusion

I've described how this site aligns with several IndieWeb principles: owning my content and metadata, owning my identity, documenting my stuff, making the tools I need and using the tools I make, having fun, and modularity.

There is one IndieWeb principle that I'm not sure is achievable: longevity. This is a personal site and it will ultimately cease to exist. Perhaps the internet archive will capture some of my content for posterity. I'm not overly concerned as the content of the site is fairly ephemeral. That said, I aim to keep the site around as long as I can.

Before I heard of the IndieWeb and its principles, I liked to think of this site as roughly similar to a Solid Pod: a way of making my web resources available, but all owned and controlled by me. However, there are no Solid-specific protocols here, just standard, open protocols which are already widely in use.

Both these descriptions — IndieWeb and Solid — fit with my software development instincts for abstraction, information hiding, modularity, and incremental development.

#colophon #IndieWeb

Footnote:

¹: warning: WebFinger documents don't seem to render as JSON on certain mobile browsers, such as Firefox. If you know how to solve this, please let me know.