Article publié par Edward Maurer sur le blog de la « XMPP Standards Foundation » (XSF), la fondation qui fait évoluer le protocole de messagerie instantanée de l’IETF.
Parce qu’elles ne comprennent pas les critères à prendre en compte pour le choix d’un type de messagerie instantanée, plusieurs personnes m’ont récemment contacté pour me demander lequel ils devraient utiliser et si elles devraient migrer d’une des solutions ayant pignon sur rue à une autre du même acabit. Je me suis demandé comment répondre à ces questions. Évidemment, j’aurais simplement pu plaider pour XMPP (Extensible Messaging and Presence Protocol), mais j’ai pensé que cela ne serait peut-être pas une réponse utile en soi. Souvent, les gens prennent une décision rapide concernant leur logiciel de communication, et ce n’est généralement pas un choix bien réfléchi, ce qui, plus tard, les amènera inexorablement à passer à une autre messagerie instantanée.
Sommaire
Beaucoup ne feront en fait qu’ajouter une autre messagerie instantanée à leur collection toujours croissante de messageries, ce qui est probablement plus frustrant qu’utile. Cela me ramène à la question initiale : quel enjeu et quel problème veut-on résoudre ici ? Quelles sont leurs motivations ? Peut-on trouver une solution avec un meilleur fondement technologique qui évite l’effet de mode et n’implique pas l’installation de plusieurs applications de messagerie ?
Il y a autant de réponses que de personnes qui posent ces questions : quand certains ont besoin d’une réelle protection de leurs données personnelles, les autres demandent un contrôle complet sur celles-ci, ou s’attendent simplement à pouvoir joindre tous leurs contacts à partir du même appareil. Quelles que soient ces attentes, migrer d’un système de messagerie à un autre implique souvent de laisser certains contacts derrière soi. De nombreux systèmes de messagerie ont en plus fait le choix de réclamer un numéro de téléphone, ce qui n’est pas un bon point de départ pour la protection des données personnelles.
Maîtrise de vos communications
Comme vous vous en doutiez, je vais recommander XMPP. Je pense que la première chose à faire n’est pas de choisir une application de messagerie, mais de choisir la technologie logicielle sous-jacente. Réfléchissons d’abord à la technologie avant de sauter d’une recommandation à l’autre.
XMPP est un protocole ouvert, comme HTTP pour le web. L’apparence de votre site web n’a pas d’importance, tout le monde peut interagir avec. L’idée derrière XMPP, c’est d’appliquer le même principe à la messagerie instantanée.
La XSF, ainsi que beaucoup de personnes impliquées dans cette technologie libre, pense que XMPP est un excellent choix d’un point de vue technique, et pas seulement en ce qui concerne la protection des données personnelles. XMPP existe depuis plus de 20 ans, ce qui a permis d’accumuler beaucoup d’expérience de terrain. Cela inclut de nombreux indicateurs clés pour le choix d’une technologie de communication maitrisée, puisqu’il prend en charge :
- la décentralisation des services de communication (fédération) ;
- la standardisation et l’extensibilité de la technologie ;
- l’interopérabilité ;
- l’innovation par la mise en place d’un développement ouvert ;
- la protection et le contrôle des données personnelles, incluant le chiffrement de bout en bout.
XMPP fournit les éléments d’information permettant de gérer la communication dans un réseau. Mais chaque personne décide du logiciel client qui lui convient, et sur quel serveur ses données doivent être stockées.
Contrairement à la situation actuelle, où d’autres gens vous incitent à utiliser leur application préférée, dans l’univers d’XMPP vous avez le choix entre de nombreux clients de messagerie : choisissez celui qui vous plaît aujourd’hui, indépendamment des effets de mode, quitte à en changer plus tard. À la différence d’autres technologies de communication, peu importe l’application que vous utilisez ou le serveur qui héberge vos données, vous resterez toujours sur le même réseau que vos contacts. Je pense que c’est une vraie solution.
Ce n’est pas une question d’applications, mais de technologie
Décidez-vous sur la technologie que vous prévoyez d’utiliser, et sélectionnez ensuite quel logiciel correspond à votre usage ou à votre environnement. XMPP et sa communauté ont accumulé une grande variété d’expérimentations qui ont été mises en pratique dans un grand nombre de logiciels. Nous pensons que c’est une bonne solution pour la plupart des individus et des organisations, ainsi que pour la cohérence d’Internet comme un tout, sans compter qu’elle reste ouverte à de futures innovations sans en limiter l’origine.
En plus d’un large choix de logiciels de messagerie, XMPP propose également plusieurs serveurs et outils de développement pour construire vos propres infrastructures.
Il n’y a pas qu’une seule manière de concevoir des applications de communication. Faites le choix d’une technologie standardisée qui restera valable à long terme : pour cette raison, et pour beaucoup d’autres, nous recommandons l’utilisation d’XMPP !
Si vous avez l’intention de choisir une solution pour la prochaine décennie, laissez-moi vous orienter vers plus de documentations :
- Pour commencer, mettez le pied à l’étrier avec le site de XSF [en anglais] ;
- Un article du blog de la XSF: C’est une question de choix et de contrôle [en anglais] par Laura, écrit et 2015 ;
- Modern XMPP, un site web en anglais utile aux développeurs comme aux nouveaux arrivants pour se lancer dans XMPP ;
- Commentaires de la communauté XMPP :
- Une chance pour XMPP [en allemand], jabber.de ;
- Comment s’assurer que votre solution de messagerie instantanée offre à vos utilisateurs une protection de leurs données personnelles et la sécurité [en anglais], Erlang Solutions ;
- message sur Mastodon de l’Association April ;
- message sur Twitter du réseau Movim.
- [Ajout des Traducteurs] :
- XMPP en 2021 ;
- Salon de la communauté jabberfr.org ;
- Salon linuxfr.
Aller plus loin
- Instant Messaging: It's not about the app (43 clics)
# Configuration serveur et écosystème de clients
Posté par aurel . Évalué à 7. Dernière modification le 30 janvier 2021 à 10:41.
Ce serait formidablement utile d'avoir un lien vers des clients qui couvrent les principales plateformes utilisées, et garantissant entre eux texte, audio, vidéo, et le plus de fonctionnalités desquelles Mme Michu ou la boulangère ont pris l'habitude (genre: en train de taper sur le clavier, accusé de réception/lecture, etc.).
Ah oui, et puis avec le tutoriel de configuration du serveur qui va bien, pour ceux qui voudraient s'auto-héberger.
Ah oui, et pi un café aussi 😶* -> []
*: je peux me le faire moi-même, comme le reste de mon message, mais je me dis que ça doit bien exister quelque part ? 🤔
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . Évalué à 4.
Il ne suffit pas qu'un client implémente les fonctionnalités souhaitées (texte, fichiers, appel A/V, …) il faut aussi que les serveurs concernés (le tien et ceux de tes contacts) les implémentent aussi.
Par ailleurs, il est vrai que XMMP permet de changer de client et/ou de serveur. Mais dans le cas d'un changement de serveur, comment ça se passe pour les données (conversations, fichiers), il y a une XEP qui décrit comment un serveur doit permettre de les exporter puis les réimporter ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Oui, c'est ici: https://xmpp.org/extensions/xep-0227.html
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Sauf que le protocole ne précise pas comment doit être stocké ce mot de passe, c'est un choix d'implémentation.
Par exemple, dans ejabberd, la partie authentification contient tout une série de processus et s'il est possible d'avoir le mot de passe en clair, il existe tout une série de possibilités permettant de s'en passer.
Personnellement, depuis les annonces de WhatsApp, j'ai quelques copains qui ont commencé à s'inquiéter et à qui j'ai proposé de monter un serveur XMPP.
Résultat des courses, je suis l'heureux administrateur et propriétaire d'une VM de petite taille (2Go de RAM et 20Go de disque) chez Scaleway et qui fait très bien le taff pour la trentaine d'utilisateurs enregistrés.
A cela, j'ai ajouté un serveur Apache hébergeant Movim.
Alors, oui, la configuration n'est pas forcément très simple et il est utile de comprendre ce que l'on fait et active.
Par contre, j'ai aujourd'hui des utilisateurs qui utilisent Xabber ou Conversations sous Android et Siskin sous iOS. Après certains utilisent aussi l'instance Movim pour causer.
Au final, cela fonctionne même si j'ai dû guider les personnes dans leur choix de client.
Globalement, pour l'instant, cela se passe bien
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 7.
Je n'ai jamais dit que c'était ce qu'il fallait faire mais simplement que ce n'est pas au protocole de définir si le champ password contient le mot de passe ou un hash, pas besoin de pousser des cris d'orfraie.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Anonyme . Évalué à 3.
1/ comme confirmé dans la section 9, c'est optionnel
2/ la section 6 précise bien qu'il faut apporter un soin particulier à ces fichiers exportés en terme de sécurité
3/ c'est à l'implémentation du serveur de décider comment stocker les mots de passe: tout comme Prosody laisse le choix aux administrateurs de stocker le mot de passe sous forme de hash, en clair, dans un fichier texte, en base de données, etc., le protocole laisse à l'implémentation du serveur la liberté de s'adapter à son cas d'usage spécifique
Donc un serveur qui veut respecter la confidentialité de ses utilisateurs, et sait pertinemment que la sécurité absolue n'existe pas, stockera le mot de passe sous forme de hash et ne l’inclura pas dans le fichier d'export.
À l'inverse, un serveur qui cible les entreprises trop number one en sécurité, leader sur leur marché, persuadées d'être à l'abri derrière leur firewall cisco dernier cri à 1M d'€ et qui veut laisser la possibilité à ses administrateurs de fliquer ses utilisateurs stockera tout ça en clair et exportera le mot de passe de la même façon
Le protocole n'a pas à préjuger du type d'utilisation qu'on en fera et doit rester flexible: j'imagine que la XSF, qui décide de ce que contiennent les XEP, inclut des organisations dont la sécurité n'est pas l'objectif premier… Il faut donc forcément faire des compromis.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
L'avantage de XMPP étant que 1) c'est documenté et 2) n'importe qui peut proposer de modifier cette spec.
Je ne pense pas que ça soit le cas chez aucun des concurrents?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 8.
A première vue, tu ne dois pas aimer l'IETF non plus… Sauf si t'aimes les pigeons :)
[^] # Re: Configuration serveur et écosystème de clients
Posté par Frédéric Blanc . Évalué à 3.
Et il y a intérêt à les aimer, parce que l'IETF elle les aime…
[^] # Re: Configuration serveur et écosystème de clients
Posté par Frédéric Blanc . Évalué à 5.
Vous ne ne savez peut-être pas, mais il y a une longue tradition au niveau des RFC de l'IETF de proposer pour la date hautement symbolique du 1er avril, des RFC «poisson d'avril». Depuis 1989, quasiment chaque année a vu au moins une telle RFC publiée (1998 ayant même été la plus gâtée avec 5 RFC : 2321 à 2325).
La XSF ne fait qu'adhérer à cette tradition, et les deux XEP que vous mentionnez font partie de ce folklore : pour leur version 1.0, la XEP-0183 a été publiée le 2006-04-01, la XEP-0076 le 2003-04-01 et son introduction débute même par une référence à la RFC 3514 qui est «published just today (2003-04-01)». La XSF a juste mis un peu plus de formalisme, puisqu'à dédié une catégorie pour ce type de XEP là où les RFC «April Fools» sont juste des RFC catégorisées «Experimental» ou «Informational».
[^] # Re: Configuration serveur et écosystème de clients
Posté par Anonyme . Évalué à 2. Dernière modification le 01 février 2021 à 23:41.
commentaire supprimé: réaction épidermique qui n'avait pas sa place ici
[^] # Re: Configuration serveur et écosystème de clients
Posté par mathieui (site web personnel) . Évalué à 5.
C’est une tradition, qui ne me fait pas beaucoup rire personnellement, mais c’est le prétexte le plus bidon pour dire qu’un protocole est pourri. On peut jeter tout ce que fait l’IETF, quitte à dire ça, ça te paraît être une bonne idée ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par paulez (site web personnel) . Évalué à 4.
Je me rappelle avoir eu cette discussion il y a 15 ans, et à l'époque il n'y avait pas de bonne réponse, il fallait stocker le mot de passe pour faire tourner un serveur XMPP.
Le wiki de Prosody a une bonne explication. Pour résumer, XMPP ne supporte qu'une méthode d'authentification ne nécessitant pas de stocker le mot de passe côté serveur seulement depuis 2010. Si un serveur veut être compatible avec les clients n'implémentant pas cette méthode, il doit stocker le mot de passe.
Comme quoi utiliser des protocoles qui ont 20 ans ou plus a de sérieux désavantages (je pense à XMPP, mais aussi SMTP et compagnie).
[^] # Re: Configuration serveur et écosystème de clients
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
C'est quoi le désavantage puisque ça fait 10 ans que le problème est réglé pour XMPP?
On devrait tout jeter alors que justement on a un protocole prévu pour évoluer et ne pas finir par être complètement dépassé?
[^] # Re: Configuration serveur et écosystème de clients
Posté par paulez (site web personnel) . Évalué à 1.
Désavantage parce qu'il faut gérer tout un tas de legacy. Il y a une armée de clients XMPP non maintenus, et qui potentiellement ne supportent pas la nouvelle méthode d'authentification. Il faut donc faire le choix de les supporter, ou d'expliquer aux utilisateurs pourquoi ça ne marche pas quand ils choisissent d'utiliser tel ou tel client non supporté.
Avec un protocole plus jeune on évite ce genre de problème, la base commune est plus récente.
Bien sûr il y aussi des avantages, comme une plus grosse maturité par exemple. Même si justement je trouve ça discutable, vu que XMPP est basé sur pas mal de choix de son époque (XML par exemple) qu'il est difficile de changer. Un protocole plus récent peut avoir plus de maturité dans sa conception en se basant sur les erreurs de l'époque de XMPP.
[^] # Re: Configuration serveur et écosystème de clients
Posté par seveso . Évalué à 2.
Il y a aussi une armée de clients Web non maintenus, et qui potentiellement ne supportent pas la nouvelle version de Javascript. Est-ce une raison suffisante pour remplacer Javascript par autre chose de nouveau (Dart par exemple) ?
Il y a tellement de questions à se poser pour peser le pour et le contre que certains préfèrent foncer et voir ce que ça donne. Si parfois cette stratégie fonctionne (par exemple, systemd, mais c'est discutable, j'en conviens ;) ), la plupart du temps ça échoue. Et pire, la solution de remplacement ne remplace pas, elle s'ajoute.
À titre personnel, j'estime que l'énergie et les ressources de Matrix auraient été mieux employées à améliorer XMPP plutôt qu'à contribuer à la cacophonie des messageries instantanées.
Bref, repartir de zéro n'est pas toujours souhaitable. C'est surtout une solution attrayante pour le développeur fraîchement arrivé, qui a la flemme de comprendre comment fonctionne l'existant, qui veut pouvoir coder rapidement sa solution alternative, solution qui fait la même chose mais en mieux (selon lui), et qui se moque de savoir si la transition sera facile à vivre ou non pour les utilisateurs et l'écosystème existant.
Je n'ai jamais compris pourquoi l'usage de XML comme format d'échange de données entre des machines était si souvent invoqué comme argument en défaveur de XMPP…
[^] # Re: Configuration serveur et écosystème de clients
Posté par paulez (site web personnel) . Évalué à 0.
Javascript est partout, HTTP est partout, XMPP est nul part ou presque. Je le sais bien ça fait 15 que je gère un serveur XMPP, j'ai essayé de convaincre mes amis et famille de l'utiliser pendant bien longtemps.
Le coût de repartir de zéro est énorme quand tout le monde utilise un protocole ou une techno. Quand elle n'est pas utilisée, il est quasi nul, vu qu'il n'y a personne à migrer.
Je comprends tout à fait le point de vue de Matrix, justement c'est bien qu'il y ait une autre tentative de techno de messagerie instantanée ouverte car au final il n'y avait que XMPP avant, et c'est un échec.
[^] # Re: Configuration serveur et écosystème de clients
Posté par seveso . Évalué à 3.
OK pour dire que contrairement à HTTP, XMPP n'est pas partout. Donc repartir de zéro serait moins coûteux. N'empêche que la démarche de Matrix a fait plus de tort qu'autre chose.
Dans l'écosystème des solutions décentralisées, il y avait quoi avant l'arrivée de Matrix ? XMPP et IRC essentiellement. IRC n'évoluait pas et ne pouvait pas prétendre concurrencer les messageries grand public centralisées. XMPP de son côté lutte tant bien que mal pour essayer d'y parvenir et attirer du monde. Ce qui lui manque surtout, ce sont des UI bien foutues, car fonctionnellement le protocole a déjà tout ce qu'il faut pour répondre aux besoins modernes. Et si ce n'était pas le cas, c'est un protocole conçu pour être évolutif.
Arrive alors Matrix avec ces fameuses UI bien foutues qui manquent à XMPP. Au lieu de participer à faire migrer en masse des utilisateurs des solutions GAFAM vers des solutions décentralisées, ça a surtout fragmenté la communauté que XMPP avait eu beaucoup de peine à bâtir.
Pour moi, l'arrivée de Matrix a surtout permis de renforcer les GAFAM.
Si au moins il existait une passerelle Matrix->XMPP qui fonctionne, ou même XMPP->Matrix, je ne serais pas aussi amer…
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . Évalué à 3.
Je partage ton point de vue sur Matrix vs XMPP. Cependant, force est de reconnaître que le processus "idéal" de standardisation de XMPP induit une grande lenteur. L'alternative qui consiste à ré-inventer un protocole qui contient tout ce dont on a besoin (et une implémentation de référence pour un serveur et un client) puis à le proposer "out of the box" comme un nouveau standard ouvert va beaucoup plus vite. D'ailleurs, preuve pour moi que ce ne sont pas les bases techniques de XMPP qui seraient vieillissantes, c'est que certaines messageries propriétaires d'aujourd'hui sont parties d'une base XMPP et ça ne les a pas empêché d'avoir des fonctionnalités complètes et de conquérir une grosse part d'utilisateurs.
[^] # Re: Configuration serveur et écosystème de clients
Posté par paulez (site web personnel) . Évalué à 0.
Je ne pense pas. On le voit bien avec le succès de Signal en ce moment que des solutions libres peuvent remporter un peu d'adhésion chez le public.
Par contre aucune solution décentralisée n'a eu du succès chez le public. Je me suis rendu à l'évidence: les solutions décentralisée n'intéressent que très peu de monde. En ce focalisant sur la décentralisation, on a laissé libre cours aux solutions proprio et fermées des GAFAM. Signal montre qu'une solution libre mais centralisée peut avoir du succès, mais est arrivé trop tard.
Pour moi c'est l'obsession de la décentralisation qui a laissé libre cours aux GAFAM.
[^] # Re: Configuration serveur et écosystème de clients
Posté par claudex . Évalué à 5.
La centralisation pose, entre autres, le problème de la confiance. Ce n'est pas parce que c'est libre que je fais confiance aux administrateurs. Ensuite, il y a le problème de la résilience. Je pense qu'il est normal de vouloir une solution décentralisée avec une solution libre.
Cependant, il y a des problèmes inhérents aux solutions décentralisées, notamment le spam (et tout ce qui tourne autour, comme le harcèlement) et la différence de fonctionnalités entre deux instances (pour des questions de configuration, d'implémentation ou de génération). Ces problèmes n'ont jamais été résolus, parce qu'à partir du moment où on permet à n'importe qui de créer un serveur, on se retrouve avec des serveurs créés par n'importe qui.
Au final, il n'y a pas de différence entre un Signal libre et un Signal non-libre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Configuration serveur et écosystème de clients
Posté par mahikeulbody . Évalué à 2.
Je ne vois pas le rapport avec la décentralisation : tu as toujours ton compte sur un serveur, géré par un administrateur auquel tu dois faire confiance.
Tu ne confonds pas avec solution distribuée (type Jami par exemple) ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par paulez (site web personnel) . Évalué à 2.
Il y a plein de raisons de préférer des solutions décentralisées, comme tu l'as exposé.
Mais comme tu l'as aussi dit, ça vient avec pas mal d'inconvénients qu'on n'a jamais réussi à résoudre.
Tu parles de confiance, et justement, l'expérience montre que les utilisateurs vont utiliser des solutions dans lesquelles ils ont confiance.
Les gens utilisent Whatsapp, parce qu'ils ont confiance que ça marche, qu'il n'y a pas de problème majeur de sécurité, parce que leurs proches l'utilisent aussi, que ça a des étoiles sur le Google store et qu'en sais-je. Quand la confiance est perdue comme récemment, ils se tournent vers d'autres acteurs comme Signal.
Avec XMPP et Matrix, il y a plein de petits acteurs vers qui se tourner. À qui faire confiance ? Au final aucun acteur n'est vraiment connu (à part peut-être Framasoft qui a un succès certain) et les utilisateurs préfèrent se tourner vers une entité en qui ils ont confiance.
Je propose un service XMPP et les seuls qui me font assez confiance pour l'utiliser sont ma famille proche. Comme quoi la confiance est une énorme difficulté pour toute solution décentralisée.
Quant à dire qu'un Signal non libre est la même chose qu'un Signal libre, au final le logiciel libre n'a donc aucun intérêt ?
[^] # Re: Configuration serveur et écosystème de clients
Posté par claudex . Évalué à 5.
Si je ne peux pas le faire tourner, oui (c'est d'ailleurs un des buts de la GPL3, pour beaucoup de monde, la Tivoisation n'est pas vraiment libre).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Configuration serveur et écosystème de clients
Posté par paulez (site web personnel) . Évalué à -2.
Qu'est-ce qui t'empêche de le faire tourner ? Tu peux installer ton propre serveur Signal, il faudra ensuite modifier le client pour qu'il s'y connecte.
J'ai aussi écrit un logiciel assez simpliste de messagerie en AGPL, il ne supporte pas la fédération parce que je n'en ai pas besoin, que c'est compliqué, etc. mais il reste libre pour autant.
Si un jour Signal disparaît ou adopte un comportement qui n'inspire plus confiance, quelqu'un peut récupérer le code et faire un service équivalent. Ça n'est pas du tout le cas de Whatsapp et consorts.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Et tu retomberas dans le même travers que ton serveur XMPP, à savoir, le manque de confiance dans l'hébergeur et au final, tu n'atteindras jamais la masse critique qui fera que tout le monde veut causer avec toi sur ton serveur Signal.
Comme dit un pote : "Tu peux avoir le plus beau produit du monde, si tu n'as pas le marketing et les commerciaux qui vont avec, ça ne sert à rien".
Et ça, ça fonctionne même dans le libre, il suffit que Linus mette son nom sur git et hop, ça devient le truc le plus génial du monde… Perso, j'aimais beaucoup Monotone…
[^] # Re: Configuration serveur et écosystème de clients
Posté par Tibo cocoecolo (site web personnel) . Évalué à 3.
Côté client, Signal est libre mais l’entreprise ne veut pas de version modifiée sur leur serveur et ne veut pas non plus de distribution autre que la leur (la licence l’autorise, donc cela reste possible, mais du coup Signal n’est pas sur F-Droid).
Côté serveur, il faut avoir confiance… Et on peut fortement douter que la version actuelle est celle disponible officiellement sur Github. Le dernier commit date du 22 avril.
[^] # Re: Configuration serveur et écosystème de clients
Posté par tisaac (Mastodon) . Évalué à 4.
Je ne vois pas trop en quoi le spam est inhérent aux solutions décentralisées.
Si j'en crois mon compte Facebook (qui est bien un truc centralisé, non ?), on peut aussi avoir pas mal de spam avec un système centralisé.
Surtout, ne pas tout prendre au sérieux !
[^] # Re: Configuration serveur et écosystème de clients
Posté par claudex . Évalué à 3.
Oui, on peut avoir du spam avec un système centralisé. Mais on peut plus facilement le limité ou l'éliminé. Avec un système décentralisé, ce n'est pas possible, tu ne peux pas limiter la création de nouveaux comptes sur les autres serveurs. Je ne connais pas ton compte Facebook, mais je doute que tu ais des dizaines de spam par jour comme on peut trouver dans les mails.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Configuration serveur et écosystème de clients
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Tu parles d'une extension qui a été écrite en 2007, et qui n'a pas été touchée depuis 2010, à l'époque les mots de passe étaient stockés beaucoup plus souvent en clair, maintenant il y a des méthodes plus à jour, et je ne pense qu'il y ait beaucoup de serveurs qui gardent les mots de passe en clair. Et le principe d'un protocole ouvert comme XMPP, c'est qu'on peut justement pointer ce genre de problème et y répondre par une mise à jour de la spécification (ou une nouvelle qui va remplacer l'ancienne).
De la même façon un code libre n'est pas dépourvu de bugs ou failles de sécurités parce qu'il est libre, mais il y a plus de chance que quelqu'un voit le problème et le corrige.
Bref, bien sûr que le protocole n'est pas parfait, il ne doit pas y en avoir beaucoup qui le sont (on trouve des failles dans des protocoles bien plus utilisés que XMPP), mais on peut le corriger et le faire évoluer, et il y a de bon mécanismes pour ça.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3. Dernière modification le 02 février 2021 à 14:06.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
non Prosody utilise une version hashée, en tout cas c'est ce qui est mis dans la configuration de base (si on omet l'option je ne sais pas, il faudrait vérifier les sources plus en détails et je n'ai pas le temps, mais cette page laisse entendre que c'est bien la version hashée qui est utilisée par défaut) : https://hg.prosody.im/0.11/file/tip/prosody.cfg.lua.dist#l127 . La page citée plus haut ne doit plus être à jour depuis longtemps, il faudrait sans doute leur remonter d'ailleurs.
Pour ejabberd je ne sais pas, à vérifier. Tu cites un ticket de plus de 2 ans qui pointe sur un fichier qui n'existe plus, c'est le code actuel qu'il faut regarder.
Enfin bref, ça sert à rien de tourner en rond, j'ai déjà répondu plus haut : oui il faut hasher les mots de passe, non le protocole n'incite pas à garder les mots de passe en clair, et oui la spec citée plus haut devrait être corrigée pour mettre ça plus en évidence.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par benoar . Évalué à 3.
Bonjour, je me permets bien après la bataille quelques commentaires historiques sur la tendance actuelle à vouloir absolument stocker les mots de passe hashés, vu ton obstination à le faire je me disais qu'une petite perspective historique pourrait t'aider à comprendre.
Très historiquement, les protocoles d'authentification étaient effectivement « en clair » et on envoyait les mot de passe directement au serveur, sans préoccupation de divulgation des secrets. Ce problème a été résolu au cours des années 90 avec différentes implémentations de protocoles défi-réponse (challenge-response) comme DIGEST-MD5 (cité plus haut) pour le web, CHAP pour PPP, etc. Ils ont été améliorés par l'ajout de nonce pour éviter les rejeux. Il faut se remémorer à l'époque qu'utiliser des canaux chiffrés n'était pas encore très répandu, et la cryptographie très réglementée et limitée (par les US) : ces protocoles protégeaient l'authentification lorsqu'on utilisait un canal non-chiffré, mais pas le canal de données associé. Le développement de la cryptographie a amené dans le même genre de thème l'authentification défi-réponse par clé dans SSH par exemple, ou l'authentification client par X.509 par certificat. Ces méthodes permettent, contrairement aux précédentes, de ne même pas stocker de secret côté serveur ! Car oui, bien que protégeant le canal d'authentification, les méthodes de défi-réponse citées nécessitent de stocker le mot de passe de manière récupérable sur le serveur (ce qui n'est pas forcément directement en clair, mais pas très loin il est vrai).
Puis est venu le temps de la généralisation du chiffrement des canaux avec TLS, qui a bien sûr commencé tôt sur le web, et s'est généralisé ailleurs après (sachant qu'il existait d'autres techniques aux buts similaires avant, mais qui ont eu moins de succès, ou alors dans des niches, comme IPsec, et SSH — pour son canal chiffré par DH, pas pour l'auth, ici —). Pour différentes raisons, les techniques « anciennes » d'authentification avec communication du mot de passe ou d'autre secret partagé sans souci de la confidentialité de l'échange — puisqu'ici obtenu à travers TLS — sont redevenues populaires, car souvent plus simples à implémenter une fois que le boulot de confidentialité de la couche TLS a été effectué. Certains voient ça comme un progrès, personnellement je vois plutôt ça comme une régression : maintenant, le serveur doit être mis au courant à travers le réseau du secret du client lors de la négociation de l'authentification. Le client doit avoir un moyen de garder ce secret sur le long terme et le présenter au serveur à sa demande ; il ne peut ainsi plus déléguer par exemple le défi d'authentification à un token comme une clé USB de cryptographie, ou utiliser de la cryptographie asymétrique qui lui permettrait de garder les secrets dans un endroits sécurisé et pérenne, puisqu'il n'a pas besoin de le « ressortir » et l'envoyer sur le réseau à chaque authentification. Mais aujourd'hui la cryptographie asymétrique « à l'ancienne » a perdu, les navigateurs veulent même supprimer l'authentification client par certificat X.509.
Bref, on a mis sur le dos du client le poids de devoir garder un secret qu'il doit communiquer « en clair » (mais sur un canal chiffré), pour simplifier la vie des serveurs qui se font facilement poutrer… pour quelle raison ? Est-ce la responsabilité du client si le serveur n'est pas capable de garder des secrets comme il faut ? On avait su inventer des mécanismes évitant tout stockage « chaud » de secret et de communication de secret en ligne grâce à la cryptographie asymétrique, mais aujourd'hui des considérations de practicité utilisateurs (c'est soit-disant trop dur à gérer) et de soit-disant préoccupation relatives au traçage d'identités (LOL c'est Google qui dirige les normes sur les nouveaux token qui empêchent la reconnaissance cross-site… sachant que Google le fait lui-même autrement) ont mis fin à ces mécanismes utilisés tels qu'à l'époque.
Alors aujourd'hui, on a su trouver des solutions intermédiaires différentes, qui ont certains avantages et d'autres désavantage : SCRAM-* par exemple, qui permet de faire du challenge-response d'un secret partagé sans avoir à stocker ce secret tel-quel sur le serveur. Ou les différentes formes d'authentification « fortes » par clé asymétriques comme WebAuthn, qui sont très spécifique au Web contrairement à X.509, et imposent des modèles d'identité et de confidentialité bien différents de ce qu'on avait avant (grand débat de savoir s'ils sont meilleurs ou moins bons…). Pourquoi pas, mais pour ça on a « mis à la poubelle » tout un tas de technologies qui étaient éprouvées et fiables, bien qu'ayant des désavantages (comme le stockage de secret « en clair » côté serveur) cités comme complètement rédhibitoire par certains comme toi, alors que les méthodes modernes ont d'autres désavantages qu'on cite moins. Tout ça est une histoire de compromis, et crier sur les gens quand ils stockent des secrets côté serveur comme si c'était universellement mauvais, alors que ça met un fardeau de gestion de secret supérieur sur le client, ça n'est pas très honnête ni constructif.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Configuration serveur et écosystème de clients
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Il y a https://snikket.org qui fait précisément ça (en réutilisant des clients/serveurs existant mais en les regroupant sous une seule "identité").
De façon plus générale il y a les "XMPP compliance suites" qui définissent le minimum attendu pour un client XMPP correct selon différents profils (mais principalement la messagerie instantanée). L'audio/vidéo est ajouté dans la version 2021. Et il y a un projet autour de "DOAP" qui va permettre de facilement voir quels clients/serveurs implémentent quelles parties de XMPP.
[^] # Re: Configuration serveur et écosystème de clients
Posté par Ppjet6 . Évalué à 2.
C'est encore plutôt grossier mais dans cette optique il y a https://joinjabber.org qui est en train de se former !
On espère proposer un endroit où les utilisateurices puissent créer un compte sur un serveur et leur proposer un client avec un ensemble de fonctionalités « modernes »—quoi que ça puisse vouloir dire, à définir.
Cet effort de définition on espère le faire avec la communauté fédérée Jabber, utilisateurices, opérateurices, etc. On propose déjà des recette pour mettre en place une partie de l'infra, et on espère que d'autres personnes participent pour proposer plus, mieux.
Je t'invite à venir faire un tour sur le salon (xmpp:joinxmpp@chat.cluxia.eu?join, adresse qui va bientôt changer d'ailleurs, pour utiliser le même nom), ou sur le forum (https://forum.joinjabber.org).
# XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 1.
J'hésite toujours entre les deux.
Tous les avantages que tu cites pour XMPP se retrouvent dans le protocole Matrix.
Avec peut être en plus des passerelles vers pas mal d'autres solutions (dont signal, Slack,IRC,Telegram,etc)
Bon en fait j'attends la version swarm de jami ;-)
[^] # Re: XMPP ou Matrix ?
Posté par aurel . Évalué à 3.
Connexe avec Jami, qui si j'ai bien compris est distribué: a été annoncée pour samedi prochain une démo de Matrix en peer-to-peer au FOSDEM2021.
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . Évalué à 4.
Le serveur de référence de Matrix est réputé super consommateur de ressources, ça va le faire sur un smartphone ?
De plus, est-ce que cette solution permettra d'avoir plusieurs devices reliés au même compte (comme le permet Jami) ?
[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 1.
Oui ça le fait sur smartphone, testé avec le serveur matrix.org ou converser.eu.
Oui on peut avoir plusieurs terminaux avec le même compte , perso c'est sur smartphone Android, client lourd Linux et aussi client web (app.element.io)
Par contre pour l'échange de fichiers (photos,vidéos ou autres ) c'est assez long, en tout cas moins rapide que whatsapp d'après les gens de mon entourage qui l'utilisent)
Je n'ai pas testé XMPP récemment alors je ne sais pas si c'est plus performant sur ce point et ça doit dépendre bien sûr du serveur sur lequel on est (chapril.org par exemple)
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . Évalué à 2.
Matrix peer to peer est présenté comme un Matrix "normal" du point de vue du client, c'est juste que le serveur est local sur le device. J'imagine donc que ton compte est sur ce serveur local. Si tu as plusieurs devices, avec chacun leur serveur local, comment ça peut être le même compte ?
[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 1.
Je suppose qu'il y a un "appairage" comme pour jami, mais je n'ai pas , encore lu la doc Matrix sur ce sujet.
Pour Jami ça marche comme ça : https://jami.net/why-is-jami-truly-distributed/
[^] # Re: XMPP ou Matrix ?
Posté par tao popus . Évalué à 7.
Le client linux de matrix c'est 300Mo :/, c'est ce qui m'a fait rejeter matrix. J'ai testé via le site web, c'est tout sauf convivial on voit les demandes des connaissances au moment de la connexion, et on a seulement le choix accepter ou refuser et le popup revient sans arrêt, si on fait refuser on perd le contact il faut le retrouver, c'est vraiment tout sauf ergonomique.
Je crois qu'on aurais plus intérêt à tous bosser sur le développement de XMPP, qui à un développement ouvert, communautaire, solide et qui date. Il y a aussi des tas de passerelles sur XMPP, dont le fédiverse. La mulitude de clients XMPP sont incomparablement plus légers que ce gros paté en jajascript de 300 Mo
[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 1. Dernière modification le 30 janvier 2021 à 18:34.
Quel client ? sur Linux j'utilise le client web qui fait 0 mo (app.element.io) et je n'ai pas le comportement que tu indiques ?
[^] # Re: XMPP ou Matrix ?
Posté par aurel . Évalué à 3.
gomuks, Arch/AUR: 16.23 MiB.
[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 1.
Client web element : 8mib de scripts , 25mib d'objets = 33 mib = 34 Mo
On est loin des 300 Mo non ?
[^] # Re: XMPP ou Matrix ?
Posté par Tibo cocoecolo (site web personnel) . Évalué à 7.
Simple test, j’ouvre https://app.element.io. Sans même me connecter,
about:performancedans Firefox m’indique plus de 60 Mio direct, largement en tête de la vingtaine d’onglets actuellement chargés, dont des sites déjà bien lourds… Sérieusement ?[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 2.
Oui je confirme , une fois connecté avec des salons et des contacts ouverts, Firefox m'indique 61 Mo.A l'utilisation ça ne monte pas.
On peut considérer que c'est beaucoup (mon Nextcloud prend 40 mo) mais on est encore loin des 300 Mo non ?
[^] # Re: XMPP ou Matrix ?
Posté par Tibo cocoecolo (site web personnel) . Évalué à 4.
Oui, si on a le navigateur web déjà ouvert, mais je réagissais surtout à :
Et là, en testant de nouveau, en partant d’un Firefox sans rien d’ouvert, puis en ouvrant https://app.element.io, ma consommation en RAM augmentent d’environ 300 Mio, en plus de ce qu’occupe déjà Firefox.
Après, je ne sais pas ce qu’a essayé tao popus, peut-être la version bureau de Element. De ce que je vois, c’est du Electron, ceci explique peut-être cela…
Un des reproches que je vois souvent pour Matrix, c’est aussi la lourdeur du serveur, spécialement hors de portée du simple auto-hébergement sur une petite machine si on rejoint des gros salons.
[^] # Re: XMPP ou Matrix ?
Posté par tuxicoman (site web personnel) . Évalué à 2.
T'as un lien vers cette passerelle? ca m'intéresse.
[^] # Re: XMPP ou Matrix ?
Posté par mahikeulbody . Évalué à 7.
Je me suis posé la même question mais j'ai tendance à rejeter "idéologiquement" Matrix pour avoir voulu ré-inventer ce qui existait déjà au lieu de contribuer à l'améliorer (y a t-il des raisons techniques empêchant d'implémenter des passerelles dans le cadre de XMPP ?).
Moi aussi !
Je ne sais pas si Jami est mieux ou moins bien que XMPP, ni même si ça recouvre tout le domaine fonctionnel de XMPP (notamment des salons publics avec beaucoup de personnes) ou celui de Matrix (passerelles) mais au moins ils ne réinventent pas un énième standard qui fait la même chose que le précédent.
[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 3.
Ce que j'aime chez Jami c'est le coté innovant.
Protocole distribué (pas de serveur) , annuaire sur Blockchain, protocole Git pour la messagerie de groupe, Opendht, client SIP , etc.
A lire :
https://jami.net/why-is-jami-truly-distributed/
https://jami.net/the-jami-quirks/
https://jami.net/swarm-introducing-a-new-generation-of-group-conversations/
J'avoue que c'est un réflexe d'informaticien et que pour l'instant Jami n'a pas toutes les fonctionnalités attendues par la plupart des gens mais ça avance bien.
Dernièrement à la demande d'un groupe April , l'équipe Jami a émis l'idée de faire une passerelle vers XMPP.
[^] # Re: XMPP ou Matrix ?
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
Il y a des passerelles avec XMPP aussi, et je doute qu'il existe beaucoup de protocoles qui ont un « bridge » Matrix et pas de passerelles XMPP. En tout cas pour Signal, Slack, IRC et Telegram ça existe.
[^] # Re: XMPP ou Matrix ?
Posté par Bruno (Mastodon) . Évalué à 1.
Ok, mon expérience qui date de deux ou trois ans fut laborieuse sur les passerelles existantes à l'époque, fonctionnement erratique.
D'après ce post c'est toujours le cas pour Signal https://linuxfr.org/users/therealnicoco/journaux/ma-passerelle-xmpp-signal
Ça a dû évoluer mais du coup ça met XMPP et Matrix à égalité.
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Mauvaise question...
Posté par Bruno (Mastodon) . Évalué à 1.
Tout à fait d'accord, c'est pour cela que quand on me demande par quoi remplacer whatsapp je dis : télécharge "element" (par exemple) et prend tous les paramètres par défaut (matrix.org) comme tu as fait pour whatsapp.
Sauf si la personne qui me le demande est un peu avancée au niveau connaissance.
[^] # Re: Mauvaise question...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7.
Avec Signal aussi tu choisis un logiciel (Signal), et un serveur (le serveur officiel de Signal), la seule différence c'est que tu l'imposes aux autres.
XMPP est un protocole qui te permet de choisir un logiciel est un serveur, ça ne veut pas dire que chaque utilisateur doit le faire, il y a des projets qui le font pour toi. C'est le cas de Snikket par exemple où le serveur est déjà choisi par la personne qui invite, et les clients sont déjà choisis aussi. La différence avec Signal, c'est que je peux communiquer avec eux avec le serveur et le client de mon choix.
[^] # Re: Mauvaise question...
Posté par Big Pete . Évalué à 8. Dernière modification le 30 janvier 2021 à 14:34.
C'est amusant que l'on fasse toujours la comparaison avec l'automobile. Si on disait : Combien de personnes choisissent un plat en fonction des ingrédients qui sont dans l'assiette ?
C'est déjà beaucoup moins net que les consommateurs ne s'intéressent absolument pas à la façon dont est fabriqué ce qu'ils mangent et que ce serait "normal", vu qu'on est pas sensé être chef cuistot pour pour pouvoir manger tout les jours.
Donc, le problème, c'est peut-être que ce n'est pas "normal" que le consommateur de bagnole en ait rien a faire de savoir comment fonctionne son automobile. Peut-être que ça le deviendra le jour où il va réaliser qu'il respire ses gaz d'échappement, et que c'est un peu moins ragoûtant que du gratin dauphinois.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Mauvaise question...
Posté par steph1978 . Évalué à 3.
1% au doigt mouillé ?
Non j'en sais rien mais l'industrie agro-alimentaire et de la restauration rapide se porte très bien et en gros tu ne sais pas ce que tu manges.
[^] # Re: Mauvaise question...
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Même les gens comme moi (pour qui une voiture est juste un véhicule et non une extension du pénis) se posent au moins la question du moteur essence, diesel, électrique ou hybride :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mauvaise question...
Posté par mahikeulbody . Évalué à 2.
Les analogies, c'est bien pour aider à faire comprendre, mais ça a de sérieuses limites quand il s'agit de s'en servir pour démontrer.
# A qui parle on ?
Posté par SlowBrain (site web personnel) . Évalué à 10.
La vraie question que je me pose en lisant cet argumentaire est : A qui s’adresse on ?
Les nombreuses questions qui se posent aujourd’hui sur les changements de logiciel de messagerie sont lié aux changements de politique de Facebook au sujet de WhatsApp.
Une problématique, pour moi, beaucoup plus vue du coté de l’utilisateur qui du coté de l’informaticien.
Le choix de WhatsApp n’était déjà pas pour moi le choix d’une DSI, ou d’un autre groupe d’éclairé numériquement. Le but étant souvent soit de combler un manque, soit de trouver une alternative aux solutions «Officiellement recommandé», mais ne convenant pas à l’utilisateur.
Nous somme ici parfaitement dans la logique du «Shadow IT», qu’elle soit alternative aux solutions de la DSI d’une grosse entreprise, ou la débrouillardise d’une petite structure (Entreprise, Associative ou Familiale).
Et c’est une alternative dans le même esprit qui est recherché : Clef en main et avec le moins de questionnement technique. Nous avons juste une lueur de vie privée qui viens d’éclore dans les esprits, et dont il faut, nous défenseur de cette valeur, profiter.
Mais XMPP, malgré ces innombrables valeurs techniques n’en reste pas moins d’une complexité sans nom pour ce qui est un simple utilisateur.
Qui, mis a part un libriste convaincu, mettra de l’énergie à choisir client et serveur ? Qui en comprendra même l’intérêt, la où les alternatives ne posent pas cette question parfaitement technique ?
Dans le grand public XMPP fonctionne, et il me semble même que Facebook messager l’utilise. Mais pas dans sa composante décentralisée, laissant le choix aux utilisateurs.
Sont ils prêts à l'opportunité du choix alors même qu’ils comprennent seulement l’idée de vie privée ?
On le vois assez souvent sur ces solutions décentralisée dont le monde du libre est si friand : C’est la solution de référence qui se trouve vite noyé sous les demandes, laissant les autres serveurs en marge … avant un grand blocage et un pavé d’explication sous la forme d’un «Faites votre choix !»
Tout cela pour dire que, plein d’espoir et de vérité technique, ce type de message me semble louper sa cible : L’utilisateur.
[^] # Re: A qui parle on ?
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9.
Il faut arrêter de dire que XMPP c'est compliqué. Les mêmes arguments marcheraient pour le web:
"HTTP c'est compliqué, il faut choisir un navigateur web, et puis ensuite il faut choisir quel site tu vas visiter."
Pourtant les gens arrivent bien à installer Chrome et à aller sur Facebook avec.
Conclusion: oui, on ne va pas arriver à grand chose en essayant de faire de la pub pour XMPP directement. Ça se fera plutôt par 2 autres voies:
- D'une part les clients, qui fournissent une expérience utilisateur rendant les choses faciles à aborder (par exemple quicksy, qui te crée un compte à partir de ton numéro de téléphone et tout le temps sur le même serveur),
- D'autre part, les communautés de gens qui utilisent déjà XMPP, probablement plus ou moins co-localisées sur un serveur déjà en ligne.
Pas le protocole. On vend pas un protocole au grand public.
[^] # Re: A qui parle on ?
Posté par SlowBrain (site web personnel) . Évalué à 5.
Je ne suis pas sur sue la popularité d’Internet Explorer 6 soit plus dû a ces qualité technologique qu’au simple fait qu’il évite de faire un choix.
Ou encore que Google paye la Mozilla fondation pour être le moteur de recherche par défaut par pure bonté d’âme.
L’utilisateur est capable de faire des choix, et il est dangereux de le prendre pour un imbécile (Certain s’y amusent :) ) Mais il faut le temps de prendre conscience de l’importance de ces choix à faire.
C’est déjà le cas ici : C’est la prise de conscience que le choix d’une messagerie instantanée n’est pas neutre. Que le choix de son gestionnaire ne l’est pas, et c’est bien pour ça que l’on entend parler de Signal ou Telegram, mais pas de Hangout par exemple.
Mais comme tu l’indique, le choix ne se fait pas sur un protocole.
Et XMPP (mais aussi plein d’autres fonctionnant sur ces même principes) as toutes les qualités technique pour être la messagerie de tout le monde.
Mais peu être en masquant les choix à disposition … ou simplement en les rendant ludique … ça ne tiens pas forcément a grand chose.
Mais ce sont rarement les qualités technique du produit qui lui ont fait remporter l’engouement du public.
[^] # Re: A qui parle on ?
Posté par anubis . Évalué à 5.
Il est vrai que la cible du message est mal définie.
Je pense que c'est effectivement difficilement accessible pour un utilisateur isolé. Cependant pour qui a un minimum de débrouille c'est la bonne solution; par exemple quelqu'un qui se débrouille avec l'auto-hébergement comme Yunohost. Et ça tombe bien, Yunohost inclut par défaut un serveur XMPP qui fonctionne bien. L'auto-hébergement est une pratique encore marginale mais Yunohost a permis une véritable diffusion; par ailleurs il suffit d'un membre dans la famille / dans un groupe pour fournir des accès à quelques dizaines de personnes inexpérimentés, cela me semble une voie possible en complément de CHATONS et de serveurs plus "officiels" pour éviter les gros cluster.
Par ailleurs, sur pourquoi XMPP plutôt que Matrix : outre le réinventage de roue et la perfo dissuadant l'auto-hébergement, le seul client utilisable l'étant par une société lucrative vers qui fuitent des métadonnées à chaque lancement me parrait inacceptable pour qui souhaite protéger sa vie privée.
aussi sur le salon xmpp:linuxfr@chat.jabberfr.org?join
# Matrix vs XMPP
Posté par dani . Évalué à 6.
Dans la balance Matrix vs XMPP, il y a quelques éléments quand même en faveur de Matrix (qui m'ont fait quitter XMPP pour Matrix il y a 3 ans, sans regret) :
- Les salons sont distribués sur tous les serveurs qui y participent. Il n'est donc pas possible de faire fermer un salon en supprimant un serveur qui l'hébergerait
- Le protocole est versionné au lieu d'avoir un cœur simpliste et toute une collection d'extensions optionnelles. C'est ce qui fait que XMPP ne marche pas dans le monde réel : pour pouvoir utiliser des fonctions élémentaires, il faut que toute la chaîne (ton client, ton serveur, le serveur de ton interlocuteur, le client de ton interlocuteur) supporte les mêmes XEP et que tout soit bien configuré. Comme c'est rarement le cas, et qu'il n'y a aucune façon de le garantir … On fini par ne plus l'utiliser pour envoyer des fichiers par exemple (puisque trop de risque que ça ne passe pas). Je parle même pas d'appels audio/vidéo. Avec Matrix, ça juste marche.
[^] # Re: Matrix vs XMPP
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Aucun problème pour l'envoi de fichiers ni l'audio/video chez moi. Je pense que c'est très exagéré de dire que tout est rarement bien configuré.
Comme je l'indiquais dans un autre commentaire il y a des XEP tous les ans avec le minimum attendu pour les clients de messagerie instantanée (entre autres, car ce n'est pas la seule utilisation de XMPP). La version 2021 par exemple inclut le transfert de fichiers via HTTP File Upload (XEP-0363) de façon obligatoire pour les clients et serveurs de messagerie instantanée et ajoute la catégorie "appels audio/vidéo".
Maintenant, si les gens insistent pour utiliser des clients et/ou serveurs pas mis à jour depuis le siècle dernier, on y peut quoi?
[^] # Re: Matrix vs XMPP
Posté par claudex . Évalué à 4.
C'est un peu tout le problème. Avec une solution imposée (Whatsapp, Signal…), tu es sûr que toutes les fonctionnalités sont là. Avec XMPP, tu ne sais pas si le type en face. Et si tu t'inscris quelque part ou si tu installe un serveur, tu ne sais pas facilement si tu vas y avoir droit (ça prend plus que 30 secondes). Surtout quand tu ne connais pas (ou de loin).
Je prends mon cas, je n'ai aucune idée de client, de serveur ou d'instance à conseiller à quelqu'un.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Matrix vs XMPP
Posté par Anonyme . Évalué à 3.
va faire un tour sur joinjabber.org :)
[^] # Re: Matrix vs XMPP
Posté par steph1978 . Évalué à 4.
erreur 404 sur linuxfr
là tu m'as tué :D
[^] # Re: Matrix vs XMPP
Posté par Anonyme . Évalué à 5.
homicide involontaire :(
https://joinjabber.org
[^] # Re: Matrix vs XMPP
Posté par dani . Évalué à 1. Dernière modification le 01 février 2021 à 20:05.
Oui, monter un serveur XMPP privé, et où l'on contrôle tous les clients (typiquement pour un usage interne en entreprise) c'est simple, et en effet, on peut plus ou moins s'assurer que toutes les fonctions de base seront dispo. Mais ça, c'est oublier que XMPP est fédéré (sinon, il n'a plus aucun intérêt). Et avec la fédération, tu n'as aucun contrôle sur le serveur de tes interlocuteurs, ni de leur client. Et là, XMPP retombe au plus petit dénominateur commun (tu seras à peu près sûr que tu pourras échanger des messages textes, probablement participer à des salons. Pour tout le reste, ça sera aléatoire)
[^] # Re: Matrix vs XMPP
Posté par Anonyme . Évalué à 3.
XMPP compliance tester te permet de savoir quel serveur supporte quelle fonctionnalité, et t'aide donc à choisir ton serveur et à savoir de quoi sont capables tes interlocuteurs en fonction du serveur qu'ils utilisent.
[^] # Re: Matrix vs XMPP
Posté par mahikeulbody . Évalué à 4. Dernière modification le 01 février 2021 à 20:56.
Savoir que tes interlocuteurs ne sont pas capables de faire de l'A/V c'est bien mais ça ne résout pas mon problème si je veux communiquer avec eux. On en revient toujours au même point : comment convaincre quelqu'un de quitter whatsapp (ou consorts) si on n'est pas capable de lui assurer que la solution proposée inclut par défaut les services considérés comme le minimum requis pour faire de la messagerie ? Des initiatives comme joinjabber citée plus haut peuvent aider mais est-ce que ça sera suffisant pour compenser ce "défaut" (stratégique, pas technique) originel de XMPP : un core obligatoire minimaliste et une multitude d'options ?
[^] # Re: Matrix vs XMPP
Posté par seveso . Évalué à 3.
Pourquoi ne pas lui suggérer un bon serveur ?
Sur la page d'accueil de Compliance Tester tu as "Randomly suggested compliant servers" qui te liste 5 serveurs serveurs au hasard qui ont une note de 100%.
[^] # Re: Matrix vs XMPP
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 4.
Comme le noyau Linux ? Je croyais que faire des monolithes, c'était mal :)
Blague à part, pour avoir monté un serveur XMPP il y a trois semaines pour la première fois de ma vie, rien qu'en installant ejabberd avec la configuration de base, j'étais déjà à plus de 80% des tests de compliance.
De base, tu as donc la communication entre clients, les multi-users channel (MUCs), le PubSub, la communication entre serveurs…
De ce que j'ai pu voir, les exemples de configuration pour Prosody fournissent grosso modo la même chose donc le plus petit dénominateur commun, il n'est peut-être pas si petit.
Après, coté clients XMPP, ce n'est pas forcément tout rose mais pour la messagerie et les discussions de groupe, ça reste correct.
Effectivement, j'ai quelques soucis pour la vidéo avec certains et un bug dans Xabber pour le transfert de fichiers mais le bug semble résolu pour la prochaine version.
[^] # Re: Matrix vs XMPP
Posté par mahikeulbody . Évalué à 3. Dernière modification le 02 février 2021 à 10:28.
On parle d'un protocole, pas d'une implémentation, hein… Je n'ai rien contre la découpe en XEP, c'est le fait qu'elles soient optionnelles qui me paraît dommageable pour le succès de XMPP.
Je parlais du protocole pas des implémentations et de leur configuration par défaut (dont tu confirmes toi-même qu'il manque quand même 20% dans une d'entre-elle et dont rien ne garantit que c'est celle qui va être choisie par l'administrateur du service).
Je persiste à penser que si le core du protocole XMPP incluait obligatoirement tout ce qu'on s'attend à trouver dans une messagerie moderne, on aurait moins d'implémentations (serveurs et clients) différentes formant la fédération et il y aurait moins de déceptions* de la part des utilisateurs qui pensaient trouver la solution pour un "whatsapp" plus respectueux de leurs données personnelles et qui marche "out of the box".
* même si celles-ci tendent à diminuer grâce aux nombreuses initiatives telles que joinjabber, snikket, quicksy, …
NB. C'est dommage mais le fait est que c'est souvent bien plus rapide de créer un protocole et l'implémentation de référence qui va avec, puis de proposer d'en faire un standard ou a minima de le rendre libre, que de construire ce protocole à plusieurs avec la nécessité d'un consensus à chaque étape. Et si en plus on rend optionnelle l'implémentation de ces étapes… C'est peut-être ce qui va faire que Matrix voire Jami vont réussir là où XMPP, pourtant parti bien avant et plein de qualités, ne va peut-être pas décoller.
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 02 février 2021 à 13:40.
Je ne pense pas qu'une réplication systématique soit une bonne chose pour beaucoup de raisons (maîtrise des données et ressources notamment), mais elle est très intéressante si elle est optionnelle.
Note qu'il est possible de le faire avec XMPP aussi (XEP-0282 et XEP-0289), mais c'est vrai que je ne connais aucune implémentation en pratique (je ne sais même pas trop ce que les XEPs valent, il faudrait regarder ça en détails). Aussi MIX (le nouveau protocole de chat en court d'élaboration/implémentation) devrait permettre aussi la réplication.
Enfin qu'on aime ou pas cette fonctionnalité, c'est vrai que Matrix le fait aujourd'hui, et XMPP en pratique non, reste à voir si c'est une fonctionnalité critique pour la personne qui choisi.
Par contre je crois me souvenir que le serveur principal de matrix était tombé il y a quelque temps, et que ça avait sacrément perturbé le réseau (à confirmer, je suis ça de très loin). Est-ce qu'en pratique la réplication permet vraiment de fonctionner sans accroc quand notre serveur principal tombe ?
Ça c'est faux. Il y a très peu de fonctionnalités qui demandent que toute la chaîne implémente quelque chose (en fait je n'en vois aucune là tout de suite), excepté PEP qui est implémenté par absolument tout le monde (c'est nécessaire pour publier des infos comme des clefs publiques). L'audio vidéo peut fonctionner si uniquement les clients l'implémentent, le serveur ne fait que fournir une aide pour traverser les réseau difficiles, et même là il suffit qu'un des 2 serveurs implémente ce qu'il faut.
L'envoi de fichier marche à ma connaissance avec tous les clients et serveurs, ça fait combien d'années que tu n'as pas essayé ?
Matrix utilise justement XMPP pour les appels audio/vidéo (via Jitsi Meet qu'il embarque), sauf pour les appels 1:1 qui sont du webRTC (et là c'est les navigateurs qui font le boulot principal).
Et en pratique, combien de clients autres que le client principal de Matrix (Element) implémentent toutes les fonctionnalités ? Est-ce qu'il y a un seul client tiers qui le fait ? Ils ont exactement le même problème pour la même raison : c'est une question de ressource, et le client principal de Matrix avance bien parce qu'ils ont de l'argent pour payer des équipes de développement à plein temps (tant mieux pour eux), mais les clients tiers n'ont pas souvent les moyens de suivre au même rythme.
[^] # Re: Matrix vs XMPP
Posté par dani . Évalué à -2.
Tu dis toi même qu'il faut que les 2 clients implémentent les mêmes XEP, et au moins pour certaines, il faut aussi le support des serveurs. Me semble difficile de commencer ta phrase par un simple "ça c'est faux" du coup. On est bien d'accord qu'en dehors des fonctions les plus basiques, il faut que tous les participants utilisent un client qui supportent des XEP, qui sont optionnelles …
Je m'en suis servi de 2007 à 2017 en gros, principalement avec Ejabberd et divers clients sous Linux. Et mon expérience était plutôt : ça ne marche jamais, sauf exceptions (à condition que les 2 utilisent le même clients, dans la même version et soient sur le même LAN en gros …). Tous les clients existants étaient au mieux médiocres (Gajim, Empathy, Psy, Pidgin, Jappix en web). Peut être que ça s'est amélioré ces 3 dernières années, mais enfin, faut se rendre à l'évidence : XMPP ne fonctionnera jamais en vrai. La XSF aurait pu en faire un vrai succès, mais au lieu de faire un client et un serveur de référence (par exemple), ils ont préféré écrire 45 XEP différentes rien que pour l'envoi de fichiers. Et démerdez vous les développeurs pour trier dans ce tas de trucs ce que vous voulez implémenter.
[^] # Re: Matrix vs XMPP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 02 février 2021 à 15:57.
Il me semble assez évident que pour une conversation audio ou vidéo, il faut que les clients supportent, quel que soit le protocole. Y'a vraiment besoin de préciser ça ?
Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.
J'aime bien comme ça a glissé de « toute la chaîne » à « tous les clients ». Évidemment que pour afficher de la vidéo, il faut que le client soit prévu pour.
[^] # Re: Matrix vs XMPP
Posté par dani . Évalué à -3.
À part un péremptoire "c'est faux", tu n'ajoutes pas grand chose de concret. Pour qu'une fonction puisse être utilisée, bien sûr il faut que les clients l'implémentent, ça paraît naturel. Le problème n'est pas là. Le problème est que rien ne garantie que les clients utilisés implémenteront tous cette fonction. Donc dans les faits, ce qui est sûr de fonctionner, c'est le plus petit dénominateur commun (c-a-d, presque rien). Le reste peut, peut être, avec un peu de chance marcher.
Même si les 2 implémentent une fonctions censées être similaire, ça ne fonctionnera souvent pas (à l'époque, il suffisait d'essayer de passer un appel A/V entre un Gajim et un Empathy pour rire. Je suppose que c'est toujours à peu près autant le bordel entre clients différents de nos jours)
Et à ça s'ajoute aussi le problème des serveurs (même si tu l'as balayé d'un revers de la main, en finissant par admettre que si, finalement, il faut que les serveurs eux aussi implémentent des trucs … optionnels). Là encore, un utilisateur n'a aucun moyen de contrôler ça. Tiens d'ailleurs, le transfert de fichier aussi nécessitent le support côté serveur …
Et un utilisateur normal, tu lui fais tester un truc qui marche pas une fois, OK il tolère. 2 fois, il se fout de ta gueule, 3 fois il va chez la concurrence, là où les choses marchent.
Bref, on peut simplifier : dans un réseau fédéré, ce qui est optionnel doit être considéré comme absent.
# Fédération et spam
Posté par paulez (site web personnel) . Évalué à 3.
Mon gros problème avec la fédération, c'est le niveau de spam.
Je fais tourner un serveur Prosody pour ma famille, et j'ai du désactiver la fédération pour que ça soit utilisable.
Difficile de vendre la solution à sa famille quand les utilisateurs reçoivent régulièrement des messages de spammeurs russes vendant des pilules magiques.
Il y a des solutions efficaces contre ça ?
[^] # Re: Fédération et spam
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Sur ejabberd, il y a la configuration s2s-access.
Il serait étonnant qu'il n'y ait pas la même chose sous Prosody.
[^] # Re: Fédération et spam
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
Regardes du côté du module de blacklist si tes spammeurs viennent toujours du même endroit.
Sinon, tu peux passer par les whitelists
[^] # Re: Fédération et spam
Posté par paulez (site web personnel) . Évalué à 2.
Oui il y a l'équivalent de allow et block lists. J'ai essayé au début d'utiliser une block list, mais les spammeurs utilisent suffisamment de serveurs différents pour que ça ne résolve pas le problème.
Si j'utilise une allow list, qu'est-ce que je mets dedans ? Ça revient presque à désactiver la fédération.
[^] # Re: Fédération et spam
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 2.
C'est le même problème qu'avec les mails donc, sauf à coller un antispam côté serveur, y a pas de solution miracle.
Après, le fait qu'une whitelist ne fonctionne pas dans ton cas est plutôt une bonne nouvelle pour XMPP car ça veut dire que tes utilisateurs discutent avec des personnes issus de plein de serveurs différents :)
[^] # Re: Fédération et spam
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Du coup, tu as piqué ma curiosité et j'ai regardé rapidement.
Je suis tombé sur ce post de Prosody mais je pense que tu as déjà dû le voir.
[^] # Re: Fédération et spam
Posté par paulez (site web personnel) . Évalué à 3.
Tout ça est bien manuel, il faut gérer sa blocklist à la main, contacter les serveurs qui envoient du spam, etc. Je suppose donc que la plupart des serveurs n'ont pas le moyen de maintenir tout ça, et sont donc ouverts aux spammeurs.
J'avais ouvert les inscriptions à mon serveur il y a longtemps, et le spam était une plaie ingérable. Bon courage aux admins de serveurs publics !
Dans le monde du mail, il y a énormément de services qui permettent de filtrer la plupart du spam, les outils sont bien plus performants.
De plus, alors que les utilisateurs acceptent de recevoir de temps à autre du spam dans leur boîte mail, sur de la messagerie instantanée pas du tout. Il n'y a pas de spam sur Whatsapp and co, alors pourquoi accepter d'utiliser un service sur lequel on reçoit du spam ?
[^] # Re: Fédération et spam
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
C'est pas ça qui devrait changer à partir de mai ? J'avais compris que le but de Facebook était de fournir un moyen pour que les entreprises puissent te contacter directement et que tu puisses commercer avec eux… De là à ce que l'on soit spammés, y a pas loin.
Alors, je ne connais rien à Matrix, mais le problème du spam ne risque-t-il pas d'arriver un jour ?
[^] # Re: Fédération et spam
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 3.
Le mail a bientôt 40 ans, encore heureux qu'on ait des solutions !
Et encore, les solutions ne sont même pas au niveau du protocole mais sont des verrues sur les serveurs SMTP et les clients mail.
D'ailleurs, sur mon téléphone, j'ai pas un bogofilter qui tourne et ça se voit tout de suite.
D'ailleurs, voilà un projet intéressant : implémenter un hook Bogofilter sur ejabberd
Tu me diras comment ils font, moi, du spam, j'en reçoit une quinzaine par jour… Sur mon compte Jabber, rien et pourtant l'adresse est dispo ici-même depuis plus de 10 ans.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.