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.
3 comments:
George, you write
"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."
Doesn't this presumes that the identity of your friend (me perhaps :-)) is passed in the call?
How do you see
a) the Consumer getting this identifier
b) you specifying permissions against the identifier
thanks
Paul
Nice writeup George. We've been looking at XRDS Simple for discovery stuff. I'm always on the fence WRT discovery models though (WSDL anyone?).
Gnip is trying to feed these "activity" aggregators, and so far we're happy w/ the results.
Let me know if you ever want a demo or help walking through things.
I hope all is well!
Paul, I think the key is that if you want to have your SocialStream collector subscribe to my activity collector, then you need an identifier for me that can be used to discover my activity collector.
I can envision your SocialStream collector using your Portable Contacts service to retrieve that identifier, so that your user experience is just picking my entry from your Portable Contacts list.
It does presume that your Portable Contacts entry for me has an identifier (e.g. an OpenID) that can be used for discovering my services.
Post a Comment