On Wed, Jul 9, 2008 at 10:25 AM, Blaine Cook <[EMAIL PROTECTED]> wrote: > On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <[EMAIL PROTECTED]> wrote: >> >> This is what I thought at first, but I'm trying to think ahead towards a >> time when I don't have to maintain buddy lists and permissions on each >> social network. > > I think that each social network is different; the permissions I grant > people on my Flickr account are fundamentally different than those that I > grant on LinkedIn, which are again different from my Twitter account, and my > blog doesn't have any permissions at all. I like it that way, and I don't > actually want Flickr to know who I've approved on LinkedIn and vice-versa. > My IM buddy list is entirely different, and actually differs from IM network > to IM network, and account to account (i.e., I have multiple IM rosters).
I've always called this "Contexts", and while right now the roster doesn't have the tools to allow this kind of parceling of items, I think it's totally reasonable to imagine being able to delegate responsibility to portions of ones roster to a 3rd party, safely while maintaining the semblance of the roster. You can almost imagine using transports to do this right now (register with the linkedin transport and it injects the linkedin buddy list into your roster and now we can grant access to those entities). But I think there might be a reasonable case for having first class support for this kind of stuff. ~ Anders > >> Another idea which avoids Flickr needing permission to auth against my >> buddy list is somehow to let Flickr auth against the node itself. ie. I >> have authorized specific people to sub from a particular node and given >> Flickr affiliate permissions to publish to that node, but I've also given >> Flickr permission to authorize people against those authorized to access >> that node. This actually solves a number of problems (though I know there >> is currently no way of doing this). Makes sense though right? > > Another way to think about it would be to have your central PubSub server > (e.g., adampisoni.com) subscribe to Flickr, and essentially act as a proxy > --- you give yourself permissions to your entire Flickr stream, and then > choose who gets permissions based on your central roster. I still think the > caveat above applies, though. > > b. >
