This blog can't be viewed on LiveJournal. Instead see

Using RSS for Activity Streams: Analysis

16th Dec 2008

I've been thinking some more and talking a bit with folks about whether Activity Streams should be in RSS or Atom. I did get some feedback saying that both should be supported, but I'm not sure I really want to create two different ways to publish/consume activity data. Here are some advantages of each...

First the advantages of switching to RSS:

  • We don't have to invent a new way to represent media objects.
  • Almost all sites publish RSS, in some cases exclusively. (So in order to publish an activity stream, they'd need to build out an extra feed endpoint.)
  • Sites that don't currently publish Atom would need to add an additional autodiscovery link, which may confuse aggregators and complicates the UI for feed subscription in browsers.

But here are the advantages of staying with Atom:

  • Its core elements are in an XML namespace, which makes it easier/nicer to include inside weird containers like XMPP stanzas.
  • We can use atom:source to deal (to a certain extent) with activity aggregation feeds such as the Atom feeds that FriendFeed publishes. No such concept exists in RSS.
  • We don't have to deal with the complexities and ambiguities of Media RSS. (In other words, we can decide on something sensible without being constrained by existing practice.)
  • The Atom schema and data model is much better defined than RSS. (Though lots of software just treats Atom as a funny serialization of RSS, so this benefit doesn't really manifest in practice.)

Here's where my head is at right now: the concept of "object feeds" in the AtomActivity spec could in theory be adapted to map onto RSS without many changes. Therefore we could include a section in AtomActivity for how to construct the "implied activity" for an RSS item much like we currently describe how to construct the same for a non-action Atom entry. The concept of "activity entries" is more complicated to adapt to RSS due to its re-use of Atom elements, but given that there are currently only a few implementations that contain something resembling "activity entries", so hopefully we can get them to converge on Atom for this.

What this means in practice is that sites publishing feeds of objects can take their existing feeds, whether Atom or RSS, and add the activity:verb and activity:object-type annotations, and be done. Sites publishing feeds of activities (FriendFeed, Plaxo, Movable Type Action Streams, Wordpress Activity Streams, ...) would need to use Atom, because there would be no representation defined for this in RSS. Consumer libraries would need to support both RSS and Atom, but there would be a well-defined mapping for how to turn both sorts of object entries into Atom-based activity entries.

This would make Atom the primary format but there would be some limited (but well-defined) support for RSS. Does that seem reasonable to folks?


TPCThread 6a010535617444970b01053614336e970c