Journal XMPP en 2021

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
58
9
jan.
2021

Sommaire

Salut nal,

Je profite de l’occasion de Whatsapp qui va bientôt tout partager à Facebook pour écrire ce petit journal sur XMPP, l’état des lieux, et ce qui est à venir pour 2021.

Tout d’abord je me présente, j’utilise XMPP depuis plus de 10 ans, je développe des trucs liés à XMPP depuis environ 10 ans (je suis notamment un des développeurs de Poezio et de Slixmpp), et je suis également un des administrateurs du serveur JabberFR.

Multimédia

Ça fait un bon paquet d’années qu’on peut partager des fichiers, quelques-unes de moins pour que ça marche à tous les coups (XEP-0363: Envoi de fichiers via HTTP). C’est maintenant pris en charge dans virtuellement tous les clients (non, Pidgin ne compte pas).

Un peu de la même façon, on peut théoriquement passer des appels audio/vidéo via XMPP depuis belle lurette, mais en pratique ça n’aboutissait pas trop, la faute à beaucoup de facteurs différents. Et puis depuis le milieu de l’année dernière environ, on peut passer des appels audio et vidéo depuis l’application Conversations, ainsi que Movim ou Siskin.

Les discussions en audio/vidéo font d’ailleurs partie des Compliance Suites 2021 (XEP-0443) qui servent de feuille de route aux développeurs pour savoir quoi implémenter.

À noter que la solution libre de visioconférence Jitsi Meet se base aussi sur XMPP, mais n’est pour l’instant pas compatible avec d’autres clients (une conversation multimédia à plus de 2 personnes est toujours complexe à mettre en place).

Le multi-plateformes

Des clients prenant en charge toutes les fonctionnalités majeures sont disponibles sur chaque plate-forme. L’exception notable est iOS, qui empêche toute utilisation en arrière-plan de TCP, ce qui n’incite pas tellement les développeurs à viser cette plate-forme pour un client XMPP. Mais les choses bougent, notamment avec les clients Monal ou Siskin qui, s’ils n’ont pas atteint la maturité de Conversations, reçoivent un développement actif.

Si je devais recommander des clients par plate-forme majeure :

  • Linux : Dino, ou Gajim
  • Windows : Gajim
  • Android : Conversations
  • iOS : Siskin, Snikket iOS (voir plus bas) recherche par ailleurs des beta-testeurs capables de fournir des rapports de bug en anglais
  • Mac OS : Beagle IM
  • Web (mais aussi n’importe quelle plateforme) : Movim
  • Interface terminal : Poezio (un certain conflit d’intérêts sur cette dernière entrée)

À titre personnel, j’utilise quasi exclusivement Poezio et Conversations, et de temps en temps Dino.

Chiffrement

Depuis 2014, année où la communauté a décidé de se débarasser de GMail qui empêchait de forcer l’utilisation de TLS en toutes circonstances, toutes les interactions XMPP sont chiffrées point-à-point (c’est-à-dire que la communication est chiffrée via TLS entre tous les acteurs du réseau).

Très tôt, XMPP a mis en place une forme de chiffrement bout-en-bout (communément appelé E2EE), par exemple avec la XEP-0027 qui utilise OpenPGP (attention, cette extension est actuellement obsolète, c’était juste un exemple). OTR, étant indépendant de la couche de transport, a toujours pu fonctionner également.

Mais depuis une petite quinzaine d’années, les choses évoluent (par exemple avec l’existence de smartphones), et dans ce contexte OTR dans sa version 3 n’était plus suffisant, tout comme l’extension définissant l’utilisation de GPG. Sont donc arrivées les extensions XEP-0384: OMEMO, et XEP-0374: OpenPGP pour la messagerie XMPP (OX).

La grande majorité des clients activement développés implémentent désormais OMEMO, et certains implémentent également OX (comme Gajim). Ces deux modes de chiffrement n’ont pas du tout les mêmes propriétés cryptographiques, et sont donc destinées à des publics différents.

