It was really interesting to read the followup from Brent's post about synchronizing the user interface of RSS reading apps. Comments appeared on a bunch of blogs, and it's a fresh group of people, which is good to see. 

To be clear, I have developed a river-of-news RSS reader that's based on the same idea in the original aggregators I wrote, dating back to 1999. Only now the user interface is a jQuery app written by a community of developers who are fluent in this new environment. In my talk yesterday with Anderson of Couchbase, I got a much better idea of the variety of ways jQuery is being used. 

There's absolutely no doubt that the technology Brent was writing about was a blind alley. RSS has always been a great basis for a web app. I don't think it should be a desktop app. Brent illustrates that so clearly. That means there's a tradeoff, offline reading would work differently if you're using a web app for RSS. And that could be handled by the web browser. A simple function that says suck down all the pages linked to from my river and put them in the cache. I'm about to unplug. I don't see how the problem is any more complicated than that. (And I'd be surprised if this doesn't already exist in some browsers, and is on its way for the rest.) 

What we do need, however are two very important features that are easily provided, without requiring the creation of any new computer science.  

1. A central place to subscribe. This is why Twitter and Facebook beat RSS in simplicity. Because managing your subscriptions is a mess in RSS. To follow someone in Twitter means just clicking a button. It can be that easy in RSS. It just means that the developers have to give up control of the subscription list. Let that be something the user stores elsewhere, that you reference, and can write to, but do not own. 

How to develop that? I propose that a university or group of universities develop and run this system. If there's a consensus among developers, I have good contacts now, and can make more. Especially if I can show that there's a consensus among developers to cooperate. This is the kind of project that students can and should work on, imho. 

2. Really simple notification. RSS 2.0 provides for notification with the cloud element. I have built on this in my aggregator and content tools. It's the kind of thing that needs to be provided by many vendors. So far WordPress has supported it. We need to do better. To be clear, there are no patents on anything in the RSS 2.0 spec, including this feature.  

My goal is to create an open and distributed equivalent of Twitter that runs on lots of people's servers, and give up none of the ease-of-use and maybe just a bit of performance (there are some advantages of centralization). I don't want anything from Google at this time. But I do want to provide incentives to them to support open formats and protocols in a cooperative way in the future. I don't ever want to be in a position where to participate in a community you have to support an undocumented API that's implemented by a single vendor. I'm sure by now we all understand why that is too fragile a foundation to build on.