Skip to content

XMPP extensions

Jump to bottom
daniele-athome edited this page Dec 26, 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 register with the push component to advertise its registration ID.

<iq to='[email protected]' type='set'>
  <register xmlns='http://kontalk.org/extensions/presence#push' provider='gcm'>REGISTRATION-ID</register>
</iq>

Currently, only GCM is supported.

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>

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