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.

Problems With This Approach

• The shared roster is totally infeasible for any large Jabber servers due to the sheer size of the list that's pushed the client. Jabber.laptop.org has in the region of 4000 registered users and the roster push is already 500k or so.
• If any significant number of these users actually log in, the XO will be deluged with a firehose of presence and PEP notifications that at best it won't be able to show to the user in any meaningful way (the mesh view is already very crowded by 30-40 individuals) or at worst will render the network or device unusable due to sheer amount of traffic and processing.
• The shared roster allows no privacy controls over who can see what information about individuals. Basic controls such as not notifying people about presence without subscription, or using subscriptions to control what kind of communication is possible are rendered totally useless.
• As hinted at above, the PEP nodes containing activity properties are published per person when they should be published per activity. This leads to needless network churn when people join activities as properties are copied between the members, and notified to their friends.
• There is currently no way to implement searching of Buddies or Activities without naive client-side filtering, which requires that the client is aware of all of the possible buddies and activities.
• The consequence of requiring PEP support and shared rosters to function at even a basic level means that its much harder than it should be to deploy OLPC-friendly Jabber servers. Only ejabberd has been made to support this configuration to date, so there is no flexibility to choose other solutions based on their respective merits.

Proposed Solution

Use Cases

We intend to be support the following use cases with this solution:

• Idle: The user has switched the laptop on for the first time, or the user is currently not doing anything else, and the mesh view is selected. A reasonable number of different activities should be displayed, along with the users for the user to select
• Buddy Search: The user is looking for a particular individual on the same school and searches for them by one of a number of properties, such as nickname or potentially full name or e-mail address. The mesh view shows just these individuals who can be added as friends or invited to activities.
• Activity Search: The user is looking to take part in a particular activity and searches for instances by properties such as name, type or tags. The mesh view shows a reasonable number of matching activities for the user to join.
• Friends: The user has a number of buddies that they have marked as friends. The laptop should always be able to show the activities these people are currently doing.

Current behaviour which we don't intend to support any longer:

• Lone Buddies: When idle, the mesh view shows a lot of buddies who are neither friends nor currently in an activity. These individuals are not only uninteresting to the user, but it represents a privacy violation to propogate their presence information if they are not currently engaged in a public activity or have made themselves searchable.

XMPP Component Implementation

The page XMPP Component Protocol has details of the proposed protocol.

Unresolved Issues

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