This blog can't be viewed on LiveJournal. Instead see http://www.apparently.me.uk/14977.html.

Action aggregators and the proxy problem

14th May 2008

There's lots of talk right now about aggregating action streams to provide a single stream of "what are my friends doing?". You can see this on Facebook's news feed and on Plaxo Pulse. The current state of the art on this is simply aggregating the content in a bunch of public RSS or Atom feeds, but there's clear interest in being able to aggregate non-public content: if the owner allows me to see it on the originating site, why can't I see it in my friend stream?

A solution that's been banded around for this is to use OAuth to fetch the RSS or Atom feeds, thus allowing the content owner to give the aggregating site (e.g. Plaxo Pulse) the ability to see the non-public items. The problem with this approach is that we're asking the wrong user; I want to view an aggregated version of all of the things that my friends would like me to be able to see on the web, but for this purpose a web-based aggregator like Plaxo Pulse doesn't work because while I have permission to view my friend's private blog on Vox, Plaxo does not. My friend is not a Plaxo user, nor does she have any business or trust relationship with Plaxo, and nor should she have to.

My gut feeling on this is that aggregators must therefore be implemented at least partially client-side, in a client that I control on a computer that I control. This simplifies things considerably: now I can authenticate to my friend's RSS and Atom feeds directly. You can imagine middle-road alternatives where the web-based aggregator just recieves encrypted, opaque blobs that can be decrypted client-side using a keypair that was set up separately, but I think that's still more than we can expect from today's browsers, and would be difficult to explain to users.

I think the most important thing to remember is that "just use OAuth" is not the answer to this problem. We've still got plenty of work to do.

Comments

  • Permission for Plaxo

    OAuth requires Plaxo to identify itself as the agent for the user, allowing Vox to make a decision about what to expose to Plaxo. Note that the situation is same with a piece of client software, assuming that it can also talk to its home server and isn't fully locked down with a locally generated private/public key pair -- end users are using agents in any case, and the full DRM solution just isn't viable. So OAuth enables realistic solutions revolving around what agents to trust and how much. Requiring opt-in from the affected friends is also a possibility in this model.
    By ext_99907 at 09:04 pm on 14th May 2008
    • Re: Permission for Plaxo

      I suppose you are right about the agent thing, but I tend to trust software on my own computer more than I trust web apps. I give software on my computer my passwords all the time, but I won't (for example) give my Hotmail password to Plaxo.

      I suppose an interation model that could work would be for the consuming user to send a subscription request (via the aggregator app, e.g. Plaxo) which the publishing user would acknowledge, thus giving permission for Plaxo to fetch events. Once you're sending subscription requests it's not much of a leap to use a push model rather than a polling model. I wonder if it would be best to push all of a user's events into a single "eventing provider" and have friends subscribe via that provider; this has the advantage that our publishing user only has to deal with one permissions UI. This sounds somewhat like what was discussed in Dick's IIW session on Monday morning.

      By Martin Atkins at 11:04 pm on 14th May 2008