Aaron Parecki

I’m always looking for fun and better ways to publish content to my website. There are several nice writing apps now, such as Byword for MacOS, which lets you write in Markdown and then converts it into HTML. Many of these kinds of apps have an option to publish to a Wordpress site, using Wordpress’ XML-RPC interface, which is more or less the MetaWeblog API.

I thought it would be a fun experiment to try to set up my website to handle those XML-RPC calls so that I can use these apps, at least until they support Micropub natively.

Problems with XML-RPC

As with most XML formats, XML-RPC is ridiculously verbose for what it’s doing. In order to send a single string value, it requires wrapping it in a surprising amount of XML:

<param>
<value><string>aaronparecki.com</string></value>
</param>

The MetaWeblog API also requires that you give apps your Wordpress password, which has been a known anti-pattern for a long time. With things like OAuth, we have better ways of authenticating against APIs without sending passwords around.

Micropub Bridge

To avoid needing to add actual XML-RPC support to my website, I set up a bridge that translates XML-RPC calls to their equivalent Micropub calls. The bridge also obtains an IndieAuth access token so that I can use a token instead of entering my password into these apps.

I didn’t bother adding any styling to the gateway since it’s something you’d only interact with once to set up, so apologies for the ugly screenshots that follow.

Here’s what it looks like to connect Byword to be able to publish to my website.

First I visit the gateway and log in.

That does the IndieAuth discovery and takes me to my website where I grant it access.

Then I’m redirected back to the gateway which provides instructions on what to do next.

The key to making Byword find the XML-RPC API is adding that EditURI tag to my website. Then I can go into Byword and add a new Wordpress site, entering my domain name.

It then asks for my username and password, which I enter by copying from the gateway.

Then Byword is all set and thinks it’s talking to a Wordpress site!

Now when I’m ready to publish this post, I click the “Publish” button in Byword, and fill in the title and tags.

Open Source

If you’d like to try this out, head to xmlrpc.p3k.io and connect your website!

The source code is available on GitHub.

I’ve only implemented the one newPost method that Byword uses when talking to the XML-RPC API. I’ve only tested this with Byword, so it’s very likely that other apps might be expecting more of the API to be implemented. Feel free to file issues if you have trouble using other apps! Eventually I’d like to implement more of the MetaWeblog API in this gateway, even if I really don’t like writing XML-RPC code!

January

Events

Went to Baltimore to help put on IndieWebCamp! It was a lot of fun, and I even added a couple fun things to my website during the second day.

I also filmed the talks at the DonutJS meetup.

Podcasts

I managed to publish only one episode of my podcast, Percolator, just before heading to Baltimore.

We launched applications for the StreamPDX Podcast Fellowship Program in January! We received way more applications than we expected!

IndieWeb Projects

We published the final version of WebSub, and the IndieAuth note, on w3.org! Thanks to the hard work of the Social Web Working Group for all their contributions!

My Website

I made several improvements to my website during January!

• Updated my Life Stack post
  
• Launched the collaborative pixel art on my home page
• Added support for posting code snippets to my site to switch off of gist.github.com
• Added a summary of my blog post archives so the archive pages are easier to use
• Added meta tags so my site looks better when links are posted to Twitter/Facebook/Slack
  

Other Stuff

Finally got my OAuth 2.0 book launched for Kindle! It turns out that the Kindle requirements made it a lot more work than just uploading the existing ePub version.

February

Events

Okta hosted Iterate 2018, where I went and had a great time chatting with people about OAuth and giving out copies of my book.

Podcasts

Again I managed to publish only one episode of Percolator during the month.

The StreamPDX team reviewed all the applications to the fellowship program, and it was really tough to narrow them down! We ended up inviting a handful of people in for interviews, and chose 4 out of that group. I began working with them on their podcasts, making pretty good progress the first few weeks!

I also taught the first Publishing your Podcast class of the season.

IndieWeb Projects

I made a lot of progress on my new IndieWeb reader during February! I wanted to get it in shape enough to use it during the conferences I was attending. I decided to split it into two parts, a Microsub server (Aperture) with no UI for viewing posts, and a separate client that has no storage backend of its own (Monocle).

I added a minor feature to OwnYourGram, made some minor changes to XRay, and released an updated version of the PHP IndieAuth client.

March

Big news in March! I accepted a full-time job at Okta! I've been working with Okta for quite some time now, but always part time as a contractor. I've written up more about what I'll be doing at Okta on the Okta Developers blog!

Events

• Co-hosted the first Homebrew Microblog Meetup with Jean
  
• Went to the PDXNode Hack Night and did a lightning talk about Monocle, my IndieWeb reader
• Filmed the talks at DonutJS, but had some technical issues with the audio, so those videos aren't nearly as good this month
  

IndieWeb Projects

I made lots of progress on Monocle, getting it to a point where I now can use it every day as my primary home on the Internet. I wrote a blog post describing how everything works, Building an IndieWeb Reader.

Thanks to the hard work of gRegor and Martijn, we were able to get a new release of the PHP Microformats parser out the door! This is now in use by Monocle, which should improve a lot of the feeds it's seeing.

Podcasts

Percolator is turning into a monthly podcast, as I managed to again get only one episode out during March.

The StreamPDX fellowship program is continuing, I've been writing some music for one of the podcasts which has been fun, but a lot of work.

We brought the StreamPDX trailer to the Portland Art Museum to record audio during an event!

I taught another session of Publishing Your Podcast.

Other Stuff

I finally set up an account at exist.io! I went through the list of all their supported integrations, and decided to customize a bunch of them.

Since I post notes and photos to places other than Twitter and Instagram, my website is the canonical source of my tweets and photos as well as the responses I get from them. I was able to use the Exist API to take over writing those values and now my Tweet/Instagram counts in Exist actually reflect the notes and photos I post to my own website.

I noticed they also support tracking miles biked, so since my bike rides are already on my website, I set up a script to push that data to Exist!

I also track other kinds of transport, and decided to use their custom tracking to visualize that per day. So now I can see at a glance which days I was on a bike, in a taxi, on a train, etc! It's pretty neat looking already, and I'm hoping they'll be able to be used in some insights later!

The Exist API even has a section for tracking money spent, although they don't integrate with YNAB (yet!). I got beta access to the YNAB API and was able to wire it up to report my spending from certain budget categories into Exist!

This release includes support for using an alternative HTML parser that understands HTML5 tags.

v0.4.3

The built-in HTML parser does not understand some HTML5 tags such as <article>, which causes issues when those tags are adjacent to elements that can be automatically closed, such as <p>. A simple example that is incorrectly parsed with a non-HTML5 parser is below.

