Lettre d’information XMPP, 3 décembre 2019, XMPP dans toutes les langues

Posté par Anonyme le 05 décembre 2019 à 17:31. Édité par Nÿco, Davy Defaud, Florent Zara, ZeroHeure, Benoît Sibaud et Ysabeau 🧶 🧦. Modéré par ZeroHeure. Licence CC By‑SA.

Étiquettes :

déc.

2019

Bienvenue dans la lettre d’information XMPP couvrant le mois de novembre 2019. Aidez‑nous à entretenir cet effort communautaire dont le processus est entièrement documenté.

Newsletter XMPP

Lettre d’information XMPP

Articles

Edivaldo Brito a écrit en portugais « Como instalar o moderno cliente Jabber/XMPP Dino no Linux via Snap » (« Comment installer le client moderne Jabber/XMPP Dino sur Linux via Snap »).

Dino

La lettre d’information XMPP de novembre 2019 a été traduite en allemand, en espagnol et en français par des membres de la communauté. Nous sommes très reconnaissants de ces contributions ! Si vous pouvez contribuer par une traduction dans votre propre langue, contactez la CommTeam.

Publications de logiciels

Serveurs

La communauté Ignite Realtime a publié :

Openfire 4.4.4 ;
le greffon HTTP File Upload 1.1.2 et 1.1.3 ;
le greffon inVerse Openfire 5.0.5.1.

Metronome IM v3.13.0 a été publié, lisez le journal des changements.

Clients et applications

Movim 0.16 – Cesco a été publié, avec du dessin et du partage de contenus, pièces jointes, améliorations de chat, et des améliorations de listes de chats et salons, et recherche, et bien plus ;
gajim.org met en avant son nouveau site Web ; il est prévu de publier un article sur le développement de Gajim tous les mois, en démarrant avec octobre et novembre ;
Goffi, le développeur principal de SàT, a publié ses notes de progressions 2019‑W48 ;
Conversations 2.6.0 a été publié ;
Converse.js 5.0.5 a été publié.

Bibliothèques

xmpp.js a été publié en versions 0.9.0 et 0.9.1 ;
Process One a annoncé la sortie de go‑xmpp 0.3.0.

Extensions et spécifications

Ce mois‑ci, pas de XEP en dernier appel, proposée ou obsolète.

Rétractation de message

La version 0.1.0 de la XEP‑0424 (Message Retraction) a été publiée :

abstract : « This specification defines a method for indicating that a message should be retracted. » ;
résumé : cette spécification définit une méthode pour indiquer qu’un message devrait être retiré ;
changement : acceptée par vote du Conseil le 23 octobre 2019 [XEP Editor (jcb)] ;
URL : https://xmpp.org/extensions/xep-0424.html.

Modération de message

La version 0.1.0 de la XEP‑0425 (Message Moderation) a été publiée :

abstract : « This specification defines a method for groupchat moderators to moderate messages. » ;
résumé : cette spécification définit une méthode permettant aux modérateurs de salons de discussion de modérer des messages ;
changement : acceptée par vote du Conseil le 16 octobre 2019 [XEP Editor (jcb)] ;
URL : https://xmpp.org/extensions/xep-0425.html.

Mises à jour

la version 1.23.1 de la XEP‑0001 (XMPP Extension Protocols) a été publiée ;
la version 1.17.0 de la XEP‑0060 (Publish‑Subscribe) a été publiée ;
la version 1.0.1 de la XEP‑0076 (Malicious Stanzas) a été publiée ;
la version 1.1.4 de la XEP‑0084 (User Avatar) a été publiée ;
la version 1.0.1 de la XEP‑0158 (CAPTCHA Forms) a été publiée ;
la version 0.3.0 de la XEP‑0423 (XMPP Compliance Suites 2020) a été publiée ;
la version 0.2 de la XEP‑0328 (JID Preparation and Validation Service) a été publiée ;
la version 0.3 de la XEP‑0372 (References) a été publiée ;
la version 0.7.0 de la XEP‑0392 (Consistent Color Generation) a été publiée ;
la version 0.2.0 de la XEP‑0393 (Message Styling) a été publiée ;
la version 1.1.0 de la XEP‑0410 (MUC Self‑Ping [Schrödinger’s Chat]) a été publiée ;
la version 0.2.0 de la XEP‑0420 (Stanza Content Encryption) a été publiée.

