Journal 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 : sat@chat.jabberfr.org ; 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.

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: http://biboumi.louiz.org/. 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 clot 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).