XMPP Extensions: Difference between revisions
(start writing up XMPP extensions) |
mNo edit summary |
||
Line 25: | Line 25: | ||
=== [http://www.xmpp.org/extensions/xep-0045.html XEP-0045: Multi-User Chat] === |
=== [http://www.xmpp.org/extensions/xep-0045.html 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) |
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). |
||
=== [http://www.process-one.net/docs/ejabberd/guide_en.html#htoc64 ejabberd mod_shared_roster] === |
=== [http://www.process-one.net/docs/ejabberd/guide_en.html#htoc64 ejabberd mod_shared_roster] === |
||
... |
|||
== Problems With This Approach == |
== Problems With This Approach == |
Revision as of 00:22, 17 November 2007
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).
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?