<div class="h-entry">
  <p class="p-name">Hello World
  <article class="e-content">The content of the blog post</article>
</div>

Without proper knowledge of HTML5 tags such as <article>, the contents of that tag ends up inside the p-name in this example. Using an HTML5 parser will properly close the <p> tag and return the expected result.

The php-mf2 library does not automatically install the HTML5 parser, since it does not want to impose additional dependencies on your code base. If you wish to use the HTML5 parser, you can include it in your project explicitly, either by loading it manually or using composer:

composer require masterminds/html5

If this library is present, then the php-mf2 parser will use it when parsing HTML.

Over the last several months, I've been slowly putting the pieces in place to be able to build a solid indieweb reader. Today, I feel like I finally have enough in place to consider this functional enough that I am now using it every day!

One of the major missing pieces of the IndieWeb ecosystem has been having an integrated reading and posting experience that mirrors the ease with which it's possible to post and follow on Twitter and other silo apps. 

We've seen a few attempts at indieweb readers over the past few years, but nothing has really taken off or stuck around. Even my own attempts at readers have fallen apart, both the previous iteration of Monocle in 2016, and my fork of selfoss in 2014. My suspicion has always been that we haven't seen many people building out this part of the ecosystem because it turns out there are a whole bunch of different parts to building a reader, many of which have no overlap in skillset: managing the subscription list, polling and fetching feeds, parsing feeds, data storage, rendering posts in a UI, providing inline action buttons to be able to reply and favorite posts, etc. 

When I'm building out the UI components of a project, the last thing I want to have to think about is the invisible backend stuff like feed polling and parsing. Similarly when I'm tackling the problems with parsing and normalizing data from feeds, the last thing I am thinking about is Javascript button interactions. Not to mention that I am barely an iOS developer, so there's no way I'd be able to build out a full indieweb reader for iOS.

In April 2017, I started outlining a spec that draws a hard line between these very different parts of building a reader, and called it Microsub (for subscribing), as a complement to Micropub (for publishing). The basic idea is to separate the feed subscriptions from the UI parts of building a reader. 

I started working from the ground up on building out the various aspects I knew I would need in order to eventually end up with a fully functional reader. 

I based a lot of these design decisions around my previous experience in building a reader, as well as my documentation of how I use IRC to read content across the web.

My goal with this is to use this as my primary online dashboard to follow all kinds of content, as well as being able to interact with the content without leaving the interface. 

Channels

The main organization of the reader is laid out in "channels". You can also think of these as "folders" if you want. Many feeds (or sources) can be added to a channel, and the posts are all combined into a single timeline view.

Displaying Posts

Monocle supports displaying a few different types of content in posts. It has native support for notes, articles, photos, multi-photos, videos, audio clips, checkins, favorites, reposts, and replies.

Since I follow my Instagram feed in the reader, I wanted to have a good display for photos, especially when there are many photos attached to a single post. I ended up doing a simple custom layout when there are two or three photos. Four or more they just start tiling as half-size photos. With three photos, the first photo appears larger on the left and the other two are stacked to the right.

I wanted to be able to read full articles in the reader without jumping out to the site, but also didn't want to have to scroll endlessly when I'm just skimming headlines. So if an article has content that is too tall, it gets truncated with a "read more" link to expand it.

If the post has an audio file, such as podcasts, then there is a simple HTML audio player inline!

Post Actions

Each post has a set of buttons to be able to respond to the post. The quickly accessible actions are "favorite", "repost", and "reply". The three dots opens up an expanded menu with some additional options, some of which I have not yet implemented.

Currently it's possible to remove a post from a channel, and to open up a debug view showing the raw data behind the post. Eventually this will expand to include muting the author, blocking the author, or unfollowing the source the post came from.

Replying

Clicking the "reply" button drops down a little text box for posting a reply.

There is a character counter just so that I have a sense of how long the post is. Since this is posting the reply back to my website, this interface has no idea what sort of character limits there are, so it's just a simple counter. When I click the "Reply" button, the app makes a Micropub post to my website to create the post there. 

My website already has all the logic for adding that to my replies feed and sending webmentions to the post I'm replying to. Since this post I replied to is on Micro.blog, and Micro.blog accepts webmentions, the post showed up there within a few seconds.

The same workflow happens for favoriting and reposting things.

Syndicating to GitHub

My website also recognizes when the post I'm replying to is a Twitter or GitHub permalink, and will automatically syndicate my reply or favorite appropriately! Since I added my GitHub notifications to a channel, I can actually reply to GitHub issues directly from the interface!

Read-State Tracking

You may have noticed the little blue dots next to the channel names in some previous screenshots. Those indicate how many unread posts are in the channel.

 

However, some feeds that I follow end up with tons of posts in the channels, so many that the actual number of posts is no longer significant! All I really want to know is whether there is something new or not. To account for this, I can choose whether a channel implements per-item tracking, or just a boolean read/unread indicator, or disables read tracking altogether.

When I'm looking at a timeline, any new posts appear with a yellow glow around them. As the post scrolls out of view, it gets marked as read, and that state is pushed to the server so that other clients will also know it's now read.

I really enjoy not having to manually mark things as read, instead the interface just handles it all for me without any additional interaction.

Multiple Website Support

Since I actually have several different websites I use, I wanted the response buttons to be able to post not just to my website, but also to the other websites I have. For example, my cat Dora, who has her own website is not always the best at using the computer, so sometimes I have to favorite things for her.

I can choose a alternate default account per channel so that the response buttons will actually post to the alternate website. Notice Dora's cat face in the bottom right corner of the screen. This lets me know that interacting with posts in this channel will be posted to this alternate account.

I can even temporarily switch to a different account by clicking on the profile icon and choosing another account.

Simple Posting Interface

You may also have noticed the little pen icon in the lower left corner. Clicking that pops up a dialog for writing a new post from the selected account. I chose to keep this interface super simple, providing just a text box and character counter. 

If I need to write something more complicated, such as including HTML content, adding a photo, or choosing where the post is syndicated, then I'll just pop over to Quill and write the post there instead.

Multiple Apps

I mentioned earlier that there were many parts to this, and I haven't talked much about that yet. The most important thing about the architecture of this system is that it is not just a single monolithic app. Instead, there is a server responsible for collecting all the data from the feeds I'm following, and separate apps for displaying them! Since I was documenting everything on the wiki as I was building this out, other people were able to jump in and start writing clients from the beginning! 

There are already two other great interfaces that work with the same backend server! 

