Martin Atkins (mart) wrote in apparentlymart,
Martin Atkins

Using RSS for Activity Streams: Analysis

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?


  • The next evolution for OpenID?

    This morning at IIW Dick Hardt presented his vision for solving the issue whereby a user is dependent on his OpenID provider being up and non-evil.…

  • HTML 5 vs. Yadis

    One of the ways that the Yadis specification allows for the XRDS document location to be declared is via the X-XRDS-Location header embedded via a…

  • Client Certificates: It's easy, man! recently added support for logging in with client certificates. I've heard people talking about client certificates lots of times, but…

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.