The Progressive (Profitable) Web

April 2, 2013 | 2 comments

Ryan Holiday laments the loss of Google Reader and RSS in general in Our Regressive Web, arguing that if someone came up with them today, we’d think they were brilliant ideas:

Nothing better has risen up to replace them. The underlying needs of a fairly large user base (that these services meet) still exist.

We’re just regressing.

[...] RSS is impervious to blogging’s worst, but most profitable traits. [...] No wonder nobody ever pushed for widespread adoption. Of course it died a slow death—along with Google Alerts and Delicious. Their mission is antithetical to the ethos of our new media age. Where noise, chatter and pushing—not pulling—rule the day.

Our Regressive Web by Ryan Holiday, on Medium

He’s right. Aggregated content – content on the reader’s terms – has a huge potential userbase, but it wasn’t profitable for either the bloggers or the aggregators, so it languished. Sure, you could tack some Google Ads onto the end of each post in a feed, but control over the form that the content is presented in is granted fully to the user. Where’s the opportunity to upsell? Where are the branding opportunities or the baked-in communities, carefully designed to maximize ongoing engagement?

The irony is that blogs have actually downgraded their on-page advertising over time. If you visit TechCrunch today, you’ll only see two ads above the fold. Check out io9, and you’ll see none at all. The redesigned ReadWrite has a few more: a giant banner above the fold, and then four small squares with another ad in the stream of content itself.

Wouldn’t it be nice if you could have your cake and eat it, too? Allow the user to consume content on his or her terms, while also allowing the content producer to make money?

Here’s an idea I’ve been working on in my own time. It’s a little technical, but bear with me:

  1. Add a simple social layer to the web. I still like the idea of the HTTP header I described in httpID. Your site may connect to my site with a mechanism like OpenID Connect and get an authentication token automatically. Think of it like a one-way friend request. Of course, I can then reciprocate by connecting to your site to create a two-way relationship.
  2. Add authentication to feeds. Each feed has just one URL. An aggregator may sign the request for a feed with an OAuth-like signature. (We’re sidestepping HTTP digest auth for obvious reasons.) The software producing the feed may choose to acknowledge the signature, or not; by default, you get all the public posts you’d normally get when accessing a feed.
  3. Manage connections and restrict access to content. I see everyone who’s connected to me from a control panel, and can reciprocate from there. More importantly, I can add any of my connections to access groups. So if I add you to a group and publish a piece of content so that it is only accessible by that group, when your site requests my feed using a signed request, you’ll see that content.
  4. Optionally: sell access to premium content. Once you can selectively broadcast content to a finite group of people, you can sell access to that group. (And of course, you can have more than one paid-access group.) For example, I’m a subscriber to NSFW, a paid publication with an online presence. They could push all their articles to me as a subscriber, while making a handful of taster articles available to everyone. You could even include a pointer to a subscription URL within that social handshake from part 1. If you decentralize the financial transactions (and why not?), you could even give a small cut to the platform owner.

All of the above is complementary to feed standards like RSS and Activity Streams, as well as to federated social web protocols and methodologies like OStatus. It’s super simple to both use and implement – but could add a layer of commerce to the content web, while also decreasing our dependence on large content silos whose interests are not in line with their customers.

Google Reader is dead

March 13, 2013 | 8 comments

Google Reader was a tentpole of the web I wanted: open, with full freedom of expression that wasn’t tethered to the platform you happened to choose to use. That web is now, largely, gone. Reader will be discontinued this spring.

In the same announcement, Google are talking about killing the standardized CalDAV API in favor of a Google Calendar specific set of calls.

You mean to say we’re going to have to go back and build that web again? That sounds like a good thing to do.

(If you’re missing Google Reader as much as I am, The Old Reader is a worthy alternative.)

PubCasts: subscribe to publications through RSS

January 28, 2010 | 1 comment

This is inspired by the iBooks launch, but it’s applicable to any ereader that uses the ePub format. (Or, indeed, it could use any ebook format – MobiPocket, Kindle, DAISY, etc.)

A podcast is just an RSS feed with a file enclosure – part of the RSS standard – that points to an MP3 file. Similarly, video podcasts point to video files. An obvious evolution, then, is the pubcast: periodical publications delivered through RSS feeds.

Free publication subscriptions

In the free case, a user would simply subscribe to a public pubcast feed with a compatible reader. The reader software would check regularly for updates, and new publications would be downloaded and fed into the user’s ereader software on release. Easy.

Paid publication subscriptions

In the case of paid publications, there are two options:

An authenticated pubcast feed. When you subscribe to a publication, you get an address to an RSS feed that requires a username and password to download content. (Gmail is an example of an application which already does this.) This authentication ensures that only paid subscribers can access the file, but you could go a step further and watermark the publications themselves.

Activation within the ebook file. The RSS feed itself is public, but each downloaded publication could require an access code to read. This would open the door for public feeds of paid journals, where users could buy each issue individually to read.

Making subscriptions an open standard

Either way, this approach would allow any ereader using any compatible software solution to subscribe to periodicals. It could be used for newspapers, magazines, journals, zines, or new kinds of periodical; they could be hosted anywhere and, in the case of paid content, use any payment provider. I love reading, but dislike monopolies, so this is something I’d like to see.