Here is a Javascript app called Together, written by Grant, showing the same posts you saw in a previous screenshot.

Here is the same content rendered by the iOS app, Indigenous, written by Eddie.

I'm pretty thrilled that already we've been able to have two people jump in and build readers so quickly already, thanks to the hard work of feed fetching being abstracted away by the server!

The Microsub Server

Now to start getting into the technical bits of how this works. Feel free to skip this section if specs make your eyes glaze over.

I mentioned before that the main separation going on here is splitting off the feed fetching and parsing from rendering the posts.

This accomplishes a few things:

• Enables app developers to focus on the UI aspects of building a reader
• Allows you to choose which service you want to use to manage your subscriptions
• Enables you to use many different reader apps all talking to the same server backend that you control
• Leaves room for servers to do experimental things with feeds and subscriptions (think "magic" or "smart" feeds) without having to bother with the UI components or needing to get clients to add support

The main idea behind this is the Microsub spec. This is the spec that the Microsub server implements so that clients know how they can talk to it. 

Ideally there will eventually be a large ecosystem around the spec, with many clients to choose from, and many servers as well. We'll see some projects build in Microsub support natively, so that they work out of the box, and we'll also see some dedicated feed subscription services support Microsub. The nice thing about using your website identity to tie the pieces together is that you can choose your Microsub server separately from choosing the software that powers your website.

For example, I decided early on when building my website that I didn't want to mix the idea of following feeds into the same software that powers my website. So instead, I wrote an external Microsub server called Aperture, which is responsible for all the feed polling and parsing and storing the posts in channels. Aperture is open source, although I still consider it "in active development", so I am not officially supporting it right now. You are of course welcome to get it running yourself, but be prepared for things to change quickly.

(Aperture actually has two components, Watchtower which is a microservice that polls feeds and delivers them to Aperture itself, and Aperture does the actual feed parsing with the content provided by Watchtower. This allows me to scale out the feed polling separately from the Microsub server.)

If you want to try to get Aperture and Watchtower running, Daniel did a pretty great writeup of his experience getting things set up in two posts: Part 1 and Part 2.

Ideally I would love to see some more implementations of Microsub servers, so head over to the spec if that's your thing!

Monocle

Monocle is the Microsub client I wrote that's featured in the screenshots above. It is also open source. Since it doesn't do any feed parsing itself, it doesn't even have a storage backend! Everything is fetched on the fly with the exception of the channel list and Micropub config which is persisted in the session data. 

When I click on a channel to view it, Monocle first makes a Microsub timeline request to Aperture to fetch the channel data, then renders it in the timeline view. This is analogous to the iOS app Indigenous fetching the timeline data from the Microsub server then rendering it on the phone, except Monocle is doing that server-side to generate HTML for the browser.

You might think I'm crazy for having written a PHP app that fetches JSON from an API and then renders --gasp-- static HTML in 2018, but guess what -- it's fast!

Monocle is open source, but I am also hosting a version online that anyone is welcome to use at monocle.p3k.io. Since it doesn't actually store anything itself, I don't expect it to take up any significant resources any time soon! Of course in order to use it, you'll need to have your website pointing to a Microsub server of your choosing. Since that's where all the actual work is done, I am not making my hosted version of Aperture available for general signups right now. You'll need to either get that running on your own server, or build a Microsub server from scratch!

Putting the Pieces Together

This last section has been a bit of a wall of text, so here is a diagram showing how all the pieces fit together to make this possible!

My website contains the IndieAuth and Micropub bits, but others have chosen to use external services for those as well. I've also chosen to outsource sending and receiving webmentions to external services, whereas other people end up handling those within their own website code as well.

The reader apps all talk to the Microsub server that I've linked to in order to view posts, and when I tap a "like" button or write a reply from the app, they post that to my Micropub server to create a new post.

I use webmention.io to handle my incoming webmentions, and it is configured to send posts to a channel in Aperture using Aperture's Micropub API.

Further Reading

This has been a very long read, so congrats if you've made it this far! Here are some links if you're curious about how you can start building out various pieces of the ecosystem as well!

Specs

• Microsub - a standardized way for apps to consume and interact with feeds collected by a server
  
• Micropub - a W3C Recommendation for creating, updating and deleting posts using external apps
• Webmention - a W3C Recommendation enabling cross-site comments and other interactions
• IndieAuth - an OAuth 2.0 extension that enables you to authorize third-party apps to talk to your Micropub or Microsub servers
• mp-destination - a Micropub extension allowing a server to designate alternate destinations for creating posts

Open Source Projects

• Indigenous - an iOS Microsub client
  
• Together - a React JS Microsub client
• Monocle - a server-side PHP Microsub client
• Aperture - a PHP Microsub server
• Watchtower - a feed fetching microservice

Future Work

While this is all a good start, and I do actually use this as my primary online home now, there is still a lot more work to do!

• More Microsub servers! I want to see at least two more solid Microsub server implementations in the relatively near future! That will help develop the spec further and ensure we're actually building interoperable tools. I suspect one of the implementations will end up being part of an integrated CMS such as Known or Wordpress, or will be a proxy to an existing feed reader service.
  
• Following private content. Private content has always been a challenge, mainly due to the fact that any time authentication is involved it complicates things a lot. With IndieAuth finally written up as a spec, we now have a solid building block to use to experiment in this area more.
• An Android Microsub app. While both Monocle and Together work pretty well on mobile browsers, there are still many advantages to having a native Android app! And it sounds like one is already in the works.
• Better UI for actually following people. I've kind of taken a shortcut on this front in order to move the rest forward. Right now, you still need to type someone's URL into a Microsub app in order to follow them. There are many challenges with streamlining this process further.

As always, I'm happy to chat about any and all of this! It's been a lot of fun already to build this all out and see it working! You can find me in the IndieWeb chat via IRC and Slack, if you send me a Webmention I'll see it in my reader, or find me at an upcoming IndieWeb event!

This release includes two new methods for quickly developing an IndieAuth client.

The library can now handle all the boilerplate work of generating a state parameter, URL canonicalization, and state management between the request and callback.

Developing an IndieAuth client now requires just setting a few configuration variables and deciding how to show error messages in your application. See the code below for an example of using the new features!

index.php

<form action="/login.php" method="post">
  <input type="url" name="url">
  <input type="submit" value="Log In">
</form>

login.php

<?php
require('vendor/autoload.php');
if(!isset($_POST['url'])) {
  die('Missing URL');
}

// Start a session for the library to be able to save state between requests.
session_start();

