anders conbere wrote:
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.
Yes we've talked about this for a while -- e.g., your "XSF" group is maintained by the Secretary of the XSF, your "Tiddlywinks" group is maintained by your tiddlywinks club, etc. But we've never quite finished defining how that would work. A beginning is here:
http://www.xmpp.org/extensions/inbox/communities.html /psa
smime.p7s
Description: S/MIME Cryptographic Signature
