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 septembre 2020.
Vous y trouverez, en plus des nouveautés, un appel à contribuer à la documentation et à la vie de XMPP.
Sommaire
- Annonces de la XSF
- Articles
- Des nouvelles des logiciels
- Extensions et spécifications
- Remerciements
- Diffusez ces informations !
- Appel à la communauté
- Licence
Annonces de la XSF
La XSF a ouvert sa période de candidature pour les élections annuelles du Bureau et du Conseil de la XSF. Les candidats pour le Conseil doivent être des membres élus de la XSF, alors que les sièges du Bureau sont ouverts à tout le monde. Si vous êtes intéressés pour candidater à ces postes, visitez la page de candidature.
La période de candidature du quatrième trimestre 2020 pour devenir membre de la XSF est également ouverte. Si cela vous intéresse, faites vous connaître ici.
Articles
Le blog allemand kuketz-blog.de a publié la partie 6 de sa série sur les messageries instantanées [en allemand], cet opus s’intéressant spécifiquement à Conversations, client XMPP pour Android.
Tigase a publié un article sur le développement de sa bibliothèque multi‑plate‑forme Halcyon [en anglais] écrite en Kotlin.
Dans un autre article publié plus tard dans le mois, ils ont abordé les problématiques de publication et d’abonnement [en anglais], toujours avec Halcyon, via la XEP‑0060.
Et pour clore cette série d’articles, l’équipe de Tigase a expliqué la mise en place de fonctionnalités STUN et TURN en complément de leur serveur XMPP [en anglais] en utilisant la XEP‑0215.
Des nouvelles des logiciels
Clients et applications
Une nouvelle version majeure de Movim est sortie, avec des notifications améliorées, de nouvelles fonctionnalités de discussion et de vidéoconférence et une grande amélioration des performances. Une nouvelle version de l’application Android est également disponible pour intégrer toutes ces fonctionnalités dans cet environnement. Découvrez toutes les améliorations de cette nouvelle version dans le billet officiel de publication Movim 0.18 – Oterma. Jetez donc un œil au widget de dessin de Movim :
Nouvelles de septembre du développement de Gajim : le billet de ce mois‑ci marque la première année des « Nouvelles du développement de Gajim » ! La refonte de la fenêtre de préférences de Gajim est arrivée à sa fin. Les invitations à rejoindre des salons ont été améliorées et le paramétrage des salons rendu plus simple d’accès. Rejoindre un salon est maintenant beaucoup plus agréable.
MCabber, le vénérable client à interface textuelle, a été publié en version 1.1.1 et 1.1.2. Outre les corrections de bogues, la prise en charge de l’affichage du nombre de messages non lus et la réorganisation de la gestion des messages en copie carbone ont été implémentées.
Le SDK Python pour les appareils de cuisine General Electric connectés par Wi‑Fi, gekitchen, a publié sa première version sur GitHub. L’objectif initial est de l’utiliser pour pousser les intégrations du Home Assistant, bien que cela nécessite probablement d’attendre l’arrivée de nouveaux types d’entités. Il utilise XMPP comme un moyen d’authentification, puisque c’est ce qu’utilise l’application GE SmartHQ pour communiquer avec les appareils.
XMPP sur iOS et macOS semble se renforcer :
Bienvenue à BeagleIM 4.0 et SiskinIM 6.0 ! Les clients iOS et macOS de Tigase communiquent via la XEP‑0369 (Mediated Information eXchange, ou MIX), nouveau protocole des salons de discussion XMPP. La connectivité VoIP a été améliorée avec l’implémentation de la XEP‑0353 (Jingle Message Initiation), la XEP‑0308 (Last Message Correction) est disponible pour corriger les messages qui ont déjà été envoyés, et d’autres fonctionnalités ont été ajoutées comme la XEP‑0424 (Message Retractation) et les réponses rapides pour les citations. La prise en charge des formulaires de CAPTCHA a été également implémentée : la XEP‑0158 (CAPTCHA Forms) est mise en place pour des vérifications supplémentaires lors de l’enregistrement d’un compte. Bien sûr, il y a aussi beaucoup d’autres changements et corrections !
Le client Monal, pour iOS et macOS, s’est vu associer un nouveau serveur de push et a reçu des améliorations concernant la gestion de l’archivage des messages. C’est un des nombreux changements qui arrivera dans les futures versions. Soyez prêts et jetez‑y un œil dans la Beta Testflight de Monal.
Serveurs
Aucune chance pour les indésirables : Openfire présente son nouveau greffon Spam blacklist qui permet aux utilisateurs de faire des signalements. Signalez les spammeurs en puissance ! Le greffon d’observation d’Openfire a été publié en version 2.1.0, permettant la recherche sur l’ensemble du texte des messages archivés.
L’équipe du serveur XMPP Prosody a été bien occupée ce mois‑ci avec plusieurs choses sympathiques. Pour commencer, elle a annoncé la publication de la version 0.11.6 de Prosody. Les développeurs ont également publié une série de nouveaux modules pour permettre une inscription sur simple invitation qui peut aider et guider les nouveaux utilisateurs à choisir un client adéquat et créer leur premier compte XMPP. Et pour finir, ils ont publié un ensemble de conseils pour quiconque souhaitant s’attaquer aux messages indésirables sévissant sur le réseau XMPP.
Bibliothèques
La petite bibliothèque libstrophe pour client XMPP, écrite en C, a été publiée en version 0.10.0 qui, outre les corrections de bogues et une nouvelle API, apporte de nouvelles fonctionnalités : prise en charge des méthodes d’authentification SCRAM‑SHA‑256 et SCRAM‑SHA‑512, prise en charge de la bibliothèque de résolution asynchrone de nom de domaines c‑ares, prise en charge de LibreSSL et ajout de gestionnaires à déclenchement périodique, indépendamment du statut des connexions.
Une deuxième bêta a été publiée pour Smack 4.4.0, la bibliothèque XMPP en Java de la communauté Ignite RealTime.
Divers
Google Summer of Code 2020 : Anmol a résumé ses trois mois de travail sur l’implémentation de messages en temps réel dans Dino (XEP‑0301 In‑Band Real Time Text) via un dernier billet de blog.
Le propriétaire du domaine joinxmpp.org manque de temps pour développer ce projet plus avant. Il a écrit un court résumé décrivant les objectifs originaux et indique qu’il cherche maintenant quelqu’un de motivé pour reprendre le projet.
Extensions et spécifications
Les développeurs et autres experts de la standardisation de par le monde collaborent à ces extensions, développant de nouvelles spécifications pour les pratiques naissantes, et affinant les manières de faire existantes. Proposées par qui le souhaite, les spécifications rencontrant le plus de succès aboutissent à un statut de « Finale » ou « Active », en fonction de leur type, alors que les autres sont soigneusement archivées sous l’appellation « Ajournée ». Ce cycle de vie est décrit dans la XEP‑0001 qui contient les définitions formelles et canoniques pour les types, états et processus. Apprenez en plus sur le processus de standardisation.
Mises à jour
- version 2.11.0 de la XEP‑0004 (Data Forms) : clarifie davantage la nécessité de l’existence d’un attribut
typedans les champs.
Derniers appels
Les derniers appels sont émis une fois que chacun semble satisfait de l’état courant d’une XEP. Après que le Conseil a décidé que la XEP était prête, l’éditeur XMPP émet un dernier appel à commentaires. Les retours rassemblés pendant le dernier appel aident à améliorer la XEP avant qu’elle ne retourne devant le Conseil pour une évolution vers le statut de brouillon :
- XEP-0411 (Bookmarks Conversion).
Extensions proposées
Le processus de développement d’une XEP commence par la mise par écrit d’une idée et sa soumission à l’éditeur XMPP. Dans un délai de deux semaines, le Conseil décide s’il accepte d’accorder à cette proposition le statut d’une XEP expérimentale :
- ensembles de tests de conformité XMPP 2021 : ce document définit les catégories d’application XMPP pour différents usages (Core, Web, IM et Mobile), et spécifie les XEP que les logiciels clients et serveurs ont besoin d’implémenter pour être conformes à ces usages.
Remerciements
Cette lettre d’information XMPP a été réalisée collaborativement par la communauté. Merci à agnauck, emus, mdosch, mwild1, pep., pmaziere, Seve, wurstsalat3000 et Zash pour leur aide durant son élaboration !
Diffusez ces informations !
Partagez ces informations sur les « réseaux sociaux » :
Trouvez et proposez des offres d’emploi sur le site xmpp.work.
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.
Licence
Cette lettre d’information est publiée sous la licence CC BY‑SA 4.0.
Aller plus loin
- Cette lettre d’information de septembre 2020 en anglais (20 clics)
- Toutes les lettres d’information (13 clics)
- Souscrire à la lettre d’information en anglais par courriel (14 clics)
- XMPP/Jabber sur LinuxFr.org (22 clics)
# corrections
Posté par Anonyme . Évalué à 2.
Bonjour,
Dans la section Divers, il faudrait séparer les deux phrases qui traitent de deux sujets complètement différents de manière à ce que chacune soit sur sa ligne, séparées par une ligne vide.
merci
[^] # Re: corrections
Posté par palm123 (site web personnel) . Évalué à 3.
corrigé, merci
ウィズコロナ
# Titre
Posté par M5oul (site web personnel) . Évalué à 2.
Avec ce titre je m’attendais à la bonne nouvelle que XMPP fonctionne mieux sur IPomme.
[^] # Re: Titre
Posté par Anonyme . Évalué à 2. Dernière modification le 12 octobre 2020 à 10:42.
c'est le cas, mais ça avance doucement…
Le mois de septembre a vu beaucoup d'efforts de la part des équipes de Tigase et Monal se concrétiser sur les systèmes d'Apple après une période assez morne: en espérant que cela continue ainsi pour aboutir à des solutions pleinement fonctionnelles et interopérables.
# Et du coup, pour remplacer Whatsapp & autres
Posté par Dring . Évalué à 3.
Bon, je ne commettrai pas l'insulte de mettre l'habituel XKCD, mais bon, l'objectif idéal serait de remplacer les 73 outils de conversation avec un seul.
Aujourd'hui, je comprends que Linux/Windows/Android, c'est bon. Mais pour iPhone, c'est pas encore ça.
Mais concrètement, si je veux me lancer demain, je suggère quoi comme client à mes amis ? Pour Android et pour iOS ?
[^] # Re: Et du coup, pour remplacer Whatsapp & autres
Posté par Anonyme . Évalué à 4. Dernière modification le 12 octobre 2020 à 15:12.
Android:
Quicksy pour une entrée dans le monde XMPP accessible à tous sans se poser de question
Conversations pour ceux qui ont compris comment cela fonctionne, quel est l’intérêt de la décentralisation et désirent choisir le fournisseur de service XMPP qui lui convient le mieux.
Apple:
Aucun de ces trois n'étant ni noob-friendly ni entièrement fonctionnel en terme d'interoperabilité. Comme expliqué plus haut, Siskin et Monal ont fait de joli progrès ce mois-ci mais je n'ai pas testé, et ChatSecure est celui que j'ai fait installé à mes contacts il y a maintenant 1 an.
Un des gros problème d'Apple que j'ai pu rencontré est sa gestion du maintien d'une connexion permanente qui nécessite un serveur de push et des contorsions complexes pour passer par dessus les barrières mises en place par cet écosystème privateur.
Mais je ne suis pas un spécialiste du sujet, ni de rien d'autre d'ailleurs :) , donc si d'autres ont une meilleure vision des difficultés liées à ces systèmes, qu'ils n'hésitent pas à corriger et compléter.
[^] # Re: Et du coup, pour remplacer Whatsapp & autres
Posté par Anonyme . Évalué à 2.
désolé, ça me fait mal aux yeux:
joli => jolis
installé => installer
rencontré => rencontrer
[^] # Re: Et du coup, pour remplacer Whatsapp & autres
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7.
Le problème est lié à l'utilisation de connexions persistantes TCP en général sur les terminaux mobiles.
En gros, avoir une connection TCP qui reste ouverte en permanence, ça oblige à envoyer des données et à rester tout le temps à l'écoute, ça empêche l'appareil de se mettre en veille, et donc ça vide la batterie.
Le problème est le même avec n'importe quel OS.
La solution proposée (aussi bien pour Apple que Android) ce sont effectivement les "push notifications" qui évitent d'avoir une connexion ouverte en permanence pour chaque application. La XSF se penche sur le sujet, a priori le point d'entrée est https://xmpp.org/extensions/xep-0286.html avec des liens vers plusieurs autres XEP donnant les bonnes pratiques pour un client fonctionnant sur ce type de réseau.
En particulier pour les push notifications: https://xmpp.org/extensions/xep-0357.html
[^] # Re: Et du coup, pour remplacer Whatsapp & autres
Posté par barmic 🦦 . Évalué à 2.
Ce qui est ironique n'est que Google a une api xmpp pour pousser des notifications (en fait il semble qu'en interne firebase utilise pas mal xmpp, même si c'est rarement exposé).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 6. Dernière modification le 14 octobre 2020 à 10:22.
Bonjour
XMPP est un sujet qui est abordé régulièrement sur ce forum et depuis longtemps,
et une question me taraude :
Serait il envisageable d'utiliser XMPP comme transporteur de fichier.
Exemple : X sites ont besoin de communiquer régulièrement des fichiers, ces fichiers sont générés périodiquement et ont besoin d'être diffusé.
Et il y a besoin de savoir si le transfert a été correctement effectué, si il a été lue etc …
Exemple : un site central envoie des relevés de factures a ses magasins
Actuellement c'est fait par mail , mais quand quelque chose n'arrive pas, difficile pour le quidam moyen de dire d'ou vient le probleme, on sait que le mails est partis c'est tout.
Le mail, le transfert ftp/sftp a ses limites propre, et ceci même sur un réseau interne.
Et un dialogue envoyé / transmis d'un coté et récupéré / confirmé de l'autre serait ideal
Surtout sur des envois/récupération automatique
Quelque chose comme CFT/Axway Transfer (pour ceux qui connaissent) mais basé sur XMPP
Ma question : est ce possible ? ou XMPP a t il des limitations sur le volume ou la vitesse de transfert ?
J'ai déjà trouvé ceci : https://linuxfr.org/users/jnanar--2/journaux/errol-envoyer-automatiquement-des-fichiers-avec-xmpp
Qui est un bon début que je vais certainement étudier pour apprendre à utiliser XMPP car cela m'a l'air d'un bel outil.
J'ai parcouru quelques XEP ( XEP-0234/XEP-0065/XEP-0096/XEP-0060) a la lecture de quelques pages (dont Errol ) mais je profite de l'occasion d'en parler ici.
Voila si vous pouviez partager vos remarques et expériences merci d'avance
[^] # Re: Petite question ...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 8.
Salut,
C'est du côté de Jingle qu'il faut regarder, et en particulier la XEP-0234. Le transfert de fichiers est un peu complexe à aborder parce que ça implique de nombreuse XEPs : il y a plusieurs méthodes, des façon de passer les NAT et autres, un système de fallback, une possibilité de faire du chiffrement de bout à bout, etc.
Cette XEP a un système de somme de contrôle (cf. XEP-0234 §8.2), permettant de vérifier que le fichier a été correctement reçu.
Je conseille fortement d'utiliser une implémentation existante plutôt que de partir de zéro, tu peux regarder sur https://xmpp.org/software/libraries.html.
Dans le projet sur lequel je travaille (Salut à Toi) il y a un composant de gestion de fichiers (via Jingle ou HTTP File Upload), fonctionnel mais qui pas encore stable. Il y a effectivement aussi le projet de jnanar (errol que tu as cité).
Bref, oui c'est possible, et non il n'y a pas de limitation sur le volume ou la vitesse de transfert (sauf si imposé par une des parties, par exemple un serveur qui sert de relai). D'autre part le côté extensible de XMPP te permet d'ajouter des choses qui te manqueraient, soit de manière spécifique à ton projet, soit en les proposant comme nouveau standard si c'est potentiellement utile à d'autres.
[^] # Re: Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Merci pour ta réponse
Oui je vois bien XMPP comme un couteau suisse et comme une base robuste pour bâtir quelque chose sans repartir de zéro.
Merci beaucoup pour les liens, j'ai de quoi m'occuper pour les longues soirées d'hiver qui viennent …
[^] # Re: Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
J'ai l'impression que "Salut à Toi" réponds à une grosse partie de ce que j'imaginais et peut être même beaucoup plus.
[^] # Re: Petite question ...
Posté par jnanar (site web personnel) . Évalué à 6.
Hello,
C'est moi qui ait développé Errol. Mon besoin est d'envoyer un fichier LaTeX d'un serveur à un autre afin de n'installer Tex Live que sur une des machines. Le PDF généré est renvoyé de l'autre côté. Je me base sur slixmpp mais leur implémentation pour le transfert de fichier n'est pas complète et je n'ai pas les compétences actuellement pour ajouter le support de jingle. Mon outil ne fait pas de vérification d'intégrité et il utilise le "stream" des données de manière brute. Ça pète en cas de déconnexion par exemple. Pour un usage plus sérieux, je pense que Salut-à-Toi est effectivement plus adapté. Avec l'outil JP, tu pourras appeler SAT depuis d'autres outils (des scripts shells, des units systemd, etc).
Je pense que ton projet est parfaitement réalisable et il y a toutes les briques nécessaires. Il faut juste parfois mettre un coup d'enduit, colmater une fissure et donner un coup de peinture mais dans l'ensemble, ça va.
[^] # Re: Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Merci beaucoup pour ta réponse
Et c'est d'ailleurs en lisant ton journal sur Errol que je me suis dit que XMPP pourrais faire l'affaire.
[^] # Re: Petite question ...
Posté par jnanar (site web personnel) . Évalué à 4.
N'hésite pas à venir faire un tour sur les salons sat@chat.jabberfr.org ou jabberfr@chat.jabberfr.org. Tu trouveras beaucoup d'utilisateurs enthousiastes prêt à donner un coup de main. Je maintiens les PKGBUILD de développement pour Salut-à-Toi sous Archlinux et Goffi est très disponible également.
[^] # Re: Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
OK merci mais j'ai encore besoin d'un coup de main :
comment je fais pour me créer un compte compatible XMPP et sat
et me permettant de me connecter sur ces salons
En attendant vos réponses, je cherche de mon coté ( rtfm … )
[^] # Re: Petite question ...
Posté par jnanar (site web personnel) . Évalué à 2.
La fédération des réseaux permet à chaque adresse XMPP de se connecter sur des salons et d’interagir avec des utilisateurs de tout réseau comme pour le mail.
Comme tous les serveurs ne supportent pas tous les même fonctionnalités, le choix du serveur peut avoir son importance dans les fonctionnalités disponibles, en fonction de ce qu'on veut.
Pour avoir une chouette expérience des capacités de type réseau social, je pense qu'une adresse movim est un bon choix. S'il s'agit juste de parler, une adresse jabberfr.org fera l'affaire.
J'en utilise une régulièrement pour mes tests.
Pour tester l'envoi et la réception de fichier, les deux devraient faire l'affaire donc je dirais que Movim est plus adapté si tu veux partager l'état d'un transfert de fichier en bloguant avec Salut-à-Toi. Ce dernier propose également une plateforme de test ouverte à la création de compte: https://www.libervia.org mais c'est plus une vitrine de test qu'un service fourni dans la durée.
[^] # Re: Petite question ...
Posté par Christophe B. (site web personnel) . Évalué à 3.
Merci pour l'info
j'avais crée un compte sur jabber mais je vais aussi en créer un sur movim
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.