// You'll need to set up two pieces of information before you can use the client,
// the client ID and and the redirect URL.
// The client ID should be the home page of your app.
IndieAuth\Client::$clientID = 'https://example.com/client/';

// The redirect URL is where the user will be returned to after they approve the request.
IndieAuth\Client::$redirectURL = 'https://example.com/client/redirect.php';

// Pass the user's URL and your requested scope to the client.
// If you are writing a Micropub client, you should include at least the "create" scope.
// If you are just trying to log the user in, you can omit the second parameter.
list($authorizationURL, $error) = IndieAuth\Client::begin($_POST['url']);
// or list($authorizationURL, $error) = IndieAuth\Client::begin($_POST['url']);

// Check whether the library was able to discover the necessary endpoints
if($error) {
  echo "<p>Error: ".$error['error']."</p>";
  echo "<p>".$error['error_description']."</p>";
} else {
  // Redirect the user to their authorization endpoint
  header('Location: '.$authorizationURL);
}

redirect.php

<?php
require('vendor/autoload.php');

session_start();
IndieAuth\Client::$clientID = 'https://example.com/client/';
IndieAuth\Client::$redirectURL = 'https://example.com/client/redirect.php';

list($user, $error) = IndieAuth\Client::complete($_GET);

if($error) {
  echo "<p>Error: ".$error['error']."</p>";
  echo "<p>".$error['error_description']."</p>";
} else {
  // Login succeeded!
  // If you requested a scope, then there will be an access token in the response.
  // Otherwise there will just be the user's URL.
  echo "URL: ".$user['me']."<br>";
  if(isset($user['access_token'])) {
    echo "Access Token: ".$user['access_token']."<br>";
    echo "Scope: ".$user['scope']."<br>";
  }
}

Just pushed a few changes to OwnYourGram this morning! Here's what changed:

You can now see the schedule of your account so you know when to expect photos! You'll see which tier you're at, and how long until your account is next polled.

You can now add a list of tags that will be sent along with every photo! This is useful if you want all your photos to be tagged "photo" or "instagram" for example.

I also updated the documentation to include an example of the JSON post format that OwnYourGram can send. 

If your site has a Media Endpoint, then OwnYourGram will first upload your photos to your Media Endpoint, and include those URLs in the Micropub request. 

That's it for now! Happy OwnYourGramming!

Today, we published the last of the two W3C specs I am editing! WebSub was published as a W3C Recommendation, and IndieAuth was published as a Working Group Note.

WebSub

WebSub is a standardized way for publishers to notify subscribers when new content is available. It was formerly known as PubSubHubbub, which was hard to say, so I'm glad we renamed it. 

One of our goals with WebSub was to ensure that existing PubSubHubbub implementations would still be compliant, so there are already lots of implementations in the wild! If you're publishing content online, want to receive realtime updates when feeds are updated, or are building a tool to facilitate either of these, WebSub is a great fit! You can use the tool at websub.rocks while building your implementation to get immediate feedback!

Thanks to everyone who contributed to the spec, and especially my co-editor Julien!

IndieAuth

IndieAuth is an identity layer on top of OAuth 2.0, and used by Micropub clients. Micropub was published as a W3C Recommendation in May of last year. Today, IndieAuth was published as a W3C Working Group Note. 

