Aaron Parecki

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.

Here is a writeup of how I built a desk bell for Kickstarter pledge alerts using a Raspberry Pi Zero and a solenoid.

First, the design goals:

• The bell should look as much like a regular desk bell as possible, no loose wires, and no visible contraption that rings the bell
• Should be entirely self-contained and not rely on external hardware or cloud services
• Should be able to be battery powered so that I can take it places

With that in mind, I set out to find the hardware I needed for this, and settled on the following.

The Bell

The bell is a traditional mechanical desk bell. I bought it on Amazon for $5.29. When you press the button on the top, it hits a little hammer that then hits the inside of the bell. This will make more sense in a later photo.

The Hardware

It turns out a Raspberry Pi Zero fits perfectly under the bottom part of the desk bell. The Pi Zero has built-in wifi, and can be powered by a portable USB battery, so it's a great choice for this.

The next piece was figuring out how to move the hammer inside the bell. I started looking on eBay and Aliexpress for cheap solenoids, and was quickly overwhelmed with options. However I needed to find one that worked on 5v or 3.3v since that's what the Pi Zero can output, and I don't want to require an additional external power supply. I also realized that there are some solenoids that have springs that force the pin back to a resting position, and others will just stop applying the magnet and the pin can move freely when it's "off". What I needed for this is one with a spring so that the pin snaps back and gets out of the way of the hammer in the bell. I took a gamble buying one on eBay that I thought matched all the criteria, but it was kind of hard to tell because the descriptions are not written in the best English. Here's the one I ended up with.

The hardest part of this whole thing, since I'm not actually super great at electronics, was figuring out how to drive the solenoid from the Raspberry Pi's GPIO pins. I know you can't just use the 5v output to drive it directly, since that's a quick way to damage the Pi's pins. You need a circuit in between with a transistor and diode to protect the Pi. 

The Circuit

With a bit of research, I found this circuit diagram for driving a solenoid from an Arduino, which is effectively equivalent to what I need to do. I've redrawn it here based on the actual components I used, and using the Raspberry Pi's 5v power instead of an external power supply.

Components:

• R1: 1KΩ resistor
• D1: 1N4004 Diode
• Q1: TIP120 Darlington NPN Transistor
• L1: 5V Solenoid

I happened to have a 1N4004 diode and 1KΩ resistor in my collection of parts, but I had to buy the TIP120 Darlington Transistor from Adafruit. Since I'll only be actuating the solenoid for a split second, I didn't worry about adding a heat sink to the transistor since it will only be on for a very short period of time.

Refer to the Pi Zero pinout diagram to know which GPIO pin you're connecting to. In my photos above, that's pin 16 which is GPIO pin 4.

Soldering

Since I need this whole thing to fit inside the bell, that doesn't leave room for adding any additional circuit boards. I decided to solder directly on to the Pi Zero, despite that not being a thing I'd normally do. Thankfully it's cheap enough that if I mess it up super bad it's not the end of the world if I have to buy another one.

The leads on the diode were thick enough to act as a sort of structural support for hanging the components off of the Pi. I tried to keep everything as tight as I could while also keeping it flat.

Assembly

The first step of putting this all together was mounting the solenoid so that it can hit the hammer when it's actuated. I cut out a little piece of cardboard and hot-glued the solenoid to it, and the cardboard to the underside of the bell.

Then I attached the Pi board to the underside, hot gluing it to the frame in a couple places. It just barely fit with the added width of the transistor hanging off, once you factor in the size of the micro USB connector also plugged in.

The wooden box is where the battery lives, so I drilled a hole for the USB cable in the top of the box. This lets the bell site nicely on the top of the box without any visible wires. When it's running off the battery, there's no visible wires at all, since everything is entirely self-contained.

The Software

Since the Raspberry Pi is a full Linux computer, we can use a high-level language to parse the Kickstarter feed and ring the bell. Here's what I did to get the Pi set up with the software I needed.

After first configuring the wifi by plugging in a physical keyboard and monitor and enabling SSH, I was able to then SSH from my laptop to install the rest.

System packages:

sudo apt install apache2 php git-core

WiringPi provides a command line utility to control the GPIO pins. To install, clone the git repository and run the build command.

