RFC: OLPC XMPP component protocol

[Robert McQueen]

Hi folks,

We're currently in the process of designing the protocol that OLPC
laptops (currently aiming at Update.2) can use to talk to a XMPP server
component. Currently we do some odd things (which seemed like a good
idea back in March when we had no UI for subscribing to people), such as
rely on a shared roster configuration on the server that lets everyone
see everyone else, and put stuff which is actually per-activity (which
are magically blessed MUC rooms) into other PEP nodes which everyone
pushes around. This sucks.

Some relevant background information:
* The protocols we use to implement shared activities:
 http://wiki.laptop.org/go/Shared_Activity_Protocol_1.0
* The XMPP extensions we rely on (and how we (ab?)use them):
 http://wiki.laptop.org/go/XMPP_Extensions
* The server configuration we require:
 http://wiki.laptop.org/go/Ejabberd_Configuration
 http://wiki.laptop.org/go/Openfire_Configuration (this is still a bit
experimental and needs a couple of patches to our client code to take
care of slightly different MUC/PEP semantic - we started with Ejabberd
because it had a PEP patch available back in March)

The goals of our component are the following:
 * it can be easily deployed without needing anything more specific than
a Jabber server that has support for PEP and MUC
 * it doesn't rely on any abnormal configuration/behaviour on the Jabber
server that breach the normal XMPP approaches to privacy
 * it doesn't rely on being able to access information from the server's
MUC or PEP implementations in any non-standard mechanisms
 * it can scale better than the current protocol, possibly even to
50,000 laptops if we consider the G1G1 (http://www.laptopgiving.org/)
programme, and a suitably scalable server
 * it adds the ability to do server-side searching which we currently
lack, except by dint of the fact that we currently see everything so we
can implement filtering on the client side

The component protocol we're designing to address these goals is
documented here:
 http://wiki.laptop.org/go/XMPP_Component_Protocol

The general idea is that we keep using PEP for the per-buddy information
(the OLPC buddy properties, and the current activity) so we receive that
for our buddies, but we stop using it for any activity information and
we use extended MUC invites and change messages inside the MUCs to send
the activity properties around. The component then uses both of these
technologies (you subscribe to the component so it can see your PEP
notifications, and you invite it into activity MUCs you want to publish)
to make the buddy property, activity property and activity membership
information searchable for people who aren't on your roster, and push
updates to them.

(For the people on the XMPP standards list, I should probably point out
that I'm not particularly proposing any of this to be standardised, I'm
just looking for any feedback or input on our design, and what concerns
will impact its scalability.)

One particular unsolved issue we have is that because the component
doesn't know who your friends are, this means that we will find out
about activities from our friends' PEP nodes which we don't have the
activity properties for. Currently this means when we encounter an
activity that's not in our current result set, we'll have to manipulate
this (or another set) of our friends's activities which we'd like to
also receive the properties for. Ideally the component would already
know, and could push these details to us. Any suggestions on how to
address this are welcome.

On a related note, it seems that there is the possibility that we want
to change the protocol so we can open up a few distinct sets of results,
such as certain activities or buddies, and have the server keep them
around so it can keep pushing us notifications when anything changes.
Should we be using something different to Result Set Management given
that says it's aimed at stateless queries, or do you think it's ok to
re-use it once we've worked out how to open/close different search contexts?

And generally, what do people think? Is there a completely different
approach we should be taking? Thanks for your time... apologies for the
over-long e-mail too. :)

Regards,
Rob