Statuses

As a bit of prior art, consider the (originally) open API that Twitter provided that created an efflorescence of Twitter clients one could use to post to Twitter. Obviously those were a bit simpler since they only involved 140 characters of text, URLs, and maybe photos or geo-coordinates. While Twitter eventually cut off the API, the concept was a strong one and the competition provided by the wealth of options, including paid options, made creating posting interfaces or editors an easy option for a variety of developers. Remember the thousands of WordPress plugins in the WordPress repository alone? (Sadly, Twitter turned off this API and all the lovely posting clients for Twitter either died or were bought up by Twitter and look where we are now.)

Several years ago the IndieWeb community took the openness of this model to heart and created the W3C recommended Micropub spec. It’s essentially an open API that dis-intermediates the CMS/publishing platform from the editor interface using a client/server model. It also has the benefit of allowing developers to create incredibly highly customized publishing interfaces. You can now use a full article editor like Quill which provides a Medium.com-like interface, but you can also use something supremely simple like Teacup (even from your watch!) to quickly post what your drinking/eating (along with a timestamp and optional location) to your website.

As a result of this development and the fact that there’s already a Micropub endpoint implemented for WordPress as a plugin, you can try several dozen editors and posting clients out today! And why not try them on other platforms like Drupal, Known, Craft, Jekyll, Kirby, Hugo, and Blot to name a few.

The added benefit is that designers and developers can create either very simple interfaces for posting custom things (maybe you want to post the book you’re reading with indiebookclub.biz to your website in a GoodReads or LibraryThing sort of way) or they can create interfaces for posting almost anything (our Quill example). Interface modalities can also be dramatically different. They could be stand-alone applications on PC/MacOS/Linux, web applications, mobile applications, or as simple as a browser extension (Omnibear for Chrome or Firefox is a great example of this).

For several months now, I’ve been using several social media sites to publish their data to my website using their RSS feeds via IFTTT/Zapier to Webhooks that post to my Micropub endpoint. There’s nothing better than owning all your data, right?

Maybe you want to go all in on the social media side of life? What’s to keep feed readers from building in these Micropub posting interfaces? Then you could read posts in something like the WordPress.com reader, type your reply or response directly into the reader and use Micropub to post it to your website and also cross-post it to social media? (Incidentally there are a handful of social readers that do this already!)

I hear UI complaints by people all the time at camps… If you’re a dev shop interested in paring down the editor interface for a non-tech-savvy client, then customize a Micropub client to post only the minimum requirements and let the WordPress CMS and theme take care of the rest for them! In fact, perhaps there’s a market for white-listed or even branded posting interfaces?

Now that we’ve fixed the root problem without tons of engineering time, all WordPress really needs to do is to create a Micropub client out of Gutenberg, and all those hours of work and engineering on that one posting interface could allow it to be a client to not only post to WordPress, but to Drupal sites, WithKnown sites, and any of the other dozens of platforms that already support the spec.

I mentioned it the other day, on my own website and on Twitter, if Iceberg were to implement their editor as a Micropub client, then their users could use it not only for WordPress, but other CMS platforms could use it as well.

Looking at @useiceberg and thinking how cool it would be if there were an app version that I could log into that had Micropub support so I could use it to publish to any of a handful of CMSes and not just WordPress. https://t.co/fAwIiBp31s — Chris Aldrich (@ChrisAldrich) May 22, 2020

What if a user got tired of using and maintaining their current CMS and wanted to move to another easier or faster one? They don’t have to dump the beautiful editor interface and workflow they’ve become accustomed to, they can just move to anything else that has a Micropub endpoint and take their editor with them. (Think about how you can take most text editors with you if you moved from PC, MacOS, or Linux. Why shouldn’t the same be true if you changed CMS? It’s all just data, right?!)

A great example of just this potential came out in the last week. The 9 year old iA Writer just added Micropub support. It’s a markdown writing app that supports publishing to WordPress, Medium, and Ghost. With Micropub support it can now be used to publish to dozens of additional CMSs and services like Micro.blog. While it’s available on Mac/iOS devices at the moment, I can’t wait for them to add the support for Windows and Android devices shortly as well.

Or what if Medium.com pivoted (maybe for the last time?) and made itself a Micropub client? Then it could be the billionaire’s typewriter that we’ve all been hoping for? And it would have the benefit of being able to post to multiple CMSs.

There are so many possibilities for such an open ecosystem. But, please, let’s not just build something that only works with WordPress API. Do we need another API that will make it harder for editor designers and developers to support each and every quirky, ever-changing snowflake API out there?

Want some more overview and some demos? I did a WordCamp session on the topic last year.