git clone git://git.drogon.net/wiringPi
cd ~/wiringPi
./build

This will compile and install the gpio command, which you can then use to configure the pins.

First we'll make an init script to set the pin to output mode and run that on boot. Open the /etc/rc.local file in an editor and add the following, which sets pin 4 to output mode:

/usr/local/bin/gpio mode 4 out

Next, make a file called ding.sh and add the following, which will turn the pin to HIGH, wait a split second, then turn it to LOW.

#!/bin/bash
/usr/local/bin/gpio write 4 1
sleep 0.05
/usr/local/bin/gpio write 4 0

Make the script executable:

chmod 755 ding.sh

Now you should be able to run this script and hear the bell ding!

./ding.sh

At this point, you can trigger this bell from anything you can use to call a shell script! 

Kickstarter

Since the main goal of this project is to be alerted when someone pledges to a Kickstarter campaign, we'll set up a small script to check the campaign stats and run the "ding" script whenever the total pledge amount changes.

The trick to this is that Kickstarter has a JSON endpoint that returns the basic campaign info used to update the stats on a campaign page. Take your Kickstarter URL and add /stats.json?v=1 to the end, and you'll see a response like the below.

{
  "project": {
    "id": 1330436901,
    "state_changed_at": 1507653791,
    "state": "live",
    "backers_count": 307,
    "pledged": "10352.0",
    "comments_count": 7
  }
}

The PHP script below will download that file, compare the pledge amount to what it last saw, and run the script to ring the bell whenever it changes.

<?php
chdir(dirname(__FILE__));
$date = new DateTime();
$date->setTimeZone(new DateTimeZone('US/Pacific'));

$hour = (int)$date->format('H');

if($hour < 6 || $hour > 21)
  die();

$kickstarter_url = 'https://www.kickstarter.com/projects/2052814389/get-your-money-together-your-purr-fect-finance-wor/stats.json?v=1';