Marketing

XMPP (pour eXtensible Messaging and Presence Protocol) n’est pas tout à fait agréable à entendre pour les non-habitués, c’est pourquoi il existe une initiative menée par plusieurs personnes de la communauté, appelée Snikket. Le but de Snikket est de mettre « sous le tapis » toute mention à XMPP et de mettre en avant la fédération, en incitant à monter des serveurs nécessitant des invitations, mais fédérés, pour une famille ou une communauté. Ils proposent également un service d’hébergement (payant) de serveurs Snikket, actuellement en beta limitée.

Le but final (l’initiative est jeune) étant de fournir à la fois un package clef en main aux administrateurs pour pouvoir installer et gérer leur serveur XMPP (basé sur Prosody) et les services qui en dépendant, mais également des applications unifiées pour toutes les plate-formes, ce qui manque cruellement aujourd’hui. L’application Android est déjà disponible et se base logiquement sur Conversations, l’application iOS est prévue pour cette année et se basera sur Siskin.

Le projet Snikket a notamment réussi à obtenir une donation pour financer le développement du chiffrement de groupes de discussions dans Siskin.

P. S. : Si vous avez un domaine et que vous voulez un service XMPP dessus sans pour autant le faire tourner vous-mêmes, à JabberFR on propose également ce genre de services, il nous suffit d’une demande et d’un CNAME qui pointe vers nous (mais merci de nous prévenir si vous décidez de le retirer, parce que ça fait foirer nos renouvellements letsencrypt après).

Attractivité

À cause de l’effet de réseau, il est toujours difficile de faire venir de nouveaux utilisateurs sur des réseaux alternatifs aux monopoles des GAFAM. Une des façons de simplifier la transition pour les utilisateurs qui n’ont pas un bagage technique suffisant pour pouvoir choisir un nom d’utilisateur, un mot de passe, ou un serveur (pour un réseau fédéré), est de leur proposer une première expérience qui ressemble à ce qu’ils connaissent en termes d’inscription.

Daniel Gultsch, l’auteur de Conversations, a donc développé Quicksy, un fork de Conversations qui ne propose plus le traditionnel choix "nom d’utilisateur/serveur/mot de passe". À la place il crée un compte sur quicksy.im en utilisant le numéro de téléphone et une validation SMS.

Contrairement à Conversations, Quicksy est gratuit sur le Play Store, et le modèle de rémunération se base sur l’annuaire interne de quicksy.im. En effet, une des idées de Quicksy est d’utiliser la liste de contacts pour découvrir d’autres utilisateurs de Quicksy (ou XMPP) et de les ajouter à la liste de contacts XMPP. Si on a un compte XMPP pré-existant et qu’on veut faire passer ses proches à Quicksy, il faut donc soit payer pour lier son numéro de téléphone à son adresse dans l’annuaire, soit faire soi-même les demandes d’ajout de contact. Bien entendu, les utilisateurs de Quicksy eux-mêmes n’ont pas besoin de payer pour être ajoutés à l’annuaire.

Quicksy étant un fork de Conversations maintenu par le même auteur, il a exactement les mêmes fonctionnalités, comme les appels audio/vidéo, le chiffrement OMEMO ou le partage de fichiers.

Côté administration

Historiquement, j’ai utilisé ejabberd quelques années avant de passer à Prosody pour des raisons de mémoire vive limitée, et depuis ça tourne. Rien à dire, l’entretien est vraiment minime, mais il faut penser à se tenir informé des nouveautés, par exemple la visio requiert en général un serveur STUN/TURN, certaines extensions modernes ont besoin de nouveaux plugins, etc…

À noter les modules "mod_measure_" pour Prosody qui ne sont pas si vieux qui permettent de facilement remonter des informations à Prometheus, comme on le fait sur JabberFR.

Passerelles

J’utilise une seule passerelle, Biboumi, afin de me connecter à IRC de façon entièrement transparente, avec un bouncer et un historique intégré à mon client XMPP (avec la XEP-0313: Gestion de l’archivage des messages). La dernière version a rajouté la prise en charge de SASL, qui était la seule chose qui me pénalisait un peu.

