Friday, October 03, 2008

Subscribing to Activity streams

Yesterday Paul asked a good question about subscriptions and identifiers in this push model for activity. If we take an explicit use case regarding how Paul subscribes to George's activity feed, the key is that Paul has to have at least one identifier for George that can be used to discover his activity service.

Leveraging XRDS, OpenID, OAuth and Portable Contacts this should be doable. Here is a graphic and flow.



  1. Paul logs into his SocialStream collector (with his OpenID)
  2. The SocialStream collector discovers Paul's PortableContacts service (via XRDS)
  3. Paul authorizes his SocialSteam collector to access his's PortableContacts service (via OAuth)
  4. The SocialStream collector asks Paul if he wants to subscribe to any of his contact's activity feeds (retrieved from the Portable Contacts service)
  5. Paul selects his friend George
  6. The SocialStream collector uses the identifier(s) for George to discover George's activity service (via XRDS discovery)
  7. The SocialStream collector subscribes to George's activity service
    • If subscribing to a public feed, no other information is needed
    • If subscribing to a protected feed, then OAuth can be used to determine if Paul is allowed access to the feed
    • Membership determination can leverage Portable Contacts tags as described here


Thursday, October 02, 2008

MyActivity vs MySocialStream

The recent production announcement by Gnip, Inc got me thinking about activity and the push vs poll model for tracking activity. As I see it, there are two kinds of activity that I want to track: (1) my activity and (2) my "friends" activity. Hence the terms MyActivity and MySocialStream.

In a truly open and distributed web environment, I should be able to separate these functions into any providers I desire. Right now, most social networks combine both my activity and my friends activity into a single stream and service. Thus if this service wants to aggregate activity, it has to poll each of those external services for updates and then merge them into the activity stream.

An interesting aspect of Gnip, Inc's offering is that it will push updates, even filtered updated, to an endpoint. Push seems like a better model, especially if it can be "throttled" in some way (meaning, the service pushing the updates can be configured to combine multiple updates in a 5 min period into a single push event).

If we model my activity separately from my friends activity, then it should be possible to define an API for an activity service. This activity service would accept my activity events from across the web. This activity service would be discoverable via my XRDS document so that any site I visit can discovery my activity service and report activity to it. If my friends want to track my activity, they can subscribe to my activity service. This subscription mechanism could include the use of OAuth for subscription to restricted activities. Managing who is allowed to see which events could leverage Portable Contacts for group membership. This way, whenever I'm involved in some activity across the web, that activity will get reported to my activity service which in turn will push out the event to all friends that have subscribed.



As for all my friends and their activity that I would like to see, I just need to have MySocialStream service subscribe to their activity services. This data aggregation could be displayed in any venue; opensocial gadget, web page, iPhone app, etc.

All that's needed is the specifications for the APIs and the ability to list them in my XRDS. Well, a little more than that, but it's definitely more doable today than ever before.