Aaron Parecki

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!

This post is part of the IndieWeb Challenge to ship something every day of December!

Today I worked on the long-standing project to upgrade our wiki to a recent MediaWiki version. 

Wiki Upgrade

I started by taking a snapshot of the database and restoring it to my laptop, then installed the latest MediaWiki version there. After running through the MediaWiki upgrade scripts, I had to test each extension we use, and either update it or drop it. I documented this progress on the upgrade page, and trimmed down the extension list to just the ones we absolutely need. I published these in a new repository so they're now tracked in version control: https://github.com/indieweb/mediawiki-extensions

New Wiki Login

One of the major sticking points of the upgrade was needing to redo the IndieAuth extension, since there have been some major changes to the internal auth mechanism of MediaWiki over the years. I was not looking forward to writing that code again, so I went with a completely different approach this time. Instead of writing any MediaWiki code, I installed the (well-maintained) Auth remoteuser extension, which just expects an environment variable to be set with the user that's logged in. Typically this is used with HTTP Basic Auth, but any mechanism that sets the environment variable will work.

I paired this with an nginx module Lasso designed to work with any OAuth or IndieAuth-compatible API. I pointed the proxy at indieauth.com so the actual authentication logic is delegated there. I got the whole thing running on my laptop after a bit of fiddling. It's pretty slick. The wiki login/logout links are replaced by redirects to the proxy, which seamlessly redirect you to indieauth.com. Overall this should not be a hugely different experience to the end user. Below is a screen recording of the flow. (Ignore the 404 not found page at the end, that's a glitch in my local environment.)

What you don't see happening is that clicking on the log in link actually takes you to sso.indieweb.org, which redirects to indieauth.com, which then redirects back to sso.indieweb.org and then back to the wiki. It happens all very quickly!

This also means that the cookie is set on *.indieweb.org, so it will be available to every other subdomain, so I can eventually make the chat logs know who you are when you're logged in to the wiki! This will become even more important once I set up Calagator for our events.

You can try out this flow right now, since I launched it on the server. Right now only a test domain is using it, events.indieweb.org. It just has a simple log in/log out link, but it's enough to demonstrate the functionality!

Wiki Backups

Since I'm about to do something drastic -- update MediaWiki -- it is always a good idea to have backups! For a while I've had a text dump of the wiki available via rsync (details here), but I wanted something that felt a little more robust as well. Today I set up that workflow to also commit all the changes to a git repo and push to GitHub! Since it's git, it means it will retain all versions of edits rather than clobbering the pages and even potentially deleting pages.

If you're interested in helping keep a backup copy of the wiki, you can set up an automatic process to clone this repo! github.com/indieweb/wiki I'm hoping that by having it available on GitHub, it's easier for more people to help back it up. An added bonus is you'll have an offline-copy of the wiki you can browse locally! (Just make sure you clone it to a case-sensitive filesystem!)

Tantek had an idea for a community challenge to ship some sort of IndieWeb feature every day of December. Anyone can contribute, just make sure you blog about it!

On December 1st, I launched some major changes to the IndieWeb chat site!

I finally migrated the chat logs from a MySQL database to flat files. Now I can finally get rid of the database that was growing difficult to deal with. As plain text, the logs are only about 500mb, which isn't too bad. But since they're just a folder of text files, it's super easy to back them up! In fact, if you want to keep a copy of the logs, you can download them from GitHub!

https://github.com/indieweb/indieweb-chat-archive

The server commits the chat logs to that repository every 15 minutes!

As part of this migration project, I also knocked out all but one of the open issues on the chat interface! You can now join the chat from the new interface at chat.indieweb.org, which also means you can chat in all the channels from the web! I also fixed some timezone bugs and other minor issues.

After far too long, I finally launched support for importing multi-photos from Instagram via OwnYourGram!

I had to make a couple tough calls, which I'm not entirely happy about, but I think it's an acceptable compromise for now. The main limitation of the way it currently works is that Instagram posts that mix photos and videos in the same post will import the videos as just their poster frame. Additionally, you can tag people in the individual images on Instagram, but when that's converted to a Micropub request and sent to your site, the person tags are combined into one list associated with the main post.

The reason for doing it this way is there were already several websites and Micropub implementations that support the "multi-photo" concept, but very few that support "collections." The difference is a multi-photo is a single h-entry that has multiple photo URLs, whereas a collection is an h-entry that contains multiple h-entrys inside of it. The collection concept allows a much richer representation of things, since you can have a collection containing photos, videos, or anything really, and each h-entry within the collection can have its own tags, person-tags, etc. There are some more notes on the advantages and limitations of each on the IndieWeb wiki.

