Skip to main content

Pretty Good Hat

Tuning up my Little Piece of the Indieweb

I’ve thought a couple of times about ways to connect this lonely personal site to the broader world. I have plenty of outgoing links, but little way to know if my posts actually connect with people on the other end, save for the occasional referrer link. Once or twice I started drafting a very small commenting system (one of which used the App.net API and would have stored comments in that system), but my energy waned with my enthusiasm for actally doing something like managing comments.

So I’m really intrigued by the notion of POSSE publishing, which I encountered via Jeremy Keith’s Adactio. The core idea, briefly, is about owning the stuff you put online — which resonates with one of my original motivations for putting up this site — and the community around it has developed and assembled a bunch of resources to implement this goal.

What does this mean for interaction? Among other things, what we think of as “comments” begin their life by being published at the writer’s own site, through the implementation of webmentions, where the target site builds its own mechanism for interpreting and syndicating those comments. The publishers going full-on with this method are using it to syndicate to platforms like Twitter or Flickr, too, all with the goal of initiating everything they put “out there” from within their own tools and sites. Needless to say, this is pretty cool, and it’s an opportunity for me to tinker with Pretty Good Hat, too.

So How Does This Work?

There are two core elements to building this: Sending outbound webmentions, and handling incoming webmentions. I’m going to try taking on each of these in pairs of phases: Phase One is most minimal, and Phase Two will try to be a little more sophisticated and integrated. Each step will need to work within the constraints of my little existing blog engine, and it all leans heavily on the writeup and work done by Jeremy.

Constraint one is that I don’t want to get too deep into the guts of the existing build system for my static blog. This means that building a lot of microformats support into my own posts will have to wait. I’ll have to work any microformats support into my own writing through specifiers to the kramdown processor and minimal modifications to the ruby code that actually builds the site.

Constraint two has to do with the fact that this is basically a static site, and I like it that way. But being a good indieweb citizen requires reciprocity: I don’t want to just be a publisher of my own stuff, and need a way to respond to the generosity of others who may link to me. The “live” appearance of links that may ping my content via a webmention poses some design difficulties.

What I’ve Got So Far

What I have going for me is that this joint is built in a pretty stepwise fashion. The pieces are ruby, but they’re invoked sequentially in a shell script. Without modifying the core write-and-post mechanism, I can add a post-processing method to send webmention(s) using mention ruby client to send webmentions automatically to each URL in my own posts.1

So that’s sending webmentions. What about receiving them? Again, I’ll lean on Jeremy’s work and use his minimum viable webmention code. I start by simply receiving and logging the mentions, putting them into a sort of attachment file linked to each of my own posts.


One great benefit of building and joining these two elements of supporting webmentions is that I can build them in parallel and use one to test the other.


On the question of static versus dynamically displaying webmentions: The strongest way to respect my static site goal would be to receive mentions, store them, and periodically check for anything needing processing, and add any new mentions to the static site entry pages. But I decided on dynamic so I wouldn’t need to poll for updates or add more to the core build script. This means a small load when displaying pages, and I could change to a scheduled rebuild if this ever becomes a problem — but this is a very low-traffic site, so that’s unlikely. I also keep a single unified log file for webmentions that I could use to rebuild all mentions if desired or as I expand my sophistication of treating them. For example, right now I reach out to target URLs and retrieve only the p-name of the entry, if available.2

So where am I now? After several hours of tinkering over a couple of weekends I have a functional webmentions implementation. Mentions should be registerable against any post here at Pretty Good Hat, and will be displayed on the single-entry page for that post. My endpoint is discoverable, but like Jeremy I also include a link (again on the single-entry pages) to a submission form for manually sending a mention. I accomplished this in what I think is a reasonably effective way given the constraints I described above: I had to add a few formatting stubs in my build code to put minimal h-entry syntax into my entries, and it look a fair amount of trial and error to get that display the way I like it.

Presenting the mentions requires a jquery call, so it cheats the static site a bit, but I’m already including jquery for lightview, so I may as well re-use it.

I extend a huge thank you to Jeremy Keith, whose posts got me started on this. (This one in particular.) I’m also grateful to this microformats post by Barnaby Walters, from which I learned a bunch. This is obviously a thing in process, and I welcome and appreciate any comments and feedback.


  1. This client is great. It finds links within an h-entry, so it’s not working with anything your footer or header, and it looks to discover a webmention endpoint at your target site. ↩︎

  2. The h-entry microformat allows me to syndicate a lot more than this; I’d be really interested in learning if there’s a community best practice for what to syndicate. My instinct isn’t to replicate the content of a mention, rather to pull just the name and link. ↩︎