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.
Example delete and undelete flow when storing posts as flat files:
• Create a post on disk stored at e.g. `/web/2017/10/15/1/post.txt` which has a public URL of `http://example.com/2017/10/15/1/` • When the client deletes the post, the server moves the file to `/web/.trash/2017/10/15/1/post.txt` • If the client sends an undelete request, the request will include the former public URL of the file `http://example.com/2017/10/15/1/` • Similar to how the server knows where to find the file for live posts, it should know how to find the post in the trash folder if it's been deleted • The server can move the file back to the public folder `/web/2017/10/15/1/post.txt` to complete the undelete
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.
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.
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.
As discussed on the last call, we've been chipping away at getting more of the Micropub implementation reports to be confirmed with the test suite now that it's complete.
I've made some updates to the implementation report summary to better reflect the current status of the submitted reports. https://micropub.net/implementation-reports/clients/ The main addition is a row at the top noting whether a report was self-reported or confirmed via micropub.rocks. There is also a new column showing the total numbers of *confirmed* implementations of each feature in addition to the existing column showing the total implementations of each feature.
We now have three implementations other than my own that have confirmed their reports with the test suite. Two of them are relatively full-featured clients, the other creates posts so doesn't need to pass any of the update/delete tests. There are at least two implementations (other than my own) of each feature, and all but two features have 2+ implementations confirmed with the test suite.
The current gap in the results is with form-encoded delete requests, since I have not been able to track down one of the implementors to get him to re-submit an updated report. However, I did test his client with the test suite myself and confirmed that it passes those tests.
At this point, I feel comfortable making the transition request, since each feature has been tested against the test suite and has two or more implementations other than my own.