Aaron Parecki

Continuing the work on the micropub.rocks client tests, today I worked on the OAuth server so that you can sign in to Micropub clients to post to the test account. Aside from providing the actual sign-in functionality, I also want this to provide helpful error messages and walk you through setting the parameters to build the authorization request.

Micropub.rocks is the test suite and debugging tool for the Micropub spec. Currently it only has tools for testing your Micropub servers. Today I began the process of adding tools for testing your Micropub clients.

For some reason, some of the time I've noticed that my "load more" links load completely the wrong content. These links previously would load the next page inline, and render the new content without a page load. I liked this as a compromise between traditional full pageload paging and infinite scroll. However, I've been seeing it behave strangely the last week or two, sometimes loading duplicate content, or the page scrolling strange after clicking it. 

When someone types an emoji in Slack, it shows up in the API as a text description surrounded by colons. For example, 😻 is :heart_eyes_cat: when it comes through the API. Previously, the gateway would just send the text through to IRC, which doesn't look great for IRC users.

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.

First of all, if you aren't subscribed to the IndieWeb newsletter, you definitely should! (available via email, RSS and h-feed).

After posting this many blog posts with Quill's HTML editor, I've been somewhat annoyed at some of the strange HTML artifacts it creates. Specifically it adds a few helper classes to the HTML for some of the visual editor parts, and some unnecessary classes are added to some of the images. Today I cleaned up the HTML that Quill sends so that it now only sends very plain and simple HTML. To do this, I send the output from the Javascript editor through the HTMLPurifier library, removing all class attributes and allowing only a specific subset of HTML tags.This ends up being only barely visible, but is a good change under the hood. The one visible change this will have for my blog posts is that now they won't sometimes have an extra empty line at the bottom. This was caused by me pressing "enter" after writing the last paragraph, creating an empty placeholder paragraph in the visual editor.

Today I added support to IndieNews for storing and displaying the timezone of submitted posts. Previously, all the dates were stored and displayed as UTC, which can be misleading such as when a post is submitted after 5pm in Pacific time since the post then has the date of the following day in UTC.

I should have known this one would take longer than I expected.My Jawbone UP finally died, so I replaced it with a FitBit. I've really enjoyed the Jawbones, but I'm not confident in the future of the company's wearables department. I decided to take the plunge and dive in to the FitBit ecosystem instead. I got a new FitBit Charge 2, which among other things includes a heart rate monitor which I'm excited about. But step one was rewriting my sleep import script to pull sleep data from FitBit instead of Jawbone.

Following up on yesterday's update of adding a Webmention form on IndieNews' Webmention endpoint, today I finished building out the UI for submitting to IndieNews from a browser.Now the "Submit" link includes a form where you can paste in your post's URL, in case your website doesn't send Webmentions automatically.

I realized today that if you visited the Webmention endpoint for IndieNews in a browser, it showed a 404 page, since the Webmention endpoint was only registered for POST requests. Today I added a page that is served for a GET request.

