Let's talk XMPP - episode 3 - core and extensions (part 2) goffi 6 years ago jabber-xmpp-en technique talk_xmpp Libre This article was initially published in French, and it got some interest, so we started to translate the whole series in English. If you can read French, you can follow the whole series there: http://www.goffi.org/tag/parlons_xmpp The translation to English was done thanks to: Poulet, Éfrit, Paco, mbarbarosa, Weyfonk and Chteufleur. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles. (Follow the corresponding link to read the previous episodes). Some functionalities can be added to this central part, hence the X of XMPP (which stands for “eXtensible”). Extensions are written using “XEP” (XMPP Extension Protocol) , following an idea taken from Python (if I am not mistaken). This is why the features supported by a server or a client are identified as XEP-0XXX. Obviously, no need to know this to use a XMPP client, but it can be useful to read an extension (you can find them at https://xmpp.org/xmpp-protocols/xmpp-extensions/) to understand correctly the utility of a functionality. Two parts are particularly useful without the need to enter in the implementation details: the “abstract” part (summary) in the top that indicates what the XEP is doing, and the “introduction” section (the very first section) that provides further details about the cause of the extension and its use cases. An XEP can describe a feature, a process (for instance the XEP-0001 explains the life cycle of the XEPs themselves), a historical legacy (related to something created before the XMPP Standard Foundation), information (like good practices), even a joke (yes, there are also lousy jokes in the XEPs!). It can have several statuses, detailed in the XEP-0001. It is interesting to note that a lot of XEPs are “experimental” and so technically not (yet) standards, but often implemented anyway. Such XEPs can be widely modified before they get the “Draft” status and eventually become a standard. Why am I talking about all this? For you to get one thing loud and clear: XMPP is not only about instant messaging! Some interesting examples of extensions: Extended Stanza Addressing (XEP-0033): to send messages to several recipients at once, or to do carbon copies, as well as blind carbon copies (as the… yes, yes you see what I mean). Multi-User Chat (XEP-0045): IRC-like group chat. Ad-Hoc Commands (XEP-0050): a generic system to handle any kind of commands. Related to users' permissions, it is a great tool! vcard-temp (Business cards, temporary version, XEP-0054): The legacy way to manage electronic business cards, which are a kind of public profile. A new extension will eventually replace it (XEP-0292). Jabber Search (XEP-0055): used to search for jid, mostly used by directories. Publish/Subscribe (XEP-0060): a big piece, used to publish all kinds of information, and its recovery based on permissions, with a notification system in real time. XHTML-IM (XEP-0071): to publish with an XHTML subset, which enables formatting (to write bold text or include a picture for example). Gateway Interaction (XEP-0100): to manage gateways, i.e. links to external networks. Personal Eventing Protocol (XEP-0163): a kind of simplified Publish/Subscribe system. Jingle (XEP-0166): Peer-to-peer session establishment with a wide range of possible applications, the most well-known being video conference. Serverless Messaging (XEP-0174): unsurprisingly used to communicate without servers. Message Archive Management (XEP-0313): to recover messages or other objects (works with Publish/Subscribe as well) following criteria such as a date. In particular, used to get a conversation history on a server, which is useful to access it from all your clients. Keep in mind that we’ve barely scratched the surface here. Further details will be provided about some of these extensions in future articles. Please note that extensions can be referred by using short names, for instance “MAM” for “Message Archive Management”. Such names are usually mentioned at the end of the related XEPs, in the “Document Information” appendices. This may lead to situations where clients and servers don’t support the same extensions subsets… How to make both parties agree on which one to use? This problem is solved through another extension (though so essential and widely implemented that it could nearly be considered as a main standard): “Service Discovery”, aka XEP-030, short name: “disco”. The idea is simple: each client, server or component discloses who it is, what it can do, or associated items. A component is a service that plugs itself into a server, see below. who it is An XMPP address (or jid) can be used by all kinds of elements, be it a server, a client, a gateway, or a bot for instance. The latter is a robot, i.e. a program that automates tasks, and is often used to behave like a client. When a client or another element sees a jid, it may need to know what kind of element is associated to that jid, for instance to render it in a special way in the user interface. This is how clients and gateways are shown in distinct ways in your contacts list. Disco’s identity provides this through a category (“client” or “server” for instance), a type (e.g. a client can be “bot”, “web”, “game”…), and a free name (eg “ejabberd”). A list of categories and their associated types can be found on https://xmpp.org/registrar/disco-categories.html. what it can do XMPP’s extensibility makes it very feature-rich, therefore knowing what the software we are talking to is able to do is mandatory. Disco provides a list of such supported features, which is why you may see disabled buttons or icons (e.g. for video conference) while talking to someone. This means the client you are talking to indicates that it does not support this feature, or more accurately: it does not reveal that it supports it. These features are linked to namespaces that are mentioned in the related XEPs. A list of XEPs based on namespaces is available here: https://xmpp.org/resources/schemas. associated items Beside its identity and available features, an XMPP entity can have associated elements. They can be servers indicating where to find chat rooms, or gateways to other networks. Let's try Let’s make this clear with an example. Salut à Toi’s command line interface “jp” can retrieve an entity’s disco using the command “jp info disco”, see below with jabber.fr: % jp info disco jabber.fr Features: http://jabber.org/protocol/commands http://jabber.org/protocol/disco#info http://jabber.org/protocol/disco#items http://jabber.org/protocol/stats iq jabber:iq:register jabber:iq:time jabber:iq:version msgoffline presence presence-invisible urn:xmpp:time vcard-temp -- Identities: ejabberd (server/im) -- Extensions: http://jabber.org/network/serverinfo -- Items: [chat.jabberfr.org] [irc.jabberfr.org] [j2j] [presence.jabberfr.org] [proxy.jabberfr.org] [users.jabberfr.org] As we can see, jabber.fr supports legacy vCards management (vCard-temp, XEP-0054) as well as ad-hoc commands (http://jabber.org/protocol/commands, XEP-0050), and the server (server/im) used for instant messaging is called “ejabberd”. We can also notice that various services are available, one of them being char.jabberfr.org. Let’s take a closer look: % jp info disco chat.jabberfr.org Features: http://jabber.org/protocol/disco http://jabber.org/protocol/muc http://jabber.org/protocol/muc#unique jabber:iq:browse jabber:iq:last jabber:iq:register jabber:iq:time jabber:iq:version urn:xmpp:ping vcard-temp -- Identities: Public Chatrooms (conference/text) -- Items: [...] JabberFR (13) [email@example.com] [...] We see that we are dealing with a chat rooms service (conference/text), which use the protocol “Multi-User Chat” (http://jabber.org/protocol/muc). It is at the moment the only one which is available for groups’ discussions (we will talk about it later). “Items” elements contain rooms’ list, with the name, the occupiers’ number with the corresponding JID. I shorten the list which was very long. In jabber.fr’s information, you may have noticed the “extensions” section, it is the XEP-0128 which allow to extend disco for all kind of information. In the case of ejabberd here, it is to give contact addresses of server, but they aren’t indicated for jabber.fr Below the disco’s window of Gajim: The first time I used XMPP, with Psi in the early 2000s, I was a bit intimidated by the “service discovery” menu, which shows near directly all information we just saw. This kind of menu is often, at my opinion, showed too abruptly in XMPP clients: using disco directly (that is all except what is automated by the client) is already advanced use. Furthermore, I will quickly mention the “software version” extension (XEP-0092) which allows, as indicated by its name, to know to which software we are talking to, and the operating system used. jp allows to show these information with “jp info version”, let’s try on jabber.fr: % jp info version jabber.fr Client name: ejabberd Client version: 2.1.13 Operating System: unix/linux 3.2.0 We now know the ejabberd version that is used. Useful when we know if a feature is supported or if a bug is fixed. And this work with every entity which implement the XEP, not only servers. % jp info version chat.jabberfr.org Client name: MU-Conference Client version: 0.9-svn (Jan 27 2014) Operating System: Linux 3.2.0-4-amd64 That’s it. Knowing about the extensions allows to truly know what we can do with a client or a server. Next time I think I will explain groups’ discussions and see what changed in relation to IRC.