Re: [Social] Federated PubSub

[Joe Cascio, Jr.]

I tend to agree most with Pedro Melo in the sense that XMPP can simply be
the transport mechanism and that the "higher" functions, if you will, of
authorizing and subsetting followers can be done in an enclosing layer.

This has several benefits, including being able to gang or parallelize
(yeah, that's not a word :) xmpp servers to distribute load from power-users
and popular sites or to provide transparent back-up if your main XMPP server
goes down.

I think it's inadvisable to look at microblogging as only what XMPP
provides, for instance using xmpp resources as the user-visible identities.

JoeC

[Adam Pisoni]

When I think about the future world of federated social networks I
definitely see XMPP as only one component and do not look it to solve
all authentication/authorization/transport issues. That said, XMPP
has this built in 'roster' piece that is hard not to see as a
federated replacement of the per social network buddy list. The
problem is that this buddy list wasn't meant to be a decentralized
buddy list so the issues I bring up of authorization haven't been
worked out. Unless we're saying people should not be thinking of
rosters as controlled buddy lists.

> But neither servers support OAuth. So real life: right now, flickr
> would host the pubsub nodes and could use the friends and family
> settings plus the connections he already has to keep the whitelist.

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.

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?

Thanks,
adam


On Jul 9, 2008, at 4:18 AM, Joe Cascio, Jr. wrote:

> I tend to agree most with Pedro Melo in the sense that XMPP can
> simply be the transport mechanism and that the "higher" functions,
> if you will, of authorizing and subsetting followers can be done in
> an enclosing layer.
>
> This has several benefits, including being able to gang or
> parallelize (yeah, that's not a word :) xmpp servers to distribute
> load from power-users and popular sites or to provide transparent
> back-up if your main XMPP server goes down.
>
> I think it's inadvisable to look at microblogging as only what XMPP
> provides, for instance using xmpp resources as the user-visible
> identities.
>
> JoeC

[Blaine Cook]

On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <apisoni (AT) geni (DOT) com> 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).

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.

[Adam Pisoni]

> 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.

Right this solves who can subscribe to KNOW ABOUT my flickr stream,
but that list of people is fundamentally the same as those I want
permission to SEE those pictures. It's a shame I have to maintain
those lists separately. I agree that in many places you want those
permissions to be separate, but in practice, non-power users don't
want to maintain many different sets of permissions. ie, most of us
only have one group we think of as our family. OpenSocial and other
such (ill conceived efforts) are trying to solve this very issue
precisely because it is so obvious.

thanks,
adam

[anders conbere]

On Wed, Jul 9, 2008 at 10:25 AM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
> On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <apisoni (AT) geni (DOT) com> 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.
>

[Adam Pisoni]

>
> 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.
>

This is a really interesting idea actually.... and is very much in
line with the 'federation' part of this discussion. You may have
users only on facebook, or on other services all mangled together in
your roster by allowing there to be relationships between 'rosters' on
different networks within your roster. A FB ID can easily be an
alias for a JID in your roster. I'm not sure how this all really
plays out, but it is an interesting line of thought. Either way,
people will be looking for solutions to this problem and it can't hurt
to have ideas on the matter.

adam

[Peter Saint-Andre]

anders conbere wrote:
> On Wed, Jul 9, 2008 at 10:25 AM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
>> On Wed, Jul 9, 2008 at 9:32 AM, Adam Pisoni <apisoni (AT) geni (DOT) com> 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

[Dan Brickley]

Ah, v interesting! Hadn't seen that before...

Dan

[Dan Brickley]

re http://www.xmpp.org/extensions/inbox/communities.html

Dan Brickley wrote:
> Ah, v interesting! Hadn't seen that before...

Well that exciting gem was intended just for Peter. So much for not
checking the To: field of my outgoing mails. Ahem.

Cool stuff though, really!
Dan

[Peter Saint-Andre]

Dan Brickley wrote:
> Ah, v interesting! Hadn't seen that before...

Yeah, it's never made it out of "pre-XEP". Perhaps the discussions at
the XMPP Summit 10 days from now will inspire us to publish this as a
real XEP.

/psa

[Peter Saint-Andre]

Dan Brickley wrote:
>
> re http://www.xmpp.org/extensions/inbox/communities.html
>
> Dan Brickley wrote:
>> Ah, v interesting! Hadn't seen that before...
>
> Well that exciting gem was intended just for Peter. So much for not
> checking the To: field of my outgoing mails. Ahem.
>
> Cool stuff though, really!

Oh yeah sorry about that, we typically deploy the evil reply-to-list
feature on the jabber.org/xmpp.org lists. ;-)

/psa

[Adam Pisoni]

I can see a lot of ways this pre-xep along with XEP-0060 can answer a
lot of the questions people will have as to how to do exactly the
kinds of things I was asking about. A combination of personalized
groups, authorization, pubsub nodes, and oath type handshakes to allow
3rd party access or authentication against.

adam


On Jul 10, 2008, at 1:10 PM, Peter Saint-Andre wrote:

> Dan Brickley wrote:
>> re http://www.xmpp.org/extensions/inbox/communities.html
>> Dan Brickley wrote:
>>> Ah, v interesting! Hadn't seen that before...
>> Well that exciting gem was intended just for Peter. So much for not
>> checking the To: field of my outgoing mails. Ahem.
>> Cool stuff though, really!
>
> Oh yeah sorry about that, we typically deploy the evil reply-to-list
> feature on the jabber.org/xmpp.org lists. ;-)
>
> /psa
>

[Peter Saint-Andre]

Adam Pisoni wrote:
> I can see a lot of ways this pre-xep along with XEP-0060 can answer a
> lot of the questions people will have as to how to do exactly the kinds
> of things I was asking about. A combination of personalized groups,
> authorization, pubsub nodes, and oath type handshakes to allow 3rd party
> access or authentication against.

Sounds like a good topic for discussion at the XMPP Summit. :)

/psa