The Social Web Working Group did not set out with the goal to standardize any sort of authentication mechanism, but since almost all of the Micropub implementations already supported the same mechanism, we decided to publish a "Note" to that effect. (The Micropub implementations that don't use IndieAuth use hard-coded tokens as a shortcut.) Notes are quite different from Recommendations in the eyes of the W3C, as described by this sentence: "The publication of a NOTE by the Consortium implies no endorsement of any kind." The goal of publishing this Note was to capture the current state of interoperable implementations.

One of the things I like most about the W3C standardization process is that specs are published after they describe things that are working, rather than published as an aspirational blueprint. We kind of pushed that definition to an extreme with IndieAuth, since there have been live interoperable IndieAuth implementations for several years now. Previously, I had written up several guides for how to implement the various roles in the IndieAuth flow, but never written it down as its own spec. The guides were certainly useful, as was clearly demonstrated by the fact that people were following them to build out various parts of the ecosystem. But there is also a need for a spec to lay things out and remove any ambiguities along the way.

Thanks to everyone who helped iron out the details of the language in the spec! We made a lot of good progress over the last few months!

As always, you can help me and the rest of the IndieWeb out by adding support for any of these specs on your own website! We are always excited to welcome new people to the IndieWeb chat if you have any questions!

I just finished my IndieWebCamp hack day project, and I'm pretty excited about it!

A long time ago, my website used to have this 7x7 grid of pixels on the home page, which visitors could toggle between blue and green. It saved the state after you'd click them, so you could leave little pictures for the rest of my website visitors. 

I eventually abandoned that version of my site, and that feature disappeared as well. I decided that it would be fun to add it back to my current website today!

So now, my home page has a similar section at the top with a little grid of pixels again!

There were a few differences in my approach this time around. I decided to make the grid 20 pixels wide by 3 pixels tall, in order to reduce the chances of people being able to spell things or draw anything inappropriate. 

I wanted the grid to be responsive as well, so that the cells shrink appropriately when the width of the column shrinks. I found this nice answer on StackOverflow, "Grid of Responsive Squares", which pointed me at a technique I hadn't know about, which is to use a percentage for the padding-bottom property. Each cell in my grid is calc(5% - 1px) wide, with padding-bottom: calc(5% - 1px) as well. This makes the height match the width, which is based on the relative size of the container.

I also made the grid realtime! If you open the home page in two browsers, you'll see one browser update when you click a pixel in the other! I was able to do this without any complicated server-side support thanks to the nginx push-stream module that I already have installed. It lets a browser subscribe to an endpoint using the EventSource API, and then from my server I can send a POST request to the nginx module to broadcast data to anyone listening.

Maybe my next project will be to get some Neopixels and make a little thing for my desk that always shows the current pattern!

It's very convenient to be able to quickly share a link to a code snippet, which is something I've mostly done using gist.github.com. While often the code snippets are sort of throwaway, I still feel bad that I'm posting them in a place that I don't control.

Today I added support to my site for natively posting code snippets. It wasn't nearly as hard as I was imagining it was going to be! Since my site doesn't have a posting interface of its own, that also meant that I needed to add support to Quill to create these posts via Micropub.

Since this is still relatively experimental, I didn't add a button to it in Quill, but the page is live.

The only required part of this is the code box. The interface lets you optionally set a filename, which will automatically set the language if it matches a list of known languages. The language is included in order to indicate to my site which syntax highlighter to use. Here's what that ends up looking like on my site.

I use the GeSHi syntax highlighter, which covers a wide range of languages and works very well, but I'm not super happy with the colors it uses. I'd like to find a stylesheet or even a different syntax highlighter that looks closer to the colors on GitHub. In the mean time, I'm happy enough with this to use it.

I ended up doing quite a bit of fiddling with my CSS to make these posts look good. You'll notice the grey background of the code block extends to the edges of the post, whereas normally there would be some padding. I also changed the font of the post name to a fixed-width font. If there is no filename, then I wanted the grey background to extend to the top of the frame, which is also something unique to these posts.

The last step of making this actually useful is to integrate this into my browser workflow, including editing the posts easily. There is a bookmarklet that will either open up a new window or launch the editing interface depending on whether I'm looking at an existing code post.

I'm pretty happy with this, and I hope I don't post on GitHub anymore unless I'm specifically using their fork feature of Gists!

I've been wanting to improve the layout of my blog post archive pages for some time. Previously, the page just listed out the full contents of the last 20 posts, and you could continue navigating back 20 posts at a time. I realize that some people like reading the full posts on the archive page, rather than having to click into each one, but it wasn't easy to just skim the post titles to get a sense of what was on the page.

As an intermediate step before launching a real archives view, I took Tantek's suggestion of adding a sort of "table of contents" view to my existing pages.

Now on my "articles" page, there is a list at the top of the names of each post. 

Below that, I still show the full contents of each post. The table of contents also links to fragment IDs for each post on the page, so that you can quickly read the posts without doing full page loads.

As a bonus, this also works with my tag-filtered article pages, such as Articles Tagged #indieweb.

I like this view since it makes it a little easier to find a lot of past content by topic rather than having to continue to page back 20 posts at a time.

I'm still planning on improving the overall archive browsing on my site, but this was a relatively easy first step and is a good improvement.

Ever since launching the new version of my website in 2016, I haven't had the special meta tags that Facebook, Twitter and Slack use for showing the nice preview of links shared. It's been annoying me a bit when I share a link to a blog post that they don't look good there.

Today I begrudgingly added the Facebook Open Graph tags to my post permalinks so that my posts look better when shared.

I say begrudgingly because my posts are already machine-parsable thanks to the Microformats on the page. For example, here's the parsed version of a recent blog post in Microformats JSON format, as well as in the cleaned-up JF2 JSON format. It's certainly possible to use that data to generate a rich link preview, but in the mean time, Twitter and Facebook have their own formats using HTML meta tags.

In order to generate the tags for my site, I didn't need to add any additional properties to my storage. Generating the tags is straightforward for articles, I use the article name, featured image if set, and generating the summary involves taking the first few sentences of the first paragraph unless there is an explicit summary set.

For other kinds of posts it was a little trickier determining what to use. I had to write a little bit of logic to pull the first few words of note posts to use as the OGP title. Some of my posts don't have a "photo" property but instead have a map image, so I had to pull that value out explicitly.

Lastly, Twitter has their own set of tags, but will also use the Facebook tags if those are present. The only tag I needed to set on Twitter was telling it which style of card to use, either the large image style or standard. If my post has a featured image, then it will use the large image style, otherwise uses the small one.

Thankfully, Slack will also use the Facebook tags, so my posts will also look better when shared into Slack now too.

Curious what I was up to in 2017? So am I! Thankfully I developed a pretty regular habit of writing short blog posts any time I finished something, so I have a nice collection of posts to draw from for this year-in-review post!

Aside from all the IndieWeb work, I also managed to finish a few unrelated projects!

OAuth 2.0 Simplified Book

In August, I released my book, OAuth 2.0 Simplified at Okta's conference in Las Vegas. It is now available in print, as an ePub, for Kindle, and PDF.

BarBot

In February, I put the finishing touches on BarBot, my robot that pours drinks for me. It can also import h-recipes to make it easy to add new drinks to the database. I've been using it all year, and it's fantastic.

100 Days of Music

While I was doing the #100daysofindieweb project, I was also writing a song every day. These are all published on 100.aaronparecki.com, which was my last #100daysofindieweb project. Since this project wrapped up in March, it's been fun to be able to use these songs in other projects, as well as having other people use them in their own projects!

• My Percolator microcast
• KmikeyM's Fortnightly Business Report
• Marty McGuire's This Week in the IndieWeb podcast
• Adam Procter's Fragmentum microcast
• Lily's Oh My Dollar podcast and radio show

Wifi Desk Bell

For the week leading up to the end of Lily's Kickstarter, I made a desk bell that would ring every time someone pledged.

Events

I helped run a few events this year:

• May 13-14 IndieWebCamp Düsseldorf 📷
• May 20-21 IndieWebCamp Nürnberg 📷
  • We had a great two IndieWebCamps in Germany in May!
• Jun 24-25 IndieWeb Summit in Portland 📷
  • IndieWeb Summit was a lot of fun this year.
• Jul 8 Lily's #Spy30 Birthday Scavenger Hunt 📷
  • Lily organized a city-wide spy-themed scavenger hunt for her birthday! I wrote an app we used to have everyone submit their challenges and handle scoring, as well as ran a live GPS shuttle tracker for the karaoke bus, built a fake radio station that played a coded message.
• Aug 15 #biketheeclipse
  • I led a small group on a day trip bike ride to reach the totality of the eclipse!
• Dec 9-10 IndieWebCamp Austin
  • I was lucky enough to be able to make it out to the first IndieWebCamp in Austin.
• Homebrew Website Club
  • DreamHost was kind enough to host our 2017 Homebrew Website Club meetups!
• I've continued to film the talks at DonutJS monthly.

Talks

My Eight Year Old Bot

In January, I gave a talk at Google about my IRC Bot, Loqi. It was a slightly updated version of the talk I gave at the XOXO Bots meetup in 2016.

Owning My Quantified Self Data

At the Quantified Self conference in Amsterdam, I gave a talk about how I keep all my quantified self data on my own website in a place I control.

• More info and slides
• Posts from June 17

Publishing Your Podcast

As part of our new class lineup for StreamPDX, I ran a workshop about how to take your podcast from the final audio file and publish it online. We're running a Podcasting 101 series again in 2018, and I'll be teaching this workshop three more times!

OAuth 2.0 Simplified

In December I gave a talk about OAuth at the Portland Linux/Unix Group.

• More info and slides

My Website

As part of my 100 Days of IndieWeb challenge, which ran from Dec 2016 through March 2017, I made a lot of progress on my website and other various IndieWeb tools! Here are some of the highlights of things I improved on my own website.

• Posting to my website from Alexa
• Improved comment display
• Showing full repost content, and automatically fetching reposted content
• Displaying reply contexts, and automatically fetching reply context
• Audio posts so that I can publish podcast episodes
• Recipe support
• Redirects for old blog posts
• Include featured photo when syndicating articles
• Creating sleep posts from FitBit import
• Media Fragment URIs
• Indexing my emoji use, and autolinking emoji in posts
• Live chat widget
• Replaced my SSL certificates
• Finally got checkins on my site!
• Indicating the audience of posts
• #now page
• Pulsing blue dot
• Stories
• Payment requests using ApplePay
• Showing full contents of likes
• Automatically POSSEing likes and reposts
• Adding weather info to posts

IndieWeb Specs

As part of my work in the W3C Social Web Working Group, I was involved in writing a few specs as well as tools to help people test their implementations.

Webmention

In January, Webmention reached the final stage of the standards process at the W3C and became a W3C Recommendation!

I continued to improve the test suite, adding some tricky edge cases for discovery and redirects.

I also did a big reorganization of the Webmention page on the IndieWeb wiki.

Micropub

Micropub reached Recommendation in May, after the Proposed Recommendation in April. I wrote some about the history of the spec and the standards process.

I did a lot of work on the test suite, micropub.rocks, over the few months leading up to Recommendation. Since Micropub requires authentication, I had to build an OAuth server into the test suite so that you can sign in to other Micropub clients. I wrote several client tests, including filling out the implementation report automatically, tests for video and audio posts, and tests for updating posts.

WebSub

WebSub was a recent addition to the working group. Formerly known as PubSubHubbub, the group adopted the spec in order to continue refining it, and we decided to give it a new name as well.

We published the Candidate Recommendation in April, and continued iterating on it over the summer, publishing the Proposed Recommendation in October.

I finished the test suite, websub.rocks in May.

IndieAuth

I finally managed to write up IndieAuth as a spec! Previously it was a series of tutorials on the wiki. I launched the first version of the spec on December 5th, and have been making minor changes since then based on community feedback.

Microsub

Early in the year, I drafted a spec intended to allow quicker development of reader applications by offloading feed fetching and parsing to a separate server. I called this spec Microsub. A few months later, I started prototyping out a server, which I've soft-launched as the reincarnation of Monocle. The spec has continued to iterate as I develop my Monocle server and Grant works on the front-end application, Together.

IndieWeb Projects

Again, thanks to my 100 Days of IndieWeb challenge, I made a lot of progress on a bunch of different IndieWeb projects. Here are some of the highlights, grouped by project.

OwnYourSwarm

I launched OwnYourSwarm in March, including sending person-tags, sending Webmentions for Swarm coins, backfeeding comments and likes, and some documentation. It will even poll your past checkins for photos, and you can also import past checkins. Later in the year, I added a property to indicate when another user checks you in, checked in by.

OwnYourGram

OwnYourGram has been around for a few years, but I made some improvements to it in 2017. You can now whitelist and blacklist terms to control what photos are imported. OwnYourSwarm now sends full h-cards for locations, and finally supports multi-photos.

Quill

I added some new features to Quill, such as the ability to set tags, slug and post status and published date for posts, a better photo upload UI, supporting posting RSVPs, showing the reply context of the thing you're replying to, and cleaned up the HTML that the visual editor creates. I also improved the docs, made some other UI improvements, fixed a JS vulnerability.

XRay

My work on XRay has continued to be useful in many different other projects. XRay parses contents from other websites and returns the data it finds in a normalized format. I added support for parsing Instagram photos, as well as tweets. I also added support for two new Microformats vocabularies, h-review and h-recipe. I made it easier for others to deploy XRay in various hosting environments. I had to jump through some hoops in order to deploy a Letsencrypt certificate on AppEngine where I run XRay.

Miscellaneous IndieWeb Projects

I published my GPS tracking app in the App Store! I also wrote some documentation for it.

I made a few updates to IndieNews, our community news aggregator. Some small improvements to displaying text in posts, enabling WebSub for IndieNews feeds, added a Webmention form, added support for different timezones per post, and added a calendar view of all stories submitted.

The Slack/IRC gateway now works across all our channels, and Slack emoji are converted to unicode in IRC. The gateway now also supports image uploads from Slack.

Atlas maps can now have curved lines.

I published a few new libraries used in various projects:

• Timezone lookup for a location
• Emoji detection

I had to make some changes to indieauth.com since Clef shut down. I also used that opportunity to remove SMS logins as it is not the most secure. I also updated the documentation.

The "This Week in the IndieWeb" newsletter now also includes podcasts.

I submitted a PR to Known to improve its Micropub handling.

I added a dashboard to webmention.io so that you can see at a glance the last few Webmentions you've received, as well as delete them if you want.

I started publishing a podcast about my IndieWeb work, called Percolator. I managed to publish 16 episodes from October to December, without much regularity. I hope to continue this in 2018.

I finished a major effort to finally update our MediaWiki to a modern version. Part of this work was also replacing the way authentication is handled, so that it can be used across our other subdomains. This also included archiving plaintext backups of our wiki as well as chat logs in Git repos.

One of the last things I did was create a set of tiny IndieWeb badges you can use on your site! I added them to the footer of my website as well. There are badges for IndieWebCamp, Webmention and Microformats.

Looking Forward to 2018

Overall I had a pretty full 2017! It felt both busy at times and slow at other times.

I'm already looking forward to IndieWebCamp Baltimore later this month, and I'll begin planning IndieWeb Summit 2018 soon!

Some of my concrete goals for 2018:

• Finally settle the indieauth.com naming confusion issue this year
• Run IndieWeb Summit in Portland
• Continue development of my IndieWeb reader, Monocle, as well as the Microsub spec
• Launch and run the StreamPDX Podcast Fellowship
• Continue filming the monthly DonutJS meetups, and expand to cover more meetups as well

Transportation

Overall, I traveled a little less in 2017 compared to 2016. My biking was down (I no longer commute downtown every day), but train travel was up, since I now live next to a MAX stop. I biked a total of 1,149 miles in 2017, down from 1,529 in 2016. I flew 44,796 miles in 2017, down from 55,271 in 2016. I spent only a little more time in cars this year, my least-used mode of transport other than walking. Car trips include me driving a car2go (very rarely), getting a ride in someone else's car, as well as taxis and Lyft rides. Sadly my bike mileage was just shy of 2x my car mileage, so perhaps I should make it my 2018 goal to double my car mileage on bikes.

While my plane trips dominate in mileage, the time spent in each mode tells a very different story. 

I spent more time on my bicycle than any other mode of transport! 126 hours on bikes, and the next highest mode is 101 hours on planes. 

Beverages

My beverage consumption was split almost 50/50 between alcoholic and caffeinated beverages, with very little of anything else. (I don't track my plain water consumption because I drink way too much water to track it easily.) Out of 1,794 beverages consumed, only 5.7% were non-caffeinated and non-alcoholic. 

My top drinks of 2017 were: Americano (coffee), Beer, Coffee, and the Boulevardier cocktail.

Overall, I tracked 16 different types of coffee, and 24 named cocktails. I lump specialty cocktails together and track them just as "Cocktail" otherwise it would take too long to enter all the data.

My cocktail of choice this year was apparently the Boulevardier, followed by the Negroni. I will also note that the Vieux Carré is way up there, which is notable because that is one that I don't make at home, I only have it at Imperial in Downtown Portland. It's $5 during happy hour so it's hard to pass up!

How I Collect This Data

All this data is collected by my own tools and stored in my website. You can see the individual entries for each bike ride, walk, and other transport, as well as everything I eat and drink.

For tracking food, I use a web app, Teacup, which I bookmark to my phone's home screen. The interface prompts me with the most often used food and drink, and I can also type in new values if I need to.

For my trip tracking, I use my GPS tracking app, Overland, which I recently published to the iOS App Store! It's a pretty barebones app, but it works well. 

It tracks my location all the time, which is used to geotag all my posts, as well as provide the weather information for the posts. It also lets me choose a mode of transport and start tracking a trip. Overland first sends the data to my Compass database, which then sends trips to my server which adds a map image and stores it on disk. Later I can query the server to find all the trip and the time/distance for each.

I'm super happy to be able to add myself to the list of people who publish weather info in their posts!

I've had a long-standing goal to include weather info on all of my posts on my site! In fact, I actually started collecting historical weather info just so that I could backfill the data on my site once I added the feature. The weather database I've been collecting goes back to 2012! I decided it's been long enough and bit the bullet and sat down to finally knock it out.

I've had the current weather up in my website header since 2016, and it turns out that I was able to reuse a lot of that existing code.

Today I finally added support for storing weather info per post, and adding it when new posts are created. The weather is based on my current location, which I've already been automatically including in my posts for a long time. So now, when a new post is created, if the cached weather info that is shown in the header is recent enough, it bakes it into the post's storage file.

Now my posts will all have little weather icons and the current temperature!

I decided on using an icon font for the weather icons so that they are all visually consistent and inline with the text. The icon set I'm using is http://erikflowers.github.io/weather-icons/ The weather info itself comes from Wunderground, although I may switch to Dark Sky in the future since they have a higher per-day API limit.

I also decided to put the weather info on the same line as the location name, since I feel like this information very closely linked to the location. (It's also stored in the location property internally.) 

I'm pretty excited to finally have this done, just in time for all my posts in 2018 to be weather-tagged! 

I'm postponing the work of backfilling all my past posts since that is going to take quite a bit of effort. I'll add it to the ever-growing list of old data to import to my site! 😂

Remember the old 80x15 badges we used to put on our websites? I just updated our IndieWebCamp badge with the new logo! You can use this on your own site by copying the HTML below! Feel free to download the image and host it yourself too.

<a href="https://indieweb.org/">
  <img src="https://indieweb.org/img/indieweb-badge.png" width="80" height="15" alt="IndieWebCamp" style="image-rendering:pixelated;">
</a>

Why not add a Webmention badge once you add webmentions to your site!

Maybe you're also looking for a Microformats badge? I made one of those as well!

Need some more badges for your site? There's a good collection of W3C badges over here.

How about some Creative Commons badges?

Remember to add style="image-rendering:pixelated;" to the img tag so that when the badge is viewed on high-resolution displays, it will retain the pixelated look instead of make it blurry when it scales up!

My #newwwyear goal this year was to make my likes and reposts automatically POSSE to Twitter when I favorite a Tweet URL.

Previously, Quill handled doing that for me when I use its browser bookmarklet. If you connect your Twitter account with Quill, then if you favorite a tweet URL, it will go and favorite the tweet on Twitter for you. This works great if you only ever use Quill to favorite stuff. Now that I've been using Eddie's Indigenous iOS app, I had lost the ability to actually favorite stuff on Twitter if I posted it to my site.

My goal was to make my Micropub endpoint understand how to POSSE likes to Twitter so that no matter which client I used to favorite things, I'll end up favoriting the twitter copy too.

Thanks to silo.pub taking care of dealing with the Twitter API, it didn't end up being that much work to actually make this happen. So now, when my Micropub endpoint receives a request to create a like-of where the URL is a tweet URL, it tells silo.pub to also syndicate that post to Twitter.

So now when I encounter a tweet on iOS, I can use the "share" button to favorite it on my site which then also favorites it on Twitter!

So I was pretty excited about that, but then quickly realized I needed to go an extra step with it! Stretch goal! What happens when I favorite someone's indie post? It's great that it favorites it directly, but if they've also syndicated their post to Twitter, I should also syndicate my like to Twitter! Thankfully this was also not a huge amount of work, thanks to a lot of infrastructure already in place in my site.

When I create a like, my site already expands the contents of the liked post and stores it internally, as well as rendering the content I favorited. I like the way this ends up looking since it makes my favorites page look more like the equivalent page on Twitter.

Since my site is already pulling in the content of the post I like, that already includes any syndication URLs reported by that post. That means I already know the syndicated tweet URL that I need to favorite on Twitter!

Adding support for this was a matter of finding the Twitter syndication URL of the post I've favorited, and then telling silo.pub to favorite that on Twitter as well.

Swarm has had a feature for a long time where you can allow your friends to check you in. It's more than just tagging a friend in a checkin, since it actually creates a full-fledged checkin on the other person's account. It's an interesting feature of Swarm, and not something I've seen elsewhere.

Today I shipped an update to OwnYourSwarm which will include that information in the Micropub request it sends to your site.

Here's a checkin from last night that was created when anomalily checked me in.

Here's what it looks like on my site now.

To accomplish this, I added a new property in the Micropub JSON that OwnYourSwarm sends. The property is checked-in-by and the value is an h-card of the person who checked you in. There was some discussion about whether this should be shown with the person who checked you in as the author, but I argued against that since on Swarm the checkin appears in your own checkin history and is otherwise identical to a checkin you created yourself.

  "checked-in-by": [
    {
      "type": [
        "h-card"
      ],
      "properties": {
        "url": [
          "http://anomalily.net/",
          "https://foursquare.com/user/894076"
        ],
        "name": [
          "anomalily"
        ],
        "photo": [
          "https://igx.4sqi.net/img/user/300x300/894076-UEP315CWOZJNKG2J.jpg"
        ]
      },
      "value": "http://anomalily.net/"
    }
  ]

If you are using OwnYourSwarm's JSON format, you'll start receiving this additional property right away! If you've followed the Micropub spec and are already storing unrecognized properties in your storage, then you can later add support for rendering this property like I did!

Happy Swarming!

At IndieWebCamp Austin, I was inspired by the discussion at the Payments session. In the session, we talked about the recent Patreon fee change disaster, and how creators could use their own websites to accept payments from their supporters.

The W3C recently published a Candidate Recommendation for the new Payment Request API, which has pretty good browser support already! It turns out that Stripe has already built support for it into their library as well!

I was on the fence about trying to implement the API directly, or just using Stripe's library, and decided to take the easy route in the end. It does mean the code I wrote is mostly tied to Stripe, but they handle a bunch of edge cases and UI elements for me so it was a lot faster to implement that way.

Despite it being pretty much a drop-in replacement for their old Checkout workflow, there were a surprising number of edge cases I had to handle on my own still. For example, their button only gets activated if there is already a saved credit card in the browser, so if there aren't any existing payment methods, you have to still present a credit card UI to the user. Also you obviously need to have a fallback workflow if there is no support for the Payment Request API in the browser.

I started off by reading through the Payment Request API spec, and quickly discovered it was written from the perspective of a browser implementing it on their end, not written for developers using the API. I don't recommend reading it if you're trying to learn about this. I then discovered Google's excellent documentation on how to actually use the spec, Introduction to the Payment Request API. That one is a much better read to understand what's going on. Mozilla also has some good documentation on the API, although it's written more as a reference rather than a tutorial. In the end, I ended up just reading Stripe's documentation since I decided to use their library.

While implementing this, I decided to simplify my payment page to reduce the number of different states I had to manage. Previously, I allowed a visitor to type in their own amount. This ended up proving challenging to get to work right with Stripe's two libraries (Payment Request library and their Checkout workflow for fallback support). So instead I dropped that UI element completely. Below is what my payment page looks like if you visit it directly.

With no amount pre-filled, the payment page does not provide a credit card option. Instead, it just links out to other services you can use to send me money. Those services will prompt you for an amount later.

I added support to my URL structure for adding a number to the end of the URL. So if you visit a URL like aaronparecki.com/pay/5, the idea is to present you with an easy way to send me $5.

In browsers that support the Payment Request API such as Chrome, and if there is already credit card info saved in the browser, I render the Stripe Payment Request button with the set amount, which looks like the below.

Clicking the "Pay now" button launches the browser's native Payment Request UI with the "order details" and allows the visitor to choose a credit card. (You might notice that the amount in the prompt is slightly more than $5, which is calculated by my code to result in me getting $5 after I pay the transaction fees. My assumption here is that you are trying to actually give me $5, not pay $5 for some service I provide.)

Unfortunately, Stripe doesn't provide a way to bootstrap this if you don't already have a credit card saved in the browser. They will hide the button completely if there are no payment methods available. In that case, I fall back to the old Checkout workflow. If you visit my pay page in Chrome to try to test this, and don't yet have a card added, you can add a card in the autofill settings in Chrome.

Next, we see what happens if you visit this page in a browser that does not support the Payment Request API (or if there are no saved cards). In this example I used Firefox, although you can actually enable the experimental API in about:config. In this case, my code detects that the API is not present, and enables the Stripe Checkout workflow instead.

Clicking "Pay With Card" launches the Stripe UI for their Checkout workflow, which is a modal dialog. The only thing I can customize here is the title and photo.

Stripe now encourages you to use their "Stripe Elements" which includes a credit card widget, although when I attempted to go down that path, I realized that I was going to have to do a lot more work on the CSS and JS interactions for that, whereas their Checkout workflow handles everything for me.

Here's the cool part about the Stripe Payment Request button. They have built-in support for feature-detecting Apple Pay and they turn the button into an Apple Pay button automatically! So in my code, I detect for either Payment Request API support or Apple Pay support and use the Stripe Payment Request flow in both cases.

if(window.PaymentRequest || window.ApplePaySession) { ... }

It was surprisingly easy to enable Apple Pay support! The only thing I had to do beyond supporting the Payment Request API through their widget, was verify my domain. This is actually a requirement of Apple's systems, but Stripe has done an excellent job of smoothing over the hard parts of that. They provide a "domain association file" that you download to your server, and then they provide a button you can press that will trigger Apple to verify that file on your server. Once you do that, you can start accepting Apple Pay immediately, on both desktop Safari and iOS.

On iOS Safari, the Apple Pay workflow works just like you'd expect to see it in any app! Tapping the "Pay" button launches the native UI to choose a credit card and verify your fingerprint.

Once you confirm your fingerprint, it charges your card and you'll see the push notification confirmation almost immediately!

And yes, as I was taking a screenshot of this, it registered my thumbprint and actually charged my card. Good thing Stripe makes it easy to refund transactions!

So hopefully that gives you an idea of what it takes to add support for Apple Pay and credit cards to your site! It was surprisingly straightforward thanks to Stripe's library, although wouldn't have been too bad doing it manually with the Payment Request API either.

It's been a long time coming, but I've finally published a proper IndieAuth spec!

IndieAuth has been around for years, and is even referenced by the Micropub spec. But until now, there wasn't a canonical version of the spec all in one place. Previously it existed as a series of how-to guides on the IndieWeb wiki. Arguably it's actually more useful that way, since the whole point of specs is to communicate a consistent way of implementing something. But it did make it awkward to refer to it formally.

So I'm happy to say that there is finally a spec for IndieAuth, at https://indieauth.net/spec/

This document captures the current state of what has been implemented, and incorporates much of the feedback we've gathered over the years. Most of the document is split up into authentication and authorization sections, for when you are trying to just identify users for sign-in in vs when a Micropub client is trying to get an access token to post to the user's site. Formally it's an extension to OAuth 2.0, and makes several decisions that were left un-specified in the OAuth 2.0 core spec.

If you've implemented any part of this spec, or are thinking about it, I'd appreciate any feedback! Feel free to comment on this post, file an issue on GitHub, or drop a note in the IndieWeb chat!