Journal Parlons XMPP - épisode 4 - les discussions de groupes

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
29
14
juil.
2015

(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@chat.jabberfr.org : « sat » est le nom du salon, « chat.jabberfr.org » le service.

La ressource est utilisée pour les occupants du salon: sat@chat.jabberfr.org/goffi correspond à l'occupant appelé « goffi » sur le salon sat@chat.jabberfr.org. 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: http://www.unicode.org/reports/tr36/. 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 à salon@example.net/pseudo_dé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.

  • # un concurrent des tribunes web ?

    Posté par  . Évalué à 1.

    Elle en est ou la Xep sur le support des horloges pour répondre aux post façon https://linuxfr.org/board ? c'est fondamental !

    • [^] # Re: un concurrent des tribunes web ?

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      J'ai fait un deal avec devnewton sur le sujet: je me pencherai sur la question et une fois implémentées il adhérera à l'association :)

      En pratique j'ai commencé à regarder, et il y a les threads dans XMPP qui permettent de suivre une conversation, mais il n'est pas possible de spécifier plusieurs parents, ce qui est nécessaire pour un équivalent des norloges. L'autre soucis est que les ids des messages ne sont pas obligatoires, il faut pouvoir identifier un message sans id (ou alors réserver la fonctionnalité aux seuls messages qui ont un id). Enfin rien d'insurmontable, mais il faudra probablement une XEP pour que ça soit propre.

      La fonctionnalité est intéressante, et ça serait particulièrement utile que ça fonctionne avec plusieurs salons à la fois, dans une même fenêtre. On a un petit refactoring à faire sur la gestion des message dans SàT, et je pense qu'ensuite une version expérimentale serait assez facile à faire.

      P.-S.: j'aurais parié qu'il y aurait une question sur le sujet :)

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3. Dernière modification le 14 juillet 2015 à 17:37.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: un concurrent des tribunes web ?

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Oui ça ça marche sur un serveur centralisé, mais la synchronisation des horloges n'est pas triviale en décentralisé, même à supposer que tout le monde utilise NTP.

          L'id est nécessaire pour identifier le message, ensuite à l'affichage tu représentes ça comme tu veux: norloge, chiffre, couleur, etc.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: un concurrent des tribunes web ?

              Posté par  . Évalué à 3.

              Euh non, le [1-9]* devient soit non stable en cas de conflit, soit différent d'un client à l'autre en fonction de l'ordre dans lequel il a reçu les message.

              Sinon il y a les horloges vectorielles aussi.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 2.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: un concurrent des tribunes web ?

                  Posté par  . Évalué à 1.

                  Euh non, l'ordre n'est total que pour une machine donnée. Plusieurs machine auront la même date pour un évènement différent, ce n'est que lorsqu'elle vont intéragir qu'elles vont se "désynchroniser" de manière pure. Ce n'est pas vrai pour les horloges vectorielles par contre, les dates sont uniques partout, même si l'ordre reste évidemment partiel.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 2.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: un concurrent des tribunes web ?

                      Posté par  . Évalué à 2.

                      Euh, il ordonne par numéro de processus, donc tu peux pas pas déterminer le numéro avant de savoir qu'il y a un conflit … donc dans un cas comme un split de quelques minutes, genre es split irc, tu peux être obligé de recalculer le nombre, sauf à coder le couple Lamport / id de l'émetteur dans la norloge. Bon certes on a le jid.

          • [^] # Re: un concurrent des tribunes web ?

            Posté par  (site web personnel) . Évalué à 5.

            Je te conseille de faire comme tout dev raisonnable ferait: un UUID pour chaque message.

            Les délires moulesques faisant référence à un "standard" qui est en fait une coutume orale sur laquelle personne n'est d'accord, c'est juste une perte de temps: format pas normalisé, possibilité de faire référence à un post dans le futur, heure locale et pas UTC…

            Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

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