Aaron Parecki

The listing for my house in Eugene just went live! If you know anyone looking for a house in a great location, feel free to send them this listing!

http://www.barbarawest.com/listing/OR/Eugene/1910-Charnelton-St-97405/58441596

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 am on the fence about whether to count today's sprint towards this goal. I started this morning by diving into catching up on accounting in my 3 Quickbooks files, which is something I've been trying to get better about doing regularly since I finally filed my taxes on time for the first time in 6 years. I spent a little over 2.5 hours on the accounting, and managed to get all caught up. (Of course I didn't screenshot that for obvious reasons.) So on that front, it was a successful morning. However, it was also over 80 degrees today which is way hotter than my comfort level and we don't have A/C in the apartment. This led to a relatively unproductive afternoon, and I never got enough energy up to do anything more creative. So on that front, I didn't make progress on my more interesting projects today. Overall, at least I have another data point to reaffirm that I am definitely more productive in the mornings!

At the end of March, I finished my #100DaysOfIndieWeb and #100DaysOfMusic projects. It was a lot of fun to focus on those during the winter months, but I'm also glad to free up my days now that they are done. It turns out 100 days is a lot of days, and I don't think I'll do such a hard #100days project again. However I did enjoy the focus I was able to achieve, and enjoyed knowing every day what I needed to work on. So for the month of May, I'm starting a new, slightly different experiment.

Along with @anomalily and @beeminder, I'm dedicating May to "Maniac Mornings". We've done some "Maniac Weekends" in the past, which is essentially a 2-day sprint trying to cram in as much focused time as possible, and is a shorter version of "Maniac Week" which is like locking yourself in the basement for a whole week with no outside distractions. With my upcoming travel to IndieWebCamp Düsseldorf and Nürnberg, and with the goal of not feeling completely overwhelmed or burnt out at the end, "Maniac Mornings" is an attempt to scale back the idea to a sustainable level.

For the month of May, the goal is to spend 2+ hours every morning on focused and high-impact work, with no distractions. High-impact work is things that have a direct impact on my goals, which at the moment are getting the WebSub spec through the W3C process, updating and printing my OAuth 2.0 book, and a new as-yet-unnamed secret project.

Part of the "Maniac" aspect is that I will also be recording a timelapse of my computer screen including a picture from my webcam!

I'll try to post these every day, and I'll also stitch them together at the end of the month into one long video!

The large clock on the screen is a small Electron app that embeds a tiny bit of Javascript and CSS to render the clock. It also sets a background timer that runs the OSX "screenshot" command every 30 seconds, and saves the images to a folder. You can download "Maniac Clock" here!

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.

I wanted a way to quickly browse and share songs from my 100 Days of Music, so I thought I would make a page with links to each song. Clicking on any of the tracks opens up a video player with the description of the song.

I am curious to find out which songs people like the best, so to start with, I added some Google Analytics code to the page. I track events for each time a video is started, paused, when the video finishes playing completely, and if a video was interrupted by starting another. Hopefully this will provide some interesting data over time.

I want to add a more robust feedback mechanism, possibly even a simple "heart" button people can click, but I'm not sure how I want to handle that yet so that will have to wait until later.

I've made download links available for each track, in case you want to use these songs in your own projects! At the bottom of the page you'll see the copyright notice. I've decided to make these all available via a Creative Commons Attribution license, so feel free to use them for various projects! All I ask is that you let me know when you've used a song, preferably by writing a post about it and linking to the track on my website! That way it will show up as a comment on my post, like Marty's podcasts!

The URL of the website is:

100.aaronparecki.com

and because emoji are fun, I made an emoji subdomain redirect to it as well, for no practical purpose:

💯🎶.aaronpk.com

The Micropub implementation report summaries had gotten kind of scattered around various URLs, so today I cleaned it up and consolidated everything. I also added the number of submitted reports to the home page, along with links, so that they are much easier to find.

I am making the report summaries all live under micropub.rocks, rather than be split between micropub.rocks and micropub.net. I updated the URL structure for the summaries on micropub.rocks to be more consistent:

• https://micropub.rocks/implementation-reports/servers/
• https://micropub.rocks/implementation-reports/clients/

The corresponding URLs on micropub.net now redirect to micropub.rocks. I also added a header bar on the spreadsheet views so that you can navigate back to the home page as well as to the other set of reports while viewing the spreadsheet.

Hopefully this makes things a little easier to find!