One of my favorite online tools is Hypothes.is. It allows you to annotate web pages as you would a book. When you’re using Hypothes.is you can highlight text on a webpage or add notes. The tool can be used to take private notes, but it becomes all the more powerful when you use it for collaborat...
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.
In August 2012, I wrote a quick script to stream front-page Hackernews stories to an IRC channel on Freenode (##hackernews in case you're interested) so that I could quickly glance at popular stories there instead of needing to load Hackernews. Since IRC is my feed reader, I've always tried to pipe as much there as possible.
My favorite part here:
So in 2.5 years of parsing the HTML, I never had any problems. In 2 days of parsing the JSON API, I hit a glitch where all the stories were empty.
Since more people and programs see the HTML than use the API, the HTML ends up being more reliable.
It might surprise some developers to learn that the 4 official apps for Micro.blog — the iOS and macOS apps, Sunlit, and our microcasting app Wavelength — don’t actually share very much Objective-C or Swift code. To minimize dependencies and so that we could more easily develop each app quick...
Great to see pieces of micro.blog opening up like this.
For some time, we have been considering how we could open up compatibility between Micro.blog and Mastodon. Any feature that could be disruptive needs to be approached carefully. In this post I want to talk about how Micro.blog supports Mastodon, why I think it’s useful, and anticipate some questi...
Findings and actions from Project Strobe—a root-and-branch review of third-party developer access to Google account and Android device data and of our philosophy around apps’ data access.
Google is about to have its Cambridge Analytica moment. A security bug allowed third-party developers to access Google+ user profile data since 2015 until Google discovered and patched it in March, but decided not to inform the world. When a user gave permission to an app to access their public pro…
In order to make it easier to track activity in Hypothes.is, I created a program called Hypothes.is Collector. The idea is that you can type in user name, a URL, a tag, or a group ID and click the button to see all of the related annotations. The program will create a new sheet with an archive of up to 200 annotations based on the search terms. It will then create a third sheet that will count how many of these annotations were made on each URL in the set by each user.
As any kindergartner can tell you, “It’s difficult to play ball when the local bully owns the ball and wants to make up their own rules or leave in a huff.”
One of the things I love about IndieWeb is that we’re all trying to create a way for balls to be roughly standardized and mass manufactured so that everyone can play regardless of what the bully wants to do or what equipment people bring to the game.1
And as Nikhil Sonnad has reminded us very recently, we also need more than just connections, we need actual caring and thinking human interaction.2
NextScripts Autoposting API for Facebook allows you to share your texts, images and links to Facebook Profiles, Pages and Groups. New API library from NextScripts can automatically share texts, images and links to Facebook.
Facebook made changes to it’s API access policy on May 1st, 2018. As the result we introduced our own Premium API for Facebook. We feel that we need to explain how exactly those changes affected SNAP. Since the beginning Facebook native API was unrestricted. Anyone w...
I announced recently that Bridgy Publish for Facebook would shut down soon. Facebook’s moves to restrict its API to improve privacy and security are laudable, and arguably ...
Brid.gy was the last thing really keeping me connected to Facebook at all. Now that Facebook is shutting down its most useful functionality from my perspective, perhaps it’s time to deactivate it and move toward shutting it all down?
APIs (application programming interfaces) are a big part of the web. In 2013 there were over 10,000 APIs published by companies for open consumption 1. That is quadruple the number available in 2010 2. With so many companies investing in this new area of business, possessing a working understanding of APIs becomes increasingly relevant to careers in the software industry. Through this course, we hope to give you that knowledge by building up from the very basics. In this chapter, we start by looking at some fundamental concepts around APIs. We define what an API is, where it lives, and give a high level picture of how one is used.
Third-party Twitter apps are going to break on June 19th, 2018.
After June 19th, 2018, “streaming services” at Twitter will be removed. This means two things for third-party apps:
If you use an app like Talon, Tweetbot, Tweetings, or Twitterrific, there is no way for its developer to fix these issues.
- Push notifications will no longer arrive
- Timelines won’t refresh automatically
We are incredibly eager to update our apps. However, despite many requests for clarification and guidance, Twitter has not provided a way for us to recreate the lost functionality. We've been waiting for more than a year.
If I was sitting on a huge pile of Twitter related code with a full set of Twitter related reading/posting functionality, I think I’d head toward some of the new open protocols coming out of the IndieWeb to build a new user base. By supporting feeds like RSS, ATOM, JSON feed, and even h-feed (possibly via Microsub) for the feed reader portion and building in the open Micropub spec, one could rejuvenate old Twitter apps to work with a myriad of microblog-like (and even traditional blog) functionality on platforms like WordPress, Drupal, Craft, WithKnown, Jekyll, Kirby, Hugo, micro.blog, and a myriad of others in the future. Suddenly all those old Twitter apps could rise from the ashes and invigorate a new, more open community. Given the open “architecture” of the community, it would give developers much more direct control of both their software and futures than Twitter has ever given them as well as a deeper sense of impact while simultaneously eating a nice portion of Twitter’s lunch. With less than a week’s worth of work, I suspect that many of these old apps could have new and more fruitful lives than the scraps they were getting before.
If the bird site doesn’t heed their cries, I hope they’ll all re-purpose their code and support the open web so that their hard work and efforts aren’t completely lost.