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.

I mantain wp-diso-actionstream, a plugin heavily inspired by MT Action Streams.

Early on, one of the things that made these two plugins so cool is that they share a config file format.  It’s YAML, which I’m not a fan of, but there was one big advantage to using it when I started: I was guaranteed someone would be interoperable with me, because I was using their format.

I’ve changed that YAML file quite a bit, but I’ve not added many “extensions” because I want MT Action Streams, at any moment, to be able to take the extra sources I’ve described and add them in.

There are essentially two parts to describing any source.

profile_services:

Yes, that’s the highest-level YAML heading for the first part.  Underneath is a list of simple hashes, described like so:
This is relatively straightforward. The source_identifier is a unique string (it must match what is used in the next part) identifying the source.  The name is a human-readable label for the source.  The url is a template for the profile URL, with %s where the user identifier goes. At this point you really have all you need.  With a service identifier and user identifier you can contruct a URL, and vice-versa.  There are three optional parameters that help make the UI nicer looking.   ident_label provides the human-readable string users would be used to seeing associated with this particular identifier (ie, Username, Screenname, etc).   ident_example is an example identifier (I usually use my own username on the service in question).  ident_suffix is any text a user might be used to seeing come after the username (such as .myopenid.com). This first part is relatively uncontroversial.  There are rarely multiple ways to map a user and service to a profile URL.  Ideally, I would love to see services hosting this YAML fragment somewhere and making it discoverable in some standard way (whether <link> tag or YADIS).

action_streams:

This section varies a bit more, since not everyone will agree on the right place to get data from, what data needs to be parsed, or how it should be output in an actionstream. Here is an example description:

The high-level identifier (here, twitter:) must match the source_identifier from the previous section.  Because one profile can have multiple sources of actions associated with it (for example, tweets and favourites), there is another lever of nesting where you give the identifier for the content type.  This is currently pretty arbitrary, but I’d like to see it move towards being the “standard” activity verb.

The name is the human readable label for the kind of content in this stream.  Description is more optional human-reabable information about the data.

html_form is any XHTML, with [_1] being replaced by the action owner, [_2], etc, being replaced with the n+1st field from html_params.

url is the URL to get the stream content from.  If not present it is assumed to be the profile URL. RSS/ATOM feeds can be detected on this endpoint if the content to be parsed is such a feed.  {{ident}} here is the same as %s in profile_services. I would like to deprecate this and switch to %s everywhere in a future version.

The final parameter describes how the data is to be parsed.  You may use atom:, rss2:, or xpath:.  RSS/ATOM feeds automatically have fields for their most popular elements (title, created_at). Any extra fields you wish are given a name and an XPath expression to use in parsing.  A more complete discussion of these field names, ones currently being used, and how I would like to see this progress can be found in this pastebin.

Moving Ahead

If the above two YAML snippets were made available by most sites with actionstream content, then the plugin could easily provide a nice set of defaults that kept themselves in sync with site evolution.  Users could override anything locally, of course.

There is one thing that neither of these describe, however: private items.  While a feed could be protected by OAuth, and the plugin could then authorize to pull in the data, this seems like going about it the wrong way around.  I’d really like to see some way of telling a site: “push my activity over there” and having it discover and hit a callback with the activity data.

I have just pushed wp-diso-actionstream version 0.50 out. You can download it from the usual place.

Changes

• Changed byline to “DiSo Development Team” to reflect all the contributions by Will Norris (more specific contributors in LICENSE file)
• actionstream_services filter as the way developers add custom service definitions
• Better YouTube support
• Support for many new services: userscripts.org, brightkite, getsatisfaction, backtype, github, and twitter favourites
• Sidebar widgets (actionstream and services list)
• Template tag for services list
• Nicer RSS feed URLs
• Some major refactoring
• Integration with new permissions plugin
• Intelligence in service display when wp-diso-profile is installed

I have updated wp-diso-actionstream to 0.45, changes include:

• Fully tested WP2.5 support
• Fixes for Last.fm support
• Better microformats output

I have updated two of my DiSo plugins: Profile and ActionStream.

The profile updates mostly involve some code cleanup, a page here documenting it, and a new API to add permissions options to the permissions page.

The ActionStream update is a bit more extensive:

• Support for coComment
• Code cleanup, of course
• RSS2 output option, linked from the stream output (add &full for a different view)
• Reportedly working in WP2.5 with a patch I accepted
• Better Safari support
• If you disable showing your service usernames they are also hidden in the collapsed items
• Abitily to set permissions on updates from each service (if wp-diso-profile0.25 is installed)