I've noticed a pattern in the blog posts that I write about these #100DaysOfIndieWeb updates, which is that I almost always include a photo in the article, most of the time embedded in the text. When I syndicate these articles to Twitter, I was previously only including the name of the post and the URL to the post, but I wanted to include the photo as well.Today I updated my syndication code to check for a "featured" photo when syndicating blog posts. It first checks for a "featured" property in the post's storage file. (So far I don't actually have any examples of storing it that way.) It then parses the post's HTML and checks if there is an image with the "u-featured" class. If so, it includes that image in the request to syndicate the post via silo.pub.Now my syndicated articles will include an image!

This was a tricky one, spawned from when sebsel failed to discover the Webmention endpoint for one of Zegnat's posts. In that case, the Webmention endpoint was a relative URL and sebsel was sending a Webmention to a URL that was also an HTTP redirect.The new test, webmention.rocks #23, instructs you to send a Webmention to a URL that is a redirect, and that page advertises a relative URL endpoint. You'll need to make sure that the URL you pass to your relative URL resolver is the final URL after following the redirect, rather than the one you start with.So give it a shot! Test if your relative URL resolution code works properly!

XRay now supports the h-recipe vocabulary!

Today I added the h-review vocabulary to XRay. This means you may now see objects of "type: review" show up when using XRay. 

My blog post from 2012 titled "OAuth 2 Simplified" is my most popular article on my website by an order of magnitude. It is referenced by over 400 repositories on GitHub, and ranks very high in searches about OAuth. I still get tweets over four years later from people who discover it for the first time and are very appreciative of finding a succinct summary of the protocol. I wrote it in 2012, when OAuth 2.0 was still relatively new, and it was based on the best practices at the time. Today I was reviewing the post, and realized that there were quite a few places where the industry standards have changed either in the terminology or in the best practices. I decided that I wanted to publish a new version of the post updated for 2017 based on what has happened in the industry over the last few years. I didn't feel comfortable updating the post at its current URL, from 2012, since that seemed like it would be rewriting history. But at the same time, I don't want to make people landing on that post from a web search or link from a GitHub repository to have to click another time to see the latest version of the post.I decided on an interesting compromise. I took the existing post, rewrote parts of it, and published it at a new URL: https://aaronparecki.com/oauth-2-simplified/I then took the old post, copied it verbatim, and published it at a new URL dated the same date as the old post: https://aaronparecki.com/2012/07/29/7/oauth2-simplifiedThe final step was creating a redirect from the post's old URL https://aaronparecki.com/2012/07/29/2/oauth2-simplified (note the "2" vs the "7") to the new URL that has no date component. (This is the part that required a new bit of code for p3k, in order to handle redirects from posts that would have otherwise matched a post permalink.)My plan going forward is to always keep the version at https://aaronparecki.com/oauth-2-simplified/ up to date, and to keep snapshots of older versions at date-based permalinks at the time when I publish an updated version. I link to the previous versions of the post at the bottom of the primary post. (Manually for now, until I decide this is an important enough feature to automate). I think this strike the right balance between providing visitors with the most current information with the least amount of effort, while still preserving the history of the older versions.

Thanks to @Zegnat and @sebsel for finding some new new edges case in Webmention discovery that deserve new tests!The new test, #22, advertises its Webmention endpoint with a URL that is relative to the page (e.g. <link rel="webmention" href="22/webmention">). The existing relative URL tests were absolute paths (e.g. <link rel="webmention" href="/test/22/webmention">).

Over the last couple years I've occasionally posted a recipe on my website, but I'd always just done it as a plain text post, nothing fancy. Today I updated p3k to support a new post type, h-recipe. Now I can properly format and display recipes on my site!

QuillDay 26: Added tag tokens and published date to QuillDay 28: Defaults to mp-syndicate-to instead of the old syndicate-to, and allows overriding for backwards compatibilityDay 30: Documentation for the bookmark interfaceXRayDay 27: XRay now returns the HTTP status code and parses the meta http-equiv tag for static filesp3kDay 29: Shows an audio player for audio posts, and a video player for audio posts with cover artIndieNewsDay 31: Shows the post text smaller and autolinked for posts without a name, and launched the Dutch translationDay 32: Enabled WebSub feeds, which led to finding and fixing a bug in the websub.rocks test suite

You can now subscribe to realtime updates of IndieNews feeds via WebSub! (formerly known as PubSubHubbub)It was relatively straightforward to add the necessary tags and ping the WebSub hub to make this work. I used Switchboard as the hub. I added the <link> tags and HTTP headers to indicate the hub and self URLs. When a new post is submitted, I then ping the hub, which is just an HTTP POST request with the URL of the feed.I then went to test the publisher using websub.rocks. That part worked great, websub.rocks was able to subscribe to my feed, and I see it receiving the ping when a new post is added to IndieNews.