Editor’s note: This post originally appeared at AltPlatform.org.
The state-of-the-art in feed readers was frozen in place sometime around 2010, if not before. By that time most of the format wars between RSS and Atom had long since died down and were all generally supported. The only new features to be added were simple functionalities like sharing out links from readers to social services like Facebook and Twitter. For fancier readers they also added the ability to share out to services like Evernote, OneNote, Pocket, Instapaper and other social silos or silo related services.
So the real question facing companies with stand alone traditional feed reader products–like Feedly, Digg Reader, The Old Reader, Inoreader, Reeder, NewsBlur, Netvibes, Tiny Tiny RSS, WordPress reader–and the cadre of others is:
- What features could/should we add?
- How can we improve?
- How can we gain new users?
- How can we increase our market share?
In short the primary question is:
What should a modern RSS feed reader be capable of doing?
First let’s look at the primary competition of feed readers. Their direct competition is Facebook, Twitter, Instagram, LinkedIn, Google+, and nearly every other social service out there.
Wait. What!? How can this be?
Built into the core and at their very hearts, each of these social silos are primarily feed readers! They’re just feed readers which are proprietary to their own platforms and only allow their users to read feeds from their services to the exclusion of others.
Does anyone think it’s a coincidence that Google Reader, the biggest and most popular feed reader of its day, was shut down at almost the exact time that Google+ was attempting to gain market share in the social space? Google was just trying to imitate their social media competition, not realizing that they had a much more powerful platform for encouraging the use of the open web that could have disrupted the disrupters.
Making matters worse, these social silo readers have typically, if not uniformly, turned off all external access to their own RSS feeds long ago. If you want to read content in Facebook, you have to log in and have an account and participate there directly, you cannot just subscribe to five peoples’ content via RSS and read it anywhere you want. This monopolistic behavior is exactly the reason we call them silos. Content goes in, but doesn’t come back out. Like the early days of AOL, some people now think that Facebook is the internet. Once you’re inside and using their system, they literally do everything they can to keep you from escaping including framing external content within their app so that you can more easily go straight back to their addictive Facebook stream.
But let’s ask ourselves an important question: Where exactly is all this content in Facebook, Twitter, et al. coming from? While a significant portion is coming from individual users whose entire online presence and identities is on these platforms, a relatively large part of it is being pumped into these silos via API or similar access from blogs and other websites in an attempt to increase their reach and interaction.
Just think for a minute about how close the New York Times and other news outlets have come in the past several years to potentially shutting down their own websites to push all of their content delivery into the capable hands of Facebook?  Or how many magazine outlets transitioned from other platforms like WordPress and even Tumblr to Medium just before Medium made their recent pivot and let go of a major part of their staff? Can you imagine how troublesome or even catastrophic things would have been or would be if sites like Medium or Facebook went down, got bought out, or disappeared altogether–potentially taking all their data with them? Or what happens weeks, months, or even years later if those social silos change their minds?
So if we go back to our first paragraph and think about what we’ve just covered, we might consider the fact that most traditional feed readers have simply become middle-man software for feeding data into social silos while extracting little, if any data, back out. This is a lopsided bargain and is, in large part, what is inexorably killing the traditional feed readers’ business model.
How can we reverse this model? And even better, how might we do it while simultaneously creating a more free, democratic, and open web?
We need to build for it! And fortunately a bunch of new pieces have been developed and matured in the past several years which can help drastically push the envelope to make this happen.
The Problem in Miniature
As an illustration, let’s look at Twitter. What is it really?
Twitter is a content management system (CMS) for posting short status updates online that has a simple and even beautiful user interface for writing, publishing, and storing content. Further, it also has a built-in reader that allows the user to read the content of others on the system. It essentially boils down to a simple CMS with a reader closely integrated into it. Similarly Facebook, Instagram, and other popular social services all do the same thing, they just specialize in different content types. In some sense they’re 5% posting interface and 95% feed reader.
Aside from the power of the tightly integrated CMS and reader functionalities, their real “secret sauce”, so to speak, is that they make it incredibly easy to interact with others. And it’s here that they win out and own the market. It’s also here where innovation within the blogosphere fell down on the job between 2005-2007 and nearly died out altogether.
I would argue that there are hundreds if not thousands of fantastic and even open source content management systems which, in flexibility and ease of use, could put each and every one of the social silos to shame. Most social networks like Twitter (status updates, links) and Instagram (photos, video) focus on only one or two content types while others Facebook (status updates, photos, video, articles, events, RSVPs, etc.) and Tumblr (articles, photo, video, audio, quotes, links, chat) do multiple content types. Hands down, systems like WordPress and Drupal, just to name two larger, well-developed, flexible, and open source CMSes, can run circles around all of these social silos in terms of the types of content they can not only post, but mashup in far better multi-media experiences. Why should you be limited to 140 characters if you prefer status updates of 280, 500, or even more characters?
But what are these hundreds of content management systems all missing?
You guessed it:
- An integrated reader
- the incredibly easy ability to interact with others
Who can easily and beneficially provide these two simple pieces of the puzzle?
All of the traditional feed readers mentioned above! Even Google Reader could come back from the dead and compete again to win back the piece of the social space that Google invented Google+ to do.
The Feed Reader Solution
These traditional feed readers have already built up the hardest part of the infrastructure that makes it easy for users to subscribe to content (via RSS, Atom, and some even JSON feeds) and read it quickly and easily. Some have even built-in algorithms that help to surface popular content. Even Pocket, a pseudo-reader, uses their aggregated content to recommend popular and interesting content.
But what about the dead-easy ability to interact? Unbeknownst to them, they’ve already got a piece of the functionality already built as most of them have integrations with social platforms for sharing reader content to them directly. Instead of sharing to the social media silos they could and should default in favor of making those posts directly to people’s personal websites and blogs. (And in turn these blogs could share or syndicate to these social silos if desired.)
What about the rest? Aren’t there some missing pieces? And how to build it easily for the hundreds or thousands of platforms out there? (I’ve had answers to all my other increasingly difficult questions, do you suppose this is where I’ll run out? Probably not today…)
The talented and dedicated developers of the Indieweb have already delivered all of the remaining pieces of the puzzle to allow us to recreate the model of the closed source social silos in an open and democratic way.
Allow me to sketch out what they’ve done and how traditional feed readers can clean up the edges to start taking back the engagement and market share. I have a suspicion that after hearing this, Google will dust off its Google Reader and the thousands of Twitter developers who made Twitter clients that were shut down when they got closed out of Twitter’s API by access limits will upgrade them a tad for the forthcoming Cambrian efflorescence of openness and interactivity on the internet.
The ubiquity of the concept of @mentions (or @replies), which was initially popularized by Twitter has spread across the social sphere. On nearly every popular social platform one can mention another user (typically with and @ symbol followed by their username, or some other similar pattern) and know that they will get a notification of the message. This feature is incredibly useful for carrying on conversations and interacting. The primarily problem with these @mentions is that they only work within their own siloed platform. One can’t @mention someone from Twitter and expect their friend will see it on Facebook. Even Medium, a service founded by Ev Williams, a former Chariman and CEO of Twitter, hasn’t enabled the ability for Twitter users to @mention users or reference content on Medium. One would think that using Twitter to comment on Medium articles would be a powerful thing right?! Maybe even a killer app?
The interesting thing is that cross-site @mentions already exist! Thousands of websites are already using the open standard called Webmentions, which is already a W3C recommended specification to do just this. Instead of using a username as the “key” for sending them, Webmentions use permalink URLs to send these simple notifications.
What does this mean? It means that I can write something on my site, and you can write a reply on a totally separate site (even using a different platform/CMS) and if both sites support the Webmention spec, I’ll receive a ping from your server to notify me of your response! I can then choose to display it on my site as a comment in a natural and even beautiful way. It’s all done so naturally that it appears as if people who have replied to my own posts have logged in on my site and written their comments here rather than somewhere else.
There are multitudes of implementations of the Webmention spec across the web already–including simple plugins for CMSes like WordPress and Drupal and some platforms like WithKnown support Webmentions out of the box. For those platforms that don’t already implement the spec, it’s incredibly clear and well written; most programmers could easily implement it within a day or two, even for a custom CMS.
The open Webmention spec isn’t directly related to the feed reader problem, but it does solve the seemingly major issue of allowing websites to intercommunicate with each other quickly and easily on the internet, in just the same way one can use their Facebook account to communicate with any other Facebook user. The major barrier broken down here is that one doesn’t necessarily need to be on the exact same platform as their friends, colleagues, or family to communicate back and forth.
And isn’t this the power of the internet? Imagine how horrible the world would be if your Sprint mobile phone could only talk to other Sprint customers? Or if you had to have Verizon and AT&T accounts to talk to people on those services. Bits are bits and the communication channels should be more open instead of more closed. Given the capabilities on the modern internet, it really is silly that one needs to have a Twitter account to communicate with people on Twitter. At the end of the day it’s just a corporate construct meant to help these corporations own internet communications.
The Micropub specification, on the other hand, does get right to the heart of the traditional feed reader piece of the communication problem.
Remember back to the early heady days of Twitter when there seemed to be a new Twitter client on the scene almost every day? Wikipedia has an entire page dedicated to some of the most popular, most of which no longer exist because Twitter drastically limited API access and drove them out of business. There was a huge amount of creativity and work to help people make it easier to read and post to twitter, and you can believe that Twitter took full advantage of all this free labor and creativity while they struggled to keep the service up and working. Once Twitter had these other moving parts sewn up and they had grown tremendously thanks in large part to the work of thousands of others, they shut them out without so much as a pat on the back. (The ultimate moral for most was not to try to build a business on someone else’s closed, proprietary code.)
All these Twitter clients used a simple API to allow them to publish to Twitter. Why not learn from that debacle and have an open spec that allows one to publish to almost any website on the web?
This is just what the developers of the Micropub open spec had in mind. Why not create a simple endpoint that any website can support to allow third party applications to publish almost any type of content to any platform on the internet? It shouldn’t matter what content management system you use, there should be a simple and direct method of posting to it. If we open things up in this way, then perhaps all these old Twitter applications could be dusted off to support the Micropub spec and they could be used to publish content of any flavor almost anywhere?
With this capability, enterprising developers could openly compete to build the best applications to publish anywhere. One application could be the best bookmarking service on the planet, while others (perhaps even Medium?) could compete to provide the best article publishing interface. Users wouldn’t be stuck with the one or two publishing interfaces that come pre-packaged with their CMS, they could have the choice of hundreds or thousands.
What traditional feed readers can add
Now let’s put it together to make this all actionable by feed readers.
This is where feed readers can win out by adding just a few lines of code! Along with others, they can then add user interfaces to their products to allow users to interact with the content flowing through them.
First users should be able to log into their feed reader accounts with some sort of authentication that allows them to lay claim to their own websites. This will allow the feed reader to publish to the user’s site on their behalf using Micropub. This can be done using a variation of oAuth or perhaps more simply using IndieAuth.
Publishing to Reader’s Sites instead of social silos
Remember back in the day where there were thousands of Twitter clients that could publish to Twitter, or even the current ability of feed readers to delegate publishing to Twitter? This is no different! The only change is that the end target is not a social silo like Twitter, but a user’s own website.
Like a particular article? Why not have a one click button to indicate your intent within the the feed reader? This then uses Micropub to publish the like to the user’s personal website! Combine this with the fact that one’s personal website supports Webmention and suddenly this posted like is turned into a like on the original website! Now the user owns the fact that they liked something (and can keep that even if the original disappears from the web), and the original website can own this same data as well. And guess what, the reader could keep its own copy as well to provide better meta-data to potentially benefit their other users as well. Win, win, win!
There are three general ways that this type of commenting workflow with publishing to the user’s personal site can occur:
A few readers, including Feedly (PRO) already support a version of this type of functionality, one can configure a custom URL to communicate an intent from the feed reader to create a post on one’s own website. Unfortunately this type of functionality is relatively difficult to use and is more dependent on the architecture of one’s own website. In Feedly’s case it only allows configuring one URL this way when many platforms may require 4 or more of these to be available to effectuate multiple different types of post kinds (bookmarks, likes, comments, replies, reposts, etc.) However, many CMSes with bookmarklets can leverage their URL structures to take effective advantage of this type of functionality.
Briefly discussed above, this open standard is already in use in many places on the web, from desktop clients, to browser add-ons, and even CMS plugins. If traditional feed readers allow their users to publish content from within the feed reader to their own personal website, there could be simple one click commenting and publishing. From a user interface perspective this would be as easy as clicking on a twitter icon to publish a post to Twitter and is close to what most traditional feed readers already do. A day or two’s worth of engineering work should quickly allow feed readers to quickly and easily publish directly to any CMS/platform that also supports the open Micropub spec.
Indie-config is slightly more complicated and not as broadly supported as the other two methods, but it provides yet another method of allowing a feed reader to interact with the user’s personal website so that they can easily publish from the reader directly to their website. In short indie-config is a method of using protocol handlers and postmessage to setup your website to both notify the browser that it can handle webactions and then do so. It also supports a broad array of post types as we’ll see in an example below.
Examples of Feed Readers and Functionality in the Wild
WordPress Reader already has some of these types of functionality built in, unfortunately it doesn’t go quite far enough and some of it is specific only to WordPress sites. I’ll briefly outline portions, but keep in mind that this example only just vaguely scratches the surface of what I’m talking about.
The photo above shows that within the WordPress reader there is the ability to algorithmicly highlight popular posts. We can see there’s a simple link included to follow the author of the suggested post. There’s also the ability to do a one click like of the post using one’s WordPress account, however this like is only displayed on the site with the original post, but isn’t displayed as a like on the user’s personal site. How could the user easily find the post in the future if they wanted to search for it again? What if users wanted to follow others’ likes in a linkblog-esque functionality?
Clicking on the “comment” bubble in the example takes you to the comments section of the original post to make a comment. Far better would be if it opened a small dialogue to let you write your comment and micro-publish it to your personal site as a reply, and then your own website could send a Webmention to the original which then has the option of displaying the comment.
The most robust version of UI that’s close to what I’m talking about is the “share” icon, which when clicked will give you the option to share a snippet of the post to one of any WordPress sites you’ve got registered. This opens up the admin UI of WordPress to allow you to modify any of the contents and publish it. Sites with pingbacks/trackbacks will send a ping to the original’s server to notify them presuming they still support these ancient protocols. Better yet, would be allowing the reader to repost or excerpt the piece and then send a Webmention, a much richer and far more robust version of pingback/trackback, to the original.
The major drawbacks within WordPress Reader are that most of the interactions are sent to the original post rather than being published on the reader’s site which could then ping the original about the interaction. The share functionality is about as close as anything in the traditional feed reader world currently comes to allowing the reader to post something from the reader to a personal site that they own and control, and, let’s be honest, it doesn’t do a good job of this at all.
Right now, the Indie reader Woodwind.xyz (code available on Github) is the gold standard of what modern feed reader functionality should be. Admittedly it’s missing some niceties that some feed readers have, but what it lacks in some traditional functionalities, it more than makes up for with more modern and forward facing functionality including the ability to send reactions and comments on articles directly to the reader’s personal website and then propagate those reactions to other sites across the open web. I’ll highlight some of these below along with screenshots and examples.
Some users will be stuck simply logging into this uber-modern feed reader because it has an interesting prerequisite for membership. The user must have their own website with rel=”me” links on their homepage that match the corresponding rel=”me” links from a Twitter, GitHub, or Flicker account. (There are other authentication avenues, but these are the most straightforward for our current purposes.)
After entering their personal website URL, Woodwind relegates sign-in to the IndieAuth site which then parses the user’s homepage to look for links to their social media profiles. It then checks those profiles to see if they link back to the users personal homepage–this can only be the case if the user has physical control of both websites. If they do, then, and only then, IndieAuth will let one of those social silos authenticate by standard oAuth to sign the user into their Woodwind account. Doing this also simultaneously gives Woodwind the ability to publish content (via the Micropub protocol) to the reader’s personal website.
This also means that the reader isn’t just a reader, it’s also a publishing interface! Is this starting to sound like a dis-aggregated social media service? You bet it does.
The Woodwind reader also has several settings options to allow people to choose which way they would prefer to publish to their personal website, the three ways are enumerated below.
Woodwind has a built in Micropub client that allows the user to like, repost, or reply to posts within the reader. One can authenticate their Micropub endpoint with the reader which then stores the publishing credentials and allows the user to react to any posts within the reader with these actions. The reader then posts to the user’s personal website with the intended actions. It’s then up to the user’s personal website to send Webmentions to the original post to notify them of the comment, repost, or like intents, which that site can then choose to display.
Woodwind also supports indie-config to allow a broad array of post types including likes, favorites, replies, reposts, and bookmarks.
Now for the practical usage from within the reader. To better illustrate what’s happening, let’s look at a typical view from within the reader.
One will notice that each of the three posts in this reader view, based on the chosen publish settings above, has a variety of buttons underneath. I can choose to reply, like, repost, bookmark, or simply share these posts directly from the reader’s interface. The resulting action will be posted directly to my own website where I’ll own it in perpetuity.
My site will then be responsible for sending a Webmention to the original post and notifying it of my reaction or interaction with it. The original post can then make its own choice to show my comment or interaction with it like a traditional comment.
By supporting Micropub, indie-config, and/or action URLs, current feed readers can make it far easier for people on the open web to not only read content the way they currently do on siloed social media services like Facebook, Twitter, Instagram, et al. Increased ease-of-use to allow these functionalities with beautiful user interface will help to move users out of walled-gardens where they’re trapped into the larger universe of the free and open internet.
Individuals with their own websites can support the acceptance of these posts to save their interactions with what they’ve read, be they comments, likes, bookmarks, or other interactions. They can also close the loop by supporting Webmentions so that their comments can be sent to (and potentially displayed) on others’ websites.
All of these pieces combined make for a more open and democratic web. Ideally the increased competition will prod current social silos to open up and compete on a more even playing field in which they’re supporting these open protocols as well. Then anyone with a web presence can use it to communicate from one website to another (or one permalink URL to any other permalink URL) on the internet, in a way that’s as simple and easy as any of the methods that’s currently available in the closed social spectrum.