Federating with XMPP
Antonio Tapiador del Dujo
We are starting to work on the federation of a HTTP based server using XMPP.
We have identified some events that should be routed though the XMPP server,
but we are not sure about what XEP using for them. They are the following:
* Request (public) information about some remote user
* Add contact request (server2server)
* Add contact response
* Activity subscription to a contact
* Activity publishing through nodes, both new thread and responses.
Is there any documentation about which XMPP components you are using for
solving these problems? Do Buddycloud and OneSocialWeb use the same components
for them? Are they compatible?
Thank you.
Daniel Renfer
<atap...@dit.upm.es> wrote:
> Hi folks!
> We are starting to work on the federation of a HTTP based server using XMPP.
Glad to see another project enter the ring!
>
> We have identified some events that should be routed though the XMPP server,
> but we are not sure about what XEP using for them. They are the following:
The core specs that OneSocialWeb uses are available at
http://onesocialweb.org/developers-protocol.html I found that it was
easiest to just set up a client and watch what it was sending to the
server by inspecting the BOSH requests in Firebug. I've saved some of
them, and linked them below.
>
> * Request (public) information about some remote user
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-query-request.xml
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-query-response.xml
> * Add contact request (server2server)
> * Add contact response
> * Activity subscription to a contact
Adding contacts is as per normal XMPP. When you subscribe to a user,
they are added to your roster, but no presence information is
requested/granted.
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/subscriber-publish-request.xml
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/subscriber-publish-response.xml
> * Activity publishing through nodes, both new thread and responses.
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-publish-request.xml
I don't believe I saved the responses. If you're brave, and you don't
mind reading Clojure, you can look through the rest of my app to see
what the responses should be. (also check out the resources directory
that is the parent of all the linked files.)
>
> Is there any documentation about which XMPP components you are using for
> solving these problems? Do Buddycloud and OneSocialWeb use the same components
> for them? Are they compatible?
OneSocialWeb doesn't use "components" because it uses pure PEP. This
means that it has to be implemented as a server plugin. I don't know
all too much about Buddycloud, but they serve all of their stuff from
a component domain. This makes interop between the 2 projects
difficult.
While Buddycloud is easier to implement, (since they use components)
their URI's are less aesthetically pleasing IMO. It's a trade off.
>
> Thank you.
>
If you have a OneSocialWeb account (or XMPP in general), feel free to
hit me up at du...@mycyclopedia.net I love being able to dogfood this
stuff.
Antonio Tapiador del Dujo
On Martes 26 Julio 2011 14:31:33 Daniel Renfer escribió:
> The core specs that OneSocialWeb uses are available at
> http://onesocialweb.org/developers-protocol.html I found that it was
> easiest to just set up a client and watch what it was sending to the
> server by inspecting the BOSH requests in Firebug. I've saved some of
> them, and linked them below.
We are trying to federate servers, so we are more interested in server2server
communication. However, client2server can give clues about how to solve some
problems. The captures are very useful!
> > * Request (public) information about some remote user
>
> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-
> query-request.xml
>
> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-
> query-response.xml
These are for getting the last posts in the activity stream, but we are
looking for a stanza for profile information. It seems XEP-0154 is the newest
specification, but it is deferred.
http://xmpp.org/extensions/xep-0154.html
> > * Add contact request (server2server)
> > * Add contact response
> > * Activity subscription to a contact
>
> Adding contacts is as per normal XMPP. When you subscribe to a user,
> they are added to your roster, but no presence information is
> requested/granted.
>
> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/subscribe
> r-publish-request.xml
> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/subscrib
> er-publish-response.xml
>
> > * Activity publishing through nodes, both new thread and responses.
>
> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-
> publish-request.xml
>
> I don't believe I saved the responses. If you're brave, and you don't
> mind reading Clojure, you can look through the rest of my app to see
> what the responses should be. (also check out the resources directory
> that is the parent of all the linked files.)
Ok, so it seems that pubsub + activity streams solves the problem, though I am
not sure if PEP is sufficient or something from XEP-0060 is needed.
> > Is there any documentation about which XMPP components you are using for
> > solving these problems? Do Buddycloud and OneSocialWeb use the same
> > components for them? Are they compatible?
>
> OneSocialWeb doesn't use "components" because it uses pure PEP. This
> means that it has to be implemented as a server plugin. I don't know
> all too much about Buddycloud, but they serve all of their stuff from
> a component domain. This makes interop between the 2 projects
> difficult.
>
> While Buddycloud is easier to implement, (since they use components)
> their URI's are less aesthetically pleasing IMO. It's a trade off.
Is this related to Buddycloud's channels?
> If you have a OneSocialWeb account (or XMPP in general), feel free to
> hit me up at du...@mycyclopedia.net I love being able to dogfood this
> stuff.
I hope we can have something running soon and make some interoperability
tests!
Daniel Renfer
<atap...@dit.upm.es> wrote:
> Hi Daniel, thanks for the quick response!
>
> On Martes 26 Julio 2011 14:31:33 Daniel Renfer escribió:
>> The core specs that OneSocialWeb uses are available at
>> http://onesocialweb.org/developers-protocol.html I found that it was
>> easiest to just set up a client and watch what it was sending to the
>> server by inspecting the BOSH requests in Firebug. I've saved some of
>> them, and linked them below.
>
> We are trying to federate servers, so we are more interested in server2server
> communication. However, client2server can give clues about how to solve some
> problems. The captures are very useful!
With the OneSocialWeb servers, the server intercepts the packets going
back and forth between users and takes appropriate action. Therefore,
the s2s protocol for OSW is just the c2s protocol. OSW doesn't have
any forms of server synchronization like buddycloud does.
>
>> > * Request (public) information about some remote user
>>
>> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-
>> query-request.xml
>>
>> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-
>> query-response.xml
>
> These are for getting the last posts in the activity stream, but we are
> looking for a stanza for profile information. It seems XEP-0154 is the newest
> specification, but it is deferred.
>
> http://xmpp.org/extensions/xep-0154.html
>
OSW uses VCards annotated with ACL information to represent users.
Personally, I've never been a big fan of the VCard support, especially
considering that the VCards used for OSW are different than the ones
used for normal XMPP.
Personally, I'd prefer something like FOAF or POCO.
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/vcard-publish-request.xml
https://github.com/duck1123/jiksnu/blob/master/src/test/resources/vcard-query-request.xml
>> > * Add contact request (server2server)
>> > * Add contact response
>> > * Activity subscription to a contact
>>
>> Adding contacts is as per normal XMPP. When you subscribe to a user,
>> they are added to your roster, but no presence information is
>> requested/granted.
>>
>> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/subscribe
>> r-publish-request.xml
>> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/subscrib
>> er-publish-response.xml
>>
>> > * Activity publishing through nodes, both new thread and responses.
>>
>> https://github.com/duck1123/jiksnu/blob/master/src/test/resources/activity-
>> publish-request.xml
>>
>> I don't believe I saved the responses. If you're brave, and you don't
>> mind reading Clojure, you can look through the rest of my app to see
>> what the responses should be. (also check out the resources directory
>> that is the parent of all the linked files.)
>
> Ok, so it seems that pubsub + activity streams solves the problem, though I am
> not sure if PEP is sufficient or something from XEP-0060 is needed.
The big challenge with PEP is that there is no easy way to determine
what messages are directed towards the user and which are ment for the
activity processor. This ties the implementation to the particular
server. The OSW plugin works only with Openfire, Jiksnu only works
with Tigase, and I believe the eJabberd guys are working on something
that'll only work with their servers.
With buddycloud, they have a domain name they can use to determine
which packets to divert. This means they can make an external
component that works with any server.
>
>> > Is there any documentation about which XMPP components you are using for
>> > solving these problems? Do Buddycloud and OneSocialWeb use the same
>> > components for them? Are they compatible?
>>
>> OneSocialWeb doesn't use "components" because it uses pure PEP. This
>> means that it has to be implemented as a server plugin. I don't know
>> all too much about Buddycloud, but they serve all of their stuff from
>> a component domain. This makes interop between the 2 projects
>> difficult.
>>
>> While Buddycloud is easier to implement, (since they use components)
>> their URI's are less aesthetically pleasing IMO. It's a trade off.
>
> Is this related to Buddycloud's channels?
yes.
Here's the buddycloud spec for what it's worth.
http://buddycloud.org/wiki/XMPP_XEP
>
>> If you have a OneSocialWeb account (or XMPP in general), feel free to
>> hit me up at du...@mycyclopedia.net I love being able to dogfood this
>> stuff.
>
> I hope we can have something running soon and make some interoperability
> tests!
>
Looking forward to seeing what you come up with.
Antonio Tapiador del Dujo
> The big challenge with PEP is that there is no easy way to determine
> what messages are directed towards the user and which are ment for the
> activity processor. This ties the implementation to the particular
> server. The OSW plugin works only with Openfire, Jiksnu only works
> with Tigase, and I believe the eJabberd guys are working on something
> that'll only work with their servers.
I do not understand this point, probably because I come with mixed HTTP/XMPP
model in mind. Could you please give an example about a message towards the
user and other towards the activity processor?
> With buddycloud, they have a domain name they can use to determine
> which packets to divert. This means they can make an external
> component that works with any server.
>
> >> > Is there any documentation about which XMPP components you are using
> >> > for solving these problems? Do Buddycloud and OneSocialWeb use the
> >> > same components for them? Are they compatible?
> >>
> >> OneSocialWeb doesn't use "components" because it uses pure PEP. This
> >> means that it has to be implemented as a server plugin. I don't know
> >> all too much about Buddycloud, but they serve all of their stuff from
> >> a component domain. This makes interop between the 2 projects
> >> difficult.
> >>
> >> While Buddycloud is easier to implement, (since they use components)
> >> their URI's are less aesthetically pleasing IMO. It's a trade off.
> >
> > Is this related to Buddycloud's channels?
>
> yes.
>
> Here's the buddycloud spec for what it's worth.
> http://buddycloud.org/wiki/XMPP_XEP
I read the spec but I did not clearly understand the need for the channels
contribution, what was missing in previous XMPP specs and what problem they
are solving.
imaginator
While Buddycloud is easier to implement, (since they use components)
their URI's are less aesthetically pleasing IMO. It's a trade off.
On the web any buddycloud account can be viewed by simply appending the the URL: http://domain.com/be...@beer-company.com
S.