But right now, there are very few implementations of collections at all, and as far as I know, nobody's Micropub endpoint supports creating collections anyway. In contrast, there are several examples of multi-photos along with support in Micropub endpoints, including recent support for it in micro.blog. So that's a compelling argument for making OwnYourGram support the simple case first, and eventually I'll see about adding support for full collections later.

Since not everyone's site supports multi-photos, I decided that for all existing OwnYourGram users, I would maintain the existing behavior where it only posts the first photo to your site. This way I avoid surprising people with a new kind of Micropub request. If you're an existing user and want to accept multi-photos, then you just need to be prepared for the "photo" property to be an array, and you can enable multi-photo support in the settings. New users will have this enabled by default.

I talked about this upcoming change on episode 1 of my new microcast "Percolator," so please subscribe if you're interested in following along with other developments I'm thinking about!

Looking forward to seeing some multi-photos on all your websites!

I'm excited to announce that Micropub is now a W3C Recommendation! It's been a long road, but we made it! This is the final stage in the W3C spec lifecycle, and means that the spec has gone through several stages of review, and all parts of the spec have been implemented by at least two people.

Incubation and Selfdogfooding

Micropub began in 2013 when I outlined a simple API to create blog posts and short notes for my website, and published it on the IndieWeb wiki. I implemented it on my server as well as in a few new client applications, and was quickly using it day-to-day. The main design goal with Micropub is that it should be easy to implement, and it should build on top of existing standards: OAuth 2.0 and the Microformats 2 vocabulary.

Micropub is also intended to be implemented incrementally. Rather than having to read, understand, and implement the whole spec, you can start by implementing the basics of just creating simple text posts. You can later expand your implementation to support more complex objects, as well as editing and deleting posts.

Implementations and Interoperability

One of the benefits of supporting Micropub on your server is that it allows you to leverage other peoples' work in building an interface to create posts on your own website. By 2014, there were already six independent server implementations, and four client implementations other than my own.

Over the next years, more and more people built out Micropub support in their blogging systems, including plugins for WordPress, Known, Kirby and more. Many client implementations have popped up as well, for a variety of platforms including the Micro.blog iOS application, a Ruby web app, an XMPP chat bot, and more. I also wrote a Micropub proxy service OwnYourGram which imports your Instagram photos to your website, and another called OwnYourSwarm that does the same for Foursquare checkins.

Micropub at the W3C

In 2015, the Social Web Working Group decided to adopt the Micropub spec to fulfill the client-to-server API aspect of our charter. 

After taking the initial spec from the IndieWeb wiki and writing it up in W3C format, I brought it to the working group as an Editor's Draft. After working on it within the group for a few months, we resolved to publish it as a Working Draft in January 2016. 

W3C Spec Lifecycle

Publishing a Working Draft is typically the first time the spec will be noticed by other groups within the W3C, as it's the first time a working group signals that a spec is intending to reach Recommendation status. Micropub went through 5 revisions of Working Drafts from January to July 2016, gathering feedback from implementers and incorporating it into the spec. The changes ranged from editorial clarifications, to changes that affect the implementations such as names of properties or response formats. You can see all of the changes in the Micropub working drafts here.

At the point the working group is satisfied that the spec is in good shape, the group can request that the spec be promoted to a Candidate Recommendation. To do so, the group must demonstrate that the spec has received "wide review" from people outside of the working group. We used GitHub Issues to get and track feedback, to make it easy to show the feedback received and how any feedback was incorporated into the spec. Publishing a Candidate Recommendation requires the approval of the W3C director.

Test Suite and Implementation Reports

The spec then stays in the Candidate Recommendation stage for a minimum of four weeks. This time is used to gather feedback from other W3C member companies, as well as gathering implementation reports from anyone interested in the spec. Implementation reports are meant to collect information on which parts of the spec are being implemented, in order to get a sense of how mature the spec is and how well it's written. While the implementation report may look like a checklist you have to complete, it's totally fine to submit it with only a few boxes checked. It's more of an evaluation of the spec than an evaluation of your implementation.

In the W3C Social Web Working Group, we set an intentionally high bar for our specs to graduate out of Candidate Recommendation. In order to be promoted from Candidate Recommendation to Proposed Recommendation, our group decided that each feature of the spec must be implemented by at least two independent implementations. This helps ensure that the spec really does encourage interop between implementations.

I created a test suite, micropub.rocks, that you can use to test your client and server implementations. The test suite helps you fill out the implementation report, and also is a great tool for debugging your application as you're building it out.

If you're building a server, micropub.rocks will pretend to be a client and will send you requests that hit all the edge cases of the spec. If you're building a client, you can use micropub.rocks as a server to test how well your client can create and edit posts.

Proposed Recommendation

