Sortie de poezio 0.10

Posté par  (site web personnel) . Édité par Davy Defaud, M5oul, Benoît Sibaud et palm123. Modéré par claudex. Licence CC By‑SA.
41
11
oct.
2016
XMPP

Pour rappel, poezio est un client XMPP en ligne de commande. La version 0.10 est sortie le 9 octobre 2016. Les nouveautés de ce nouvel opus sont présentées dans la seconde partie de la dépêche.

Logo Poezio

Sommaire

Nouveautés

Performances

Link Mauve a passé pas mal de temps à rendre poezio plus rapide, ce qui le rend plus agréable et plus réactif sur des machines avec une puissance de calcul faible dans une situation avec beaucoup de contacts et de salons remplis.

Il a ainsi passé beaucoup de temps à profiler poezio pour déterminer les endroits critiques pour les performances, ainsi qu’à se plaindre de la lenteur de Python pour des opérations des plus classiques ; ensuite est venu un nombre de micro‐optimisations (et pas si micro que ça). Son objectif à terme est de rendre tout compilable via Cython, afin d’avoir des performances encore meilleures.

Stream Management (XEP-0198)

Allant de pair avec la réparation du greffon slixmpp pour la XEP-0198 est venue l’implémentation dans poezio. Il n’est néanmoins pas activé par défaut, car il ajoute une quantité substantielle d’échanges avec le serveur et n’est pas foncièrement utile dans les cas standard d’utilisation de poezio (i.e. des sessions longues laissées à tourner dans une fenêtre screen ou tmux). Il suffit de mettre l’option idoine à true pour le réactiver.

Cette extension (qui a besoin d’une prise en charge côté serveur) permet à un client de restaurer une session après une déconnexion abrupte, tant qu’un certain délai n’est pas dépassé côté serveur. Elle permet également d’avoir une meilleure fiabilité dans le flux entre le client et le serveur en ayant des accusés de réception à intervalle régulier avec des numéros de séquence. Si les numéros de chaque côté ne correspondent pas, l’entité qui a envoyé les messages manquants les renvoie simplement à l’autre.

Activation de copies carbones

C’était un oubli, mais un oubli notable ; l’extension Carbon Copies (XEP-0280) est maintenant activée par défaut dans poezio 0.10. Cette extension permet une transition naturelle entre différents terminaux XMPP en dupliquant les messages reçus et envoyés sur chaque terminal. On peut donc continuer sur son ordinateur une conversion entamée sur son téléphone en voyant tous les messages.

Fichier de configuration commenté

Encore un oubli : comme les options du fichier de configuration étaient décommentées par défaut (et que ce fichier est copié au premier lancement de poezio), il n’y avait aucun moyen de savoir si une valeur était là parce que l’utilisateur le désirait, ou si c’était juste la valeur par défaut. Il n’y avait donc pas de possibilité de changer les valeurs par défaut dans les nouvelles versions pour les gens utilisant déjà poezio. En fait, il n’y en a toujours pas, mais dorénavant les options du fichier de configuration sont toutes commentées par défaut, donc les nouveaux utilisateurs n’auront pas ce problème.

P.‐S. : Il est possible d’utiliser poezio -c pour voir quelles options diffèrent de leurs valeurs par défaut.

Script poezio_logs

Les fichiers journaux de poezio sont depuis un moment déjà dans un format proche de mcabber. Cependant, lire ces journaux depuis poezio est au mieux compliqué, mais surtout impossible. Même si ce problème est connu et voué à être résolu un jour, c’est toujours appréciable de pouvoir lire ses journaux sans avoir à se coltiner le format spécifique de stockage.

Cette version inclut donc un outil poezio_logs qui reçoit en paramètre le chemin d’un fichier journal et sort le résultat nettoyé sur la sortie standard, avec quelques couleurs. Il peut également prendre quelques paramètres pour enlever la couleur, la date et l’heure, ou les messages d’information.

