So, I’ve been thinking for awhile about the aggregator experience I want to have for reading my blogs and microblogs. As I’ve increasingly been moving to my own infrastructure for both, my subscription experience has been evolving as well. Right now I have a rather hacky script polling the Twitter and Identi.ca APIs every 2 minutes, putting the content into my WordPress database, and exposing that information over a partial implementation of the Twitter API. I then use a ruby script that polls said Twitter API and sends the messages to me over XMPP (as well as allowing me to post to my self-hosted microblog). I read other feeds using newsbeuter.

This entire setup is a bit suboptimal. Why, for example, is my server polling and then storing content I am subscribed to? Isn’t that normally my aggregator’s job? I’ve realised, that the reason the model has evolved this way elsewhere (such as at status.net) is that in many microblogging services, the service acts as both publisher and aggregator, but this is sort of artificial. My server has no good reason to act as an aggregator, that function is not related to publishing my content.

I thus intend to build a better aggregator infrastructure. My current thought is to build some sort of modular system with data sources and sinks. The primary sources (to start) will be RSS/ATOM feeds and maybe Twitter compatible APIs. On top of this can be built a nice web-feed-reader infrastructure (like Bloglines was), which should support PubSubHubBub for its subscriptions (since it lives on a server asnyway), or an XMPP feed-delivery system (which just connects, delivers the content, and disconnects), or an ncurses or other GUI system for local use.

The system also needs to support replies (via Salmon or Trackback/Pingback) and also cross-posting of said replies (using Twitter-compatible or WordPress-compatible APIs). The public key that goes with the private key the aggregator is using to sign the Salmon slaps needs to be publicly discoverable somewhere (likely at your publishing point), but otherwise the aggregator doesn’t need any kind of public or always-on presence.

So, finally someone talking about the future of distributed social networking. The tech and the connecty bits we want have really been mostly there for some time now, the problem is, no one has been very clear on what the next step is. Chris Messina has been a bit distracted with the Activity Streams project, and no one else has really been saying much about DiSo.

The next step, however, is really coherent UI. I’ve been talking about it off and on as my “ultimate aggregator”, Marc Canter is calling it “dashboards”.

One of the things he talks about in the presentation is “distributed friending”. This is something I’ve brought up before. IMHO, the best way to go about this is to have magical buttons that, when clicked, take the user to their “dashboard” with the target’s URI (or one of them, anyway) already filled in. At that point, you have an asynchronous friending model. The local software can then do different things (like permissions, autofilling searches, pulling in content, just making the list available to other services than then do these things, whatever) based on this data, but no magical “protocol” or anything is needed, because with an asynchronous model all you’re really doing is making a note of the relationship in a data model and letting the software use that list for whatever.

Past integrating the posting/following/aggregation UI a bit more, I’m not really sure there’s anything left, conceptually. I’d like to dig up some code and make OAuth+AtomPub work for sure with the newest version (so that any aggregator can talk to my WP blog 🙂 ), and code can always be improved, but really, what is a social network? It’s an aggregator of sorts, a posting mechanism of sorts, and email. We’ve had the later two for ages, which is why so much work has been dancing around the first one.

I want a feedreader that is also a mublog client and an activity stream aggregator. That is, like Bloglines+Socialthing+Tweetdeck, as a desktop app.

Content could be categorized (automatically, by source, or by metadata from the source) as “short” (like twitter/del.icio.us/notifications), “medium” (like tumblog-style stuff, or content from backtype), and “long” (blog posts etc), as well as by any actual categories/tags on the content (including hashtags on tweets, etc), and by source.

The left pane could let you filter by only certain categories (select one or more sources/categories/lengths, union each kind and then intersect, ala (source1 union source2) intersect (category1 union category2) intersect (length) ). Each kind of category would be separated by a line or something, with lengths at the top (there’s just three), then sources, then categories. Unread counts next to all of them.

Right pane in river-of-news (or, more like tweetdeck) style. Style should be smartly selected based on item. Tweets/mublog posts should link the username, @replies and #hashtags, etc, and show the avatar. Feeds with mediaRSS show thumbnail lieu of avatar. Feeds with a feed image show that. Otherwise, show favicon. Keep all items the same size, with snippets, etc, and click/otherwise select to expand.

Action links associated with each kind of data. Comment links for feeds with a <comments> tag on items, “show comments” for ones with wfw:commentRSS, long-term it’s be great to post a comment from the feedreader. “favourite”/”reply”, etc for the mublog, “bookmark too” for del.icio.us, etc.

Allow the user to associate multiple authors together (also try to do automatically) and maybe assign an avatar if there isn’t one: so that all of one person’s content displays and archives in a consistent fashion.

*Keep archives*! Make it easy to search through, or browse through, read content by category/author/source. Allow the user to file content under custom categories.

Have awesome keyboard shortcuts. j/k/space/enter/n/d… check out gmail/greader/mutt/trn for inspiration.

Be modular. Don’t just hardcode all the services/formats you want to support: take a hint from libpurple and others and just make *everything a plugin*. That way I can have NNTP support and you don’t have to care.

Support feed:// … I know it never took off, but supporting it isn’t hard and may yet prove useful.

Provide sane import/export of all data.

Provide posting support. In the plugins that implement it, of course. This means being able to update my mublog, bookmark to del.icio.us, etc 🙂

*Be portable*! It’s really not that hard to do 80% of your work in a cross-platform manner, so just do it already! Use a cross-platform GUI framework for your initial GUI and add native UI plugins for some platforms (looking at you, Apple fanboi’s) later.

Would I pay for this? Yes. I mean, it would have to be libre software (I’m not going to pay you to restrict my freedom!), but I would pay quite a bit for something like this. I dunno, if I were to pick a number, $40? Something like that. If I don’t figure it out and write it myself. GUI programming is not exactly my strong suit, but I’m playing around with it.

Some significant improvements to my ActionStream plugin. The plugin can always be downloaded from that page.  The changes are:

1. Bugfix in how some feeds were handled (notably google reader)
2. If nicknames are being displayed, they are hcards with links to your profile at that service
3.  Including updates from your own blog is now optional
4. There is now an option to remove services you have added
5. Collapsed (5 more… et al) nodes may now be expanded on link click

It seems that another feedreading project is recognising XOXO! According to this post Plagger has, if I understand correctly, added the ability to import subscriptions from an XOXO reading list and also to export that as OPML. Not recognising XOXO enough to provide an export mechanism for it yet, but a step forward nevertheless!