Skip to content

XMPP extensions

Jump to bottom
daniele-athome edited this page Oct 21, 2014 · 10 revisions

The XMPP protocol and the XEPs lack a few things that we needed in order to better integrate with a mobile environment. Here we describe the modifications we made to a few XEPs and the new XEPs we would like to propose to the XMPP Council.

Our aim is to better outline these extensions and make them standard XEPs. Until then, we will have to use custom XML namespaces (an exception is for server receipts).

File upload

This extension is actually just a support to "guide" clients into choosing an appropriate file hosting service to upload message attachments.

This extension is far from complete and far from being useful outside of Kontalk specific usage. It needs a lot more work and there are also some security concerns that need to be addressed.

Servers can advertise this feature during service discovery.

<iq from='example.com' type='result' id='H-1' to='[email protected]'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://kontalk.org/extensions/message#upload'/>
  </query>
</iq>

Client then requests info about that.

<iq id='H-2' to='example.com' type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items' node='http://kontalk.org/extensions/message#upload'/>
</iq>

Let's say this server supports the Kontalk dropbox service only.

<iq from='example.com' type='result' id='H-2' to='[email protected]'>
  <query xmlns='http://jabber.org/protocol/disco#items' node='http://kontalk.org/extensions/message#upload'>
    <item node='kontalkbox' jid='kontalk.net' name='Kontalk dropbox service'/>
  </query>
</iq>

And client again wants to know more:

<iq id='H-3' to='example.com' type='get'>
  <upload xmlns='http://kontalk.org/extensions/message#upload' node='kontalkbox'/>
</iq>

Server replies with information about the service. It actually depends on the service.

<iq from='example.com' type='result' id='H-3' to='[email protected]'>
  <upload xmlns='http://kontalk.org/extensions/message#upload' node='kontalkbox'>
    <uri>http://prime.kontalk.net:5280/upload</uri>
  </upload>
</iq>

File information in Out of Band Data (XEP-0066)

As a hint, we added two attributes to the url tag:

  • type - supposed MIME type of data
  • length - supposed length of data in bytes
  • encrypted - flag indicating that content is encrypted

NOTE: this is just a hint to avoid doing a request to the server.

Push notifications capability

This extension will be probably replaced by a new XEP being defined in these days. Please refer to the relevant mailing list discussion.

Servers can advertise this feature during service discovery.

<iq from='example.com' type='result' id='H-1' to='[email protected]'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://kontalk.org/extensions/presence#push'/>
  </query>
</iq>

When clients want to know more about the service, server replies with supported push notifications providers.

<iq id='H-2' to='example.com' type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items' node='http://kontalk.org/extensions/presence#push'/>
</iq>
<iq from='example.com' type='result' id='H-2' to='[email protected]'>
  <query xmlns='http://jabber.org/protocol/disco#items' node='http://www.kontalk.org/extensions/presence#push'>
    <item node='SENDER-ID' jid='gcm.push.kontalk.net' name='Google Cloud Messaging push notifications'/>
  </query>
</iq>

In this case, the node attribute contains the GCM sender ID that clients must use in order to obtain a registration ID.

After registering with Google Cloud Messaging, client must send a presence stanza to advertise its registration ID.

<presence>
  <status>...</status>
  ...
  <c xmlns='http://www.kontalk.org/extensions/presence#push' provider='gcm'>REGISTRATION-ID</c>
</presence>

Currently, only GCM is supported.

Server receipts

This is an extension to XEP-0184: Message Delivery Receipts, allowing clients and servers to be safer when delivering messages and also to provide a reliable delivery receipt system. In this case we decided to use a non-custom namespace URI urn:xmpp:server-receipts.

When sending a message, a client can ask for server-managed delivery confirmation by adding a receipt request.

<message id='H-1' from='[email protected]' to='[email protected]'>
  <body>Hello world!</body>
  ...
  <request xmlns='urn:xmpp:server-receipts'>
</message>

Server will assign an ID to the message and, if the message is accepted, it will reply with a sent receipt using the same stanza ID.

<message id='H-1' from='[email protected]' to='[email protected]'>
  <sent xmlns='urn:xmpp:server-receipts' id='MESSAGE-ID'>
</message>

When a client receives the message, it needs to acknowledge it.

<message id='H-2' from='[email protected]' to='[email protected]'>
  <received xmlns='urn:xmpp:server-receipts' id='MESSAGE-ID'>
</message>

Server will reply with an ack.

<message id='H-3' from='[email protected]' to='[email protected]'>
  <ack xmlns='urn:xmpp:server-receipts'>
</message>

Now the server will send a delivery receipt to the sender's client.

<message id='H-2' from='[email protected]' to='[email protected]'>
  <received xmlns='urn:xmpp:server-receipts' id='MESSAGE-ID'>
</message>

Clients need to acknowledge that, this time by using the delivery receipt stanza ID.

<message from='[email protected]' to='[email protected]'>
  <ack xmlns='urn:xmpp:server-receipts' id='STANZA-ID'>
</message>

Public-key presence subscription extension

When a user wants to subscribe to someone else's presence, it sends a presence with type subscribe as usual. If the server realizes that the requester has no permission to see the other user's presence, it forwards the subscription request, but not before having appended the requester's public key using a variant of XEP-0189.

<presence type='subscribe' from='[email protected]' to='[email protected]'>
  <pubkey xmlns='urn:xmpp:pubkey:2'>
    <key>[Base64-encoded public key block]</key>
    <print>[key fingerprint]</print>
  </pubkey>
</presence>

Presence unsubscription

Because Kontalk has a live subscription system (that is, subscription is requested on demand), a presence stanza of type unsubscribe has the effect to just "unwatch" a user.

This feature needs serious work: it breaks compatibility with RFC 6121 because unsubscribe means that a user will be removed from the roster. A possible solution to this would be to implement a filter in the s2s component which will filter out unsubscribed presence stanzas if the watched user is still in the whitelist of the requester.

Kontalk in-band registration (XEP-0077)

This extension is used to register to the Kontalk service. It uses XEP-0077: In-band registration with a few more form fields to include some stuff such as verification code, phone number and public key.

TODO

A registration-like form is also used to register a new public key for the user, in case the previous one has been compromised.

TODO

Clone this wiki locally