Merci à tous !

Cette lettre d’information XMPP est produite de manière collaborative par la communauté. Merci à Nÿco, Guus, Wurstsalat, MDosch, Neustradamus, Ppjet6 pour leur aide durant son élaboration ! Merci de partager ces informations sur les « réseaux sociaux » :

Twitter ;
Mastodon ;
LinkedIn ;
Facebook ;
Reddit.

Licence

Cette lettre d’information est publiée sous la licence CC by‑SA.

Aller plus loin

Cette lettre d’info de décembre 2019 en anglais (18 clics)
Toutes les lettres d’information (15 clics)
Souscrire à la newsletter en anglais par courriel (12 clics)
XMPP/Jabber sur LinuxFr.org (22 clics)

# Un client pour iOS ?

Posté par Anonyme le 05 décembre 2019 à 18:12. Évalué à 3.

[pas taper !]

je cherche pour un inconscient qui n'arrive pas à trouver un client potable pour iOS. quelqu'un aurait une suggestion ? Les besoins sont OMEMO, chat, MUC et envoi d'image.

On a testé siskin, astrachat et chatsecure mais l'envoi d'image ne semble pas fonctionner avec mon serveur prosody.

Je n'exclus pas une erreur de ma part dans la config prosody, mais cela me semble peu probable puisque d'autres clients non iOS fonctionnent sans soucis

merci

