[Social] Federated PubSub

[Adam Pisoni]

This topic has been covered before loosely, but I have some questions
I was hoping people could opine on as far as how they see the future
working out. I'm currently working on a messaging product which
relies heavily on XMPP and eventually PubSub. We're also looking at
PEP and other ways to consume/expose our data in a brave new PubSub
world of federated social networks. This has led to a lot of
interesting questions.

Imagine bob (AT) somejabberhost (DOT) com posts an image to flickr. Bob has
many friends who might be interested in that. In a PubSub world,
those friends would subscribe to a node somewhere which flickr would
publish to. Bob's friends would subscribe to that node. Here's
where the questions start. Do people imagine that node living on
flickr or on somejabberhost.com? There are benefits to both.
Imagine this particular node of Bob's is private. He only wants to
allow a subset of his roster to have permission to subscribe to that
node. Lets say, from Bob's point of view, he has a roster group
called Family who he wants to give permission to. If
somejabberhost.com hosts that node then it would be easy for Bob to
say he only wants his Family roster group to have access to his
images_stream node. He also would need a way of authorizing flickr to
publish to that node on his behalf (OAuth) Of course now Flickr
can't further authenticate users for Bob since flickr doesn't know or
have access to Bob's roster. Nor would Bob want flickr poking in his
roster.

We tried to imagine a scenario where Bob could give Flickr permission
(perhaps using OAuth) to authenticate people against his roster
(without flickr being able to read his roster fully). All of that
seems complicated though.

If Flickr keeps the node, then you have the same issues of Flickr not
having any knowledge of Bob's roster.

I know there may not be answers for these questions yet. I guess I'm
just wondering what people think logical solutions might be. Or maybe
there are answers.

Thanks,
adam

[Nathan Fritz]

