XMPP Extensions

  This page is monitored by the OLPC team.

This page documents the current server extensions relied upon by the Telepathy client in use on the XOs, and the ways they are used. On the whole these are official XMPP Extension Proposals (XEPs) from the XMPP Standards Foundation, along with ejabberd specific shared roster behaviour. In some respects, it is a more verbose version of Shared Activity Protocol 1.0 but is focussed on server extensions rather than the client<->client protocols. It goes on to propose a new OLPC-specific XMPP server component which will address scalability issues, and replace the reliance on shared rosters and perhaps also on PEP.

Server Extensions Currently In Use

XEP-0077: In-Band Registration

Every laptop registers itself a JID on the configured server whose username part is the base64 of their public key ID, and password is a hash of the private key. This can be easily replaced by the user entering an existing XMPP account.

XEP-0054: vcard-temp

Every laptop publishes a vCard which contains the user's nickname, or updates the NICKNAME field of any existing vCard to patch. Avatars are not currently used.

<iq type="set">
  <vCard xmlns="vcard:temp">
    <NICKNAME>foo</NICKNAME>
  </vCard>
</iq>

XEP-0030: Service Discovery

Upon connection, the client requests http://jabber.org/protocol/disco#info and http://jabber.org/protocol/disco#items nodes from the server, to find whether the server has PEP (its JID has the appropriate http://jabber.org/protocol/pubsub features), and the address of the server's conference server (the first JID on the items list which has category="conference", type="text" and has the http://jabber.org/protocol/muc feature).

XEP-0045: Multi-User Chat

Every shared activity is represented with one MUC room on the server's conference server. They are configured so that they are not persistent (ie the server discards them when the last user has left), are private (users are made aware of the activities by other means or direct <message> invitations), and all members are able to see the full JID of the members (MUC nicknames are not used or exposed anywhere in the UI). Shared activity data is exchanged over these rooms with Telepathy's Tubes and MUC Bytestream protocols.

XEP-0163: Personal Eventing via Pubsub

PEP is used on the server to propogate information. Each XO publishes a number of nodes with properties as documented here, which are seperate nodes on the basis that they will change at different frequencies, so that each update is as small as possible. The nodes are:

• Nickname (as in XEP-0172: User Nickname)
• Buddy properties (colour, public key, etc)
• Current activity (changes more often)
• List of all joined activities
• Properties for the activities (type, colour, instance ID, etc)

Activities are identified by the JID of the MUC room they use to communicate. Note that the activity properties are only stored in a seperate PEP node to the list of activities as an interim solution. It is inefficient because it requires every member of the activity to publish the properties, to make the activity metadata robust against any individual leaving. It was always intended that activity properties would be stored somewhere elsewhere per-room, although no such mechanism has been identified or implemented to date.

ejabberd mod_shared_roster

The server is configured with ejabberd's shared roster module so that there is a group in the roster of every user which contains every other user on the server. This means that presence and PEP notifications for every user on the server are sent automatically to every user who is logged in, and that all PEP nodes published with default (equal to presence) permissions are readable by all.

Currently XOs automatically approve any incoming subscription requests, because no UI has yet been created for this. It is intended that before Update.1, we fix #4965 and the roster will at least contain the XO's friends so that we can stop relying on shared roster functionality and existing XOs will at least still see their friends.

Unresolved Issues

• Do we still want to use PEP for notifying our subscribed friends about our properties, current activities, and such like?