Why support this? Frankly, I don't use PGP for anything except as an option for logging into sites that use IndieLogin, via the markup on my homepage. One of the reasons for this is that PGP is largely incomprehensible. However, WKD seems to be a fairly useful step in the direction of making it more usable. Since the maintenance overhead of WKD for a single-user site is basically zero, I decided I might as well set it up.

Setting it up

WKD lives in the .well-known/ namespace, and can be implemented as a flat file structure. There is a more complex mechanism called Web Key Service which can be used for more dynamic implementations, but this is overkill for a personal site.

Generating the WKD directory structure can be done with the gpg-wks-server command in recent versions of gnupg. The wiki page claims you should use gpg-wks-client, but my installation doesn't have this tool and the server takes the same options. In my case, generating my directory looked like this:

>> mkdir openpgpkey
>> gpg --list-options show-only-fpr-mbox -k vil@vil.lv | gpg-wks-server -v --install-key -C openpgpkey
gpg-wks-server: gpg: Total number processed: 1
gpg-wks-server: using key with user id 'vilhalmer <vil@vil.lv>'
gpg-wks-server: gpg: Total number processed: 1
gpg-wks-server: directory 'openpgpkey/vil.lv' created
gpg-wks-server: directory 'openpgpkey/vil.lv/hu' created
gpg-wks-server: policy file 'openpgpkey/vil.lv/policy' created
gpg-wks-server: key 7CFAF4A3748190EB6EAC778005FA2E1C6481BDF3 published for 'vil@vil.lv'

You'll notice that the directory structure includes the domain. In the case of a personal site, you actually need to remove this layer from the path. From the wiki:

The hu directory has to be published on your server as https://openpgpkey.example.com/.well-known/openpgpkey/example.com/hu/ (or https://example.com/.well-known/openpgpkey/hu/ iff openpgpkey.example.com is not resolvable via DNS).