Vérification HTTP (XEP-0070)

L’invité surprise de cette nouvelle version est l’arrivée d’un onglet de vérification de requêtes HTTP utilisant la XEP-0070 pour authentifier des requêtes HTTP en utilisant seulement votre JID.
Vérification de requête HTTP

Un greffon MediaWiki est en cours d’écriture afin de tirer parti de cette extension, et un greffon WordPress est déjà disponible depuis un bon moment. Comme les composants dont celui de Chtefleur (décrit plus en détail ici) parlent en HTTP, aucune prise en charge de XMPP n’est requise dans l’application qui fait la vérification ; il suffit d’entrer votre JID, puis de vérifier et accepter la requête dans votre client.

Changement de l’avertissement de certificat

La façon qu’avait poezio d’afficher un changement de certificat auparavant n’était vraiment pas pratique et, après avoir implémenté la XEP-0070, c’était naturel de réutiliser l’onglet créé pour l’occasion avec des couleurs différentes pour avoir une façon plus agréable de vérifier le nouveau certificat (particulièrement depuis le passage de SHA-1 vers SHA-512).
Validation de certificat

Détournement des corrections de messages

Cela s’apparente plus à de l’abus de protocole qu’autre chose, mais puisque nous avons déjà un nombre conséquent de greffons « rigolos », en voici deux nouveaux qui exploitent la possibilité de correction de message offerte par la XEP-0308 :

  • marquee, qui reproduit le comportement d’une balise HTML <marquee> en déplaçant du texte de gauche à droite dans une boucle, tout ça dans un seul message, en utilisant les corrections ;
  • dice, pour faire « rouler » un certain nombre de dés durant une durée fixe, une fois de plus dans un seul message, en utilisant les corrections.

Indication de l’état du client (CSI, XEP-0352)

CSI est une extension plutôt portée sur le mobile qui demande une prise en charge côté client et côté serveur, et qui permet au client de dire au serveur qu’il est « off » (par exemple, un client mobile avec l’écran éteint en étant dans une poche).

Étonnamment, cette extension s’applique plutôt bien à poezio, puisque le greffon screen_detach fait exactement ça, en ayant un état « off » et un état « on ».

Régler l’état à actif ou inactif permet au serveur d’activer un certain nombre de filtres pour limiter les échanges entre le client et le serveur (et donc les réveils du téléphone en cas d’information inutile). Par exemple, quand l’écran est éteint, le client n’a que faire des informations de présence des contacts, qui seront donc filtrées, alors qu’il est encore intéressé par des nouveaux messages.

Les filtres activés sont à la discrétion de l’administrateur du serveur.

VCards

Prendre en charge VCard-Temp (XEP-0054), qui permet de récolter des informations sur son interlocuteur, est toujours appréciable, et cette version ajoute un greffon pour visualiser les informations fournies par une entité distante. L’implémentation est encore un peu brute, car elle n’implémente qu’une partie de la spécification et réutilise un onglet de poezio qui n’était pas fondamentalement prévu pour ça, mais cela s’améliorera.

Bien sûr, une fois que la prise en charge de vcard-temp sera finalisée, celle de VCard 4 (XEP-0292), qui est plus actuelle et pratique, viendra.

Bits of Binary

Bien que poezio ne dispose toujours pas de vraies capacités de partage de fichiers, nous avons désormais un greffon BoB (XEP-0231), qui permet d’envoyer des petits fichiers à travers la connexion XMPP. Comme la bande passante est souvent limitée à raison à quelques kilobits/octets par seconde, il doit être utilisé avec raison, mais est pratique pour envoyer de petits fichiers.

Et bien plus encore

Il y a bien sûr bien plus de commits que juste ceux‐ci, par exemple l’intégralité du code a été refactorisée pour éviter une bidouille du chemin Python durant l’importation, plusieurs corrections d’interface ont été apportées, les thèmes graphiques sont mieux respectés (moins de valeurs en dur), les reconnexions dans certaines conditions ne provoquent plus une boucle infinie sans pause, etc. Vous pouvez consulter le journal des modifications ou l’historique Git pour plus de raisons de mettre à jour.

