N. D. T. — Ceci est une traduction de la lettre d’information publiée régulièrement par l’équipe de communication de la XSF, essayant de conserver les tournures de phrase et l’esprit de l’original. Elle est publiée conjointement sur les sites Linuxfr.org et JabberFR.org.
Bienvenue dans la lettre d’information XMPP couvrant le mois de juin 2020.
Vous y trouverez, en plus des nouveautés, un appel à contribuer à la documentation et à la vie de XMPP.
Sommaire
- Appel à la communauté
- Annonces de la XSF
- Articles
- Vidéos
- Des nouvelles des logiciels
- Bibliothèques
- Divers
- Google Summer of Code
- Extensions et spécifications
- Remerciements
- Diffusez ces informations !
- Licence
Appel à la communauté
Inscrivez‑vous à la lettre d’information
Nous vous invitons à vous inscrire pour recevoir les prochaines éditions en anglais dans votre boîte de courriel dès qu’elles seront publiées ! Diffusez cette lettre d’information à quiconque serait intéressé.
Aidez‑nous à élaborer cette lettre d’information
Nous avons commencé à mettre en place un brouillon à chaque nouvelle édition dans le dépôt GitHub de la XSF.
Et nous sommes toujours ravis d’accueillir des contributeurs et des contributrices. Joignez‑vous à la discussion dans le salon de notre équipe de communication et aidez‑nous ainsi à alimenter cette lettre dans un effort communautaire.
Vous avez un projet et vous écrivez, ou voudriez écrire, à son sujet ? N’hésitez pas à venir partager vos informations ou évènements ici‑même, et diffusez‑les à un large public ! Même si vous n’y passez que quelques minutes, cela sera déjà utile.
Les tâches qui nécessitent d’être réalisées de manière régulière sont, par exemple :
- l’agrégation des informations de l’univers XMPP ;
- la reformulation courte des informations et des évènements ;
- le résumé des communications mensuelles sur les extensions (XEP) ;
- la relecture du brouillon ;
- les traductions, particulièrement en français, allemand et espagnol.
Annonces de la XSF
JC Brand a mis en place un site de publication d’offres d’emploi en lien avec XMPP !
Il vous permettra d’accéder à des offres d’emploi, mais également de faire la publicité de services XMPP.
Jetez‑y un œil, publiez vos propres offres et recommandez‑le. XMPP ça marche !
Articles
Ingo Jürgensmann a écrit un article sur l’historique des termes « Jabber » et « XMPP », leur différences et similarités [en anglais].
Le client XMPP Dino est un des trois projets qui ont été récompensés par le 10e trophée Thomas Krenn [en allemand].
Michał Piotrowski a écrit un article sur comment initier rapidement l’implémentation d’une messagerie instantanée dans une application [en anglais]. Il y aborde la valeur d’une fonctionnalité de discussion dans une application, son passage à l’échelle, sa personnalisation et les erreurs fréquemment commises : « Choisissez vos XEP, et choisissez intelligemment. ».
Le contributeur Space_e_man du site LinuxFr.org a proposé une brève revue de Quicksy, la messagerie instantanée libre basée sur XMPP facile. Tandis que l’article lui‑même se concentre sur les raisons qui devraient le faire préférer à d’autres solutions propriétaires, les commentaires des utilisateurs de LinuxFr.org, comme à l’accoutumée, apportent leur lot de points de vue variés, ainsi que des alternatives.
Vidéos
Au mois d’avril 2020, Conociendo XMPP, la Comunidad Latina de Tecnologías Libres, a fait une présentation en ligne de XMPP pour ses utilisateurs. Nous voudrions mettre en exergue cette vidéo [en espagnol], même si elle date un peu. Ils proposent également un espace de discussion pour les utilisateurs, joignable à cette adresse courte et pratique comunidadlatinadetecnologiaslibres@chat.disroot.org.
Daniel Gultsch et Holger Weiss ont eu un échange virtuel sur leur implémentation des fonctionnalités audio et vidéo [en anglais] au sein de Conversations, dans lequel ils y décrivent les détails techniques. La session a été conclue avec une deuxième présentation par eta, qui définit l’amour par cette équation : Asterisk + XMPP = <3.
Prof. Dr. P. Löbbecke a parlé dans une présentation en ligne de « Freie Messenger - Sichere Kommunikation » (messageries libres — communication sécurisée) [en allemand] qui traite de XMPP.
Des nouvelles des logiciels
Clients et applications
Gajim 1.2.0 a été publié. Plus d’une année après la sortie de Gajim 1.1.3, le moment est finalement venu pour Gajim 1.2. Une année mise à contribution pour développer de nouvelles fonctionnalités, nettoyer du vieux code et corriger des bogues. Parmi tous les changements, on remarquera particulièrement : l’amélioration du système de salon de discussion, la réécriture complète du code touchant les aspects réseau et un nouvel assistant de création de compte. Et il y a bien plus à découvrir.
Nouvelles du développement de Gajim : juin a déjà apporté avec lui Gajim 1.2, python-nbxmpp 1.0 et de nombreuses mises à jour de greffons. Mais il y a plus : Blind Trust Before Verification (confiance aveugle avant vérification) pour OMEMO, des améliorations dans le glisser‑déposer et un nouveau service de traduction pour Gajim.
Anu, le principal développeur de Monal, a publié de nouvelles versions bêta pour iOS et macOS. Grâce aux efforts de Thilo et Friedrich, de nouvelles fonctionnalités de débogage ont été incorporées. Il demande de fournir des journaux de débogage pour les rapports de bogues existants quand cela est possible.
Profanity a sorti sa version 0.9.0, qui prend en charge la XEP‑0308 (Last Message Correction) et corrige divers problèmes qui sont détaillés dans leur publication de blog. Après cette nouvelle sortie majeure, les versions 0.9.1, 0.9.2, 0.9.3 et 0.9.4 ont suivi, corrigeant des bogues.
JSXC a sorti sa version 4.1.1, qui corrige plusieurs problèmes liés à la vidéo et améliore l’interopérabilité avec Conversations. De plus, la première version expérimentale d’une application de bureau pour toutes les plates‑formes a été publiée. Le projet recherche des testeurs et des personnes avec de l’expérience sur Electron et la chaîne de compilation Travis.
Pix‑Art Messenger a supprimé sa prise en charge d’OTR depuis le 30 juin. La note générale à ce sujet peut être lue sur GitHub.
Et pour finir, pouvez‑vous croire cela ? Pidgin 2.14.0 ! 😯 Il y a également une chaîne Twitch de développement en direct qui émet chaque jeudi.
Serveurs
La communauté Ignite RealTime a sorti Openfire bêta 4.6.0 qui implémente la XEP‑0289 (Federated MUC for Constrained Environments) et améliore la prise en charge PEP et PubSub. Si vous avez le temps de tester, rejoignez‑les pour aider !
Bibliothèques
La bibliothèque XMPP de Gajim, python-nbxmpp, a vu sa version 1.0 publiée. Divergence amicale de l’antique bibliothèque xmppy, de nombreuses choses ont changé depuis. Beaucoup de travail y a été investi, particulièrement durant l’année passée. Si vous êtes intéressés, un exemple simple de client est disponible.
Divers
Le saviez‑vous ? League of Legends utilise XMPP en interne.
Google Summer of Code
Depuis début mai, des étudiants du monde entier travaillent sur plusieurs projets libres dans le cadre de cette saison du Google Summer of Code. Nous aimerions présenter les étudiants qui travaillent sur les projets XMPP du GSoC et partager leurs premières entrées de blog :
Aditya Borikar travaille sur la prise en charge de WebSocket dans Smack ; historique de son blog :
- Chapitre 1 : Les amabilités de connexion ;
- Chapitre 2 : Changements vers une composante modulaire ;
- Chapitre 3 : Les négociations SASL ;
- Chapitre 4 : Corriger les cibles défectueuses ;
- Chapitre 5 : Méthode de découverte discrète HTTP ;
- Chapitre 6 : Une partie de l’ensemble, intégré.
Anmol (wolfie_anmol) travaille sur l’implémentation de l’envoi de messages à la volée dans Dino (XEP‑0301 In‑Band Real Time Text) ; historique de son blog :
- Le GSoC 2020 débute — Introduction au RTT ;
- Stanza RTT et comparaison de messages ;
- Recevoir des messages en temps réel ;
- Interface utilisateur.
Merci de votre participation aux projets XMPP du GSoC et continuez votre travail de qualité ! À suivre.
Extensions et spécifications
Mises à jour
- la version 0.5.0 de la XEP‑0373 (OpenPGP for XMPP) :
- utilise le lexique de la RFC 4880 : il s’agit d’une « clé primaire » et non d’une « clé maîtresse »,
- clarifie le chiffrement des données de la clé secrète,
- déplace les informations de l’attribut date vers l’élément ID (fs) ;
- la version 1.3.0 de la XEP‑0156 (Discovering Alternative XMPP Connection Methods) :
- corrige la référence à la RFC 6415 et organise les prérequis plus clairement ; ceci fait évoluer le prérequis JSON de « peut » (optionnel) à « devrait » (dans les faits), pour s’adapter aux applications Web (fs) ;
- la version 1.1.0 de la XEP‑0157 (Contact Addresses for XMPP Services) :
- ajoute la valeur status‑addresses dans le registre, avec un exemple (mb, fs),
- la version 0.1.0 de la XEP‑0440 (SASL Channel‑Binding Type Capability) :
- acceptée par vote du Conseil le 27 mai 2020, (éditeur des XEP (jsc)) ;
- la version 0.3.1 de la XEP‑0390 (Entity Capabilities 2.0) :
- ajoute un autre exemple de xml:lang (fs) ;
- la version 0.6.0 de la XEP‑0384 (OMEMO Encryption) :
- intègre des retours à propos des termes de chiffrement et du contenu, par Sofia Celi (ps) ;
- la version 0.3.0 de la XEP‑0424 (Message Retraction) :
- clarifie quand un service doit rendre publique sa prise en charge via disco,
- ajoute un autre URN de découverte de service pour les pierres tombales [N. D. T. : nom donné à ce qui remplace le message rétracté] (jcb) ;
- la version 0.4.0 de la XEP‑0393 (Message Styling) :
- retire la description du mécanisme pour désactiver la personnalisation du style des spans et des blocks individuels, les utilisateurs pouvant faire cela eux‑mêmes sans que nous ne documentions l’utilisation d’un caractère Unicode qui n’est pas spécifiquement dédié à cela (ssw) ;
- la version 0.3.0 de la XEP‑0393 (Message Styling) :
- ajoute la capacité de désactiver la personnalisation des styles, clarifie davantage les aspects d’accessibilité et mentionne que Styling n’est pas compatible avec Markdown dans la section des aspects sécurité (ssw).
Remerciements
Cette lettre d’information XMPP a été réalisée collaborativement par la communauté. Merci à emus, jonas, nyco, pep., pmaziere, sualko, vanitasvitae, wurstsalat3000 et Zash pour leur aide durant son élaboration !
Diffusez ces informations !
Partagez ces informations sur les « réseaux sociaux » :
Licence
Cette lettre d’information est publiée sous la licence CC BY-SA 4.0.
Aller plus loin
- Cette lettre d’information de juin 2020 en anglais (10 clics)
- Toutes les lettres d’information (3 clics)
- Souscrire à la lettre d’information en anglais par courriel (2 clics)
- XMPP/Jabber sur LinuxFr.org (19 clics)
# Retours demandés
Posté par Anonyme . Évalué à 7.
La dernière lettre d'information a été l'occasion d'avoir un retour de certains lecteurs qui l'ont considérée comme trop technique, voire opaque.
Il faut savoir que, à ma connaissance et en dehors de l'e-mailing, ce contenu était publié à l'origine uniquement sur des sites centrés sur XMPP, à savoir xmpp.org pour la version originale, et jabberfr.org pour la traduction française. De fait, le public ciblé implique davantage des personnes ayant déjà une bonne connaissance de XMPP et des développeurs, plutôt que de simples utilisateurs.
Avec l'arrivée de cette traduction sur Linuxfr.org, qui s'est faite via Nÿco, il me semble que cette lettre a atteint un public francophone plus large que la cible initiale.
En conséquence, je serai très intéressé par recueillir vos impressions sur ce contenu, vos critiques et vos attentes éventuelles. Cela permettrait de soumettre des propositions aux personnes gérant cette lettre en amont. Ainsi, si ces propositions étaient acceptées, elles pourraient également bénéficier aux lecteurs anglophones, voire à ceux des autres traductions.
D'ailleurs, si vous maîtrisez l'anglais et une ou plusieurs autres langues, il serait utile d'avoir un éventail plus large de traductions pour maximiser la diffusion de cette lettre d'information. Pour le moment, il y a une traduction en français, en allemand et en espagnol. Ces deux dernières sont gérées par la même personne qui se trouve être également le coordinateur des lettres des 3 derniers mois: je pense qu'il ne rechignerait pas à avoir un peu d'aide :)
[^] # Re: Retours demandés
Posté par Space_e_man (site web personnel) . Évalué à 3.
Les thèmes qui nous préoccupent généralement sont :
[^] # Re: Retours demandés
Posté par Anonyme . Évalué à 8. Dernière modification le 13 juillet 2020 à 00:28.
À cela je répondrai trois mots: oui mais non :)
En préambule, je précise que je ne suis pas membre de la XSF, et encore moins membre de la commTeam qui gère cette lettre d'information: je ne suis qu'un relai parmi d'autres volontaires bénévoles qui apportent des infos à la newsletter, et accessoirement je me suis mis à sa traduction en français pour publier des dépêches et gagner des points de karma sur linuxfr.
Donc je n'ai pas de position officielle à transmettre, juste mon ressenti sur ce que je vois passer sur le salon public de l'équipe de communication.
La lettre d'information de la XSF ne me semble pas avoir pour vocation de générer du contenu original: elle n'est qu'un moyen de rassembler des informations éparses et de les servir à des personnes souhaitant les recevoir. Ce sur quoi les rédacteurs pourraient avoir la main relève plus de la manière dont ces informations sont présentées que du fond qui, lui, provient nécessairement de sources extérieures.
Tes deux premiers points demandent une recherche et une analyse qui me paraissent non seulement sortir de ce cadre, mais également être gloutons en moyen humain et en temps que les rédacteurs n'ont pas à leur disposition actuellement. Peut-être que la XSF possède ces données, mais je n'en ai aucune idée. Il faudrait qu'un ou plusieurs acteurs du monde XMPP pondent ce genre d'articles pour qu'ils soient ensuite relayés dans la lettre d'information.
Par contre, ta troisième proposition pourrait venir enrober chacune des news présentées pour fournir une vision plus globale et rendre l'ensemble moins aride, en particulier la section sur les XEPs.
[^] # Re: Retours demandés
Posté par Ppjet6 . Évalué à 5.
Je suis de loin ce qui se passe sur le salon et j'y contribue de temps en temps, mais je tenais avant tout à préciser que j'apprécie beaucoup le travail que vous faites sur cette newsletter, toi et les autres qui y contribuent :)
On en a déjà discuté, mais je pense que la cible visée n'a jamais vraiment été claire pour qui que ce soit. Il n'y a jamais eu d'instruction de la part de commteam, (l'équipe de la XSF qui est responsable de cette newsletter). Il se trouve que les sites sur lesquels cette newsletter était publiée visaient un public plutôt technique, ou tout du moins intéressé.
J'aimerais clarifier ce point au sein de l'équipe directement, et j'espère que cette discussion pourra aider.
Je suis sûr que cette newsletter ne répond déjà pas entièrement à cette supposée cible. Les plus techniques d'entre ses lectrices seront peut-être satisfaites, mais pour les personnes « intéressées » que je cite au dessus (notion assez vague au final), ça reste en effet assez compliqué à lire. Je serais content de rendre la newsletter plus accessible et d'avoir du matériel de vulgarisation pour aider.
Je ne suis pas convaincu par contre que ce soit important pour nous de faire des efforts pour essayer d'atteindre des utilisateurs moins intéressés.
Petite histoire marrante, ce matin sur un salon public un développeur nous fait une confidence à propos d'une personne de sa famille et il raconte : « Une personne de ma famille m'annonce qu'elle arrête d'utiliser son compte XMPP initial “parce qu'XMPP ne marche pas correctement”. Elle m'informe qu'elle sera uniquement joignable sur Snikket. »
Pour celles qui ne sont pas au courant, https://snikket.org est une solution basée entièrement sur XMPP[0].
Et c'est précisément ces utilisateurs que je ne veux pas viser. J'ai souvent l'impression que personne dans l'équipe et aux alentours ne sait vraiment ce qui se cache derrière le mot « utilisateur » quand c'est utilisé en tant que cible.
Quant au contenu lui-même, je ne serais pas vraiment dire, je suis un développeur XMPP et donc je suis biaisé :P
[0]: https://snikket.org. Je vous recommande d'y jeter un œil. C'est Conversations avec un autre thème + Prosody, ça fédère, tout ce qu'il faut, mais les utilisateurs n'ont pas besoin de savoir. Il y a aussi certaines garanties qui font que ça mérite de s'appeler « Snikket » et pas juste Conversations + Prosody et c'est exactement ce que je trouve intéressant dans ce projet.
[^] # Re: Retours demandés
Posté par Anonyme . Évalué à 4.
La question du matériel de vulgarisation se pose de manière parallèle à l'accessibilité de la newsletter. Cela va demander un travail sur le long terme, alors que j'espère qu'on pourra améliorer la lettre dès la prochaine édition.
Si les outils sont disponibles, ce sont ces utilisateurs qu'il faut amener vers XMPP.
Je suis d'accord avec seveso quand il dit que XMPP a un problème de masse critique et ce manque de popularité pourrait venir de deux choses:
- la disparité des nombreux clients en terme de fonctionnalités les rendant difficilement compatibles, sans que cela ne soit clairement établi où que ce soit (le cas android vs iOS en est un exemple flagrant).
- la méconnaissance des avantages d'XMPP par rapport aux solutions plus à la mode, induit par le nombre et l'opacité des XEPs
La partie "clients" est de la responsabilité des développeurs. Mais, tel que je comprends son rôle, celle de la XSF est de les amener à réduire ces disparités, par exemple en recensant quel client implémente quelle fonctionnalité/XEP, à l'image d'un omemo.top: cela aiderait à éclaircir l'horizon.
Par contre je vois la newsletter comme un outil de communication qui vise à faire connaître l'activité autour de XMPP:
et ainsi contribuer à réduire cette mauvaise connaissance des avantages d'XMPP.
Pour ce qui concerne les réseaux sociaux, il faudrait au minimum susciter la curiosité en ne se limitant pas à un simple lien vers la lettre: un élément de la lettre devrait servir d'accroche.
Pour ce qui est de la lettre elle-même, elle devrait au moins apporter un contexte simplifié dans la présentation de chaque news plutôt que de se borner comme actuellement à une simple reprise des information extérieures.
Comme tu l'as dit, cette discussion devrait avoir lieu sur le salon de la commTeam, donc j'arrête là.
Mais je voudrais vraiment que toutes ces personnes "intéressées" donnent ici leurs avis pour pouvoir avoir des arguments appuyés à proposer sur le salon.
[^] # Re: Retours demandés
Posté par Ppjet6 . Évalué à 2.
Je ne suis pas d'accord pour dire que XMPP a un problème de masse critique, parce que ça ne m'intéresse pas d'amener XMPP à la masse.
Ce qui j'aimerais voir arriver à la masse ce sont des solutions avec des directions communes au niveau graphique, design, fonctionnalités, interopérabilité, etc.
Ça fait qu'on est assez d'accord sur le premier point dont tu (et seveso) parles, mais je ne place pas la faute sur XMPP (ni la XSF). C'est un point auquel je tiens et pour lequel je vois beaucoup d'utilisateurs faire l'amalgame, en disant que « tous les clients XMPP doivent supporter X parce que sinon c'est nuisible pour l’interopérabilité. » Et je m'y oppose fermement en disant que non, pas tous les clients doivent supporter X, mais il est possible qu'un set de clients supportent X et interop proprement. Ce set de client pourrait être « tous les clients XMPP » mais ça n'est pas obligatoire.
C'est pour ça que j'encourage des solutions comme Snikket qui répond exactement à ce problème, (de même que les produits de Tigase sur iOS à moindre mesure).
Au final pourquoi c'est important que ce soit XMPP qui soit utilisé derrière par cet ensemble de clients, tant qu'il y a les mêmes propriétés au niveau du client (attention à la vie privée, sécurité, fédération, etc.), (et serveur pour les opérateurs). Je suis de l'avis que ça n'est pas du tout important.
Quant à ton 2è point j'y ai déjà répondu au dessus.
[^] # Re: Retours demandés
Posté par seveso . Évalué à 2.
J'avoue être très surpris par cette phrase. Et la suite de ton commentaire ne m'aide pas vraiment à comprendre le fond de ta pensée.
Pour ma part, j'aimerais que XMPP arrive à la masse critique. Ça me permettrait plus facilement de répondre à quelqu'un qui me demande de rejoindre Whatsapp (ou autre) : "rejoins-nous plutôt sur XMPP, presque tout le monde a déjà un compte"
Je crois que ce que Pierre Mazière disait au sujet de la XSF ce n'est pas qu'elle était fautive de quoique ce soit mais que ce serait pas idiot qu'elle prenne prenne à bras le corps les problèmes de "lisibilité" de XMPP. L'initiative modernxmpp semble chercher à combler ce manque. De sorte que le vocabulaire employé dans différentes applications soit un peu cohérent par exemple.
En tout cas je trouve que l'écosystème XMPP est vraiment trop obscur à comprendre, même pour quelqu'un qui accepte de prendre le temps de faire de recherches sur le sujet.
En attendant que l'univers XMPP devienne limpide pour l'humanité entière, perso je pousse les gens vers les docs de chapril.org (oui encore de la pub pour chapril :)) parce qu'elles s'adressent à des gens qui souhaitent juste se lancer dans XMPP, sans blabla. L'idée étant de pouvoir faire le premier pas rapidement. Les subtilités de XMPP arriveront après, éventuellement à tâtons.
[^] # Re: Retours demandés
Posté par Ppjet6 . Évalué à 1.
Je pense que le point important—en lisant la suite de ton commentaire—est qu'on ne cible pas le même public.
Pour reformuler ma phrase : « Je ne suis pas d'accord pour dire que XMPP a un problème de masse critique, parce que ça ne m'intéresse pas d'amener XMPP à la masse. Ce qui m'intéresse c'est d'amener des solutions qui utilisent XMPP à la masse. ». Ceci vise évidemment un public qui ne connaît pas / ne comprends pas / ne cherche pas à comprendre ce qu'est XMPP, qui pour moi est une majorité.
Tant mieux si XMPP réussit à se faire un nom, mais ça n'aura d'intérêt uniquement que pour ceux qui comprennent et qui sauront utiliser ce fait.
[^] # Re: Retours demandés
Posté par Ppjet6 . Évalué à 1.
Ces commentaires m'ont poussé à mettre toute ces idées en forme et j'ai publié https://bouah.net/2020/07/what-about-design/ (en anglais pour l'instant). J'espère que ça aide un peu.
[^] # Re: Retours demandés
Posté par jnanar (site web personnel) . Évalué à 4.
Merci pour ce travail. Je suis intéressé par l'actualité du monde XMPP. Je suis de loin les évolutions et j'apprécie de pouvoir lire la traduction de la newsletter. J'avoue survoler le paragraphe des extensions mais j'apprécie particulièrement de voir les évolutions des clients. Pour résumer, la dépêche dans sa forme actuelle me convient et je vous félicite/vous suis reconnaissant pour le travail accompli. :-)
[^] # Re: Retours demandés
Posté par seveso . Évalué à 2. Dernière modification le 17 juillet 2020 à 20:31.
Cette newsletter s'adresse clairement à des personnes qui s'intéressent déjà d'assez prêt à XMPP. Publier sa traduction "telle quelle" sur linuxfr n'est pas forcément une bonne idée.
Peut-être faudrait-il envisager un travail éditorial dédié pour linuxfr. Au lieu de poster sa traduction, on publierait à chaque fois une news linuxfr "inspirée de la newsletter". Ainsi, on n'aurait pas cette contrainte de devoir rester fidèle à l'original. Et donc pas besoin de forcer la main aux auteurs de la newsletter pour qu'ils s'adaptent aux besoins de linuxfr.
Bien sûr ça ferait un peu plus de boulot pour linuxfr. Mais si ça venait à se faire je veux bien proposer mon aide. Je n'ai encore jamais participé à la rédaction d'une news linuxfr, je n'ai aucune idée du temps et du dévouement que ça me demanderait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.