>> cd openpgpkey
>> mv vil.lv/* .
>> rmdir vil.lv

Now the openpgpkey directory needs to be published to .well-known/ at the root of your site. This is left as an exercise to the reader. :)

I had to add the execute bit to the hu subdirectory in order for nginx to be willing to serve the file within. I have other rules in place to prevent directory listings as the wiki specifies you should. This recommendation probably doesn't matter so much on a single-user site anyway, but is instead designed to prevent user enumeration on a shared instance.

Finally, I verified that my key was fetchable. To be explicit you can add --auto-key-locate wkd, but this has been the preferred mechanism for a while.

>> gpg --locate-external-keys vil@vil.lv
gpg: key 05FA2E1C6481BDF3: "vilhalmer <vil@vil.lv>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
pub   rsa4096 2016-04-05 [SC]
      7CFAF4A3748190EB6EAC778005FA2E1C6481BDF3
uid           [ultimate] vilhalmer 
sub   rsa2048 2016-04-05 [E] [expires: 2024-04-03]
sub   rsa2048 2016-04-05 [SA] [expires: 2024-04-03]

Troubleshooting

If it doesn't work, you'll see something like this instead:

>> gpg --locate-external-keys vil@vil.lv
gpg: error retrieving 'vil@vil.lv' via WKD: No data
gpg: error reading key: No data

If things aren't in quite the right place on the first try and gpg is unable to find the .well-known/ path when you query for your key, it will cache the belief that the domain does not support WKD. This makes it difficult to test again after you adjust things. You can tell this is happening by running gpg verbosely and looking for the following line:

gpg: Note: WKD uses a cached result

I left Twitter over one year ago, with the intent that I would reappear on some more open platform. Mastodon seemed like the obvious choice, but profile migration still doesn't exist, and I didn't want to join what was effectively yet another silo. In my view, the number of instances that have shut down over the past year have vindicated this decison. I want to own the things I post on the web, so that if they eventually disappear it's at least my own fault.

Well, it's time to go. It's hard to leave after ten years, but this is no longer a good place to be and Twitter is committed to making it worse. You've all been an important part of my life, and I'll miss that. See ya around. vil vilhalmer 4:43 PM - 16 Aug 2018

At the time, Mastodon had just added interoperability with the ActivityPub protocol. This seemed like the obvious solution: I could be part of the fediverse without needing to choose an instance, and without the complexity of hosting one myself (Mastodon is not designed for a single user, the administrative overhead and the fact that it's written in a language I don't use made running it not worth it.) I started writing my own implementation of ActivityPub, with the following design goals:

• Mastodon-compatible
• Database-free
• Static-first

This turned out to be a much larger project than I intended. (Story of my life.) In particular, Mastodon is very picky about the AP implementations it will talk to, and I spent more time trying to keep it happy than actually building a system I could use to post words on the internet. I made some good progress, and I intend to continue work as I have the inspiration^*, but I needed a way to get myself back on the web in the near-term as well.

So the question becomes: what existing, open technology allows you to post text on the web with the minimal amount of up-front work? Surprise: it's HTML.

HTML?? Who writes that anymore? We have like, Markdown and stuff! While it's true that writing HTML by hand isn't the most fun thing in the world, it's far from the worst. This post was entirely hand-crafted. With that said, it was crafted with an eye toward eventually generating the structure with some sort of static site generation tool. I haven't settled on one, but historical evidence suggests I will end up writing my own.

Standards to the rescue, sort of

Posting stuff on my website only solves one part of my original goal, though. While it gives me ownership of my content, it also ensures that no one will ever see any of it. The second part, syndication, falls squarely in the realm of the Indieweb. Indieweb isn't a single technology, it's a loose collection of parts that you can put together however you like to teach your website to communicate with other websites.

One of the coolest aspects of the Indieweb is built on top of the original semantic intent of HTML using Microformats. By annotating content with simple standard classes (this article is an h-entry, for instance), you enable an ever-growing set of tools to automatically parse your website into feeds, contact information, calendar entries, and things not yet imagined.

In my case, I'm using these building blocks to make it possible for readers to subscribe directly to my website, much like you would an RSS feed. By annotating the content directly using an h-feed, I avoid the need to maintain two (or more!) disparate representations of my posts. People can subscribe to the h-feed simply by dumping vil.lv into their reader. The reader will automatically discover the feed using the <link rel="feed"> tag on the homepage, which points to /posts. If I wanted, I could also have a feed embedded directly into the homepage with a few recent posts, but currently the homepage is static and I like it that way. It also has some features of its own.

There is of course a downside or two. The most obvious is that, even if you clicked on every single link in the above paragraph, you have no idea how to subscribe to my posts. The Indieweb is a big space, full of standards which need to be used in combination with each other to be useful. Most things have no "one-stop shop" (at least not yet). There's no Google Reader here (again, not yet), but then again there's no Google Reader anywhere anymore. Subcribing to things on the web in 2020 is kind of a mess.

This is a chicken-and-egg problem. Until enough^* websites are using Indieweb standards to publish content, it will remain a niche. Some standards, like rel-me have gained wide adoption, but these are tiny pieces of the puzzle. I can't even point you to a reader that you can use right now, without any up-front work.

Philosophy

The core of the Indieweb philosophy is that your website is the One True Representation of "you" on the web. This means you use it for everything, including signing in on other Indieweb sites and services. Since encouraging the growth of the Indieweb is obviously among the community's top priorities, there isn't much of an incentive to offer alternative methods.

So what does this mean for potential Indieweb users? It's always tempting to make the "well my <insert older relative here> won't be able to do this" argument. We'll ignore the general accuracy of this argument in favor of the spirit behind it: non-technical people are very unlikely to own a domain, or even care to. They're even less likely to want to read about what a microformat is, or how to tell people about their articles using something called WebSub. This makes the Indieweb necessarily a fairly tech-centric space. However, I don't believe that this makes it less valuable. The Indieweb is a new technology, though it happens to be built on top of some very old ones. New technologies are always inhabited by tech types at the beginning. But the reason we create them (or at least the reason we should create them) is with the intent of improving the world at large. While the Indieweb may not yet be usable^* by the average internet denizen, this doesn't mean it has to remain this way.

With every tool that the community builds and every standard that they iterate on, we get a little closer to having a truly open web. What is currently a complex pile of disparate parts has the potential to grow into something even simpler than the web we currently inhabit. In the future where the Indieweb reaches its full potential, no longer does a user have to join silo after silo, trying to keep up with the latest trends, and having to rebuild their identity each time. Instead, they simply have a domain, and that domain is them. Represented however they want, however much they want, truly a space of their own. Being on the web is complicated because we haven't made it simple. Simple as that. Let's build the tools to change that.

Enough philosophy already

This article got quite long and abstract at some point. The concrete takeaway is that I'm going to be posting things here from now on. This will make it hard to follow my content at first, but it will get easier as I build out my integration with Indieweb and other standards. Hopefully someone out there finds what I have to say interesting enough to stick around during that process. I have no idea how I'm going to bootstrap my presence outside of existing friends and the Indieweb circle, but I'll figure something out.

The second takeaway is that while the Indieweb may not yet be useful for a general audience, the fact that it is built on existing web technologies makes it a perfect example of progressive enhancement. I can still send the url of this post to anyone with an internet connection, and they will be able to read it without any proprietary clients or registering an account that they don't want. And if we ever reach that glorious Indieweb future? It will be visible there from day one.

The final point of this article was to get someone else interested in the lost art of building a personal website, and to let that someone know that there are exciting new things happening. Did it work? Get started. (P.S.: while it's obviously not optimal, you could use a Github Pages site to get your feet wet. It's enough to give you a web sign-in identity. You will lose your identity if you move to your own domain later.)