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

Posté par (page perso) . Licence CC by-sa
43
21
juil.
2015

(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.

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: 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).

  • # Merci de parler de XMPP

    Posté par . Évalué à 3.

    Merci pour ce journal. Je découvre XMPP et trouve cette série passionnante au point au j'ai commencé à lire XMPP: The Definitive Guide. C'est fou tout ce qu'on peut faire avec XMPP; on est loin de se limiter à la messagerie instantanée.

    Merci d'écrire cette série. J'ai l'impression que reparler périodiquement XMPP peu augmenter l'intérêt que les gens y portent.

    Est-ce que tu compte parler éventuellement de l'écriture des bots?

    • [^] # Re: Merci de parler de XMPP

      Posté par (page perso) . Évalué à 4.

      L'écriture de bot n'a rien de bien compliqué, il suffit d'utiliser l'une des lib XMPP dispo pour ton langage. La dernière fois que j'ai codé un bot XMPP (2011), j'ai utilisé sleekxmpp et c'était vraiment d'une simplicité enfantine.

    • [^] # Re: Merci de parler de XMPP

      Posté par (page perso) . Évalué à 5.

      Salut, merci pour le commentaire :). La série a plus de succès que ce à quoi je m'attendais, on m'en a parlé plusieurs fois aux RMLL, et effectivement ça fait monter l'intérêt pour XMPP (ce qui était un peu le but). On m'a par exemple demandé si c'était utilisable pour la contrôler un robot (oui), ou pour faire de la surveillance de machine - ou « monitoring » pour ceux qui préfèrent - (oui aussi), d'ailleurs on m'a parlé de jimbo que je ne connaissais pas: http://www.darkcoding.net/software/jimbo/ .

      Sinon oui je songe à faire des tutos par la suite, un bot est effectivement simple à faire, mais ça peut être l'occasion de présenter différentes façon de faire. Enfin on verra bien, c'est un peu en fonction de l'humeur au moment d'écrire.

  • # MUC 2

    Posté par (page perso) . Évalué à 3.

    Est-ce que tu as plus de détails sur les discussions sur MUC 2 ? J'avais lu la XEP-289, et je l'avais trouvé super intéressante, à mon avis tant que XMPP n'aura pas de salon de discussion qui vont dans ce sens IRC aura encore une bonne raison d'exister, parce que la fédération des serveurs permet d'avoir un endroit où il est plus facile de

    • lister et indexer les discussions qui existent, pour les rendre plus facilement découvrables
    • tenir un salon, sans avoir à l'héberger soi-même

    Je vois également que tu vas t'intéresser de plus près au côté non-messagerie, qui est effectivement extrêmement important à remonter tant il est sous-exploité, j'ai hâte !

    • [^] # Re: MUC 2

      Posté par (page perso) . Évalué à 2.

      Il y a quelques discussions sur standard@, notamment sur la possibilité de supprimer les salons semi-anonymes.

      Donc MUC2 l'idée principale c'est d'utiliser PubSub, et d'avoir quelque chose de plus souple. Il y a aura une compatibilité MUC1 (assurée probablement par le serveur). Des choses qui devraient être possibles sont les salons sans présence, ou permettre de se connecter depuis plusieurs ressources (par exemple ordinateur de bureau et téléphone portable) à un même surnom (nick) dans un salon.

      L'intérêt d'avoir des salons sans présence c'est d'une part d'alléger le trafic, et d'autre part de pouvoir mieux gérer les micro déconnexions qui n'étaient pas un problème à l'époque de MUC1, mais qui le deviennent aujourd'hui avec les appareils mobiles (si j'ai bien compris).

      Lister et indexer les salons publics c'est possible, mais le problème c'est qu'il peut il y avoir des salons un peu partout et qu'il faut trouver les serveurs. Il faudrait pouvoir avoir un annuaire distribué, et ça serait aussi très utile pour trouver des personnes. En attendant tu as des moteurs qui regroupent les résultats de plusieurs serveurs, par exemple http://search.wensley.org.uk/ .

      Tenir un salon sans avoir à l'héberger c'est déjà possible, tu peux demander à avoir un salon persistant et être le créateur, selon le serveur MUC utilisé. Ou alors je n'ai pas compris ce que tu entends par là.

      Je vois également que tu vas t'intéresser de plus près au côté non-messagerie, qui est effectivement extrêmement important à remonter tant il est sous-exploité, j'ai hâte !

      Oui dès le prochain article. Tu peux déjà regarder ce qu'on fait avec SàT, en particulier la vidéo sur la télécommande (dont je parlerai dans le prochain article), ou celle avec l'envoi de la bande annonce de Sintel: http://salut-a-toi.org/media.html et http://salut-a-toi.org/specifications.html#exp

      • [^] # Re: MUC 2

        Posté par (page perso) . Évalué à 3. Dernière modification le 22/07/15 à 21:27.

        Lister et indexer les salons publics c'est possible […] Tenir un salon sans avoir à l'héberger c'est déjà possible

        Techniquement tout ça c'est possible, le problème c'est qu'en pratique c'est beaucoup moins accessible qu'IRC: déjà il faut trouver quelqu'un qui veut bien l'héberger, je suis sûr que des services existent bien mais là comme ça aucun nom ne me vient en tête. À l'inverse sur IRC le premier réseau qui te vient en tête pour avoir un chan pour ton projet c'est Freenode. Je suis convaincu qu'avec une fédération au niveau des salons de discussion-même (et non pas juste au niveau des serveurs), on pourra voir émerger un réseau communautaire qui hébergera la plupart des salons (un peu comme Freenode), et que ça facilitera la dissémination de XMPP (plus de découvrabilité, plus de visibilité)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.