Informations d’empaquetage

Cette version comme la précédente dépend toujours de la bibliothèque slixmpp qui, elle‐même, requiert aiodns, et peut être optimisée avec Cython (auquel cas libidn ainsi que ses en-têtes seront requis durant la compilation).

Contributeurs

À part les habitués que sont mathieui, louiz’ et Link Mauve, il faut également saluer les autres contributeurs, eijebong, Lasse Aagren, Frédéric Meynadier, Nicolas Braud‐Santoni, Lancelot SIX et Luke Marlin, pour leurs ajouts de fonctionnalités ou corrections de bogues.

Merci également à tous les utilisateurs et testeurs qui nous remontent des bogues et des suggestions d’améliorations, que ce soit via des remarques constructives dans le salon ou des rapports de bogues.

Bogues

Comme toujours, si vous rencontrez un bogue inconnu qui n’est pas corrigé dans la version Git de poezio, merci de nous en faire part, merci.

Pour la suite…

Pour la prochaine versions, les développeurs vont sans doute se pencher sur des fonctionnalités très réclamées telles qu’OMEMO l’extension de chiffrement de bout en bout qui correspond à une adaptation du protocole dit « double ratchet » pour XMPP, ainsi que le « nouveau » protocole d’archivage MAM (pour Message Archive Management).