Je n’en utilise pas d’autres, mais je sais que beaucoup fonctionnent via Spectrum, et j’ai connaissance de celle-ci pour Whatsapp.

À venir

  • Gajim vient de sortir une version 1.3 beta avec un nombre significatif d’amélioration pour l’expérience utilisateur et la stabilité
  • Beaucoup d’extensions intéressantes ont été publiées l’an dernier et sont en cours d’implémentation ou déjà implémentées dans des clients (lire à ce sujet les excellentes dépêches de la Lettre d’informations XMPP mensuelle) :
    • Les stickers
    • Les réactions (emojis) à des messages
    • L’effacement de messages qu’on envoie
    • La modération avec suppression de messages (sur des groupes de discussion)
    • Une interface simplifiée pour les interactions avec les bots

Et bien d’autres choses encore, certaines un peu trop techniques qui rendraient ce journal encore plus long, d’autres plus mineures, mais on peut en discuter dans les commentaires bien sûr !

  • # Audio / Video

    Posté par  . Évalué à 1 (+2/-2).

    Il y a des clients XMPP qui l'implémente ou pour l'instant c'est réservé à jitsi ?

    • [^] # Re: Audio / Video

      Posté par  (site Web personnel) . Évalué à 6 (+6/-1).

      Je crois que je réponds à cette question dans la première section de ce billet :) : « Et puis depuis le milieu de l’année dernière environ, on peut passer des appels audio et vidéo depuis l’application Conversations, ainsi que Movim ou Siskin. »

      • [^] # Re: Audio / Video

        Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

        je crois que Gajim, qui avait la vidéo il y a quelques années mais n'a pas maintenu le code, et en train de travailler à remettre ça en état.

        Dino a eu une subvention pour implémenter la vidéo aussi.

        • [^] # Re: Audio / Video

          Posté par  . Évalué à 1 (+0/-0).

          Ce sont des bonnes nouvelles, à suivre de (très) près.

          • [^] # Re: Audio / Video

            Posté par  (site Web personnel) . Évalué à 2 (+1/-0).

            Il me semble que gajim 1.3 (qui vient de passer en beta 2, depuis l’écriture de ce journal), a également des nouveautés côté audio/vidéo, même si ce ne sera pas complet. Je ne suis pas sûr et tout ça sera de toute façon dans les notes de sortie quand la version finale sera disponible.

            • [^] # Re: Audio / Video

              Posté par  . Évalué à 6 (+6/-0).

              Pour les impatiens comme moi qui voudrait pouvoir avoir la vidéoconférence (XEP-0320 DTLS-SRTP) sur le Desktop (en attendant que Dino/Gajim l'intègre). Il existe JSXC un client XMPP HTML5/JS plutôt bien maintenu qui via electron (oui je sais) le permet. C'est très fonctionnel avec Conversations et Siskin : https://github.com/jsxc/desktop

              • [^] # Re: Audio / Video

                Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                Comment ca marche faire fonctionner la version desktop (pour quelqu'un que ne connait pas les applis electron/javascript) Je vois un main.js dedans. T'es censé faire quoi avec?

                Je viens d'installer la version web en attendant. Je me vois en video/audio entre Conversations et JSXC. Je ferai des tests plus poussés de connectivité demain. Merci pour le tuyau!

                • [^] # Re: Audio / Video

                  Posté par  . Évalué à 1 (+1/-0).

                  Si tu veux pas te prendre la tête prend simplement le .AppImage et exécute-le.

                  La version source demande plus de choses, il faut normalement commencer par télécharger les libs nodejs externes (npm install) et ensuite lancer l’exécution (npm start) qui si mes souvenirs sont bons s’exécute en mode debug.

              • [^] # Re: Audio / Video

                Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                Je teste la version 4.2.1 web en autohébergement (serveurs XMPP + web)

                La visio fonctionne.
                OMEMO n'est pas actif par défaut.
                L'envoi de fichiers/images entre Conversations et JSXC n'est pas au point

                Conversations(omemo) -> JSXC ne marche pas. JSXC afficher l'url AESGCM.
                JSXC(clair) -> Conversations ne marche pas. Conversation affiche l'url http_upload.

  • # Un petit oubli

    Posté par  (site Web personnel) . Évalué à 10 (+13/-0).

    Quelque chose que j’aurais dû rajouter, car ça rajoute pas mal de lisibilité à l’écosystème, c’est le travail fourni (principalement par Link Mauve) pour pousser l’utilisation de DOAP (Description Of a Project) dans XMPP. DOAP est un format (se basant sur RDF) permettant de décrire de façon sémantique un projet logiciel. Grâce à des extensions spécifiques à XMPP, il va permettre d’apporter les modifications suivante au site xmpp.org, ainsi qu’à n’importe quel site qui souhaite présenter ces données :

    • Pour les développeurs, des informations rapides sur quel client/serveur/bibliothèque implémente quelle extension, et dans quelle proportion (un exemple est disponible sur linkmauve.fr, avec l’affichage du nombre dans la liste des extensions, et l’affichage de chaque projet avec son logo dans la visualisation de chaque extension.
    • Pour les utilisateurs, une façon rapide de voir si le client prend en charge les “Compliance Suites” les plus récentes, ainsi qu’un format standard pour visualiser un projet avec logo, capture d’écran, etc.

    C’est un travail qui n’est pas terminé, certains projets n’ont pas encore renseigné les informations, certains partiellement, et certains n’ont pas encore référencé leur fichier DOAP sur xmpp.org, mais c’est quelque chose qui devrait rendre la vie des gens qui découvrent XMPP plus simple.

    • [^] # Re: Un petit oubli

      Posté par  . Évalué à 3 (+2/-0).

      Ce qu'il faudrait, c'est que github et autres forges adoptent ce format DOAP et on aurait enfin une adoption conséquente pour pouvoir en faire des merveilles

  • # Petite typo

    Posté par  (site Web personnel) . Évalué à 1 (+0/-0).

    Avis aux modérateurs : on m’a fait remonter la typo "recherrche", je croyais l’avoir corrigée mais visiblement pas !

  • # Messages de groupes

    Posté par  . Évalué à 4 (+4/-0).

    Bonjour,

    Je m'intéresse à XMPP en tant qu'utilisateur cherchant des alternatives libres aux messageries GAFAM, et je remercie Matthieu pour ce point complet sur XMPP.

    Il me semble que l'une des fonctionnalités les plus appréciées des solutions comme Whatsapp est la faculté de réunir plusieurs personnes dans un groupe.

    Or avec XMPP, c'est loin d'être intuitif pour un béotien comme moi, même si j'ai quand même fini par créer un salon sur un serveur qui l'acceptait (chat.jabberfr.org), après avoir essayé vainement avec Chapril.

    Je pense que faciliter la création de salons privés, soit en documentant davantage soit en implémentant une nouvelle fonctionnalité (?), pourrait réduire l'appréhension à passer le pas.

    Les polémiques du moment sur les messageries instantanées US peuvent créer un effet d'aubaine, dont il serait dommage que Signal et Telegram soient les seuls bénéficiaires.

    • [^] # Re: Messages de groupes

      Posté par  . Évalué à 5 (+5/-1).

      Salut,

      La plupart des serveurs XMPP activent les salons de discussion. Parfois, ils restreignent la création d'un salon aux utilisateurs/trices du même serveur.

      L'autre point qui peut faire échouer la création d'un salon, c'est de ne pas valider la configuration de la salle. Les clients XMPP sont dans ce cas censés présenter ces options de configuration lors de la 1ère ouverture. Il faut la valider pour que la room soit effective.

      Selon les clients XMPP, niveau interface, j'ai constaté qu'il peut y avoir quelques ambiguités sur les fonctions qui servent à :
      - rejoindre un salon existant
      - créer un salon
      - parler à un contact
      Le fait qu'un JID puisse correspondre à la fois à une personne et à une room peut aussi contribuer à cette confusion.

      Voilà, j'alimente juste le dossier pour reconnaître que ce n'est pas toujours intuitif.

      • [^] # Re: Messages de groupes

        Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

        J’utilise cette fonctionnalité assez peu, mais pour alimenter le dossier :

        • Je sais qu’au moins Conversations a une option facile d’accès pour le faire ("Créer un groupe de discussion privé"), avec choix des participants dans la liste de contacts
        • Les serveurs doivent indiquer aux clients dans leur configuration quel serveur de salons les utilisateurs peuvent utiliser pour créer leurs salons privés
        • Il y a normalement une fonctionnalité "transparente" qui permet de transformer un chat entre deux personnes en groupe de discussion au besoin
        • En effet, il faut valider la configuration, mais la plupart des clients gèrent l’envoi automatique du formulaire sans interaction utilisateur (les champs sont standard et il est donc possible de ne pas l’exposer à l’utilisateur directement)
    • [^] # Re: Messages de groupes

      Posté par  . Évalué à 3 (+2/-0).

      j'ai quand même fini par créer un salon sur un serveur qui l'acceptait (chat.jabberfr.org), après avoir essayé vainement avec Chapril.

      Si tu as un compte chapril.org normalement tu peux créer des salons sur muc.chapril.org.
      Et lorsque c'est fait tu peux y inviter des personnes ayant des comptes sur n'importe quel serveur XMPP.

      As-tu un compte chapril.org ? Si oui, avec quel logiciel as-tu essayer de créer un salon sans succès ?

      • [^] # Re: Messages de groupes

        Posté par  . Évalué à 1 (+1/-0).

        Bonjour. Oui, j'ai un compte chapril.org, mais il m'avait échappé qu'il fallait utiliser muc.chapril.org pour les salons. Merci pour l'information !

    • [^] # Re: Messages de groupes

      Posté par  . Évalué à 2 (+1/-0). Dernière modification le 11/01/21 à 23:15.

      Si tu as ton serveur Prosody (oui je sais, c'est pas forcément évident mais on trouve des VM à 3€ par mois de nos jours), ça marche bien avec Gajim, DinoIm et Conversation.

  • # Merci et serveur

    Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

    Merci pour ce journal.

    Honnêtement, je ne suis pas sûre de bien comprendre comment tout ceci fonctionne et comment cela pourrait m'être utile, mais j'ai, du coup, profité de l'occasion pour demander à jabberFR de m'héberger. On verra bien ce que je pourrais en faire (j'y vois bien au moins une utilité éventuelle).

    Designeuse de masques pour sphéniscidés.

  • # Yunohost, XMPP et Jitsi

    Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

    L'année dernière, pendant le premier confinement, Jitsi était installable sur Yunohost. Le confinement a évidemment porté l'attention sur ce logiciel. Malheureusement l'installation ne permettait pas de faire des visio-conférences à plus de 2 écrans. Le mainteneur du paquet n'a pas réussi à amélioré la situation puis il a jeté l'éponge, le paquet Jitsi n'est plus maintenu pour Yunohost.

    Yunohost utilise Metronome, un fork confidentiel de Prosody, est-ce pour ça que Jitsi n'était pas facilement configurable ?

    La dernière fois que j'ai testé, les adresses xmpp auto-hébergeables avec Yunohost avaient un mauvais score au Compliance Suites, en particulier pour l'audio et la vidéo. Encore une fois, est-ce du à l'utilisation de Metronome ?

    Yunohost-XMPP-Compliance-Suite

    • [^] # Re: Yunohost, XMPP et Jitsi

      Posté par  (site Web personnel) . Évalué à 5 (+3/-0).

      Pour la petite histoire, Metronome a été intégré dans Yunohost parce qu'il a été à un moment poussé par Jappix et Movim * (Movim avait des problèmes à l'époque avec Ejabberd, et le composant Pubsub de Prosody perdait tout au redémarrage).

      Metronome est un fork de Prosody, maintenu par une seule personne (à l'origine pour un jeu il me semble, mais je n'en suis pas sûr du tout). Le problème c'est qu'il n'a pas été maintenu pendant longtemps.

      Entre temps le Pubsub de Prosody s'est nettement amélioré, je ne sais pas pourquoi Yunohost n'a pas rebasculé dessus (ou sur un autre serveur, Ejabberd, OpenFire, Tigase, ou autre).

      Le développeur de Metronome avait repris la maintenance la dernière fois que je m'y suis intéressé, je ne sais pas ce qu'il en est aujourd'hui (mais je pense que Prosody évolue beaucoup plus vite et régulièrement).

      Pour répondre à ta question: oui le mauvais score est probablement dû à l'utilisation de Metronome ou au moins à une mauvais configuration de celui-ci.

      * SàT avait les même contraintes à l'époque, mais le choix a été fait de développer un composant pubsub complet et utilisable avec tous les serveurs (SàT Pubsub, encore actif et développé aujourd'hui) plutôt que de pousser un serveur en particulier.

      • [^] # Re: Yunohost, XMPP et Jitsi

        Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

        Cette histoire est vraiment dommage parce qu'il y a régulièrement des utilisateurs de Yunohost qui viennent poser des questions à propos de limitations liées à ce choix.
        Les ressources sont limitées pour eux aussi et la dernière fois que j'avais regardé, faire un paquet Yunohost n'est pas aussi simple qu'un PKGBUILD ou un Ebuild.

        La migration vers Prosody était bien engagée puis le dev de Metronome s'est réveillé (Maranda) et ils ont décidé de le garder.

        Pour les intéressés voici la discussion complète:
        https://github.com/YunoHost/yunohost/pull/240

        Janvier 2017: PR crée
        Mars 2018: metronome se réveille
        Août 2018: la décision de garder metronome est prise
        Un commentaire mentionne qu'il n'y a pas eu de commit durant les 5 derniers mois.

        Maranda répond ceci:

        There were no commits in 5 months because the code is stable and also there are no feature requests whatsoever as I explained over and over, the next thing on the roadmap is MIX but I'm waiting on implementation when there's anything supporting it that isnt just experimental.

        Le projet est maintenant visiblement bien vivant mais j'ai toujours du mal à voir ce qu'apporte réellement le projet à l'écosystème xmpp.

        • [^] # Re: Yunohost, XMPP et Jitsi

          Posté par  . Évalué à 4 (+3/-0). Dernière modification le 13/01/21 à 13:37.

          Après le rappel historique donné par goffi, je pense qu'il serait raisonnable pour Yunohost de retenter la migration vers prosody. Surtout si ça a une chance de résoudre le problème de Jitsi Meet.
          Metronome n'apporte rien aujourd'hui, et n'est maintenu que par une seule personne.

          Je vais peut-être tenter ma chance et proposer une PR à ce sujet.

    • [^] # Re: Yunohost, XMPP et Jitsi

      Posté par  . Évalué à 5 (+4/-0).

      L'audio/vidéo qui ne fonctionne pas sur Yunohost c'est juste que ce sont des changements "récents" dans metronome qui n'ont pas encore été intégré dans Yunohost. En attendant que ça arrive quelqu'un a documenté un manière de faire "à la main" dans ce ticket :
      https://github.com/YunoHost/issues/issues/1607

      La plupart des autres points devraient pouvoir être corrigés également par les dév de Yunohost, sauf "In-Band Registration" qui est volontairement désactivé. Car les comptes utilisateurs XMPP sont forcément des comptes utilisateurs créés dans Yunohost.
      Le site XMPP Compliance Tester sert surtout à comparer les instances publiques de XMPP. Il faut considérer ton instance XMPP sur Yunohost comme une instance privée plutôt.

Envoyer un commentaire

Suivre le flux des commentaires

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