XMPP Extensions

From OLPC
Revision as of 19:46, 16 November 2007 by RobertMcQueen (talk | contribs) (start writing up XMPP extensions)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  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 . 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)

ejabberd mod_shared_roster

...

Problems With This Approach

Proposed Solution

Unresolved Issues

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