Aller plus loin

  • # Merci

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

    Merci pour cette belle présentation bien alléchante :-) Je sens que ce client XMPP va bientôt arriver dans un Tmux (très) près de chez moi.

    Y.

  • # Super une nouvelle version !

    Posté par  . Évalué à 3.

    Salut !

    Super cette nouvelle version, plusieurs nouveautés qu'il me tarde de tester.

    Je suis particulièrement intéressé par la vérification HTTP et l'intégration des vCard.

    Je sais que c'est un sujet épineux pour un client CLI, mais quid de l'affichage des avatars ?

    • [^] # Re: Super une nouvelle version !

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

      Les afficher, non, libcaca (ou ses jumeaux) n’est pas une solution agréable, ça prendrait trop de place en plus d’être moche, et on n’a pas vraiment moyen de les afficher dans un framebuffer de façon convenable. On pourrait par contre permettre de les télécharger pour les ouvrir dans un programme externe comme eog/feh/gpicview, et les envoyer en implémentant l’édition de sa vcard.

      • [^] # Re: Super une nouvelle version !

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

        certains terminaux permettent d'afficher des images (comme Terminology), c'est peut-être sortir un peu du principe du terminal, mais ça peut valoir le coup d'y jeter un œil : https://www.enlightenment.org/about-terminology

        • [^] # Re: Super une nouvelle version !

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 12 octobre 2016 à 12:40.

          J’avais cherché à implémenter l’affichage des images pour Terminology, le problème est qu’ils n’ont pas pensé à en ajouter le support dans ncurses donc il faudrait passer outre cette lib pour afficher les bons caractères d’échappement, ce qui casserait au premier rafraîchissement de l’écran. Il faudrait aussi en implémenter le support dans tmux pour ceux qui l’utilisent, screen pour ceux qui l’utilisent, et toujours avoir le dossier des images monté (avec sshfs par exemple) pour éviter de voir des ##### à la place.

          Sans compter les memory leaks que les développeurs de ce terminal m’ont dit être parfaitement normal, par exemple s’il y a moins de # que prévu, Terminology gardera l’image chargée en mémoire jusqu’à sa fermeture, c’est assez mauvais je trouve.

          En bref, c’est une bonne idée, mais ça ne peut marcher actuellement qu’en utilisant des programmes simplistes qui font appel à tycat.

  • # Bravo

    Posté par  (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 12 octobre 2016 à 11:44.

    Bravo pour votre super boulot, et content de voir la XEP-0070 se répandre, hâte de voir le plugin mediawiki.

    Petite remarque, pour moi Poezio est un client console et pas ligne de commande, vous faites du ncurses (comme Vim ou Mutt), la ligne de commande c'est uniquement une commande dans un shell (comme ls ou grep). Enfin c'est un détail.

    • [^] # Re: Bravo

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

      Très juste, j'ajouterais toutefois que la ligne de commande n'est pas limitée au shell, il y a des programmes dont l'interface est elle-même une ligne de commande, citons notamment :

      • ed pour l'édition de texte ;
      • mail pour le courrier électronique ;
      • Freetalk pour la messagerie instantanée ;
      • ftp et sftp pour les transferts de fichiers.
  • # Super!

    Posté par  . Évalué à 3.

    C’est vraiment chouette de voir tant de nouveautés depuis longtemps attendues et d’autres vachement intéressantes et modernes, malgré l’absence de véritable transfert de fichiers.

    On a parfois l’impression que le monde Jabber stagne un peu alors que ça a énormément de potentiel.

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Super!

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

      On a parfois l’impression que le monde Jabber stagne un peu alors que ça a énormément de potentiel.

      Je crois que depuis quelques temps, on peut vraiment pas dire que ça stagne : https://linuxfr.org/tags/xmpp/public

      • [^] # Re: Super!

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

        En effet, je trouve qu’il y a depuis un an environ un vrai réveil de XMPP open-source, avec un gros effort de collaboration et compatibilité entre les différents projets. Merci à vous tous !

      • [^] # Re: Super!

        Posté par  . Évalué à 3.

        Oui c’est vrai, mais l’évolution se voit très peu de l’extérieur (càd que pour la plupart des gens c’est un peu mort). Par contre, loin de moi l’idée de nier l’énorme travail qui se fait en ce moment sur Jabber!

        Mais le fait est que parmi les clients Jabber sur bureau, y a principalement Pidgin et Gajim et les deux font un peu vieillot et semblent assez peu évoluer; la plupart des clients Android sont à chier, le reste est bof/loin des standards des autres applications de communication. Bon y a MOVIM quand même qui a vu beaucoup de changements arriver il y a peu.

        Enfin bref, j’aurais vraiment du mal à convaincre des contacts sur Telegram de passer à Jabber, et j’attends avec impatience de pouvoir le faire, si jamais c’est possible un jour.

        Écrit en Bépo selon l’orthographe de 1990

        • [^] # Re: Super!

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

          Pour les clients de bureau, gajim a peut-être un look qui n’évolue pas beaucoup (avec une forte connotation GTK), mais il implémente quand même beaucoup de normes récentes qui améliorent la qualité de l’utilisation ; on peut citer également swift qui part plutôt pour un look et une utilisation "minimaliste" mais moderne, ou encore Salut à toi qui avance quotidiennement (mais pas forcément sur la partie desktop, cela dit).

          Côté Android, je ne suis pas d’accord, il y a un paquet de clients fonctionnels assez simples d’utilisation, et en particulier conversations qui prend en charge toute les extensions récentes (voire qui est un des vecteurs d’adoption de ces extensions) et essaie de fournir le même genre de workflow que les messageries privatrices hypes du moment.

          • [^] # Re: Super!

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

            gajim a peut-être un look qui n’évolue pas beaucoup (avec une forte connotation GTK), mais il implémente quand même beaucoup de normes récentes qui améliorent la qualité de l’utilisation ;

            Gajim est très complet et les implémentations de fonctionnalités sont en général bonnes voire excellentes, c'est ma référence quand je veux tester une fonctionnalité, ils ont fait un client vraiment bon.

            encore Salut à toi qui avance quotidiennement (mais pas forcément sur la partie desktop, cela dit).

            En fait si, on a Cagou notre nouveau frontal qui tourne déjà sur bureau ( https://www.goffi.org/blog/goffi/ddc8d18f-bae7-4929-8af8-fe51b8d80323 ) et le port Android est en cours : encore quelque problèmes à régler mais ça se lance.

            Il n'est pas super joli pour le moment parce qu'il faut d'abord qu'il tourne bien avant de s'occuper de la peinture, mais il sera clairement là pour notre prochaine version (et j'espère qu'une version au moins alpha sortira avant la fin d'année).

          • [^] # Re: Super!

            Posté par  . Évalué à 3.

            Je n’avais jamais entendu parlé de Swift, par contre je connaissais évidemment Salut à toi mais qui je pense reste encore assez confidentiel (mais je suis toujours ravi d’avoir des nouvelles de ce projet qui semble très prometteur).

            Côté Android, je ne suis pas d’accord, il y a un paquet de clients fonctionnels assez simples d’utilisation

            Lesquels? Le seul client libre que je connais qui n’est pas à moitié bugué est Xabber. Quand à Conversations, je trouve son fonctionnement absolument atroce (et je vois pas le rapport avec une messagerie centralisée comme Line, What’s app ou Telegram qui ont un fonctionnement intuitif et agréable contrairement à mon expérience de Conversations).

            Je regrette qu’un client qui semble si avancé et innover dans le domaine XMPP soit si mal foutu niveau interface.

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Super!

              Posté par  . Évalué à 3.

              Ah oui au passage Gajim c’est un client que je trouve très sympa mais il est parfois un peu lent et surtout j’ai quand même régulièrement des bugs avec.

              Écrit en Bépo selon l’orthographe de 1990

  • # utilisation IRC

    Posté par  . Évalué à 2.

    Pour l'instant j'utilise irssi + irssi-xmpp et je me tate pour migrer vers poezio + biboumi.
    Malgré la volonté de ressembler à irssi, mes 2 ou 3 tentatives d'utilisation de poezio ne m'ont pas paru très fluides: il va me falloir un moment pour chercher et intégrer les différences.
    Et comme ni l'un ni l'autre ne gère OMEMO pour le moment, je maintiens le statuquo puisque je ne gagnerai rien à changer.

    Quels seraient les arguments du combo poezio+biboumi que j'aurais loupé qui pourraient m'inciter à sauter le pas ?
    A l'inverse quels seraient les inconvénients par rapport à irssi + irssi-xmpp ?

    Pour finir, j'ai essayé de rejoindre le MUC de poezio mais on me dit que le serveur n'existe pas, que ce soit avec poezio ou irssi+irssi-xmpp:
    Error> poezio@muc.poez.io/peetah: cancel: remote-server-not-found
    Par contre l'accès via le client web en lien sur le site de poezio fonctionne très bien.
    Je force le s2s sur mon serveur prosody: est ce que cela peut en être la cause ?

    • [^] # Re: utilisation IRC

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

      Je ne suis pas très bon pour convaincre les gens d’utiliser poezio (en plus de ne pas être très objectif) ; ce que j’apprécie néanmoins dans le combo poezio+biboumi pour IRC, c’est la possibilité de se passer de bouncer et de pouvoir utiliser n’importe quel client XMPP android (j’utilise conversations) qui prend en charge les salons, pour avoir accès à tout l’historique de manière transparente (maintenant que biboumi implémente MAM et les Multi-Session Nick qui permet à plusieurs clients d’être connectés derrière le même nick). Après, je préfère poezio à l’utilisation courante (avec les chat states, corrections, xhml-im, attention, message receipts), mais ce n’est pas vraiment un argument :).

      Sinon, le serveur muc.poez.io est up, a un certificat letsencrypt valide, et n’expire pas avant 2017, donc je ne vois pas très bien la cause du problème. Si tu as des logs côté serveur ce serait sans doute pratique (peut-être un problème de DNS côté prosody ?).

      • [^] # Re: utilisation IRC

        Posté par  . Évalué à 2.

        c’est la possibilité de se passer de bouncer

        J'avais cru comprendre que ce n'était pas encore au point (#3116)

        Sinon, le serveur muc.poez.io est up, a un certificat letsencrypt valide, et n’expire pas avant 2017, donc je ne vois pas très bien la cause du problème. Si tu as des logs côté serveur ce serait sans doute pratique (peut-être un problème de DNS côté prosody ?).

        voilà le contenu du log prosody:

        s2sout177e0e0 info Beginning new connection attempt to muc.poez.io ([62.210.82.114]:5269)
        mod_s2s warn Forbidding insecure connection to/from muc.poez.io
        s2sout177e0e0 info outgoing s2s stream mydomain.tld->muc.poez.io closed: stream closed
        s2sout177e0e0 info Sending error replies for 1 queued stanzas because of failed outgoing connection to muc.poez.io

        je suis sous debian jessie (prosody 0.9.7) avec les modules de jessie-backports (2016/08/13)
        Cela peut il venir des certifs lets encrypt non reconnus ?

        • [^] # Re: utilisation IRC

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

          J'avais cru comprendre que ce n'était pas encore au point (#3116)

          Ce bug est justement pour se passer de poezio et de se servir directement de biboumi comme un bouncer, ce qui n’est pas encore possible. En revanche, ce bug ne concerne pas le fait d’utiliser poezio + biboumi + un autre client, puisque poezio est déjà présent sur les salons, pas besoin du fonctionnement de "join forcé" du bouncer qui pose problème à biboumi (on peut même choisir de n’en rejoindre que certains via l’autre client).

          je suis sous debian jessie (prosody 0.9.7) avec les modules de jessie-backports (2016/08/13)
          Cela peut il venir des certifs lets encrypt non reconnus ?

          Seulement si s2s_secure_auth est activé et que le système n’a pas les trust anchors letsencrypt

          • [^] # Re: utilisation IRC

            Posté par  . Évalué à 2.

            Donc pour l'instant il faut forcément un bouncer + biboumi si on souhaite se connecter à irc via un autre client lorsque poezio n'est pas connecté à biboumi.

            Seulement si s2s_secure_auth est activé et que le système n’a pas les trust anchors letsencrypt

            ça doit être ça alors, merci.

        • [^] # Re: utilisation IRC

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 13 octobre 2016 à 15:57.

          c’est la possibilité de se passer de bouncer

          J'avais cru comprendre que ce n'était pas encore au point (#3116)

          Biboumi pose toujours problème si tu essayes de l’utiliser derrière un bouncer.

          Mais actuellement, tu peux l’utiliser quasiment comme un bouncer directement, tant que tu laisses au moins un client connecté en permanence au chan (dans le cas de mathieui, je pense qu’il laisse poezio connecté en permanence, et quand il lance son Conversations et qu’il rejoint un chan, biboumi lui balance tous les logs qu’il a ratés).

          Dans la 4.0 (qui sort dans peu de temps), biboumi devrait se comporter convenablement derrière un bouncer (en envoyant des invitations à rejoindre le chan, dans le can d’un forced-join venant du bouncer, par exemple).

          Dans la 5.0 il pourra rester idle dans un chan même si tous tes clients XMPP sont déconnectés, afin d’agir véritablement comme un bouncer.

    • [^] # Re: utilisation IRC

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

      As-tu essayé profanity ( https://github.com/boothj5/profanity ) lequel tu conseilles ?

      • [^] # Re: utilisation IRC

        Posté par  . Évalué à 3.

        je ne connaissais pas, mais je testerai, merci.
        A priori pas de prise en charge de OMEMO pour le moment, mais cela semble être prévu.
        Reste à savoir comment il se comporte avec biboumi, l'idée principale pour moi étant d'avoir un seul outil pour XMPP et IRC.

Suivre le flux des commentaires

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