It's simpler than that. You would "affiliate" Flickr's XMPP
bot/component/whatever as "publisher" to the node (
http://www.xmpp.org/extensions/xep-0060.html#owner-affiliations-modify). Of
course you don't want Flickr controlling your roster! And so if you want
Flickr to be able to control which JIDs are subscribed to this node (you
wouldn't want to do that, would you?), then you'd have to make flickr an
administrator of the node and use whitelist or authitication access models.
However, I wouldn't see any need for Flickr to control who subscribes to
this node and not, as it is your business.

On Tue, Jul 8, 2008 at 3:34 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:

> This topic has been covered before loosely, but I have some questions I was
> hoping people could opine on as far as how they see the future working out.
> I'm currently working on a messaging product which relies heavily on XMPP
> and eventually PubSub. We're also looking at PEP and other ways to
> consume/expose our data in a brave new PubSub world of federated social
> networks. This has led to a lot of interesting questions.
>
> Imagine bob (AT) somejabberhost (DOT) com posts an image to flickr. Bob has many
> friends who might be interested in that. In a PubSub world, those friends
> would subscribe to a node somewhere which flickr would publish to. Bob's
> friends would subscribe to that node. Here's where the questions start.
> Do people imagine that node living on flickr or on somejabberhost.com?
> There are benefits to both. Imagine this particular node of Bob's is
> private. He only wants to allow a subset of his roster to have permission
> to subscribe to that node. Lets say, from Bob's point of view, he has a
> roster group called Family who he wants to give permission to. If
> somejabberhost.com hosts that node then it would be easy for Bob to say he
> only wants his Family roster group to have access to his images_stream node.
> He also would need a way of authorizing flickr to publish to that node on
> his behalf (OAuth) Of course now Flickr can't further authenticate users
> for Bob since flickr doesn't know or have access to Bob's roster. Nor would
> Bob want flickr poking in his roster.
>
> We tried to imagine a scenario where Bob could give Flickr permission
> (perhaps using OAuth) to authenticate people against his roster (without
> flickr being able to read his roster fully). All of that seems complicated
> though.
>
> If Flickr keeps the node, then you have the same issues of Flickr not
> having any knowledge of Bob's roster.
>
> I know there may not be answers for these questions yet. I guess I'm just
> wondering what people think logical solutions might be. Or maybe there are
> answers.
>
> Thanks,
> adam
>
>

[Nick Vidal]

Hi,

Adam Pisoni wrote:
>> He also would need a way of authorizing flickr to publish to that node on
>> his behalf (OAuth)

For this, Nathan's response is perfect:

> It's simpler than that. You would "affiliate" Flickr's XMPP
> bot/component/whatever as "publisher" to the node

Much simpler indeed. This skips OAuth entirely. XMPP controls your
roster, your nodes, and who has access to these (read/write
privileges).

However, if the photos are hosted in Flickr *and* you want to restrict
this access to some groups, then you have to delegate access control
to Flickr some way. In this case, OAuth would be recommend.

Best regards,
Nick

On Tue, Jul 8, 2008 at 8:24 PM, Nathan Fritz <nathanfritz (AT) gmail (DOT) com> wrote:
> It's simpler than that. You would "affiliate" Flickr's XMPP
> bot/component/whatever as "publisher" to the node
> (http://www.xmpp.org/extensions/xep-0060.html#owner-affiliations-modify).
> Of course you don't want Flickr controlling your roster! And so if you want
> Flickr to be able to control which JIDs are subscribed to this node (you
> wouldn't want to do that, would you?), then you'd have to make flickr an
> administrator of the node and use whitelist or authitication access models.
> However, I wouldn't see any need for Flickr to control who subscribes to
> this node and not, as it is your business.
>
> On Tue, Jul 8, 2008 at 3:34 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
>>
>> This topic has been covered before loosely, but I have some questions I
>> was hoping people could opine on as far as how they see the future working
>> out. I'm currently working on a messaging product which relies heavily on
>> XMPP and eventually PubSub. We're also looking at PEP and other ways to
>> consume/expose our data in a brave new PubSub world of federated social
>> networks. This has led to a lot of interesting questions.
>>
>> Imagine bob (AT) somejabberhost (DOT) com posts an image to flickr. Bob has many
>> friends who might be interested in that. In a PubSub world, those friends
>> would subscribe to a node somewhere which flickr would publish to. Bob's
>> friends would subscribe to that node. Here's where the questions start.
>> Do people imagine that node living on flickr or on somejabberhost.com?
>> There are benefits to both. Imagine this particular node of Bob's is
>> private. He only wants to allow a subset of his roster to have permission
>> to subscribe to that node. Lets say, from Bob's point of view, he has a
>> roster group called Family who he wants to give permission to. If
>> somejabberhost.com hosts that node then it would be easy for Bob to say he
>> only wants his Family roster group to have access to his images_stream node.
>> He also would need a way of authorizing flickr to publish to that node on
>> his behalf (OAuth) Of course now Flickr can't further authenticate users
>> for Bob since flickr doesn't know or have access to Bob's roster. Nor would
>> Bob want flickr poking in his roster.
>>
>> We tried to imagine a scenario where Bob could give Flickr permission
>> (perhaps using OAuth) to authenticate people against his roster (without
>> flickr being able to read his roster fully). All of that seems complicated
>> though.
>>
>> If Flickr keeps the node, then you have the same issues of Flickr not
>> having any knowledge of Bob's roster.
>>
>> I know there may not be answers for these questions yet. I guess I'm just
>> wondering what people think logical solutions might be. Or maybe there are
>> answers.
>>
>> Thanks,
>> adam
>>
>
>

[Adam Pisoni]

>
> Much simpler indeed. This skips OAuth entirely. XMPP controls your
> roster, your nodes, and who has access to these (read/write
> privileges).
>
> However, if the photos are hosted in Flickr *and* you want to restrict
> this access to some groups, then you have to delegate access control
> to Flickr some way. In this case, OAuth would be recommend.

Right, but I don't believe there's a mechanism for this. Really what
I'm saying is, I have a roster group and only want those JIDs to have
access, but I also don't want to give Flickr access to my roster. So
I want to use something like OAuth to allow flickr to authenticate
against my roster somehow without being able to read my roster.
This is more than just allowing Flickr to publish to some node, this
is further authenticating ON the flickr site based on my roster.

I take it from the this and the prior post that the expectation is
that pubsub nodes are hosted by the server controlling the JID that
owns the node, which makes sense.

thanks,
Adam



>
>
> Best regards,
> Nick
>
> On Tue, Jul 8, 2008 at 8:24 PM, Nathan Fritz <nathanfritz (AT) gmail (DOT) com>
> wrote:
>> It's simpler than that. You would "affiliate" Flickr's XMPP
>> bot/component/whatever as "publisher" to the node
>> (http://www.xmpp.org/extensions/xep-0060.html#owner-affiliations-modify
>> ).
>> Of course you don't want Flickr controlling your roster! And so if
>> you want
>> Flickr to be able to control which JIDs are subscribed to this node
>> (you
>> wouldn't want to do that, would you?), then you'd have to make
>> flickr an
>> administrator of the node and use whitelist or authitication access
>> models.
>> However, I wouldn't see any need for Flickr to control who
>> subscribes to
>> this node and not, as it is your business.
>>
>> On Tue, Jul 8, 2008 at 3:34 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
>>>
>>> This topic has been covered before loosely, but I have some
>>> questions I
>>> was hoping people could opine on as far as how they see the future
>>> working
>>> out. I'm currently working on a messaging product which relies
>>> heavily on
>>> XMPP and eventually PubSub. We're also looking at PEP and other
>>> ways to
>>> consume/expose our data in a brave new PubSub world of federated
>>> social
>>> networks. This has led to a lot of interesting questions.
>>>
>>> Imagine bob (AT) somejabberhost (DOT) com posts an image to flickr. Bob
>>> has many
>>> friends who might be interested in that. In a PubSub world, those
>>> friends
>>> would subscribe to a node somewhere which flickr would publish
>>> to. Bob's
>>> friends would subscribe to that node. Here's where the questions
>>> start.
>>> Do people imagine that node living on flickr or on
>>> somejabberhost.com?
>>> There are benefits to both. Imagine this particular node of
>>> Bob's is
>>> private. He only wants to allow a subset of his roster to have
>>> permission
>>> to subscribe to that node. Lets say, from Bob's point of view,
>>> he has a
>>> roster group called Family who he wants to give permission to. If
>>> somejabberhost.com hosts that node then it would be easy for Bob
>>> to say he
>>> only wants his Family roster group to have access to his
>>> images_stream node.
>>> He also would need a way of authorizing flickr to publish to that
>>> node on
>>> his behalf (OAuth) Of course now Flickr can't further
>>> authenticate users
>>> for Bob since flickr doesn't know or have access to Bob's roster.
>>> Nor would
>>> Bob want flickr poking in his roster.
>>>
>>> We tried to imagine a scenario where Bob could give Flickr
>>> permission
>>> (perhaps using OAuth) to authenticate people against his roster
>>> (without
>>> flickr being able to read his roster fully). All of that seems
>>> complicated
>>> though.
>>>
>>> If Flickr keeps the node, then you have the same issues of Flickr
>>> not
>>> having any knowledge of Bob's roster.
>>>
>>> I know there may not be answers for these questions yet. I guess
>>> I'm just
>>> wondering what people think logical solutions might be. Or maybe
>>> there are
>>> answers.
>>>
>>> Thanks,
>>> adam
>>>
>>
>>

[Pedro Melo]

On Jul 9, 2008, at 1:41 AM, Nick Vidal wrote:

> Hi,
>
> Adam Pisoni wrote:
>>> He also would need a way of authorizing flickr to publish to that
>>> node on
>>> his behalf (OAuth)
>
> For this, Nathan's response is perfect:
>
>> It's simpler than that. You would "affiliate" Flickr's XMPP
>> bot/component/whatever as "publisher" to the node
>
> Much simpler indeed. This skips OAuth entirely. XMPP controls your
> roster, your nodes, and who has access to these (read/write
> privileges).

Actually, OAuth can have its place. You can use OAuth as the protocol
Flickr and the user use to accept Flickr JID as a publisher to your
node. The OAuth component on your jabber server would then add flickr
jid as a publisher of your node.

So OAuth used on the intereaction between Flickr and user, classical
XMPP pubsub to do the enforcing. I think this will probably be the
easier first because right now I don't know many clients that support
control over pubsub nodes.

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.

Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo (AT) simplicidade (DOT) org
Use XMPP!

[Alexander Gnauck]

> I take it from the this and the prior post that the expectation is
> that pubsub nodes are hosted by the server controlling the JID that
> owns the node, which makes sense.

not necessarily,
* if your server runs no pubsub component you can use pubsub services from
other federated servers
* If the server runs a pubsub component which is not build into the server
directly, but used the XMPP component protocol you have no roster access.

I see your points, maybe you should also take a look at PEP (XEP-0163)
which interacts with the roster.
I like your ideas, but to make this happen we need first a new component
protocol which gives us access to the roster. Otherwise we will have no
portable pubsub components or addons.

Alex

[Kevin Smith]

On Wed, Jul 9, 2008 at 9:09 AM, Alexander Gnauck <gnauck (AT) ag-software (DOT) de> wrote:
> * If the server runs a pubsub component which is not build into the server
> directly, but used the XMPP component protocol you have no roster access.
> I see your points, maybe you should also take a look at PEP (XEP-0163)
> which interacts with the roster.

As things stand at the moment, all the roster and +notify stuff sits
in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
pubsub is currently not implementable through the component protocol).

/K

[Blaine Cook]

On Wed, Jul 9, 2008 at 1:17 AM, Kevin Smith <kevin (AT) kismith (DOT) co.uk> wrote:

>
> As things stand at the moment, all the roster and +notify stuff sits
> in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
> pubsub is currently not implementable through the component protocol).
>

I strongly disagree. Parts of XEP-0060 aren't implementable via the
component protocol unless you also implement the roster protocol, but I have
written a functional and useful PubSub implementation that interfaces via
the component protocol.

Moreover, those who've met me know I'm prone to saying that much of the
PubSub protocol is confusing and not necessarily useful in practice, so
having roster-based permissions is far from necessary for most things,
especially web-based apps of the sort we're discussing.

b.

[Adam Pisoni]

I'm working on a component myself and have had to implement much of
the roster stuff as well. I agree with Blaine that you can probably
implement a fully featured/compliant PubSub within a component.

Thanks,
adam

On Jul 9, 2008, at 10:18 AM, Blaine Cook wrote:

> On Wed, Jul 9, 2008 at 1:17 AM, Kevin Smith <kevin (AT) kismith (DOT) co.uk>
> wrote:
>
> As things stand at the moment, all the roster and +notify stuff sits
> in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
> pubsub is currently not implementable through the component protocol).
>
> I strongly disagree. Parts of XEP-0060 aren't implementable via the
> component protocol unless you also implement the roster protocol,
> but I have written a functional and useful PubSub implementation
> that interfaces via the component protocol.
>
> Moreover, those who've met me know I'm prone to saying that much of
> the PubSub protocol is confusing and not necessarily useful in
> practice, so having roster-based permissions is far from necessary
> for most things, especially web-based apps of the sort we're
> discussing.
>
> b.

[Kevin Smith]

On Wed, Jul 9, 2008 at 6:18 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
>> As things stand at the moment, all the roster and +notify stuff sits
>> in -0060 itself, -0163 is now just a profile of -0060 (yes, that means
>> pubsub is currently not implementable through the component protocol).
> I strongly disagree. Parts of XEP-0060 aren't implementable via the
> component protocol unless you also implement the roster protocol, but I have
> written a functional and useful PubSub implementation that interfaces via
> the component protocol.

Ah, so you've got the roster access, and the +notify stuff going from
a component?
That's interesting (and quite cool).

> Moreover, those who've met me know I'm prone to saying that much of the
> PubSub protocol is confusing and not necessarily useful in practice

I'm not going to disagree there, I've been saying it for years.

> so
> having roster-based permissions is far from necessary for most things,

Sure, but it's necessary for a complete implementation of -0060, which
was all I intended to assert. That said, you've done the roster stuff
in a component, so I was wrong to assert it anyway.

/K

[Kevin Smith]

On Wed, Jul 9, 2008 at 6:21 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
> I'm working on a component myself and have had to implement much of the
> roster stuff as well. I agree with Blaine that you can probably implement
> a fully featured/compliant PubSub within a component.

I'm impressed (and I think that's pretty cool, people have been saying
that you can't do the roster model, or the +notify stuff, from a
component, so I'm glad to see it done).

/K

[Adam Pisoni]

I'll be open sourcing this component pretty soon. The idea is that it
will have an adaptable storage system such that you can choose how you
are persisting your roster and presence info, but the API remains the
same. Though Anders and I have had many discussions about how it's
unfortunate that by choosing to create a component you MUST accept
responsibility for roster/presence. Ideally it would be nice in some
circumstances if you could re-delegate, or never accept responsibility
for those things from your jabber server if you wanted.

adam

On Jul 9, 2008, at 10:34 AM, Kevin Smith wrote:

> On Wed, Jul 9, 2008 at 6:21 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
>> I'm working on a component myself and have had to implement much of
>> the
>> roster stuff as well. I agree with Blaine that you can probably
>> implement
>> a fully featured/compliant PubSub within a component.
>
> I'm impressed (and I think that's pretty cool, people have been saying
> that you can't do the roster model, or the +notify stuff, from a
> component, so I'm glad to see it done).
>
> /K

[anders conbere]

On Wed, Jul 9, 2008 at 10:44 AM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
> I'll be open sourcing this component pretty soon. The idea is that it will
> have an adaptable storage system such that you can choose how you are
> persisting your roster and presence info, but the API remains the same.
> Though Anders and I have had many discussions about how it's unfortunate
> that by choosing to create a component you MUST accept responsibility for
> roster/presence. Ideally it would be nice in some circumstances if you
> could re-delegate, or never accept responsibility for those things from your
> jabber server if you wanted.

Right, I know I've bounced around this idea to a few of you, and it
sounds like there are some servers (djabberd) that work a bit like
this. But I've seen /a lot/ of components being built lately. And at
this point I'm fairly well convinced that this is the only way to
build scalable services that act like bots (plug into your internal
services closely and without managing individual clients). That being
said, as soon as you choose to use a component you throw the baby out
with the bathwater, you get a lot of freedom, but as far as I can tell
no modern server gives you a framework to attach to and build upon the
tools already in place to handle presence, rosters, permissions, etc.
etc.

So it seems to me that this could go one of two ways.

1) Components could be the wrong tool to use here. If that's the case
then we as a community need to come up with a better solution for the
kinds of use cases were seeing.

2) Components are the right tool, in which case it would be
interesting to talk to server authors about how we could better tool
servers to allow this kind of reuse.

