Planete JabberFR

Let's talk XMPP - episode 2 - core and extensions

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:

The translation to English was done thanks to: Poulet, Éfrit, Paco and mbarbarosa and Weyfonk. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.

Now that we know what we’re talking about, let’s see what the core of the protocol looks like.
Originally, XMPP is defined by 3 (previously 2) RFCs: RFC 6120, RFC 6121, and RFC 6122 (there are others, but these 3 are the main ones). They explain the core of the system, such as sending messages, presence information, statuses and so on.
Without getting too much into details related to developers, we can quickly explain that XMPP is based on 3 element types, or “stanzas”:
  • <presence/> to primarily indicate… our presence information (sometimes, we also add other things like our avatars, our capabilities, but let’s stay focused). The presence is broadcast by the server to all the people that you have given permission to (see below).
    We can associate a state and a message to our presence. The state can be one of the following (names can change depending on the client):
    • available (default): you’re online.
    • away: you’re away for a short period
    • chat: you want to talk
    • dnd (do not disturb): you’re occupied (often called “busy” in clients)
    • xa (eXtended Away): you’re away for a long while.
    The status messages allow you to specify your availability in a clear language (for example: “I’m watching a movie, do not disturb”), even though, in practice, it is used for any kind of message (a lot of people use a quote, for example).
  • <message/> A message’s sending of type “send and forget”. There are 5 types of messages::
    • chat: the most well-known message, used for simple instant messaging;
    • error: this one is usually managed directly by client software. It is often shown by means of a notification window in your client, indicating that something wrong occurred;
    • groupchat: as “chat”, but for discussion with multiple people. In practice the difference concerns only developers and it should be transparent in the client;
    • headline: an important message, an announcement. Normally, these messages aren’t kept offline, so if you aren’t connected while the message is sent, you shouldn’t receive it. These messages don’t expect answers. A typical example is an announcement for an imminent server maintenance;
    • normal: a little known yet interesting type. It is a message which generally has a subject, but outside of an instant conversation. Yes, exactly like an email! It is more or less its XMPP equivalent.
    Conversation threads are managed as well, but we’ll talk about it another time.
  • <IQ/> (Info/Query): used for everything that works on a question/answer pattern (it is mandatory to provide an answer to an request, even if you need to reply with an error). This is used mainly by developers, as it serves as a basis for most of the features you need. Using it is like saying "I need to know or edit this information".
