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

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
81
25
juin
2015

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 une 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 , 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 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.

  • # comme quoi Linux n'est pas prêt

    Posté par  . Évalué à -10.

    Quand je lis ça

    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.

    je me dis que quelque chose ne va pas.

    • [^] # Re: comme quoi Linux n'est pas prêt

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

      C'est parce que je m'adresse à un public averti, donc j'essaye d'expliquer un peu comment ça marche en dessous. Parler de IQ et de RFC n'est vraiment pas nécessaire pour comprendre un client XMPP.

      Par contre savoir qu'on peut envoyer un message avec un sujet est important, et je ne suis pas persuadé que tous les utilisateurs de clients XMPP le savent. C'est ce que j'entendais par cette phrase. Tu peux toutefois très bien utiliser XMPP sans le savoir.

      • [^] # Re: comme quoi Linux n'est pas prêt

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

        Mais je me rends compte que j'entre peut-être un peu trop dans les détails, c'est difficile de placer le curseur, donc n'hésitez pas me dire ce qui est trop compliqué, j'adapterai pour les prochains articles.

        • [^] # Re: comme quoi Linux n'est pas prêt

          Posté par  . Évalué à 10.

          Le curseur est très bien placé je trouve. C’est le juste milieu entre technique et simplification, je sais tout ce que tu as expliqué pour le moment mais pour ceux qui ne connaissent XMPP que de nom mais qui s’intéressent à son fonctionnement, cela me semble très bien fait, en partant du début et en progressant petit à petit.
          Bonne continuation.

        • [^] # Re: comme quoi Linux n'est pas prêt

          Posté par  . Évalué à 3. Dernière modification le 27 juin 2015 à 01:32.

          Non c'est au poil Goffi, un grand merci! Ne perd pas d'énergie avec les trolls.

          Pour revenir au sujet, je trouve qu'une erreur d'XMPP c'est tout de même sa nomenclature, je lis l'anglais couramment mais je ne suis pas parfait dans cette langue et je me souviens avoir eu pas mal de soucis avec l'idée de "roster" qui n'est au final qu'une liste de contact, non? Et d'autres trucs qui ne me viennent pas tout de suite à l'esprit.

          Bon c'est tout, j'ai hâte de lire tes prochains journaux!

          • [^] # Re: comme quoi Linux n'est pas prêt

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

            Oui je ne sais pas pourquoi ils ont parlé de « roster » mais je trouve aussi que amène de la confusion. Il s'agit effectivement juste d'une liste de contacts.

            Je pense que c'est aux clients à simplifier ça aussi: ce sont des choses internes qui n'ont pas besoin d'être nommées ou représentées de la même façon pour l'utilisateur final. La première fois que j'ai utilisé Psi, au début des années 2000, j'ai été un peu perdu en voyant la découverte des services (dont je vais parler dans la prochain article): ça n'a pas besoin d'être aussi visible. De même on n'a pas besoin d'utiliser le terme « roster » au niveau du client, surtout en français (ou toute autre langue que l'anglais) où ça ne veut rien dire !

            • [^] # Re: comme quoi Linux n'est pas prêt

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

              Quel est le problème avec "roster"? Le fait qu'il n'y a pas de traduction directe en français?

              Ce mot est utilisé de façon similaire en informatique à d'autres endroits, par exemple dans BeOS et Haiku: https://api.haiku-os.org/classBRoster.html

              Je trouve ça bien d'utiliser la richesse de la langue, qu'elle soit anglaise ou française. D'après le wiktionnaire, un roster est une liste de noms (https://en.wiktionary.org/wiki/roster). C'est exactement le cas du roster XMPP, alors pourquoi l'appeler autrement en anglais?

              • [^] # Re: comme quoi Linux n'est pas prêt

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

                En anglais probablement, avant XMPP je ne connaissais pas le terme en tout cas. Un des problèmes c'est qu'on (et je m'inclus dedans) a tendance à l'utiliser même en français.

                • [^] # Re: comme quoi Linux n'est pas prêt

                  Posté par  . Évalué à 2. Dernière modification le 04 juillet 2015 à 22:34.

                  En anglais probablement, avant XMPP je ne connaissais pas le terme en tout cas. Un des problèmes c'est qu'on (et je m'inclus dedans) a tendance à l'utiliser même en français.

                  Tu veux dire que tu l’as adopté tout de suite quoi…

                  Faut dire que comme traduction littérale « liste » est trop vague et imprécise… une liste est un objet plus rudimentaire… « tableau de service » c’est un peu long.

                  L’étymologie est intéressante :

                  https://en.wiktionary.org/wiki/roster

                  From Dutch rooster “gridiron”.

                  Dutch to English: more detail…
                  rooster:
                  roster; timetable; lattice; grate; trellis work; sive; screen; lattice-works; duty-roster; school schedule; roaster; grill
                  timesheet

                  http://www.interglot.com/dictionary/nl/en/translate/rooster

                  Pour trouver un mot français pour décrire le roster XMPP ça va pas être facile. Ce n’est pas un emploi du temps, c’est plus une liste d’accès… Je propose matrice, c’est exactement ça, la matrice de ton réseau social… « Grid » va bien… ah mais merde c’est un mot anglais aussi /o\

              • [^] # Re: comme quoi Linux n'est pas prêt

                Posté par  . Évalué à 3.

                Quel est le problème avec "roster"? Le fait qu'il n'y a pas de traduction directe en français?

                Je vois pas le problème avec le fait de traduire ça par "liste".

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: comme quoi Linux n'est pas prêt

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

                  On ne peut pas juste dire "la liste" pour traduire "the roster", le sens du mot est plus précis et spécifique. Éventuellement, "la liste de contacts" ou "carnet d'adresses", mais ce ne sont pas des traductions directes.

                  • [^] # Re: comme quoi Linux n'est pas prêt

                    Posté par  . Évalué à 2.

                    On ne peut pas juste dire "la liste" pour traduire "the roster"

                    C'est pourtant une traduction qui fonctionne très bien.

                    le sens du mot est plus précis et spécifique

                    Et ce sens est… ?

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

              • [^] # Re: comme quoi Linux n'est pas prêt

                Posté par  (site web personnel) . Évalué à 5. Dernière modification le 01 juillet 2015 à 11:29.

                On notera que roster en français est un verbe (probablement peu usité ou alors dans des domaines spécifiques) qui signifie :

                • (Passementerie) Garnir un bouton de points d’or ou d’argent.
                • (Marine) Lier deux pièces de bois par une corde roulée autour et formant des anneaux très rapprochés.

                (alors qu'en anglais on note le décollage du terme dès le début de XMPP en 1900…)

    • [^] # Re: comme quoi Linux n'est pas prêt

      Posté par  . Évalué à 4.

      Il ne dit pas que c'est nécessaire pour l'utiliser. Mais si tu lis ce 2ème journal, c'est bien que tu veux en savoir plus que la liste des options de ton client, non?

    • [^] # Re: comme quoi Linuxn'est pas prêt

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

      Quel rapport avec linux ?

  • # faute de frappe ?

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

    s/votre contact à avoir votre information de présence/votre contact à voir votre information de présence

    ウィズコロナ

    • [^] # Re: faute de frappe ?

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

      non, « avoir » peut aller ici (on parle de l'information). Mais vu que je mets voir juste après c'est vrai que ça peut paraître bizarre. Enfin les 2 peuvent aller de toute façon.

      Par contre j'ai mis 2 fois liste à la suite là: « ce n'est pas une liste liste de groupes » (avant dernier paragraphe). Merci

  • # correction

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

    comme j'ai mis un s à RFC, le lien wikipédia est cassé, il devrait pointer vers https://fr.wikipedia.org/wiki/Request_for_comments . Si un modo peut corriger, merci :)

  • # Chiffrement et multi-poste

    Posté par  . Évalué à 1.

    Ca fait un moment que je cherche :

    • un moyen de recevoir les messages sur plusieurs postes en même temps, façon chat de Facebook ;
    • un moyen de chiffrer les conversations et de les recevoir sur plusieurs postes en même temps, comme évoqué dans mon point précédent.

    Je serais vraiment heureux de trouver des explications sur ces 2 points dans les articles futurs, soit pour nous dire dire pourquoi ce n'est pas possible, soit pour nous dire comment le faire (ou comment contourner le problème).

    En tout cas merci pour cette série d'articles, ça manquait vraiment je pense.

    • [^] # Re: Chiffrement et multi-poste

      Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 08 juillet 2015 à 08:31.

      désolé je réponds tard, mais je suis à Beauvais pour les RMLL depuis samedi, et du coup je me connecte peu.

      un moyen de recevoir les messages sur plusieurs postes en même temps, façon chat de Facebook ;

      Je ne sais pas ce que tu entends par là (je n'ai jamais vraiment utilisé facebook, et j'ai supprimé le compte que j'avais depuis longtemps), mais tu as plusieurs façons de faire:

      • si c'est par « plusieurs postes » tu entends des clients à différents endroits (par exemple téléphone, ordi fixe, ordi portable) pour le même compte, tu as Message Carbons (XEP-0280) qui permet ça, c'est de plus en plus implémenté

      • si c'est plusieurs personnes en même temps, c'est de la discussion de groupe (MUC, XEP-0045), je vais expliquer ça dans le prochain article mais je suppose que tu connais déjà le principe (en gros comme IRC)

      • si c'est un message de type « normal » (celui qui ressemble au courriel), alors tu as la XEP-0033 (Extended Stanza Addressing) qui permet d'envoyer à plusieurs personnes en même temps.

      • si c'est pour des messages type microblogage, c'est PubSub qui gère ça, j'expliquerai dans un futur article, et je vais faire une conf de 20 min sur le sujet demain pour les RMLL.

      un moyen de chiffrer les conversations et de les recevoir sur plusieurs postes en même temps, comme évoqué dans mon point précédent.

      Alors là c'est un problème par contre parce qu'il n'y a pas encore de bonne solution pour le chiffrement de bout en bout. Enfin OTR est utilisé (mais pas encore standardisé avec XMPP), et couplé à message carbons tu le recevras sur plusieurs machines connectées avec le même compte. Si par contre tu entends ça comme une discussion de groupe, il n'y a pas encore de solution établie, c'est un vieux problème avec XMPP et il y a eu plusieurs tentatives mais rien qui n'a vraiment percé. Il était question de s'enfermer 2 jours avant le prochain Fosdem pour régler ça.

      Je serais vraiment heureux de trouver des explications sur ces 2 points dans les articles futurs, soit pour nous dire dire pourquoi ce n'est pas possible, soit pour nous dire comment le faire (ou comment contourner le problème).

      Tu devrais déjà avoir les pistes avec ce que je viens d'écrire, sinon indique moi ce que tu entends exactement par « recevoir les messages sur plusieurs postes en même temps ».

      En tout cas merci pour cette série d'articles, ça manquait vraiment je pense.

      je suis content de voir que ça plaît, plusieurs personnes sont venues m'en parler pendant les RMLL :). N'hésitez pas à me dire si vous voulez voir des sujets particuliers traités (bon bien sûr il y a des domaines que je connais mieux que d'autres).

Suivre le flux des commentaires

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