PS: mes excuses pour le copier/coller de ce commentaire posté dans la précédente dépêche ayant peu de chance de recevoir une réponse
- [^] # Re: Un client pour iOS ?
  
  Posté par Goffi (site web personnel, Mastodon) le 05 décembre 2019 à 22:50. Évalué à 4.
  
  Sans avoir testé moi même (je n'ai pas d'appareil avec iOS), Monal est un nom qui revient souvent (avec ChatSecure que tu as testé). Sinon l'équipe de Tigase est assez active ces derniers temps, leur clients sont sans doute à tester (BeagleIM et Siskin IM).
  
  Si tu testes, ça pourrait être pas mal de dire ce que t'en penses ici, pour voir si ce sont des clients qu'on peut recommander.
  - [^] # Re: Un client pour iOS ?
    
    Posté par Anonyme le 05 décembre 2019 à 23:18. Évalué à 3.
    
    Je n'ai pas d'appareil iOS non plus et la personne qui teste n'est pas du genre à aimer tester: il faut que ça marche sinon ça dégage, donc c'est déjà énorme d'avoir tenter plusieurs clients :)
    
    Siskin est ce qui a été retenu pour le moment, mais on n'arrive toujours pas à transférer et afficher des images
    
    Quant à Monal, ca n'est pas stable du tout: plantage toutes les 30s
    - [^] # Re: Un client pour iOS ?
      
      Posté par seveso le 06 décembre 2019 à 21:01. Évalué à 2.
      
      Je n'ai pas d'appareil iOS non plus et la personne qui teste n'est pas du genre à aimer tester: il faut que ça marche sinon ça dégage
      
      J'ai aussi trouvé une personne pour tester quelques applis sur iOS et c'était le même état d'esprit :)
      Mais finalement on a pu tester Siskin et ChatSecure et je confirme que Siskin permet le partage d'images.
      
      Siskin est ce qui a été retenu pour le moment, mais on n'arrive toujours pas à transférer et afficher des images
      
      Le problème ne serait-il pas côté serveur plutôt ? Est-ce que ça fonctionne avec un autre client comme Conversations sur Android ou Gajim sur PC ?
      - [^] # Re: Un client pour iOS ?
        
        Posté par Anonyme le 07 décembre 2019 à 21:01. Évalué à 2.
        
        pas de problèmes avec d'autres clients android, linux ou windows
      - [^] # Re: Un client pour iOS ?
        
        Posté par Anonyme le 08 décembre 2019 à 23:41. Évalué à 3.
        
        coté serveur j'ai ajouté la XEP-357 (push notification), via mod_cloud_notify et mod_muc_cloud_notify, qui semble être nécessaire pour iOS, mais je n'ai pas encore eu la possibilité de retester.
        Quelles spécificités as-tu du mettre en place pour que cela fonctionne ?
        
        [^] # Re: Un client pour iOS ?
        
        Posté par seveso le 09 décembre 2019 à 09:02. Évalué à 2.
        
        De mon côté j'ai testé avec un serveur ejabberd 18.12 installé à partir des dépôts Debian Buster. Dans la config par défaut il y avait déjà mod_push d'activé (XEP-357) mais je ne vois pas quel rapport ça pourrait avoir avec le partage de fichiers. Je pense que ton soucis est ailleurs.
        
        Peut-être que le service XMPP Compliance Tester pourrait t'aider à déceler ce qui cloche sur ton serveur. C'est un service en ligne mais que tu peux aussi le faire tourner sur ta propre machine si tu préfères garder ton serveur XMPP discret.
        
        [^] # Re: Un client pour iOS ?
        
        Posté par Anonyme le 09 décembre 2019 à 11:27. Évalué à 2.
        
        Merci, je ne connaissais pas.
        Tout passe à l'exception de:
        
        XEP-0153: vCard-Based Avatar (MUC)
        XEP-0363: HTTP File Upload
        XEP-0368: SRV records for XMPP over TLS
        XEP-0411: Bookmarks Conversion
        
        ce qui, si je ne me trompe pas, ne devrait pas être limitant pour l'upload d'image qui passe un component proxy65
        
        [^] # Re: Un client pour iOS ?
        
        Posté par Goffi (site web personnel, Mastodon) le 09 décembre 2019 à 15:51. Évalué à 4.
        
        Le transfert d'image se fait la plupart du temps avec HTTP File Upload, donc ton problème est très certainement là.
        
        [^] # Re: Un client pour iOS ?
        
        Posté par seveso le 09 décembre 2019 à 20:28. Évalué à 2.
        
        Je confirme que sur Siskin ce qui fonctionnait c'était le partage de fichier par HTTP file upload.
        
        Les autres mécanismes de partage de fichiers dans XMPP n'ont jamais vraiment bien fonctionné à ma connaissance. Je suis (agréablement) surpris d'apprendre que tu as réussi à les utiliser sur plusieurs plateformes mais je ne saurais trop te conseiller de mettre en place la XEP-0363, car "ça juste marche" :)
        
        [^] # Re: Un client pour iOS ?
        
        Posté par Anonyme le 10 décembre 2019 à 11:07. Évalué à 3.
        
        Y a t il un moyen de mettre une espèce de priorité dans les méthodes d'upload ?
        
        Maintenant que http upload est en place, il semble que Conversations n'utilise plus proxy65: lorsque j'envoie une image via Conversations, un lien aesgcm:// s'affiche dans profanity alors qu'avant il n'affichait aucun message.
        
        Sauf erreur de ma part, éviter de passer par le stockage de fichier sur le serveur me parait plus simple, donc je souhaiterai prioriser proxy65 quand il est supporté par les deux clients, émetteur et destinataire.
        
        [^] # Re: Un client pour iOS ?
        
        Posté par Goffi (site web personnel, Mastodon) le 10 décembre 2019 à 16:23. Évalué à 4.
        
        Y a t il un moyen de mettre une espèce de priorité dans les méthodes d'upload ?
        
        C'est le client qui gère ça, et la plupart du temps HTTP upload est utilisé de nos jours. Ceci dit ça marche bien pour les petits fichiers (< 10 Mio) mais c'est généralement bloqué au dessus.
        
        Proxy 65 n'est qu'un outil pour faire le transfert de fichier en le faisant transiter par le serveur si la connexion directe ne passe pas (c'est un peu plus compliqué que ça mais c'est l'idée en gros). La méthode derrière c'est Jingle File Transfer, j'en avais parlé dans parlons XMPP épisode 10. C'est un meilleur système mais c'est moins répandu (et personne – à part dans SàT, que je développe – ne l'utilise avec un composant serveur, du coup ça oblige à avoir les clients connectés en même temps).
        
        Donc bref, c'est HTTP Upload qui est utilisé dans la plupart des cas parce que ça marche à coup sûr pour ceux qui reçoivent les fichiers, et ça ne nécessite pas d'être en ligne en même temps.
        
        Le lien aesgcm:// est une méthode non standard utilisée par Conversation pour envoyer un fichier chiffré avec OMEMO. C'est documenté de façon non officielle mais n'est pas passé en standard officiel, et nous n'avons à l'heure actuelle pas de méthode alternative pour chiffrer un fichier sur le serveur, donc si tu peux trouver un client qui le gère (c'est le cas au moins de Conversation et de Gajim) c'est pas plus mal.
        
        Il y a eu des progrès sur le partage de fichier ces dernières années, mais ça n'est pas encode idéal (et c'est l'un des problèmes sur lesquels je travaille d'ailleurs).
        
        Donc explications mises à part, utilise HTTP Upload et des clients qui gèrent aesgcm:// et ne te prends pas la tête. Pour un gros fichier, un bon client devrait passer automatiquement à Jingle quand c'est nécessaire.
        
        [^] # Re: Un client pour iOS ?
        
        Posté par Anonyme le 10 décembre 2019 à 18:03. Évalué à 2.
        
        C'est un meilleur système mais c'est moins répandu
        
        c'est le betamax du transfert de fichier XMPP :)
        
        personne […] ne l'utilise avec un composant serveur
        
        pourtant prosody explique comment dans sa doc: je fais tourner ce composant sur mon serveur depuis plusieurs années, et ce n'est que parce que j'ai un utilisateur sous iOS que je dois faire ces changements. Je n'ai jamais eu de problème de transfert de fichier auparavant.
        
        utilise HTTP Upload et des clients qui gèrent aesgcm://
        
        donc pour mon utilisateur sous iOS, ce n'est pas encore gagné :)
        
        merci pour les explications
        
        [^] # Re: Un client pour iOS ?
        
        Posté par Goffi (site web personnel, Mastodon) le 10 décembre 2019 à 18:39. Évalué à 4.
        
        pourtant prosody explique comment dans sa doc: je fais tourner ce composant sur mon serveur depuis plusieurs années, et ce n'est que parce que j'ai un utilisateur sous iOS que je dois faire ces changements. Je n'ai jamais eu de problème de transfert de fichier auparavant.
        
        Tu parles de proxy65 ou d'un composant Jingle pour le transfert de fichiers ? Parce que le premier oui ça existe depuis des années, ça date même d'avant Jingle (ça a été repris dans Jingle).
        
        Si tu as un appareil A qui veut envoyer un fichier à un appareil B de ton contact, et que A<->B ne passe pas (à cause d'un NAT ou autre), tu peux utiliser ce proxy au milieu (appelons le P), et tu fais le transfert de fichier avec A->P, et B le récupère en faisant B->P et il n'est pas nécessaire d'accéder à un port ouvert de B. C'est expliqué dans la XEP-0065, d'où le nom. Mais ce composant ne change rien au fait que tu dois être connecté en même temps pour faire le transfert de fichiers via Jingle.
        
        Ce dont je parle avec un composant Jingle, c'est un composant qui garde les fichiers et permet de les retrouver quand on veut, ce qui fait que A peut partager un fichier avec B même s'ils ne sont pas en ligne au même moment (mais du coup ça transite par le serveur). Et ça, il n'y a à ma connaissance que SàT qui le permet à l'heure actuelle. Le gros intérêt par rapport à HTTP Upload, c'est que tu as tous les mécanismes de négociation de Jingle + les extensions comme les vignettes (thumbnails) pour les grosses images, que j'utilise avec les albums photos.
- [^] # Re: Un client pour iOS ?
  
  Posté par InfoLibre le 05 décembre 2019 à 23:10. Évalué à 3.
  
  Voir liste sur https://omemo.top
  - [^] # Re: Un client pour iOS ?
    
    Posté par Anonyme le 05 décembre 2019 à 23:16. Évalué à 3.
    
    je me suis basé dessus pour sélectionner les clients à tester, mais il me manque le transfert et l'affichage d'images

Suivre le flux des commentaires

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