I don't want to delve into technical details, but it seems essential for a user to know different message and presence types to understand their client.
One should note that there is an excellent feature that is largely underused in XMPP: it natively knows how to handle different languages because of its inheritance from XML (xml:lang). In other words, you can specify a normal or status message in French, German and Slovak at the same time. This is a major asset that we intend to use in Libervia.
Now let's talk about another essential part: the contact list.
It is called "roster" in the XMPP world. You can assign 0, 1 or several groups ("family", "friends", etc.), a name (which is an alias chosen by yourself, not by your contact), and subscription information to every contact you add to your roster.
Subscription lets you know whether you have allowed your contact to see your presence information and whether you are allowed to see theirs. Therefore, every time someone adds you to their contact list, your client (e.g. Gajim) asks you whether you wish to grant them access to your presence information. Note that these permissions don't need to be symmetrical: a contact may have been allowed to see your contact information without enabling you to see theirs, and vice versa. It might even be possible that neither of you can see each other's presence information (but I think most clients remove the contact from the roster in that case).
Groups are dependent on contacts, not the other way around (it's not a list of groups which contains the contacts): this explains why having an empty group (i.e. without any contact) isn't possible. In my opinion, groups too are underused in the XMPP world, but we'll get back to this.
That's it for today. I opted to keep the part on extensions for the next post to keep this one lighter.

Let's talk XMPP - episode 1 - the basics

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:

The translation to English was done thanks to: Poulet, Éfrit, Paco and mbarbarosa. The whole series is under CC By-SA, and any help would be appreciated to help with the translation of next articles.

Well, as it’s a shame that XMPP is not well known or understood, I decided to start a series of articles to explain what it is.
These articles are for a technical audience, but not necessarily for developers, and I hope it will help you to understand the advantages of this protocol and to use your software in a better way.
Being a developer of the “Salut à Toi” project, I’ll probably give examples with it quite often.
So let’s start with basis.
What’s XMPP? It’s a standard message and presence protocol, and extensible (XMPP means « eXtensible Message and Presence Protocol », that is it’s documented and used as a reference (validated by standards organization: the IETF). It allows all software which use it to speak the same language, and so to be interoperable. It’s a libre protocol, that is you can get the documentation and use it for free, without any legal or technical restrictions, and you can improve or modify it (but if you divert and don’t suggest your modifications, you risk to lose the compatibility with other software).
XMPP is decentralized and federated, that is you can have servers anywhere, they could (if they don’t forbid it explicitly in their configuration) communicate with each other.
It’s a popular protocol, many software allow to use it: for servers, there are Prosody, Ejabberd, Openfire, Tigase, Mongooselm, Metronome, etc. For clients: Gajim, Poezio, Pidgin, Psi, Swift, Jappix, Movim and of course Libervia/Salut à Toi (I let you find the official websites by yourself). A complete list (servers, clients and libraries) is available here:
If you cannot install your server at home, many public ones are available: in France one can cite those of APINC ((,, etc), of the Quadrature du Net, etc. A small list (it’s not up-to-date, don’t hesitate to contribute) is available here in French,, if not you can check on or (yes, there are a lot!). But I strongly suggest you to install your own server or to go meet a local organization that you can contact easily: on the one hand if you install it by yourself you’ll have a better control on your own data and on the other hand if you want a specific feature you’ll be able to ask admins for an update.
Knowing all that, let’s try to install an account.
Once the server installed or a public server chosen, you can create an account. You’ll have then an address, a “JID” (Jabber ID, “Jabber” is the former name of the protocol, this name is now owned by a private company and is kept here for historical reasons).
This address is on the form of local_name@domain.tld/resource, or in canonical form (or what is called “bare JID”) local_name@domain.tld. For example, mine is Does it sound familiar? Yes, it really looks like email addresses!
So what is this resource? The resource is linked with the client software that you use to connect: XMPP has been designed from the beginning to allow several clients to connect at once (10 years ago, a few messaging protocols were able to do that, and connecting again from a different place was often resulting in the disconnection of the first client) and this resource is used to identify them. In other words, you have a resource only once connected, and it will be a different one for each client that you are using: if I connect with Libervia, Gajim and Movim, I’ll have 3 different resources.
It used to be several strategies to name the resource, sometimes it was used to show the connection location (“home”, “work”), clients often used their names as default value (“gajim”, “psi”). Today, it’s well accepted that it’s better to have a resource that we cannot guess, as somebody can know if you are online or not (even if you don’t want this information to be public) by doing a request to this resource. The best way is to let the server choose the resource for you.
Finally, the resource is linked with a priority: it allows to indicate, if several resources are available, which one will get the message. But we’ll see that later.
In the next episode, I'll talk about extensions an features discovery
That’s it. Let me know if you are interested in this series, if it seems too technical for you, or if you have any comment or fix to suggest. Everything is under the license CC By-SA, so don't hesitate to re-use, share or modify !

Conférences des RMLL

Salut à vous,

j'attendais de voir les vidéos publiées, c'est désormais le cas. Notre passage aux RMLL s'est très bien passé et a été l'occasion de se faire de nouveaux contacts et d'avoir des discussions très intéressantes. J'ai particulièrement apprécié participer à la table ronde sur les nouveaux médias, et rencontrer Arno de SPIP/SeenThis (je connaissais déjà les autres participants).
Je n'ai pas eu l'occasion de voir beaucoup de conférences car j'étais au stand, mais je viens bien sûr vous recommander de voir celles sur XMPP ou en particulier la table ronde sur les nouveaux médias:

Toutes les interventions étaient vraiment intéressantes, y compris dans le public. Merci à ceux qui y ont participé, et à Olicat pour avoir animé.

En ce qui concerne XMPP, il y a bien sur les conférences de Libervia et Movim. Pour Libervia la qualité est vraiment mauvaise, aussi je vous recommande plutôt la version de Pas Sage En Seine, c'est la même conférence:



Et sur un plan plus technique, la conférence « PubSub, Microblogage et XMPP » dont j'ai déjà parlé plusieurs fois:

En dehors de ça comme je l'ai dit je n'ai pas pu voir beaucoup de conférences. J'ai particulièrement aimé celle de Paul Kocialkowski sur Replicant (en anglais, il y en a aussi eu une en français que je n'ai pas pu voir, je ne sais pas si c'est le même ou pas, du coup je mets les 2):

À voir aussi celle de Gelnior (de Newebe/Cozy cloud) sur la conception graphique, je l'avais vue aux JDLL:

Enfin, autre conférence que je n'ai pas (encore) vue, mais comme on en parle dans la table ronde je la mets ici, la conférence « SPIP et sa communauté »:

Il y en a eu beaucoup d'autres, aussi n'hésitez pas à préciser en commentaires celles que vous conseillez.

Appel à la communauté: aidez moi à traduire la série « Parlons XMPP »

Salut à vous,

la série que j'ai commencé fin juin, « Parlons XMPP » a plus de succès que ce à quoi je m'attendais (surtout en été !), et a incité plusieurs personnes à regarder un peu plus ce que peut faire ce protocole.

Du coup j'aimerais bien traduire la série en anglais (ou autre !), mais je n'ai vraiment pas le temps de le faire moi même, vu que je dois déjà travailler sur Salut à Toi, et que l'écriture des articles en français me prend beaucoup de temps.

Alors je veux tenter le coup avec une traduction collaborative, un peu comme ce que fait framasoft pour traduire des articles de l'anglais vers le français, mais dans l'autre sens.

Tous les articles sont sous licence libre (Cc By-SA), et il faut bien noter que je parle souvent de « Salut à Toi » sur lequel je travaille, même si je parle aussi d'autres projets.

Bref, je tente le coup, j'ai ouvert un framapad avec le premier article.

Si vous voulez participer ajoutez votre nom ou pseudo pour être dans les auteurs de la traduction, et vous pouvez traduire en dessous du paragraphe en français. Je demanderai une relecture par un anglophone à la fin.

En dehors des 6 articles déjà publiés, je pense continuer au rythme d'un par semaine au moins pendant l'été.

Pour aider à la traduction, c'est par ici:

Merci d'avance !


Parlons XMPP - épisode 6 - les commandes à distance

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Aujourd'hui nous allons parler d'une de mes fonctionnalités favorites dans XMPP : les commandes à distance. Il s'agit de la possibilité pour 2 entités XMPP d'exécuter des actions à distance de manière générique.

La première méthode, assez peu utilisée à ma connaissance, est via la XEP-0009 (oui c'est une vieille, elle date de 2001), qui donne une méthode pour utiliser XML-RPC à travers XMPP.
XML-RPC est un Système de communications inter processus, c'est à dire un moyen pour 2 entités de communiquer à distance. Vous pouvez ainsi exécuter des commandes indépendamment du langage de programmation, en ayant des données décrites (est-ce que je reçois un entier ? Une chaîne de caractères ?). Ceci est particulièrement adapté pour la communication de machines à machines, quand on sait déjà quelles méthodes sont disponibles et ce qu'elles font. Le cas type est une interface de programmation (ou API) pour permettre de contrôler quelque chose, comme un serveur par exemple.

La deuxième méthode est appelée commandes « ad-hoc » (de circonstance), et c'est la XEP-0050 qui les explique. L'idée est aussi de pouvoir exécuter de manière générique des commandes, mais cette fois sans savoir à l'avance ce qui va être disponible, et en pensant plutôt à une interaction humain/machine, bien que machine/machine soit bien sûr tout à fait possible.

Le cas typique d'utilisation est la configuration d'un service, mais ce peut être utilisé pour n'importe quoi.
Ce qui rend cette fonctionnalité particulièrement puissante, c'est qu'elle fait partie de XMPP et donc peut profiter de tous ses avantages, en particulier l'authentification forte (quand on parle à, on sait qu'on ne parle pas à quelqu'un d'autre) et la liste de contacts (roster) avec leurs groupes. Nous avons ainsi un système de permissions simple à mettre en œuvre et efficace.

Prenons un exemple: vous êtes administrateur sur Prosody (pour mémoire, un serveur XMPP populaire) – pour cela il vous suffit de donner votre jid dans la variable « admins » dans la configuration –, et vous voulez… pouvoir administrer votre serveur. Pas besoin de s'embêter à avoir une page web dédiée avec mot de passe etc, il vous suffit d'avoir un client XMPP qui gère les commandes ad-hoc (Gajim par exemple), et d'entrer l'adresse de votre serveur.

Exemple ci-dessous avec Libervia, l'adresse est celle du serveur, voici ce que, en tant qu'admin, je peux voir.

capture d'écran des commandes ad-hoc pour un admin avec Libervia

Le « Send Announcement to Online Users » (envoyer une annonce à tous les utilisateurs en ligne) est particulièrement utile juste avant une mise à jour.

Avec un compte lambda, voilà ce que l'on voit :
capture d'écran des commandes ad-hoc pour un utilisateur lambda avec Libervia

Malheureusement avec certains clients, l'accès est tout sauf intuitif. Je pense que l'exemple le pire est Psi : pour accéder aux commandes du serveur il faut aller dans la découverte des services (« service discovery ») soit via le menu « General » soit en cliquant droit sur votre profil, puis cliquer sur le nom de votre serveur dans la liste des services, puis enfin cliquer sur l’icône en forme de terminal, appelée « execute command » (exécuter une commande).

Dans Gajim c'est plus simple (clique droit sur votre profil puis « exécuter une commande »), dans Swift c'est dans le menu Actions => Run Server Command (Exécuter une commande serveur). Si vous voulez exécuter des commandes sur un jid arbitraire dans Gajim, il vous faut passer par le menu « Découvrir les services », comme avec Psi ; je n'ai pas l'impression que ce soit possible avec Swift.

Ci dessous une capture de Movim, ces commandes sont dans le menu « actions »:

les actions dans Movim

Même sans être administrateur, les commandes « ad-hoc » peuvent vous être utiles. Par exemple, vous avez oublié de déconnecter votre client chez vous et vous vous trouvez chez un ami. Il vous suffit de vous connecter, et de spécifier le jid complet, avec la ressource, de votre client à la maison. SàT par exemple vous permet à l'heure actuelle de changer votre statut voire de vous déconnecter. Gajim permet en plus de transférer les messages non lus ou de quitter des salons de discussions.

Accès à un client Gajim à distance

Il est facile d'imaginer à quel point cette fonctionnalité peut être utile pour l'administration ou la surveillance de serveurs, pour la robotique, la domotique, le contrôle à distance de votre ordinateur, de votre bot XMPP, etc.

Voyons un autre cas pratique que nous avons implémenté dans Salut à Toi : on couple les commandes « ad-hoc » avec D-Bus. Pour ceux qui ne connaissent pas, D-Bus est un autre système de communication inter-processus qui a été développé par Freedesktop comme un standard commun dans les bureaux libres, en s'inspirant de l'existant et en particulier du DCOP de KDE. Il est donc très largement utilisé dans les logiciels libres, et permet de piloter beaucoup de logiciels courants.
En liant D-Bus et ad-hoc, SàT permet de créer très facilement une télécommande universelle, pilotable depuis n'importe quel client XMPP compatible (y compris sur votre téléphone, ce qui est particulièrement intéressant pour une télécommande), et en prime avec gestion des permissions par groupe.

Cette fonctionnalité est montrée dans le courte vidéo ci-dessous, on autorise les membres du groupe « coloc » à piloter une instance de VLC, pratique quand on fait une séance cinéma dans la colocation :).

Nous allons ajouter également la possibilité d’exécuter des scripts ou des commandes shell, on pourra ainsi très facilement autoriser tous les administrateurs d'un serveur à le redémarrer ou à avoir son statut.

Petite note sur le fonctionnement : les commandes ad-hoc, comme à peu près tout ce qui demande de la transmission d'informations typées dans XMPP, se basent sur les « Data Forms » (formulaires de données, XEP-0004). Cette extension standardise donc les formulaires, et permet de demander des booléens, des mots de passes ou encore des listes de jids.

J'en profite aussi pour vous donner le lien vers la conférence « PubSub, microblogage et XMPP » que j'ai faite aux RMLL il y a un peu plus de 2 semaines. J'y explique en 20 min les bases de PubSub et du microblogage dans XMPP, ainsi que l'intérêt des 2 XEPs que nous avons publiées (cf ce journal sur DLFP). J'en reparlerai bien sûr dans un prochain article.

Bien qu'ayant plusieurs idées en tête, je ne suis pas encore décidé pour le prochain article, il est possible que je parle de PubSub, de copie de fichiers, de chiffrement de bout en bout, ou de tout autre chose…

Conférence « PubSub, microblogage et XMPP » en ligne

Un petit billet pour vous dire que ma conférence rapide (20 min) et technique sur le (micro)blogage dans XMPP, « PubSub, microblogage et XMPP » vient d'être publiée.

Nous avons beaucoup travaillé dessus cette dernière année, et je pense qu’on va voir XMPP arriver en force dans ce domaine dans les mois à venir.

À voir aussi sur

Parlons XMPP - épisode 5 - les discussions de groupe (suite) et les transports

(pour lire les épisodes précédents, suivez l'étiquette correspondante)


Autre point intéressant par rapport à IRC, XMPP conserve l'ordre des messages, par exemple si vous avez la conversation suivante :

[Morphée] tu peux avoir la pilule rouge
[Lué] OK je prends celle-là
[Morphée] ou la bleue

Avec XMPP vous êtes sûrs que c'est la pilule rouge qui a été choisie, vous évitez ainsi les confusions (et de vivre dans l'ignorance).

Comme dit précédemment, la présence est envoyée au service MUC, pas besoin de vous renommer en xxx_away pour prévenir que vous n'êtes pas là, il suffit d'utiliser l'état associé (et vous pouvez utiliser le message de statut pour compléter). Une autre information utile nous est fournie par la XEP-0085 : les notifications d'états de discussion (« Chat State Notifications »). Cette extension permet de savoir ce que fait un utilisateur par rapport à une conversation : est-ce qu'il est actif dessus ? Est-ce qu'il est parti ? Ou est-il en train de taper un message ? Ceci fonctionne aussi avec les conversations de groupes, et c'est vraiment pratique à l'usage.

Quand vous commencez à fréquenter beaucoup de salons, vous avez envie que votre client en garde la liste, ou d'y aller automatiquement à la connexion ; c'est l'extension « Bookmarks » (marque-pages, XEP-0048) qui permet cela, et vous pouvez ainsi retrouver vos salons en changeant de client (puisque la liste est gardée sur le serveur). Alors petite parenthèse là-dessus, nous sommes plusieurs à penser que cette extension a des problèmes : elle est censée gérer les urls mais personne ne l'utilise de cette façon, elle ne gère pas les étiquettes, et elle pose des problèmes de concurrence, ou si on veut l'utiliser hors standard. Nous (plusieurs développeurs dont Edhelas de Movim que vous connaissez ici) avons donc commencé à écrire une alternative, qui pourrait même être utilisée pour synchroniser les marque-pages dans les butineurs, y compris différents. Affaire à suivre.

En plus de garder la liste, il est bien sûr utile de pouvoir facilement donner un lien vers un salon. La XEP-0045 défini les URI à utiliser pour cela (ici), avec la possibilité de préciser un mot de passe ou d'inviter du monde. C'est de cette façon que l'adresse suivante est cliquable : ; il suffit de prendre l'adresse du salon, d'en faire une url XMPP en préfixant avec « xmpp: » et d'ajouter « ?join » à la fin pour indiquer qu'on lie un salon MUC. Pour que le lien fonctionne, il faut que vous ayez associé dans votre système un client XMPP avec ces urls (comme vous associez un butineur à une url http:).

Tout n'est pas toujours parfait non plus dans XMPP, et parfois l'héritage historique, ou les évolutions, ou la trop grande souplesse, amènent à un peu de complications.
Ainsi pour MUC il existe 2 méthodes pour inviter quelqu'un : directe (XEP-0249) ou arbitrée (« mediated invitation » définie dans le XEP-0045). La seconde méthode envoie une invitation à travers le salon lui-même, elle est surtout utilisée pour les salons « réservés aux membres » qui sont rares.
Elle risque en outre de se faire bloquer (si un utilisateur n'accepte pas, par exemple, que les messages de personnes dans sa liste de contacts – « roster » –, nous verrons dans un futur article comment faire cela). L'invitation directe est envoyée au jid à inviter sans passer par le salon – d'où son nom –, c'est celle qui est à préférer.
En pratique cette situation ne pose de problèmes éventuels qu'aux développeurs de clients, et il suffit souvent d'implémenter la XEP-0249.

D'un autre côté les extensions permettent des fonctionnalités alléchantes. Ainsi le « Federated MUC » (salons MUC fédérés, XEP-0289) permet de lier des salons entre eux pour qu'ils soient les miroirs les uns des autres. Ceci permet de choisir un serveur plus proche géographiquement de vous, ou d'avoir une solution de repli en cas de problème avec le vôtre. Des discussions sont en cours actuellement pour faire un « MUC 2 » basé sur « PubSub », bref XMPP est un protocole qui est loin d'être figé.

Bon tout ça c'est bien joli, mais IRC est tout de même un protocole qui fonctionne relativement bien, et qui est très populaire, ce serait bien de pouvoir communiquer avec.
XMPP gère des passerelles (ou « gateways » ou encore « transports »), c'est un moyen de communiquer vers un réseau extérieur sans rien modifier à votre client.

La passerelle est souvent sous forme d'un composant qui vient se greffer à votre serveur, et qui traduit le réseau externe (un peu pompeusement appelé « legacy » – réseau hérité – dans le jargon XMPP). La grande force de leur fonctionnement est que le mécanisme pour s'enregistrer est standardisé, et que pour votre client c'est du XMPP classique.
Une passerelle se concentrera la plupart du temps sur un réseau en particulier, et si elle est complète tentera de traduire le maximum voire toutes les fonctionnalités du réseau en question.

C'est la XEP-0100 qui explique le fonctionnement des passerelles, et elle réutilise – comme souvent – des XEP existantes, en l’occurrence « service discovery » dont on a parlé dans l'épisode 3, la XEP-0077 qui gère les enregistrements de comptes et la XEP-0144 (« Roster Item Exchange », échange d’éléments de la liste de contacts) pour l'ajout, la modification, ou la suppression des contacts (ou des « amis » sur les réseaux d'ours en peluche ou tout le monde s'aime et s'observe).
Disco permet, comme on l'avait vu, de nommer les passerelles, voire même pour les plus courantes d'avoir un type dédié. Ainsi il est possible d'identifier une passerelle IRC grâce au couple catégorie/type « conference/irc ».

Ci-dessous, une vielle capture de SàT, tirée de la première vidéo de présentation (2011 !) qui montre un gestionnaire de passerelles. Vous remarquerez peut-être qu'il y a une passerelle vers XMPP lui-même, elle peut être utile pour regrouper différents comptes XMPP si votre client ne le gère pas d'origine.

vieille capture gestionnaire passerelles SàT

Quelques remarques sur les passerelles:

  • souvent vous devez fournir un mot de passe pour vous connecter sur votre compte sur le réseau externe. C'est pratique car vous n'aurez pas à vous souvenir de X mots de passe (une fois enregistré dans la passerelle, plus besoin d'y penser), mais ça veut dire que vous le fournissez à la fois au serveur, et à la passerelle. Il vous faut donc faire confiance aux logiciels utilisés, mais aussi aux administrateurs des serveurs concernés. Encore une fois, il vaut mieux héberger soi-même son serveur.

  • vos communications passeront donc sur le serveur externe. C'est évident, mais il est bon de rappeler que le chiffrement de XMPP ou les précautions prises par vos administrateurs n'auront plus aucun effet une fois passé sur l'autre réseau (et donc selon le réseau, il est possible qu'on enregistre vos conversations, qu'on fasse du commerce avec vos données, etc). Il est toutefois possible d'utiliser du chiffrement de bout en bout dans certains cas, mais nous y reviendrons dans un futur article.

  • les fonctionnalités disponibles sont l'intersection de ce que sait faire XMPP, ce que sait faire/à implémenté votre passerelle, et de ce que sait faire/à implémenté votre client. Dans certains cas vous pouvez tout faire comme avec votre client d'origine du réseau externe (voire plus, avec le chiffrement de bout en bout par exemple), dans d'autres non.

  • si vous utilisez une passerelle vers un réseau non standard voire hostile, il est possible que votre passerelle cesse de fonctionner du jour au lendemain si le protocole change. Utilisez des standards !

Un service souvent utilisé pour les passerelles est Spectrum 2. Pour IRC, je vous recommande particulièrement biboumi: C'est fait par la même équipe que Poezio dont j'ai parlé précédemment, et c'est une passerelle très complète et vraiment simple d'utilisation.

Petit détail encore lié à la décentralisation de XMPP : si votre serveur n'a pas la passerelle que vous voulez, vous pouvez parfaitement utiliser une passerelle sur un autre serveur (si celui-ci ne l'interdit pas explicitement), mais cela veut dire que vous devez faire confiance à cet autre serveur pour votre identifiant/mot de passe et pour vos conversations.

Ce fonctionnement par passerelles standardisées et côté serveur permet d'avoir des logiciels qui se concentrent sur un réseau pour pouvoir communiquer avec le mieux possible, de garder le client qu'on apprécie et auquel on est habitué, d'éviter d'avoir à se souvenir de dizaines de mots de passes, d'avoir toutes nos communications au même endroit, ou encore de laisser les administrateurs s'occuper des mises à jour pour tout le monde d'un coup. C'est un gros atout dans la manche de XMPP.

Enfin, il existe aussi des techniques pour synchroniser un salon MUC XMPP avec un canal IRC (ou autre), qui vont du simple bot qui se contente de répéter tout entre les 2 salons (le plugins « Parrot » – Perroquet – permet de faire ça très facilement avec SàT), à celui un peu plus élaboré qui va créer plusieurs connexions sur IRC pour simuler les différents occupants du salon (c'est ce que faisait le désormais abandonné xib – merci Link Mauve pour le nom –). Cette dernière option risque de poser des problèmes avec les administrateurs du serveur IRC, aussi le mieux serait d'avoir un serveur multi-protocoles (ou tout le monde sur XMPP !).

Ceci clos notre tour des MUCs. Je n'ai pas parlé des détails comme les rôles car ils sont calqués sur IRC, et vous pouvez lire la XEP si vous voulez savoir vraiment comment tout cela fonctionne à l'intérieur. J'y reviendrai peut-être dans le futur pour expliquer d'autres XEPs, ou si MUC 2 voit le jour (ce qui semble bien engagé).
La prochaine fois je pense sortir un peu de la messagerie instantanée pour parler des commandes « ad-hoc » (de circonstance).

Parlons XMPP - épisode 4 - les discussions de groupes

(pour lire les épisodes précédents, suivez l'étiquette correspondante)

Dans le milieu du développement logiciel, et surtout dans le logiciel libre, les discussions de groupes sont très populaires, le plus souvent via IRC (Internet Relay Chat).
Ce vénérable protocole fait ce qu'on lui demande, et XMPP s'en est fortement inspiré. Voyons ça de plus près.

Les discussions de groupes utilisées actuellement sont appelées MUC pour « Multi-User Chat » et sont définies par la XEP-0045. Cette dernière standardise et étend la solution utilisée à l'origine, appelée « groupchat ». Comme tout ceci est calqué sur IRC, je vais expliquer au fur et à mesure les différences majeures avec lui.

Il est possible d'accéder à un salon situé sur n'importe quel serveur depuis n'importe quel serveur (encore une fois, tant que ça n'est pas explicitement interdit dans la configuration). Les salons ont un jid, comme les utilisateurs, qui est de la forme nom_salon@service. Par exemple celui de Salut à Toi est : « sat » est le nom du salon, « » le service.

La ressource est utilisée pour les occupants du salon: correspond à l'occupant appelé « goffi » sur le salon Ah, petit détail que j'ai oublié de vous préciser dans les précédents articles: tout est unicode en XMPP, y compris le jid. Vous pouvez donc utiliser un pseudo arabe ou russe. Mais attention : certains caractères unicodes se ressemblent fortement, aussi il peut y avoir un risque de confusion visuelle entre 2 mots qui se ressemblent graphiquement, qu'on appelle « homoglyphes » : par exemple « gοffⅰ » ressemble à « goffi » mais il utilise des caractères différents. Ce problème est mentionné dans un rapport technique unicode: Aussi, ne vous basez pas uniquement sur un pseudonyme pour identifier quelqu'un (surtout qu'il est possible qu'il soit réutilisé par quelqu'un d'autre entre 2 sessions).

Le pseudonyme (« nickname » ou « nick » en plus court) est lié au salon et non au service : vous pouvez vous appeler « toto » sur un salon et « titi » sur un autre, et il peut y avoir quelqu'un d'autre qui s'appelle « titi » également sur un troisième salon. Ceci est une autre grosse différence avec IRC où on a un seul pseudonyme par serveur, qui sera utilisé pour tous les salons (canaux ou « channels » chez IRC) de celui-ci.

Pour entrer ou sortir d'un salon, ou changer de pseudonyme, on envoie une présence disponible (ou pas) directement àésiré, mais ceci est normalement géré par votre client.

Il est possible d'écrire directement à tous les occupants du salon (en dessous c'est un message de type « groupchat » qui est envoyé au bare jid du salon), ou d'avoir une discussion privée avec un membre (on écrit normalement au jid complet – ou full jid – du destinataire).

Un salon peut être public ou caché (il n’apparaîtra alors pas dans la liste des salons), non anonyme ou semi-anonyme (dans le premier cas tout le monde peut voir le jid réel d'un occupant, dans le second seuls les modérateurs et administrateurs le peuvent), persistant ou temporaire, ouvert ou accessible uniquement à une liste blanche d'utilisateur ou encore protégé par un mot de passe, modéré ou pas.

Ces paramètres se règlent normalement à la création du salon, ou se modifient après coup via l'option idoine de votre client (sur Gajim : clique droit sur un onglet de salon => Gérer le salon => Configurer le salon). Selon le service utilisé, vous pouvez configurer plus ou moins de choses, par exemple limiter le nombre maximal d'occupants.

Une fonctionnalité souvent implémentée est l'historique, ou « back log » : quand vous arrivez dans un salon, le service vous envoie les X derniers messages, vous permettant ainsi de comprendre le contexte de la conversation en cours.

Aussi, si une archive publique du salon est conservée (on parle de salon « loggué »), le service doit vous avertir (c'est obligatoire dans la XEP), ce qui est un autre bon point par rapport à IRC. Il faut bien sûr garder à l'esprit que n'importe qui dans le salon peut garder une archive au risque de la publier sans votre consentement.

Bon tout ça c'est bien joli, mais une grande force d'IRC c'est sa simplicité : pas de compte à créer, il faut juste choisir un pseudo (unique), un serveur et roulez jeunesse ! Eh bien vous ne serez pas déçus, XMPP propose exactement la même chose avec les connexions dites « anonymes ». Pas d'anonymat au sens de Tor ici, mais plutôt la possibilité d'avoir un compte temporaire, avec un jid plus ou moins aléatoire, le temps de vous connecter. Ceci est disponible de base mais doit souvent être explicitement autorisé dans la configuration du serveur, et la plupart du temps les connexions anonymes sont limitées au serveur local, pas de communication avec les autres (pour éviter les pourriels).

Si vous voulez faire des conversations à la IRC de manière simple et intuitive, et si vous aimez la console, je vous recommande fortement Poezio qui est un excellent client XMPP, et qui joue la simplicité : de base, sans rien changer à la configuration, vous serez connecté anonymement sur le service MUC de Poezio. Il s'inspire de Irssi/Weechat, et reprend les commandes de ces derniers (ou plus généralement d'IRC). Ci-dessous le message au premier lancement, sans avoir touché à la configuration, on voit le jid anonyme attribué le temps de la session.

capture Poezio

Bon cet épisode est déjà suffisamment long, mais je n'ai pas fini avec les MUCs, aussi on en reparlera la prochaine fois, probablement avec les transports.

Libervia/Salut à toi aux RMLL à Beauvais toute la semaine

Salut à tous,

Nous serons présents avec Libervia/Salut à Toi pendant toutes les Rencontres Mondiales du Logiciel Libre à Beauvais, avec présence aux journées grand public (moi je n'y serai qu'à partir de dimanche, Souliane dès demain), puis au village associatif, et 3 conférences:

  • conférence « Libervia : repenser nos communications » lundi 6 juillet de 14h40 à 15h20 (salle 124) ;
  • table ronde/débat sur les nouveaux médias avec Timothée Jaussoin (Edhelas) de Movim, Pouhiou (Framasoft), Luc Fievet (April), Arno* (SPIP/SeenThis), Souliane et moi pour SàT, le lundi 6 juillet de 16h20 à 18h (amphi Brunuel) ;
  • PubSub, microblogage et XMPP jeudi 9 juillet de 15h00 à 15h20 (salle 203/204).

Si vous passez dans le coin, c'est l'occasion de discuter de vive voix.

Parlons XMPP - épisode 3 - le cœur et les extensions (suite)

(pour lire les épisodes précédents, suivez l'étiquette correspondante).
En plus de cette partie centrale, des fonctionnalités peuvent être ajoutées, d'où le X de XMPP (pour eXtensible).
Les extensions sont rédigées sous la forme de « XEP » (XMPP Extension Protocol), idée héritée — si je ne m'abuse — de Python. C'est de cela qu'on parle quand on voit les cryptiques XEP-0XXX dans les fonctionnalités gérées d'un serveur ou d'un client. Pas besoin évidemment de savoir cela pour utiliser un client XMPP, mais il peut être utile de lire une extension (elles se trouvent sur pour bien comprendre à quoi sert une fonctionnalité. Deux parties sont particulièrement utiles sans avoir à entrer dans les détails d'implémentation : la partie « abstract » (résumé) tout en haut qui indique ce que la XEP fait, et la section « introduction » (la toute première section) qui explique un peu plus les raisons et les cas d'utilisations de l'extension.
résumé de la XEP-0045
Une XEP peut décrire une fonctionnalité, une procédure (par exemple la XEP-0001 explique le cycle de vie des XEPs elles-mêmes), un héritage historique (c'est à dire le fonctionnement de quelque chose créé avant la XMPP Standard Foundation), une information (comme des bonnes pratiques), voire une blague (si si, y'a des histoires de toto dans les XEPs aussi !). Elle peut avoir plusieurs statuts (expliqués dans la XEP-0001, je ne sais pas s'il existe une version traduite en français quelque part). Il est intéressant de noter que beaucoup de XEPs sont « experimentales », et donc techniquement pas (encore) des standards, mais souvent implémentées tout de même. De telles XEPs peuvent changer fortement avant le passage au statut de « brouillon » (« Draft »), puis de standard final.
Pourquoi je vous parle de tout ça ? Pour que vous compreniez bien une chose: XMPP ce n'est pas que de la messagerie instantanée !
Voici quelques exemples d'extensions intéressantes:
  • Extended Stanza Addressing (Adressage de « stanzas » étendue, XEP-0033): permet d'envoyer un message à plusieurs destinataires à la fois, ou de faire des copies carbones ou des copies carbones invisibles (comme le … oui oui vous voyez où je veux en venir)
  • Multi-User Chat (Discussions multi-utilisateurs, XEP-0045): les discussions de groupes, à la IRC.
  • Ad-Hoc Commands (commandes de circonstance, XEP-0050): un système générique pour gérer tout type de commandes. Lié aux permissions des utilisateurs, c'est un outil absolument génial !
  • vcard-temp (Cartes virtuelles, version temporaire, XEP-0054): la façon historique de gérer des cartes de visites, une sorte de profil public. Une nouvelle extension va la remplacer à terme (la XEP-0292)
  • Jabber Search (Recherche Jabber/XMPP, XEP-0055): pour chercher des jid, utilisé en général par les annuaires.
  • Publish/Subscribe (Publication/Abonnement, XEP-0060): un très gros morceau, qui permet la publication de tout type d'information, et sa récupération en fonction de permissions, avec un système de notification en temps réel.
  • XHTML-IM (XEP-0071): pour publier avec un sous-ensemble de XHTML, c'est à dire avec une mise en forme (écrire en gras ou mettre une image par exemple).
  • Gateway Interaction (Communication avec les passerelles, XEP-0100): permet de gérer les passerelles, c'est à dire des liens avec des réseaux extérieurs
  • Personal Eventing Protocol (protocole d'événements personnels, XEP-0163): une sorte de Publish/Subscribe simplifié
  • Jingle (XEP-0166): Négociation de session pair à pair (P2P), avec un grand nombre d'applications possibles, la plus connue étant la visioconférence.
  • Serverless Messaging (Communication sans server, XEP-0174): permet, comme indiqué, de se passer des serveurs
  • Message Archive Management (gestion des archives des messages, XEP-0313): permet de récupérer des messages ou autre (ça fonctionne aussi avec publish/subscribe) selon certains critères comme une date. Utilisé notamment pour avoir votre historique de conversations sur votre serveur (et ainsi y accéder depuis tous vos clients).
Et dites-vous bien qu'on ne vient que de gratter la surface.
Plusieurs de ces extensions seront expliquées dans de futurs articles.
À noter aussi qu'on utilise souvent des noms courts pour désigner les extensions par exemple « MAM » pour « Message Archive Management ». Ces noms sont normalement indiqués en fin de XEP, dans les appendices (« Document information »): c'est le « short name » (nom court).
Avec toutes ces extensions, on va se retrouver avec des clients ou serveurs qui gèrent l'une ou l'autre, comment se mettre d'accord ? Eh bien grâce à une autre extension (mais tellement indispensable et couramment implémentée qu'on peut presque la considérer comme standard de base): « Service Discovery » (découverte de services, XEP-0030, nom court : « disco »)).
Le principe est simple, chaque client ou serveur ou composant (un composant est un service qui vient se greffer à un serveur, voir plus bas) dit qui il est, ce qu'il sait faire, ou les éléments associés.

qui il est

Une adresse XMPP (le jid) peut être utilisée par beaucoup de monde: un serveur, un client, un « bot » (robot, nom qu'on utilise pour un programme qui automatise des tâches, agissant souvent comme un client), une passerelle, etc.
Quand un client (ou autre) en voit une, il est utile de savoir à quoi on parle, par exemple pour afficher de telle ou telle façon dans l'interface (c'est grâce à cela que votre client peut afficher une passerelle d'une autre façon que les clients normaux).
C'est l'identité de disco qui permet ça, et elle donne une catégorie (par exemple « client » ou « serveur »), un type (dans client par exemple ça peut être « bot », « web », « game » — jeu —), et un nom libre (par exemple « ejabberd »). Vous avez une liste des différentes catégories et les types associés ici :

ce qu'il sait faire

XMPP grâce à son côté extensible, est très riche en fonctionnalités, aussi il est indispensable de savoir ce que le logiciel avec lequel on discute est capable de faire. Ce sont les « features » (fonctionnalités) indiquées par disco, c'est pour cette raison que parfois quand vous discutez avec quelqu'un une icône est grisée, par exemple la visioconférence: cela indique que le client en face indique qu'il ne sait pas la faire, ou plus exactement n'indique pas qu'il sait la faire.
Ces fonctionnalités sont liées à des espaces de nommage (namespaces) qui sont indiqués dans les XEPs concernées, vous avez aussi une liste qui permet de retrouver une partie des XEPs depuis un espace de nommage ici :

les éléments associés

En plus de l'identité et des fonctionnalités disponibles, une entité XMPP peut avoir des éléments associés. Ce peut être un serveur qui indique que des salons de discussions sont disponibles à telle adresse, ou une passerelle vers tel réseau.



Pour que cela soit plus clair, prenons un exemple. « jp », l'interface en ligne de commande de Salut à Toi, permet d'obtenir le disco d'une entité avec la commande « jp info disco », essayons avec le serveur :
% jp info disco
ejabberd (server/im)
On voit ici que sait gérer la version historique des vcards (vcard-temp, XEP-0054) ou les commandes ad-hoc (, XEP-0050), qu'on discute avec un serveur (server/im) qui s'appelle « ejabberd ». On voit également que plusieurs services sont disponibles, par exemple Regardons de plus près :
% jp info disco
Public Chatrooms (conference/text)
JabberFR (13) []
On voit qu'on a affaire à un service de salons de discussions (conference/text), qui utilise le protocole « Multi-User Chat » (discussions multi-utilisateurs,, qui est à ce jour le seul disponible pour les discussions de groupes (nous y reviendrons). Les éléments « Items » contiennent ici la liste des salons, avec le nom, le nombre d'occupants, et le jid correspondant, j'ai tronqué la liste qui était très longue.
Dans les informations de, vous avez peut-être remarqué la section « extensions », il s'agit d'une XEP (la XEP-0128) qui permet d'étendre disco pour tout type d'informations, dans le cas d'ejabberd ici, c'est pour indiquer les adresses de contact du serveur, mais elles ne sont pas renseignées pour
Ci-dessous, la fenêtre disco de Gajim:
disco chez Gajim
La première fois que j'ai essayé XMPP, avec Psi au début des années 2000, j'ai été un peu intimidé par le menu « service discovery », qui permet d'afficher quasi directement les informations que nous venons de voir. Ce genre de menu est souvent, à mon sens, affiché un peu trop « brut » dans les clients XMPP : utiliser disco directement (c.-à-d. en dehors de ce qui est automatisé par le client) relève déjà de l'utilisation avancée.
En bonus, je vais rapidement évoquer l'extension « software version » (version logicielle, XEP-0092) qui permet, comme son nom l'indique, de savoir à quel logiciel on parle, et le système d'exploitation utilisé. jp permet d'afficher ces informations avec « jp info version », essayons sur :
% jp info version
Client name: ejabberd
Client version: 2.1.13
Operating System: unix/linux 3.2.0
On connaît désormais la version d'Ejabberd utilisée, pratique quand on veut savoir si une fonctionnalité est présente, ou un bogue corrigé. Et cela fonctionne avec toute entité qui implémente la XEP, pas uniquement les serveurs:
% jp info version
Client name: MU-Conference
Client version: 0.9-svn (Jan 27 2014)
Operating System: Linux 3.2.0-4-amd64
Voilà, connaître les extensions permet de vraiment savoir ce qu'on peut faire avec un client ou un serveur. La prochaine fois je pense m'attaquer aux discussions de groupes, et voir ce qui change par rapport à IRC.

Parlons XMPP - épisode 2 - le cœur et les extensions

Maintenant qu'on sait de quoi on parle, voyons à quoi ressemble le cœur du protocole.
À la base XMPP c'est 3 (anciennement 2) RFCs: la 6120, la 6121, et la 6122 (il y en a d'autres, mais ces 3 là sont les principales). Elles expliquent tout le cœur comme l'envoi de messages, les informations de présence, les statuts, etc.
Sans trop entrer dans les détails qui vont concerner surtout les développeurs, on peut rapidement expliquer que XMPP se base sur 3 types d'éléments, ou « stanzas »:
  • <presence/> pour indiquer principalement… notre information de présence (parfois on y accroche aussi d'autres choses comme des infos sur notre avatar ou nos capacités, mais ne nous égarons pas). La présence est relayée par votre serveur à toutes les personnes à qui vous avez donné l'accès (voir plus bas).
      On peut associer un état et un message à notre présence. L'état peut être un des suivants (les noms peuvent changer selon votre client)
    • disponible (par défaut): vous êtes en ligne normalement
    • away (absent): vous êtes absent pour une courte période
    • chat (discussion): vous avez particulièrement envie de parler
    • dnd (do not disturb – ne pas déranger): vous êtes occupé (souvent appelé « busy » aussi dans les clients)
    • xa (eXtended Away – durablement absent): vous êtes absent pour une longue période
      Le message de statut permet spécifier en langage clair votre disponibilité (par exemple « je regarde un film, ne pas déranger »), même si en pratique c'est utilisé pour tout type de message (beaucoup de gens mettent une citation par exemple).
  • <message/> un envoi de message de type j'envoie et j'oublie. Il existe 5 types de messages :
    • chat (discussion): le plus connu, celui qui sert à la messagerie instantanée simple
    • error (erreur): celui-là est normalement géré par les logiciels directement, il se traduit souvent par un fenêtre vous indiquant dans votre client que quelque chose s'est mal passé
    • groupchat (discussion de groupe): comme « chat », mais pour les discussions à plusieurs. En pratique la différence ne concerne que les développeurs et cela devrait être transparent dans le client
    • headline (manchette): un message important, une annonce. Normalement, ces messages ne sont pas gardés hors ligne, aussi si vous n'êtes pas connecté au moment du message, vous ne devriez pas l'avoir. Ces messages ne sont pas faits pour y répondre. Un exemple typique est une annonce de maintenance du serveur imminente
    • normal : un type méconnu et pourtant intéressant. Il s'agit d'un message ayant généralement un sujet, et en dehors d'une conversation instantanée. Oui oui, exactement comme un courriel ! C'est plus ou moins son équivalent XMPP.
    À cela s'ajoute la gestion des « thread » (fils de discussion), mais nous en parlerons une autre fois.
  • <IQ/> (Info/Query – information/requête): utilisé pour tout ce qui est de type question/réponse (il est obligatoire de répondre à une requête <IQ/>, au pire par une erreur). Son utilisation concerne plutôt les développeurs, c'est la base de la plupart des fonctionnalités que vous utilisez : cet élément sert à dire « je veux connaître ou modifier telle information »
Je ne veux pas trop entrer dans les détails techniques, mais il me semble essentiel de connaître les différents types de messages et de présences pour bien comprendre son client.
À noter un point excellent avec XMPP, et largement sous exploité : XMPP sait nativement gérer les différentes langues, grâce à son héritage de XML (xml:lang). Autrement dit, vous pouvez spécifier un message normal ou de statut à la fois en français, en allemand et en slovaque. C'est un atout majeur que nous comptons bien exploiter dans Libervia.
Passons maintenant à une autre partie essentielle : la liste de contacts.
Dans le monde XMPP, on l'appelle « roster » (qui se traduit par « liste » ou « tableau de service »). À chaque contact que vous y ajoutez, vous pouvez associer 0, 1 ou plusieurs groupes (« famille », « amis », etc), un nom (donné par l'utilisateur et non le contact), ainsi qu'une information d'abonnement (« subscription »).
L'abonnement permet de savoir si vous avez autorisé votre contact à avoir votre information de présence, et si le contact vous a autorisé à voir la sienne. C'est pour cela que quand quelqu'un vous ajoute dans sa liste de contacts, votre client, par exemple Gajim, vous demande si vous l'autorisez à connaître votre information de présence. Il est tout à fait possible d'avoir autorisé un contact à vous voir sans qu'il ne vous autorise à le voir (et inversement évidemment), voir qu'aucun des deux ne soit autorisé à voir la présence de l'autre (mais je pense que la plupart des clients suppriment le contact du roster dans ce cas).
Les groupes sont associés aux contacts, et non l'inverse (ce n'est pas une liste  liste de groupes qui contiennent des contacts), c'est la raison pour laquelle il est impossible d'avoir un groupe sans contact associé (c.-à-d. vide).Là encore les groupes sont à mon sens sous-exploités dans le monde XMPP, nous y reviendrons.
Voilà pour aujourd'hui. J'ai finalement préféré couper la partie extensions pour le prochain article, pour éviter de trop charger.

Parlons XMPP - épisode 1 - les bases

Salut à Vous,
Bon, comme je trouve vraiment dommage que XMPP soit mal connu ou compris, j'ai décidé de commencer une série d'articles pour vous expliquer ce que c'est.
Ces articles sont destinés à un public averti, mais pas forcément de développeurs, et j'espère qu'il vous aidera à comprendre les intérêts de ce protocole et à mieux utiliser vos logiciels.
Étant développeur du projet Salut à Toi, je donnerai probablement souvent des exemples avec.
Donc commençons par les bases.
XMPP c'est quoi ? C'est un protocole de messagerie et de présence standard, et extensible (XMPP signifie « eXtensible Message and Presence Protocol », soit « protocole de présence et messagerie extensible »), c'est à dire qu'il est documenté et utilisé comme une référence (ici validée par un organisme de standardisation : l'IETF). Ceci permet à tous les logiciels qui l'utilisent de parler la même langue, et d'être interopérables. Il s'agit d'un protocole libre, c'est à dire que vous pouvez obtenir la documentation et l'utiliser gratuitement, sans restriction légale ou technique, et que vous pouvez l'améliorer ou le modifier (mais si vous déviez et que vous ne proposez pas vos modifications, vous risquez de perdre la compatibilité avec les autres logiciels).
XMPP est décentralisé et fédéré, c'est à dire que vous pouvez avoir des serveurs un peu partout, ils pourront (s'ils ne l'interdisent pas explicitement dans leur configuration) communiquer entre eux.
C'est un protocole populaire, de nombreux logiciels permettent de l'utiliser : en serveurs on peut citer Prosody, Ejabberd, Open Fire, Tigase,, Metronome, etc. En client: Gajim, Poezio, Pidgin, Psi, Swift, Jappix, Movim, et bien sûr Libervia/Salut à Toi (je vous laisse chercher les sites officiels vous-même). Une liste plus complète (serveurs, clients et bibliothèques) est disponible ici:
Si vous ne voulez pas installer un serveur chez vous, de nombreux serveurs publics sont disponibles: en France on peut citer ceux de l'APINC (,, etc), de La quadrature de Net, etc. Une petite liste (la page n'est pas à jour, n'hésitez pas à contribuer !) est disponible ici en français, sinon vous pouvez regarder sur ou (oui il y en a beaucoup !). Mais je vous recommande très fortement d'installer votre propre serveur ou de vous approcher d'une association locale avec qui vous pouvez communiquer facilement : d'une part si vous installez vous-même, ça vous permet de mieux maîtriser vos données, et d'autre part si vous voulez une fonctionnalité en particulier, il vaut mieux pouvoir demander facilement aux administrateurs une mise à jour.
Bon maintenant qu'on sait tout ça, essayons de créer un compte.
Une fois un serveur installé ou un serveur public choisi, vous pouvez créer un compte. Vous aurez alors une adresse, un « jid » (pour Jabber ID, « Jabber » est l'ancien nom du procole, ce nom appartient désormais à une société privée, il est juste gardé ici pour des raisons historiques).
Cette adresse est de la forme nom_local@domaine.tld/ressource, ou en forme canonique (ce qu'on appelle le « bare jid ») nom_local@domaine.ext. Par exemple la mienne est . Celà ne vous rappelle rien ? Et oui ça ressemble beaucoup aux adresses de courrier électronique !
Mais alors c'est quoi la ressource ? La ressource est liée au logiciel client que vous utilisez pour vous connecter : XMPP a été pensé dès l'origine pour permettre à plusieurs clients de se connecter en même temps (il y a 10 ans, peu de protocoles de messagerie le permettaient, et se reconnecter ailleurs signifiait souvent la déconnexion du premier client), et cette ressource permet de les identifier. Autrement dit, vous n'avez une ressource que quand vous êtes connectés, et elle est différente pour chaque client que vous utilisez : si je me connecte avec Libervia, Gajim et Movim, j'aurais 3 ressources différentes.
Il y a eu plusieurs écoles pour nommer la ressource, parfois on s'en servait pour indiquer le lieu de connexion (« maison », « bureau »), les clients mettaient souvent leur nom par défaut (« gajim », « psi »). Aujourd'hui, il est admis qu'il vaut mieux avoir une ressource non prédictible, car sinon quelqu'un peut savoir si vous êtes connectés ou pas (même si vous ne souhaitez pas que ça se sache) en faisant une requête à cette ressource. Il vaut donc mieux laisser le serveur choisir la ressource pour nous.
Enfin, votre ressource est associée à une priorité: elle permet de déterminer, si plusieurs ressources sont connectées, laquelle va recevoir le message. Mais nous y reviendrons plus tard.
Dans le prochain épisode je vous parlerai des extensions et de la découverte de fonctionnalités.
Voilà, dites-moi si vous êtes intéressés par cette série, si cela vous semble trop technique, ou si vous avez des remarques ou des corrections à faire. Je publie la série en même temps sur DLFP, et le tout est sous licence CC By-SA, donc n'hésitez pas à réutiliser, diffuser ou modifier !

Campagne d'adhésion pour financer le développement de Libervia

Salut à vous !
Ça y est, on y est, c'est le lancement de la campagne d'adhésion à l'association « Salut à Toi ». Cette campagne, si elle réussit, va nous permettre de nous salarier et développer le projet pendant 1 an, de sortir une version stable pour la fin d'année, et de préparer plusieurs évolutions.
Avant tout un petit rappel, sur Libervia et Salut à Toi. Ci dessous une vidéo courte (3 min) expliquant le projet:
Libervia est donc un outil de communication (ou « réseau social » comme disent certains) qui se distingue par plusieurs points. Il est multi-interfaces, et non web uniquement, il se base sur un standard (XMPP) ce qui le rend compatible avec d'autres logiciels comme Gajim, Jappix ou Movim, et il suit une ligne éthique et philosophique claire, notamment expliquée dans son contrat social.
Le projet est déjà bien avancé et utilisable, il est disponible dans des distributions GNU/Linux comme Debian ou Arch (mais les versions commencent à dater, nous en avons une nouvelle proche de sortir), et vous pourrez voir en consultant le site officiel qu'il offre des fonctionnalités originales.
Nous souhaitons qu'il soit développé dans un cadre éthique et solidaire aussi nous cherchons à nous salarier à travers une association loi 1901 autogérée.
Si la campagne est un succès, nous prévoyons les évolutions suivante:
  • une version stable et utilisable par le grand public pour la fin d'année 2015
  • des passerelles vers d'autres réseaux libres, comme Diaspora*, SeenThis, ou SMTP
  • une version permettant des connexions anonymes (via TOR)
Ceci est réalisable en 2015. Pour l'année 2016 nous envisageons:
  • la création d'un boitier pré-installé, qu'il suffira de brancher sur sa connexion Internet
  • l'intégration du projet dans d'autres logiciels libres comme Blender, GIMP ou Inkscape, afin de pouvoir travailler avec ses contacts sans quitter lesdits logiciels. Cette partie est particuièrement excitante et ambitieuse, mais demandera beaucoup de travail.
Afin de ne pas surcharger ce billet je n'entrerai pas plus dans les details, nous avons rédigé une dépêche pour le site de référence linuxfr expliquant plus en longueur (et de façon plus technique) les projets à venir (je mettrai le lien quand la dépêche sera publiée). Le site officiel est bien sûr une autre source d'informations, et vous pouvez nous rejoindre sur le salon XMPP
Nous travaillons à plein temps sur le projet avec nos propres resources, aussi la question du financement se pose sérieusement. Si vous voulez soutenir un projet qui a de nombreuses possibilités, libre et éthique, c'est le moment !
Vous pourrez nous rencontrer cet été:
  • à Pas Sage En Seine cette semaine: conférence « Libervia : repenser nos communications » jeudi 18 juin de 13h à 14h
  • au RMLL à Beauvais, avec 3 conférences et la présence au village toute la semaine:
    • conférence « Libervia : repenser nos communications » lundi 6 juillet de 14h40 à 15h20 (salle 124) ;
    • table ronde/débat sur les nouveaux médias avec Timothée Jaussoin (Edhelas) de Movim, Pouhiou (Framasoft), Luc Fievet (April), Arno* (SPIP/SeenThis), Souliane et moi pour SàT, le lundi 6 juillet de 16h20 à 18h (amphi Brunuel) ;
    • PubSub, microblogage et XMPP jeudi 9 juillet de 15h00 à 15h20 (salle 203/204).
  • en Allemagne les 22 et 23 août pour la FrOSCon (University of Applied Sciences Bonn-Rhein-Sieg), pas de conférence cette fois, mais un stand.

Maintenance le dimanche 26 avril 2015

Comme vous l’avez sûrement remarqué, nos certificats pour les domaines et sont expirés. La plupart des clients affichent un message d’avertissement à chaque connexion à cause de ça.

De nouveaux certificats ont été générés, et seront mis en place ce dimanche 26 avril 2015 aux environs de 10h du matin, heure française, entraînant une coupure de quelques minutes.

Comme à notre habitude, vous serez informés de l’état de la maintenance par des mises à jour de ce billet. :)

Mise à jour du 26/04/2015 à 11h15 : après quelques péripéties avec le nouveau certificat, la maintenance est terminée !

Maintenance exceptionnelle le dimanche 29 mars 2015

Bonjour à tous !

Suite à une faille présente dans une bibliothèque que Prosody utilise, ce serveur a été redémarré en urgence. Pour plus d’informations sur cette faille, vous pouvez lire les notes de version de Prosody 0.9.8 (en anglais)

mu-conference, notre serveur de conférences, sera redémarré ce mercredi premier avril à 20h (et c’est pas une blague !) afin de corriger quelques problèmes de connexion.

Votre nouvel administrateur, Link Mauve. :)

Mise à jour du 01/04/2015 à 21h45 : mu-conference a été correctement relancé, la connexion à la base de données est rétablie.

Changement dans l’équipe d’administration du serveur JabberFR


Suite à une décision unanime des administrateurs du serveur JabberFR, une nouvelle personne rejoint l’équipe : il s’agit d’Emmanuel Gil Peyrot (Link Mauve). Certains d’entre vous le connaissent déjà vu qu’il est un membre actif de JabberFR.

J’en profite également pour officialiser le départ de Grégoire Menuel (omega). Merci à toi pour toutes ces années de bonheur. Dif tor heh smusma.

L’équipe d’administration est donc actuellement composée de deux personnes : Link Mauve et moi-même (elghinn).

Maintenance exceptionnelle le dimanche 22 mars 2015

Une maintenance exceptionnelle du serveur de JabberFR, entraînant l’arrêt complet de tous les services, aura lieu dans la journée.

Vu le caractère exceptionnel, pas d’heure de début ni d’heure de fin, et encore moins de programme. Plus d’informations en fin de journée.

Mise à jour de 12h00 : Mise à jour de prosody vers la 0.9.7 et désactivation du mod legacyauth.

Firefox OS: pas encore convaincu

C'est pas que j'aime les téléphones, mais j'ai un petit côté curieux et mon dernier téléphone premier prix a lâché dans des circonstances pour le moins mystérieuses (et pile 2 mois après la fin de la garantie). Manque de bol, ça tombe à un moment où je n'ai pas de ligne fixe ni Internet, et où j'ai besoin d'être joignable.

C'est pas que j'aime acheter des trucs un peu gadgets, mais on parle de Firefox OS en ce moment. Vu qu'il y a un téléphone à vraiment pas cher, et que j'envisage de porter « Salut à Toi » sur cette plate-forme, c'est l'occasion.

Premier essai: une boîte qui fait parler d'elle pour sa campagne de pub sexiste actuellement (j'ai commandé avant ladite campagne). Tout se passe normalement, confirmation, j'attends un peu. Et je reçois un gentil courriel qui me traite de pirate (potentiel), et me demande tenez-vous bien: une photocopie recto-verso de ma carte d'identité et un justificatif de domicile, rien que ça ! Y'a des gens qui acceptent ça sérieusement ? En tout cas j'ai gentiment annulé ma commande et été voir ailleurs, en laissant un message pour l'occasion.

Deuxième essai plus concluant, j'ai tout de même perdu une semaine au passage, à un moment où j'avais besoin d'être joignable...

Le gadget arrivé, je peux tester. Pas trop de commentaires sur le téléphone, ce sont tous des clones aujourd'hui de toute façon.

Ça démarre, le petit renard/panda avec sa queue en feu est joli, ça donne une impression de fini, c'est sympatoche. On me demande si je veux être géolocalisé: bon on me demande c'est déjà ça, mais pourquoi ? Je réponds bien évidemment non. Plus tard la page d'accueil me le redemandera, je ne sais pas pourquoi, mais je sais que ça ne me plait pas du tout. Petit message sur les logiciels libres et l'esprit d'ouverture, j'aime bien.

Après ça ressemble à du très classique: des boutons, des applications. J'ai le regret de voir des saletés comme fb et twitter pré-installées, je suppose que ça vient du constructeur et je supprime. Le système de recherche est pas mal.

Je vérifie la version, c'est Firefox OS 1.3. Je regarde rapidement le « firefox marketplace », là encore du très classique. Je regrette beaucoup l'absence d'indication « logiciel libre »: ça m'aiderait à choisir beaucoup plus sereinement ce que je peux installer. C'est d'autant plus malheureux que Mozilla en fait son cheval de bataille. F-droid devrait être pris en exemple ici, non seulement tout est libre dessus, mais en plus on a des liens vers le code source, et les « anti-fonctionnalités » (espionnage, publicité, etc) sont indiquées clairement.

Aussi j'ai l'impression que beaucoup « d'applications » sont en fait des sites webs déguisés, et là ça me ferait une belle jambe d'avoir du libre. J'espère que Firefox OS ça ne veut pas dire tout avoir sur des serveurs distants: je veux des vrais logiciels sur mon téléphone, qui marchent hors ligne.

Je cherche une application de navigation GPS, qui gère au possible le hors ligne, Evernav me semble la plus adaptée. C'est une application très basique de navigation, qui se proclame la seule sur Firefox OS qui fait de la navigation avec indication des tournants. Il est marqué « fonctionne sans connexion », bien je cherche justement de la navigation hors ligne. La description n'est pas traduite, et l'application n'est pas disponible en français... moi ça ne me gêne pas, mais je pense que ça ne doit pas être le cas de tout le monde.

En pratique, l'application est quasi inutilisable: la « navigation hors ligne » est en fait un cache et je ne vois pas trop comment on peut lui indiquer quelles cartes on veut précisément. Je n'ai pas pu trouver ce que je cherchais, pas gégé. En plus la création d'un compte est obligatoire pour utiliser le guidage  (!), j'en ai fait un vite fait en utilisant une adresse jetable, mais le principe m'énerve. L'application est propriétaire et payante. Bref, je n'aime pas du tout et supprime.

L'application installée de base, « Here » de Nokia arrive à trouver ce que je cherche, et le chemin est calculé facilement. Mais il n'y a pas de guidage, et là encore c'est du proprio. Au moins la création de compte n'est pas obligatoire.

Un des intérêts principaux d'un ordiphone pour moi, c'est d'avoir une application de guidage qui fonctionne hors ligne, et qui ne m'espionne pas. OsmAnd~ (la version compilée par F-droid) est parfaite de ce point de vue, j'espère la voir portée sur Firefox OS (ce qui devrait être possible avec emscripten, l'application étant en C++, mais ça va sûrement demander beaucoup de travail). L'absence d'un équivalent est un frein majeur pour utiliser Firefox OS de mon point de vue.

En dehors de ça, l'absence de copier/coller ne me gêne pas, l'absence d'écriture par les gestes un peu plus mais ça n'est pas indispensable. Par contre l'absence de bouton « retour » qui oblige a chercher dans l'application l'équivalent me gêne *énormément*, je ne comprends pas cette décision de Mozilla. C'est peu intuitif, pas pratique du tout, voire carrément insupportable.

Au niveau téléphonie ça marche comme on l'attend, rien à dire. Ah si je n'ai pas réussi à avoir les détails d'un message (heure de réception), je n'ai trouvé que l'heure du début de la conversation, ce qui est assez gênant pour un message du type « on se retrouve dans 20 min ».

À noter aussi des redémarrages intempestifs, problème de jeunesse qu'on pouvait prévoir, mais dommageable sur une version stable en production. Enfin je suis dév, je sais ce que c'est.

J'ai voulu faire une mise à jour pour voir si ça corrigeait ça, rien d'officiel sur le site du constructeur (ma 1.3 semble la plus récente), je cherche donc sur le net et tombe sur un billet de développeur qui m'indique comment faire. Aïe, il faut windows et je n'en ai pas... La faute au constructeur encore une fois, mais c'est plus que malheureux. Tant pis je tente le coup en téléchargeant quand même et en tentant de flasher moi même. M'intéressant assez peu aux téléphones, je n'ai pas encore l'habitude des archi Android (Firefox OS utilisant la même base), mais je trouve rapidement de quoi faire: fastboot est disponible dans ma Debian, et m'évite l'installation du SDK Android à la main. Dans l'archive pour rooter le téléphone, je trouve des images notamment pour les partitions recovery, boot et system. Les deux premières se flashent sans soucis, mais pas moyen d'envoyer la 3ème, probablement à cause de sa taille. Résultat, je n'ai plus de partition système, et mon téléphone ne boot bien évidemment plus (ma faute, pas celle de Mozilla ou du constructeur :)).

Ne voyant pas de solution simple pour rattraper le coup avec Firefox OS, je décide de temporairement passer à CyanogenMod, à l'aide de cette version, je l'installe sans les google apps.

Au final, je me retrouve avec tout ce que je veux: F-Droid, OsmAnd~, j'ai pu récupérer mes contacts grâce à SlightBackup, et je n'ai pas de compte google lié au téléphone. Le port marche très bien et c'est fluide, et en plus les application Firefox OS peuvent marcher via Firefox dispo sur F-Droid. Je ne vois pas pour le moment ce que Firefox OS m'apporte de plus au niveau vie privée. Aussi, il ne faut pas oublier que l'utilisation d'un téléphone portable est déjà une grave atteinte à la vie privée, et que l'opérateur sait à tout moment où on se trouve avec ces saletés :(.

Enfin bref, je salue tout de même l'arrivée de Mozilla qui reste une boîte en qui j'ai à peu près confiance, et l'effort des équipes de dév, je pense juste que c'est encore jeune. Je reviendrai sûrement rapidement à Firefos OS, ne serait-ce que pour porter « Salut à Toi ».

Ce que j'aimerais:

  • une indication « logiciel libre » dans le gestionnaire d'applications (enfin « marketplace » pour son terme commercial)
  • une vraie application libre de navigation hors ligne, un port de OsmAnd~ serait idéal
  • la possibilité de coder en python. Pour le moment je vois 2 solutions: un transpileur à la Pyjamas, ou le port de Python (déjà fait) via emscripten, reste à voir si on peut accéder à tout le nécessaire pour une véritable application, et ce que donnent les performances. Un port de Kivy serait idéal.
  • un bouton « retour » !!!
  • moins important, mais agréable: la possibilité d'écrire avec des gestes

et bien sûr, je suis très gêné par l'accord entre Mozilla et Foxconn, même si j'ai conscience que mon téléphone premier prix vient de là et qu'il n'a pas dû être fait dans des conditions de travail exemplaires. J'ai un peu honte de financer ça en l'achetant :(. La solution idéale serait de jeter ces fichus téléphones aux chiottes, mais c'est une autre histoire.

Ceci dit, je pense que Mozilla est assez proche d'arriver à quelque chose de pas trop mal, et je souhaite bon courage aux équipes qui bossent dessus. Je vais suivre de plus ou moins loin l'évolution, et tenter de développer dessus sous peu j'espère.

Astuce du jour: utiliser Konqueror pour avoir un aperçu temps réel.

Salut à vous,

comme je fais actuellement de l'édition de XEP (extension XMPP), je dois utiliser les outils fournis par la XSF (XMPP Standards Foundation) en console. Moi ça me va, je peux utiliser mon vim habituel, avec syntastic qui me dit quand il y a une erreur, etc. Seulement j'aimerais bien avoir un aperçu en temps réél de ce que j'édite. Pas de soucis, Konqueror vient à la rescousse, car il a le bon goût d'être pilotable via D-Bus.

J'entre la commande magique suivante dans une console:

$ while true; do; inotifywait -e modify xep-proto-namespace-delegation.xml; echo transformation; xalan -in xep-proto-namespace-delegation.xml -xsl xep.xsl  -out xep-proto-namespace-delegation.html -html; echo rafraichissement; qdbus $(qdbus org.kde.konqueror\*) /konqueror/MainWindow_1 reload; done

et maintenant, à chaque enregistrement de mon fichier, Konqeror m'affichera l'aperçu en cours.


while true; do;

ça c'est facile, on tourne en boucle jusqu'à ce que je presse C-c pour tout stopper.

inotifywait -e modify xep-proto-namespace-delegation.xml;

Cette commande très pratique permet de réagir à un évenement inotify. inotify est une fonction du noyau Linux qui fournit des notifications en cas d'évenement. Là je demande à la commande de bloquer jusqu'à ce que le fichier xep-proto-namespace-delegation.xml que je suis en train d'éditer soit modifié. En d'autres termes, ça bloque jusqu'à ce que je fasse mon :w dans vim.

echo transformation; xalan -in xep-proto-namespace-delegation.xml -xsl xep.xsl  -out xep-proto-namespace-delegation.html -html;

Là on est dans la partie spécifique à XMPP, j'indique que je veux transformer mon fichier xml en HTML (xalan est un outil qui utilise XSLT pour transformer de l'XML, le xep.xsl étant fourni par la XSF). Le echo étant bien sûr juste pour m'indiquer qu'on fait la transformation.

echo rafraichissement; qdbus $(qdbus org.kde.konqueror\*) /konqueror/MainWindow_1 reload;

Ici on a la partie intéressante. D'abord j'indique avec le echo qu'on va faire un « rafraichir » sur le Konqueror en cours. Le problème c'est que le nom de service de Konqueror n'est pas toujours le même, c'est org.kde.konqueror-[pid du konqueror en cours]. Il serait assez facile de retrouver le pid, mais ici je préfère utiliser une fonctionnalité de qdbus pas forcément connue (qdbus étant très mal documenté), à savoir l'utilisation du métacaractère (wild card) « * » pour chercher tous les noms de services.

Ici donc, $(qdbus org.kde.konqueror\*) nous donne le nom du service voulu (à supposer qu'il n'y a qu'un Konqueror qui tourne). Nous utilisons à nouveau qdbus pour appeler la méthode « reload » de Konquy (il est possible d'utiliser D-Feet pour retrouver facilement le nom et le chemin de la méthode).

Et nous finissons la boucle avec done. Voilà, plus qu'à appuyer sur [entrée] et dégainer votre vim favori.

Bien évidemment, j'applique ici à l'édition de XEP parce que je suis en plein dedans, mais vous pouvez vous en servir pour, par exemple, faire un aperçu Markdown (avec la commande... markdown), ou pour tout ce qui se transforme en (X)HTML.

Salut à Toi disponible en docker + passage à la radio

Salut à vous,

nous venons de mettre en place des images Docker pour simplifier l'installation et l'utilisation de Salut à Toi/Libervia.

Pour ceux qui ne connaissent pas, Docker est un logiciel de gestion de conteneurs, une sorte de chroot boosté. En gros l'idée c'est que vous distribuez un système complet avec toutes les versions des dépendances qui vont bien, et que vous faites tourner le tout de manière isolée mais sur un noyau Linux existant, avec un impact faible sur les performances.

Dans notre cas c'est idéal, car Salut à Toi est pour le moment complexe à installer (surtout Libervia: on y travaille, mais on a besoin de faire bouger les standards XMPP pour ça, et ça prend du temps).

Avec Docker, l'installation est très simple, et en prime nous avons fait un script pour faciliter encore tout ça.

Pour installer et lancer Libervia, il vous suffit d'entrer la commande suivante:

wget && chmod a+x

Qui va télécharger et rendre exécutable le script de gestion du conteneur Libervia. Ensuite, et si Docker est bien installé chez vous, il vous suffit d'entrer:


Le téléchargement la première fois devrait prendre quelques minutes, ensuite le tout est executé avec quelques instructions sur l'utilisation.

Vous pourrez ainsi tester la version en cours de développement de Libervia. pour mettre à jour, il suffit d'entrer:

./ update

Vous aurez tous les details ici (en anglais seulement pour le moment, toute aide à la traduction bienvenue):

N'hésitez pas à nous signaler si quelque chose ne fonctionne pas comme prévu ou est mal expliqué (le mieux étant de venir sur le salon XMPP de Salut à Toi:

Sinon je n'avais pas donné le lien ici: j'ai été invité il y a quelques semaines par radio « Ici et maintenant », une radio libre parisienne, avec d'autres acteurs du libre comme Benjamin Bayart (FDN, minitel 2.0), Julien et Valérian (Jappix), Éric et Stéphane (, Thuban (Host@Home), et Tanguy (Planet auto-hébergement). L'émission est longue (3h30), et divisée en 2 parties principales, celle qui cause de SàT est à partir de 2:20. Vous la trouverez ici (ou mieux via bittorrent).