At the point the working group has determined that all features of the spec have been implemented, and that the spec has been reviewed by people outside the working group, the group can decide to request that the spec be promoted to Proposed Recommendation. The spec can't have any substantive changes between Candidate Recommendation and Proposed Recommendation, but things like typo fixes are okay. The W3C director must approve the request to transition to Proposed Recommendation. The Proposed Recommendation step is one last chance to broadcast widely that the W3C believes the spec is ready to publish as a Recommendation, and gives the W3C Advisory Committee an opportunity to formally object to any aspect of the spec.

Micropub reached Proposed Recommendation status in April 2017.

Recommendation

The final step is to publish the spec as a W3C Recommendation. In order to be promoted from Proposed Recommendation to Recommendation, the W3C Advisory Committee and the Director must approve the request. Once a Recommendation, the spec is finished, and can only be changed by submitting Errata.

Getting Started

In addition to the test suite, there are already many clients and servers you can try out yourself! We've been documenting Micropub clients and servers on the IndieWeb wiki, so have a look around!

If you're building a blogging platform, you can allow your users choose from a wide variety of posting clients by implementing the Micropub spec.

If you're building a posting client and want it to work with many different server backends instead of hard-coding it to Twitter or other proprietary APIs, implement the Micropub spec and you'll quickly have people eager to start using the app!

I hope this post has been a useful overview of what I've been working on for the past several years, and gives you a bit of a sense of what it's like to work on specs at the W3C!

I just added my favorite new relatively unimportant feature to my website!

I added my Swarm checkins to my website a few weeks ago, which has been super fun. One thing I always thought was missing from Swarm was knowing whether a friend was still at a venue they checked in to. Since I have checkins on my own website, I can do that now!

So now, when you're viewing a checkin on my site, if I am still at that location, you will see a pulsing blue dot next to the venue name!

This works because my phone always tracks my GPS location and reports it to my website already. My website compares my last location with the last checkin, and if I'm still nearby, will show the dot!

I'm super excited to announce that DreamHost will be hosting our Homebrew Website Club PDX meetups for the rest of 2017! We've got all the dates planned out, so put them on your calendar! 

• April 5th
  
• May 10th
• June 7th
• July 12th
• August 2nd
• September 13th
• October 4th
• November 8th
• December 6th

The meetups are from 5:30-7:30pm at the DreamHost Portland office, at 621 Southwest Morrison St, 14th floor.

You can see all the events on the IndieWeb wiki and on Calagator.

For quite some time, we've been running my IRC/Slack gateway so that our main #indieweb IRC channel is also available in Slack. It's great because it allows people to use the nice mobile-friendly Slack client, while also not locking ourselves into a proprietary platform. The bridge is also used to allow people to join the chat from our web interface.

Prior to the previous IndieWeb Summit (now over 6 months ago!), we only had one IRC channel. At the Summit, we decided to start using more channels to help keep technical discussions separate from general and user-centric discussions. (See https://indieweb.org/discuss for more details). However, the bridge was written with only one IRC channel in mind so it only bridged the main channel. Lately, we've had more people joining the Slack instance and it's started to cause fragmented discussions.

Today I updated the Slack gateway to be able to support multiple IRC/Slack channels!

You can define multiple pairs of channels in the config file, so that the gateway knows which Slack channels correspond with which IRC channels. When a message is received in Slack, a new IRC user joins all the defined rooms and the messages are routed appropriately.

This is live today, and is now bridging the following rooms:

• #indieweb in IRC to #indieweb in Slack
  
• #indieweb-dev in IRC to #dev in Slack
• #indieweb-chat in IRC to #chat in Slack
• #microformats in IRC to #microformats in Slack
• #knownchat in IRC to #known in Slack
• #bridgy in IRC to #bridgy in Slack

We have public logs for all the channels except for #indieweb-chat. We've intentionally always had an un-logged channel available for off-topic chatter. That channel has been called #indiechat. Even though we don't have a paid Slack account so the channel history is limited to 10,000 across all channels, I wasn't comfortable bridging the #indiechat room to Slack since it has traditionally been ephemeral, and sending it to Slack means that visibility would change a little. So instead, I used the under-consideration #indieweb-chat channel to connect with Slack since people weren't using that very much on IRC yet anyway.

Today I closed a long-standing request on XRay to return the HTTP status code from the retrieved page, as well as parsing the <meta http-equiv="Status" content="410 Gone"> tag in the HTML. I also now return the final URL that XRay retrieved the document from, after following any HTTP redirects that were sent.

This means XRay can now be used to know when a previously received Webmention has been deleted, even if the source website is a static HTML file that returns HTTP 200 with a meta-equiv tag indicating the delete.

The XRay response will now include two additional keys:

• url - The effective URL that the document was retrieved from. This will be the final URL after following any redirects.
• code - The HTTP response code returned by the URL.

These have both been documented in the README as well.