$ch = curl_init($kickstarter_url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36');
curl_setopt($ch, CURLOPT_HTTPHEADER, [
  'Accept: application/json'  
]);
$data = curl_exec($ch);
$stats = json_decode($data, true);

if($stats) {
  $current = [
    'backers' => (int)$stats['project']['backers_count'],
    'pledged' => (float)$stats['project']['pledged']
  ];
  
  if(file_exists('stats.json')) {
    $previous = json_decode(file_get_contents('stats.json'), true);
  
    if($current['pledged'] > $previous['pledged']) {
      shell_exec('/home/pi/ding.sh');
      echo "Now $".$current['pledged']."\n";
    }
  }

  file_put_contents('stats.json', json_encode($current));
}

Replace the Kickstarter URL with your own of course. The script will cache the last seen amounts in a file called stats.json. Now you just need to set up a cron job to run this every 5 minutes!

*/5 * * * * /usr/bin/php /home/pi/cron.php >> /home/pi/cron.log 2>&1

Just for Fun

Just for fun, I also made a web page that I can load if I want to ring the bell manually, or from some other server in my house. Here's a really simple PHP script that you can set as index.php which will show a giant full-screen button and ring the bell when it's pressed.

You can also run this from an external script using curl:

curl http://bell.pad/ -d action=ring

I've set up a static IP address for my Pi at home and given it a DNS name on the local network, so I can refer to it as bell.pad from inside the house.

<!doctype html>
<html>
<head>
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Ring the Bell
</head>
<body>

<form action="/" method="post">
  <input type="hidden" name="action" value="ring">
  
  <div class="page">
    <input type="submit" value="🛎">
  </div>
</form>

<style>
body {
  font-family: sans-serif;
  margin: 0;
  padding: 0;
}
.page {
  display: flex;
  align-items: center;
  justify-content: center;
  width: 100vw;
  height: 100vh;
}
input {
  font-size: 70pt;
  width: 100vw;
  height: 100vh;
  background-color: #fff;
  border: none;
  -webkit-appearance: none;
}
</style>
</body>
</html>
<?php
if(isset($_POST['action']) && $_POST['action'] == 'ring') {
  shell_exec('/home/pi/ding.sh');
}

And here's how it looks on my phone!

And before you ask, no I'm not going to launch this as a Kickstarter project!

Why Passwordless Logins?

There are many reasons passwords are terrible, especially passwords that you have to remember. There are also many situations in which it's not practical to enter a password, or it's not safe.

When I travel for IndieWebCamps or other conferences, I often need to log in to my website to give demos of things. Sometimes I'm giving a demo in front of a bunch of people, or using a computer that isn't mine. I can't be sure that there isn't a keylogger on the computer I'm using, or that my typing isn't being recorded by cameras for the livestream. It would be great if there was a way to log in on a guest computer without having to type in my password manually.

I was able to create a workflow where I replaced the password box on my website with a button which sends a login request to my phone. I then have to unlock my phone and confirm the login request from the device, and then the session on the desktop that requested the login is confirmed and I'm logged in.

But first, a bit of background.

Authentication Factors

There are generally three categories of authentication factors talked about in security.

• Something you know (Knowledge): A knowledge factor is something you know, such as your password.
• Something you have (Possession): Possession factors are something you have, such as a Yubikey, a phone, or some other physical security token.
• Something you are (Inherence): An Inherence factor is something you are, usually a biometric characteristic such as a fingerprint, voice pattern or iris pattern.

For most of computing history, only a knowledge factor (a password) was used. If you never wrote down the password, then a password is strictly a knowledge factor.

Lately, more systems are now requiring two factors of authentication, such as asking you for your password (Knowledge) and also requiring that you insert a security key (Possession). Apple accomplishes two-factor authentication with a password (Knowledge) and your fingerprint (Inherence). This obviously provides better security, since an attacker now needs to compromise two things with very different attack surface areas.

With the advent of password managers, more people are now turning passwords (Knowledge factors) into Possession factors. It's worth thinking about this from the threat model perspective. If someone is trying to hack into my account that has only a password, then it is possible to brute force the account eventually. If the account requires just a possession factor to log in, then if someone steals the physical device they can log in to my account. Password managers end up converting a password into a Possession Factor, since if someone steals the device that is storing my passwords, they would be able to use the passwords. Because of this risk, most password managers protect the device with either a "master password" (Knowledge Factor) or a biometric aspect, such as using Apple's TouchID (an Inherence Factor).

The Passwordless Workflow

Now that we have that out of the way, let's get into how I can use an iPhone app as the primary authentication factor for logging in to my website.

The workflow that I ended up using, and that I'll document in a future blog post, works as follows:

• Go to the website and, click "sign in"
• Enter my username, and press the "log in" button
• A notification on my phone pops up asking to confirm the login
• Tap "approve", and swipe my thumbprint
• The website sees that I've confirmed the login request and starts the session

No password is required for this flow! Instead, we require two factors: something you have (your phone), and something you are (your fingerprint). This means we are now even more secure than using just a password. 

To implement this on my website, I used the Okta Verify app, since they've gone to great lengths to create a secure iPhone app and they run servers that will handle that aspect of the security.

In addition to the server no longer accepting a brute-forceable password, we rely on the security provided by the Okta app and their servers to handle the multi-factor aspect of security. 

Why is this more secure than TOTP?

TOTP is the spec used by Google Authenticator and other similar apps that ask you to enter a 6-digit code. Typically setting this up will involve scanning a QR code into an app, and then it will generate 6 digits that change every 30 seconds. You might be tempted to use this as a primary login factor, since ultimately the end user flow for this ends up looking similar to the Okta Verify flow outlined above. However, there are a couple reasons using TOTP as a primary factor isn't secure.

The TOTP spec, used by Google Authenticator and many others, is acceptable as a second factor of authentication. However it was not designed to be the primary factor.

If you try to use TOTP as the only factor, it is essentially a really bad password. Since the length and character set of the TOTP codes are known, an attacker only has to try guessing 6 digit passwords until they get in. Another attack vector is if someone can watch you enter a valid code, they could steal the code and log in on another device, since the codes can typically be replayed.

Because of these issues, TOTP is only acceptable as an additional factor after already confirming a first authentication factor such as a password.

Implementing the Flow

In a future blog post, I'll outline the steps required to actually implement this flow using the Okta Verify app. 

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!

Note: I will be keeping this post up to date based on the latest plans.

From Hollywood: 4:15am

Bike 3.7mi (~30m) to Gateway TC, arrive by 4:45.

From Gateway, attempt to get on any of the following Green Lines to Clackamas TC: 4:56 5:19 5:31 5:44 5:59

• If all trains are full, bike to Oregon City (14.3mi, 1h 45m) 6:00am-7:45am goo.gl/maps/FYUDCiRcu442

If all goes well catching the train, will arrive at Clackamas TC before 6:45

Clackamas TC to Oregon City: 7.5mi ~1 hour

• goo.gl/maps/vZEnXjvwhLF2 (warning: Google does not know about 205 path all the way)
• ridewithgps.com/routes/24258104

Oregon City

Arrival time in Oregon City will be between 6:20 - 7:20 by train+bike, or 7:45 by bike. Wait in Oregon City for people to meet up.

• Singer Hill Cafe opens at 6:30

From Oregon City: 7:45am

Leave Oregon City before 7:45am. It will be about 14 miles to the riverbank, ~1h 45m. There are two options, either Hwy 213 or back roads.

Back Roads (14 miles)

Most of the route is single-lane in two directions with no shoulder, and lots of windy roads. There is almost no reason cars would take this route.

• Summary: goo.gl/maps/c1N9R2LfgRU2
• Details: ridewithgps.com/routes/24258326

Hwy 213 (12 miles)

This is the route advertised on biketotheeclipse.com. It is very straight, and has a shoulder almost the entire way, and has slightly less elevation gain. It is likely to have a lot of car traffic since it's the main route from Oregon City to Molalla. However there is something to be said for riding alongside other bikers.

• Summary: goo.gl/maps/1fpEcWumFr82
• Details: ridewithgps.com/routes/24391698

The two routes meet up for the last mile and a half at this intersection.

The Destination

Arrive at the riverbank of Wagonwheel Park at 9:30am, during the partial eclipse. There will still be 45 minutes of partial eclipse until the peak.

Eclipse Times

• Start of partial: 09:06:02
• Start of total: 10:18:40
• Peak: 10:19:01
• End of total: 10:19:25
• End of partial: 11:38:37

Seriously Simple Podcasting is a great Wordpress plugin for hosting your own podcast. However, the number of episodes it includes in the RSS feed is tied to the number of items you include in all your other RSS feeds as well. 

If you want your podcast listeners to be able to find old episodes, you'll need to make sure that all your podcasts appear in the feed all the time, since some clients like iTunes will treat your RSS feed as authoritative, and delete episodes from their directory when they disappear from the feed.

Tonight I took a plunge into the WordPress plugin to see why it was only including the last 10 posts. It turns out the plugin will actually show the number of posts of all your other RSS feeds, and also provides a hook to override that. Why they don't expose that in the interface I don't know.

So, rather than making all your RSS feeds show all of your posts (which will slow down your site and use a lot more of your server's bandwidth), I wrote a plugin that overrides the default setting!

Download this plugin to your plugins folder, and enable it in the WordPress panel! You can download the zip linked below, or just copy and paste this super tiny amount of code into a file in your plugins folder.

<?php
/*
Plugin Name: Include All Podcast Episodes in RSS Feed
Plugin URI: https://aaronparecki.com/ssp-include-all-episodes-in-rss-feed
Description: This plugin enables displaying all podcast episodes in the Seriously Simple Podcast feed
Version: 1.0
Author: Aaron Parecki
Author URI: https://aaronparecki.com
License: CC0
*/

add_filter('ssp_feed_number_of_posts', 'ssp_modify_number_of_posts_in_feed');

function ssp_modify_number_of_posts_in_feed( $n ) {
  return 10000;
}

Note that after you install the plugin, you'll have to change something about your podcast (upload a new episode, change the description of an episode, whatever) in order to get the plugin to regenerate the RSS feed since it seems to cache it.

Below are notes from my workshop at the Quantified Self 2017 conference in Amsterdam. Thanks to everyone who participated in the workshop!

These are some criteria I use when determining whether a tool will actually be useful to me, and whether I want to invest money and time in the product.

Effort vs Value

How much active effort does it take to use? On a scale of:

• Completely automatic
  
  • FitBit is always on, tracks sleep automatically
    
• Easily accessible
  
  • Jawbone UP requires a button press to track sleep, but is always on my wrist so it's easy
    
  • Withings scale requires no additional effort to upload/sync after stepping on the scale
    
• App on a phone
  
  • Requires extra work to unlock the phone and find the app
    
  • e.g. Sleep Cycle app requires launching the app and setting the phone on your bed
• Manual data entry
  
  • e.g. in a paper notebook, or manually adding to Google Sheets

Once you determine the level of effort the tool requires, ask yourself whether you are willing to put in that effort. Sometimes the value of a tool is high enough that you're willing to go to great lengths to use the tool.

Syncing

How does the device sync? Does it require that a company run servers? Does the device download directly to your own computer?

For example, the Withings scale only talks to the Withings servers. You can download the data from their servers later.

The Eye-Fi card can download directly from the card to your computer, which doesn't require a third party service to be running in order for the device to work.

Exportability

What kind of export options are available from the tool? Planning on the service at some point shutting down or planning on moving to a new tool later will mean you will want to choose a tool that ranks higher on this list.

• Full data portability - The tool provides a complete export and import, and you can expect to be able to import the data into another tool later. Almost no services support this, likely because there aren't very good standards defined for what the raw data should look like.
  
• API to export data continuously - The tool provides an API that exposes the data and can be used to connect with things like IFTTT.
• Export in machine-readable format - The tool does not provide an API, but does allow manual exporting in a machine-readable format. Things like exporting CSV files, JSON files, etc. This is the minimum bar a service must hit before I will consider using it.
• Export in non-machine-readable format - The tool provides an export, but it is in a format that is not machine readable, e.g. PDFs or images.
• No data export - The tool does not support exporting data at all.

How does the tool make money?

There are several ways tools make money, and you should be aware of the profit motive of any tool you use. There is no "right answer" and no "wrong answer" for whether you should use a tool based on this, but it's important to be aware of.

Did you pay just one time to buy a device?

• Things like FitBit charge exponentially more for the device than the manufacturing of it costs, because they don't charge you for membership later. 
  
• If you've paid only once but continue to cost the company money because they have to maintain servers for the device to work, then the company will likely try to sell you a new device in order to continue making money from you.
• Customer acquisition is often a huge cost to companies, and if each customer only pays once (how many wifi scales do you really need), then each customer is not going to be very profitable especially if the customers also incur costs on the company.

Are you paying a monthly subscription?

• If you are paying monthly for a tool, then chances are the company is working in your best interests since they will want to retain you as a customer.
  

Is the company making money off your data?

• Often times a company will be making money off the data they collect from their customers. The data can be useful in aggregate, so the company might want to encourage lots of people to use the tool to be able to collect enough data to make it valuable.
  
• This is not necessarily bad, but you need to be aware of this tradeoff.
• I've never paid any money to Foursquare, but I continue to use the app and allow them to use my data because I get a lot of value out of their tool.

Battery Life

For portable devices, battery life is often a huge concern. People often have different preferences for this as well. Some people are willing to charge a device every night, others want to not think about it for months.

My FitBit battery lasts around 5-7 days. That's enough to go out of town for the weekend and not worry about bringing my charger. I also can't charge my FitBit at night, since I wear it to track my sleep.

Related to battery life is what connector the device uses to charge. Is it a proprietary connector? That's usually less ideal since it can be more expensive to replace, and is harder to borrow chargers if you need. Thankfully most devices are moving towards charging via Micro USB or USB-C, so it's usually not too hard to find connectors.

Competition

Another thing to keep in mind is whether the tool you're considering has competition in the market. Are there other options you can switch to if this service shuts down, or if your device breaks?

Are there other services that provide this or similar functionality? If not, you might end up "stuck" as a customer, and the company will have little incentive to improve things or reduce costs.

Longevity

What will happen to the device if the company shuts down?

A Jawbone UP is completely tied to the company existing. The band has no interface, and requires syncing with their iOS or Android app to continue working. If the company shuts down their servers and unpublishes the app from the stores, the device will be nothing more than a decorative bracelet.

A Withings scale will still be a scale if the servers shut down, since it actually has a visual display on the device.

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!