~ Anders

>
> adam
>
> On Jul 9, 2008, at 10:34 AM, Kevin Smith wrote:
>
>> On Wed, Jul 9, 2008 at 6:21 PM, Adam Pisoni <apisoni (AT) geni (DOT) com> wrote:
>>>
>>> I'm working on a component myself and have had to implement much of the
>>> roster stuff as well. I agree with Blaine that you can probably
>>> implement
>>> a fully featured/compliant PubSub within a component.
>>
>> I'm impressed (and I think that's pretty cool, people have been saying
>> that you can't do the roster model, or the +notify stuff, from a
>> component, so I'm glad to see it done).
>>
>> /K
>
>

[Peter Saint-Andre]

Kevin Smith wrote:
> On Wed, Jul 9, 2008 at 6:18 PM, Blaine Cook <romeda (AT) gmail (DOT) com> wrote:
>> Moreover, those who've met me know I'm prone to saying that much of the
>> PubSub protocol is confusing and not necessarily useful in practice
>
> I'm not going to disagree there, I've been saying it for years.

Yes, the full pubsub spec has all sorts of little sidelines to address
less common use cases, but I'd say that 20% of the spec will be used 80%
of the time. Would it help to call that out?

/psa

[Nathan Fritz]

>
> Yes, the full pubsub spec has all sorts of little sidelines to address less
> common use cases, but I'd say that 20% of the spec will be used 80% of the
> time. Would it help to call that out?
>
> /psa
>
> I think the PEP spec does a good job of defining a VERY specific set of
features and calling it a complete spec. I think more of this should be
done.

[Peter Saint-Andre]

Nathan Fritz wrote:
> Yes, the full pubsub spec has all sorts of little sidelines to
> address less common use cases, but I'd say that 20% of the spec will
> be used 80% of the time. Would it help to call that out?
>
> /psa
>
> I think the PEP spec does a good job of defining a VERY specific set of
> features and calling it a complete spec. I think more of this should be
> done.

Yes, that's a possibility too. XEP-0060 provides a large set of features
and options you can choose from in defining specific application types
or profiles or whatever we want to call them.

/psa