I think this is the first time in the 100days project that I've worked on a project that is not my own! Today I added support for JSON requests to Known's Micropub endpoint. I also added support for JSON checkins that OwnYourSwarm sends.
I tried writing as little code as I could, and changing as little as possible about how it worked, so essentially I am just extracting the properties it knows about from the JSON request to the variables the plugin expects to find. This does mean that a few Micropub JSON features are still not supported, such as sending HTML content (Known seems to strip HTML tags from all content sent to it), and Known doesn't provide a mechanism for storing arbitrary nested JSON objects. However, I was able to get it to pass tests 200, 201 and 203 from the micropub.rocks test suite, which is enough for basic support.
It also is able to create checkins from the payload that OwnYourSwarm sends! I also made it download the photo that is attached to a checkin, rather than hotlink the Foursquare image URL.
Since I don't have commit access to the Known repo, I sent a pull request to Known with these changes. I tested everything with a local Known installation. Hopefully benwerd or mapkyca can merge the PR soon!
Hopefully this improves people's experience using tools like OwnYourSwarm and OwnYourGram with Known!
Today I wrote up documentation on OwnYourSwarm. It actually took quite a bit longer than I expected to write everything up. The documentation walks through each component:
Rather than repeat any of the information here, I will just send you off to read the docs! Please let me know if you have any questions! I hope to see some more implementations of people receiving checkins via Micropub soon!
An interesting feature of the Swarm app is how it handles photos uploaded to checkins. If you check in and attach a photo, the checkin is actually created before the photo is uploaded. If you're on a spotty Internet connection, you'll see this because your checkin will exist and you'll get points for it, but there won't be a photo yet. The app will then continue to upload the photo separately, retrying if it fails. This is actually a really great app design on the part of Foursquare, but does lead to some tricks with the API.
Since OwnYourSwarm uses Foursquare's realtime API, it will receive a POST request almost immediately, often before the photo exists at the API. This means the initial Micropub request might be missing the photo.
Today I made OwnYourSwarm send a Micropub update request to update your post after the photo is uploaded. When you post a checkin, if there is no photo, then OwnYourSwarm queues a background job on a 15-second delay. It will then check after 15 seconds to see if a photo exists, and sends an update request with the photo URL if so. If still no photo is found after 15 seconds, it will wait another 30 seconds and try again. This continues for the following schedule: 15 seconds, 30 seconds, 1 minute, 2 minutes, 5 minutes, 10 minutes, 30 minutes, 1 hour. We'll see if this is too much polling, but the rate limits on Foursquare are relatively high. (500 requests per user per hour). This does mean that every checkin with intentionally no photo will be requested from Foursquare 8 times.
I had originally planned on using this same polling schedule to later pull back responses to your checkins (likes, and comments), but Ryan pointed out that I can probably use a simpler and more efficient polling schedule since the Foursquare API provides a method to return the last N checkins.
Beginning a slow project of updating the docs about the IndieAuth spec, today I started by updating a few pages on the wiki. Right now, most of the docs about IndieAuth (the spec), and how to use it, live across a variety of pages on the wiki, grouped together at https://indieweb.org/Category:IndieAuth.
My goal with the spec IndieAuth is to make it an extension of the OAuth 2.0 spec. It has always been based off of the OAuth 2.0 spec, but I've never written it up properly as an extension. It's always been just a series of how-to guides. Additionally, I had originally started by specifying all of the responses being form-encoded responses, whereas the OAuth 2.0 spec says all responses must be JSON format. I've been slowly converting my various apps that use IndieAuth to support both, based on the HTTP Accept header, although I haven't publicized this much yet.
Today's project was updating the existing IndieAuth documentation on the wiki to explicitly include the JSON versions as a valid response format.
Eventually I hope to write up IndieAuth as a formal extension to OAuth 2.0, in the same format that something like the Device Flow is an extension.
Today I added an option to OwnYourGram to opt in to receiving an h-card as the location property instead of a geo:// URI. On the dashboard, there is a setting to toggle between receiving a geo:// URI with file uploads, and an h-card location with a reference to the Instagram photo URL.
Since Micropub's form-encoded format doesn't support nested objects like h-card, we have to use the JSON format to send that. However in JSON format, we can't upload files, so we need to send just the image URL. Typically, a Micropub client would first upload the photo to the user's Media Endpoint and include the resulting URL in the JSON Micropub request. However since the photo already exists at a URL on Instagram's server, I just skipped the extra upload step and pass the endpoint the Instagram URL.
So if you want to start receiving the location as an h-card, you can opt in to this change on the OwnYourGram dashboard!
I finished all the client tests for creating posts, and launched them on micropub.rocks today!
Here's a video showing how I sign in to the test suite in Quill and make a post that passes the first test.
Here are the list of tests currently implemented. The numbers correspond with the equivalent test for servers.
Currently the test tool does not keep track of which tests you've passed, it just tells you whether you passed them. It's still a manual step to check off the boxes in the implementation report.
The good news is that Micropub.rocks passes its own tests!
On the last telcon of the W3C Social Web Working Group, we voted to request that Micropub move to PR, the next stage of publication within the W3C! This is the second to last step before Micropub becomes a W3C Recommendation!
Since it's sometimes confusing to remember all the stages that specs go through, here is a little diagram to help, taken from the new W3C Process Document.
Today I prepared the document for publication. This involved a last-minute pass through the document looking for obvious typos, adjusting the language around the exit criteria to be in the past tense (when this is published we will have exited the Candidate Recommendation stage!), and expanding the acknowledgements section. With any luck, we'll be publishing this next week!
Now that I have a basic pattern for supporting edits in Quill, I was able to quickly add support for editing reposts today. It works the same as yesterday's project of supporting edits of "likes", where the main "edit" page detects the "repost-of" property in the post and redirects to the repost interface. Not much else to say about today's project other than that!