Messagerie instantanée : ce n’est pas une question d’applications

Posté par  (site Web personnel) . Édité par Pierre Maziere, pulkomandy, Ysabeau et anubis. Modéré par Ysabeau. Licence CC By‑SA.
Étiquettes :
32
30
jan.
2021
XMPP

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 :

Aller plus loin

  • # Configuration serveur et écosystème de clients

    Posté par  . Évalué à 7 (+5/-0). Dernière modification le 30/01/21 à 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  . Évalué à 4 (+2/-0).

      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 […]

      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  (site Web personnel) . Évalué à 4 (+2/-0).

        • [^] # Re: Configuration serveur et écosystème de clients

          Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

          Un truc qui me fait méga peur quand je lis le XEP-0227 :

          Each user is represented by a element under the element. The element MUST have a 'name' attribute, which contains the node part of the user's JID, and SHOULD have a 'password' attribute, which contains the user's password.

          Lors de l'export, le mot de passe de l'utilisateur devrait être inclus dans l'export. Alors, certes, ce n'est pas un DOIT (MUST), mais un DEVRAIT (SHOULD) mais quand même…. Comment en 2021 on peut encore promouvoir ce genre de chose ?

          Cela ne fait déservir qu'une chose : la sécurité de XMPP (car si les serveurs doivent conserver le mot de passe….)

          Pour rappel, pour un stockage sécurisé, on ne stocke JAMAIS le mot de passe des utilisateurs au niveau d'un serveur. Toujours un hash, avec au minimum un sel.

          • [^] # Re: Configuration serveur et écosystème de clients

            Posté par  (site Web personnel) . Évalué à 4 (+3/-1).

            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

            • [^] # Re: Configuration serveur et écosystème de clients

              Posté par  (site Web personnel) . Évalué à 2 (+4/-4).

              Sauf que le protocole ne précise pas comment doit être stocké ce mot de passe, c'est un choix d'implémentation.

              NON NON NON ET NON !

              Jamais le mot de passe en BD, qu'il soit en clair ou non. C'est une règle d'or. Il existe plusieurs possibilités pour s'en passer, et il faut les utiliser.

              Un utilisateur ne devrait JAMAIS pouvoir récupérer son mot de passe. S'il le perd, c'est un processus de renouvellement, pas de rappel.

              Un service qui stocke le mot de passe (en clair ou non, on s'en fiche) est un service NON SECURISE qu'il faut fuir à tout prix.

              • [^] # Re: Configuration serveur et écosystème de clients

                Posté par  (site Web personnel) . Évalué à 7 (+6/-1).

                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.

                • [^] # Re: Configuration serveur et écosystème de clients

                  Posté par  (site Web personnel) . Évalué à 2 (+2/-2).

                  Si, c'est nécessaire, car le protocole incite à de mauvaises pratiques. Et le protocole parle bien de mot de passe, pas de hash. Aucune excuse à ce niveau là donc.

                  Tu peux penser que ma réaction est exagérée. Perso, je le vois régulièrement, des failles à cause de ce genre de négligence (car oui, il s'agit de négligence déjà sanctionné à plusieurs reprises par la CNIL).

                  D'ailleurs, en parlant de CNIL, elle le rappelle elle-même :

                  Le mot de passe ne doit jamais être stocké en clair. Lorsque l’authentification a lieu sur un serveur distant, et dans les autres cas si cela est techniquement faisable, le mot de passe doit être transformé au moyen d’une fonction cryptographique non réversible et sûre, intégrant l’utilisation d’un sel ou d’une clé.

                  Je n'ai rien inventé !

                  • [^] # Re: Configuration serveur et écosystème de clients

                    Posté par  . Évalué à 3 (+2/-1).

                    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.

                    Ce commentaire passe-t-il les trois tamis de Socrate ? -- je ne moinsse pas les conversations auxquelles je participe

                    • [^] # Re: Configuration serveur et écosystème de clients

                      Posté par  (site Web personnel) . Évalué à 0 (+1/-3).

                      Encore heureux que c'est optionnel. Mais même si c'est optionnel, c'est encourage (SHOULD) et non laissé comme une simple possibilité (MAY)

                      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.

                      Je suis d'accord, sur le fait qu'un protocole n'ait pas à préjuger de l'utilisation et doit être flexible. Toutefois, cela ne doit pas se faire au détriment de la sécurité. Ce qui est largement le cas ici. Surtout qu'il est tout à fait possible de mettre à la place du password, son hash, l'algo utilisé et le sel par exemple. Donc clairement, c'est non sécurisé à souhait, et ce n'est pas en mettant un simple paragraphe sur la sécurité (la section 6) que le problème sera résolu.

                      Le souci, c'est qu'un "détail" comme ça amène à s'interroger sur le protocole en lui-même… En 2021 ce n'est plus possible d'avoir de genre de laxisme. Désolé.

                      • [^] # Re: Configuration serveur et écosystème de clients

                        Posté par  (site Web personnel) . Évalué à 5 (+4/-1).

                        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?

                        • [^] # Re: Configuration serveur et écosystème de clients

                          Posté par  (site Web personnel) . Évalué à 0 (+1/-3).

                          C'est tellement ouvert qu'on peut proposer n'importe quoi. De la télépathie (XEP-0183) ou une manière de flagger les messages malicieux (XEP-0076) dans le style "attention, je t'envoie un malware mec !".

                          Je n'ai rien contre l'humour (au contraire), mais honnêtement, ça n'a rien à faire dans un protocole, fut-ce dans des XEP (et même si c'est clairement mentionné qu'il s'agit d'humour).

                          C'est triste parce que je suivais XMPP de plus ou moins loin. Le fait d'avoir creuser un peu me donne l'impression d'un protocole de geek en plus de ne pas être sécurisé. Je trouve que cela ruine les efforts de ceux qui essaient de le faire évoluer et de le promouvoir.

                          Bref, à choisir entre XMPP et Matrix (qui est aussi un protocole ouvert et tout aussi documenté), le choix me semble plus facile maintenant…

                          • [^] # Re: Configuration serveur et écosystème de clients

                            Posté par  (site Web personnel) . Évalué à 8 (+6/-0).

                            Je n'ai rien contre l'humour (au contraire), mais honnêtement, ça n'a rien à faire dans un protocole, fut-ce dans des XEP (et même si c'est clairement mentionné qu'il s'agit d'humour).

                            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  . Évalué à 5 (+5/-1).

                            C'est tellement ouvert qu'on peut proposer n'importe quoi. De la télépathie (XEP-0183) ou une manière de flagger les messages malicieux (XEP-0076) dans le style "attention, je t'envoie un malware mec !".

                            Je n'ai rien contre l'humour (au contraire), mais honnêtement, ça n'a rien à faire dans un protocole, fut-ce dans des XEP (et même si c'est clairement mentionné qu'il s'agit d'humour).

                            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  . Évalué à 2 (+0/-0). Dernière modification le 01/02/21 à 23:41.

                            commentaire supprimé: réaction épidermique qui n'avait pas sa place ici

                            Ce commentaire passe-t-il les trois tamis de Socrate ? -- je ne moinsse pas les conversations auxquelles je participe

                          • [^] # Re: Configuration serveur et écosystème de clients

                            Posté par  (site Web personnel) . Évalué à 5 (+4/-0).

                            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  (site Web personnel) . Évalué à 4 (+4/-1).

                        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  (site Web personnel) . Évalué à 6 (+4/-0).

                          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  (site Web personnel) . Évalué à 1 (+1/-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  . Évalué à 2 (+1/-0).

                              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.

                              […] vu que XMPP est basé sur pas mal de choix de son époque (XML par exemple)

                              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  (site Web personnel) . Évalué à 0 (+0/-1).

                                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  . Évalué à 3 (+3/-1).

                                  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  . Évalué à 3 (+1/-0).

                                    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  (site Web personnel) . Évalué à 0 (+0/-1).

                                    Pour moi, l'arrivée de Matrix a surtout permis de renforcer les GAFAM.

                                    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  . Évalué à 5 (+2/-0).

                                      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.

                                      Signal montre qu'une solution libre mais centralisée peut avoir du succès

                                      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  . Évalué à 2 (+0/-0).

                                        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.

                                        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  (site Web personnel) . Évalué à 2 (+1/-0).

                                        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  . Évalué à 5 (+2/-0).

                                          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 ?

                                          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  (site Web personnel) . Évalué à -2 (+0/-3).

                                            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  (site Web personnel) . Évalué à 1 (+0/-1).

                                              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.

                                              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  (site Web personnel) . Évalué à 3 (+2/-0).

                                          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 ?

                                          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  . Évalué à 4 (+2/-0).

                                        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)

                                        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  . Évalué à 3 (+0/-0).

                                          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  (site Web personnel) . Évalué à 5 (+3/-0).

            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.

            • [^] # Re: Configuration serveur et écosystème de clients

              Posté par  (site Web personnel) . Évalué à 3 (+2/-1). Dernière modification le 02/02/21 à 14:06.

              Tu parles d'une extension qui a été écrite en 2007, et qui n'a pas été touchée depuis 2010

              Justement. La XEP est en draft, ce qui signifie prête en production, mais susceptible de changer. Qu'elle n'ait pas changé en 11 ans pour un sujet qui peut être aussi critique, c'est assez incroyable.

              je ne pense qu'il y ait beaucoup de serveurs qui gardent les mots de passe en clair.

              Déjà mentionné plus haut, Prosody le fait (cf. conclusion). Pour information, la configuration par défaut de ejabberd est de stocker les mots de passe en clair.

              Alors, je suis d'accord, là ce n'est pas le protocole, ce sont les implémentations. Mais justement, les implémentations peuvent être foireuses car le protocole est une passoire. Tant que ce genre de chose sera supporté par le protocole, les implémentations le feront.

              La justification de Prosody est intéressante à ce sujet. Je résume grossièrement : il existe 3 méthodes d'authentification : PLAIN, DIGEST-MD5, SCRAM-SHA-1 :
              - PLAIN : mot de passe en clair
              - DIGEST-MD5 : hash, mais obsolète depuis 2011
              - SCRAM-SHA-1 : pas supporté par tous les clients.

              Du coup, pour les serveurs, la seule manière de ne pas perdre de clients, c'est de stocker les mots de passe en clair. Configuration faite par défaut par Prosody et ejabberd (et sans doute d'autres serveurs, je n'ai regardé que ces deux là et les deux ont fait le même choix).

              Les connexions ont beau être sécurisées et donc le mot de passe ne pas transiter en clair sur les réseaux, cela n'en représente pas moins une énorme faille. Si la BD fuite, que l'admin est véreux, qu'il y ait une injection SQL ou que sais-je encore, cela veut dire que les mots de passe des utilisateurs sont accessibles à des tiers. Quand on connait la proportion de gens qui réutilise le même mot de passe pour leurs différents services, c'est inquiétant.

              • [^] # Re: Configuration serveur et écosystème de clients

                Posté par  (site Web personnel) . Évalué à 4 (+2/-0).

                Déjà mentionné plus haut, Prosody le fait (cf. conclusion).

                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.

                • [^] # Re: Configuration serveur et écosystème de clients

                  Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                  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.

                  Effectivement, il semblerait que cela soit une erreur dans la documentation qui n'est pas à jour partout. Mea culpa.

                  Pour ejabberd je ne sais pas, à vérifier.

                  Je viens de le faire : https://github.com/processone/ejabberd/blob/master/config/ejabberd.exs

                  On trouve notamment un "auth_method: :internal". Dans ce cas, d'après la doc, il faut aller voir auth_password_format. Qui n'est pas spécifié dans le fichier. Donc pour la valeur par défaut, on regarde la doc et on trouve :

                  auth_password_format
                  plain | scram

                  The option defines in what format the users passwords are stored. plain: The password is stored as plain text in the database. This is risky because the passwords can be read if your database gets compromised. This is the default value.

                  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.

                  Comme dit plus haut, je n'ai pas dit que le protocole incitait à garder les mots de passe en clair. J'ai dit qu'il incitait à garder les mots de passe (en clair ou chiffré, qu'importe, mais possibilité de les récupérer) via l'usage de SHOULD. Hors, il ne devrait pas.

                  Regardons comment le SHOULD est défini (RFC 2119) :

                  1. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

                  Je me hasarde à une traduction rapide :

                  1. DEVRAIT Ce mot, ou l'adjectif "RECOMMANDE", signifie qu'il peut exister des raisons valides, dans certaines circonstances, d'ignorer ce point particulier, mais que toutes les répercussions doivent être comprises et précautionneusement évaluées avant de choisir une voie différente.

                  Donc, je persiste, mais une personne qui n'est pas suffisamment avertie du point de vue sécurité ne se posera pas de question. Le protocole me demande un mot de passe, je fais le nécessaire pour qu'il y en ait un.

                  Je suis peut être pointilleux la dessus, mais c'est l'expérience qui parle. Je le vois régulièrement, et même chez des personnes que l'on s'attend sensibilisée à ce genre de problème (comme le DSI d'un hôpital dont je tairais le nom qui ne voyait pas pourquoi il fallait chiffrer des données de patients avec une URL GET, un service d'imagerie médicale qui dispose d'une API pour faire une recherche de patient selon des critères et qui retourne TOUS les patients en l'absence de critère, et j'en ai encore plein d'autres des comme ça).

                  • [^] # Re: Configuration serveur et écosystème de clients

                    Posté par  . Évalué à 3 (+1/-0).

                    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.

                    • [^] # Re: Configuration serveur et écosystème de clients

                      Posté par  (site Web personnel) . Évalué à 3 (+1/-0).

                      C'est un pavé assez difficile à lire, tant il est fouillu et mélange allègrement authentification et sécurisation du canal de communication.

                      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.

                      Je pense que tu n'as pas compris pourquoi c'est rédhibitoire. Est-ce que le client est responsable du fait que le serveur soit "facilement poutrable" ? La réponse est bien évidemment non. Maintenant, devant la tendance d'un utilisateur à réutiliser le même mot de passe partout (et oui, il y a encore beaucoup de chemin à faire là-dessus), le fait que le serveur se fasse poutrer peut avoir de très grave conséquence pour l'utilisateur. Un attaquant peut facilement accéder à différents services auxquels l'utilisateur est abonné. Et s'il a accès à la messagerie, alors là, c'est la voie royale ! Non seulement l'attaquant peut avoir accès à l'ensemble de tes informations, mais en plus, il peut usurper ton identité !

                      Et l'attaquant peut être une personne extérieure comme en interne ! Les admin "véreux" ou en conflit avec leur boite, ça existe. Il n'y a qu'à prendre l'exemple récent de CDiscount pour se rendre compte que ce genre de pratique est juste… inadmissible aujourd'hui.

                      Je milite effectivement pour ne pas stocker de secret côté serveur, que ce soit en clair ou de manière chiffrée, pour éviter ça. Si le serveur se fait poutrer, seules les données du serveur sont violées. Pas d'autres accès, pas d'usurpation d'identité possible.

                      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.

                      Ce n'est pas une histoire de compris, c'est une histoire de responsabilité. Demain un de mes serveurs est attaqué et les mots de passe sont stockées, je suis responsable, qu'importe les moyens de sécurisation mis en place.

                      Il faut bien comprendre que lorsqu'une techno est "mis à la poubelle" pour reprendre tes dires du point de vue sécurité, c'est qu'elle présente des failles majeures qui la rendent non sécurisée. Pas moins sécurisée mais bien non sécurisée. Car si la techno en elle-même ne présente pas de faille, elle oblige à une conception en présentant, rendant de facto le tout non sécurisé.

                      Donc lorsque je lis que c'est une affaire de compromis, je me dis qu'on a encore beaucoup de chemin à faire, y compris ici…

    • [^] # Re: Configuration serveur et écosystème de clients

      Posté par  (site Web personnel) . Évalué à 6 (+4/-0).

      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  . Évalué à 2 (+2/-0).

      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  . Évalué à 1 (+1/-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  . Évalué à 3 (+1/-0).

      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  . Évalué à 4 (+2/-0).

        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  . Évalué à 1 (+0/-0).

          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  . Évalué à 2 (+0/-0).

            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).

            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  . Évalué à 7 (+9/-3).

          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  . Évalué à 1 (+1/-1). Dernière modification le 30/01/21 à 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  . Évalué à 3 (+1/-0).

              gomuks, Arch/AUR: 16.23 MiB.

              • [^] # Re: XMPP ou Matrix ?

                Posté par  . Évalué à 1 (+0/-0).

                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  (site Web personnel) . Évalué à 7 (+7/-1).

              sur Linux j'utilise le client web qui fait 0 mo (app.element.io)

              Simple test, j’ouvre https://app.element.io. Sans même me connecter, about:performance dans 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  . Évalué à 2 (+1/-0).

                Firefox m’indique plus de 60 Mio direct,

                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  (site Web personnel) . Évalué à 4 (+3/-0).

                  On peut considérer que c'est beaucoup […] mais on est encore loin des 300 Mo non ?

                  Oui, si on a le navigateur web déjà ouvert, mais je réagissais surtout à :

                  sur Linux j'utilise le client web qui fait 0 mo (app.element.io)

                  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  (site Web personnel) . Évalué à 2 (+0/-0).

            Il y a aussi des tas de passerelles sur XMPP, dont le fédiverse

            T'as un lien vers cette passerelle? ca m'intéresse.

    • [^] # Re: XMPP ou Matrix ?

      Posté par  . Évalué à 7 (+6/-1).

      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 ?).

      Bon en fait j'attends la version swarm de jami ;-)

      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  (site Web personnel) . Évalué à 5 (+3/-0).

      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)

      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.

  • # Mauvaise question...

    Posté par  (site Web personnel) . Évalué à 10 (+14/-2).

    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.

    Et si l'erreur c'était ça ? Combien de personnes choisisse un véhicule pour le moteur qu'il y a sous le capot ? Un smartphone pour son processeur ? Réponse : 1% (je l'accord, c'est une state au doigt mouillé).

    Je pense que XMPP a eu sa chance de devenir un protocole fédérateur, y est presqu'arrivé, mais que cela n'a malheureusement pas abouti. Je pense notamment à Google ou Facebook qui ont, pendant un temps, supporté XMPP avant de l'abandonner.

    Les problèmes de récupération et de transfert de données sont bien moins vrai aujourd'hui qu'il y a ne serait-ce que 2 ans (merci le RGPD !).

    Le problème de XMPP du point de vue utilisateur lambda, c'est qu'il faut faire, au minimum, 2 choix :
    - le logiciel à utiliser (et il y en a pléthore)
    - le serveur sur lequel sera héberger notre compte (et potentiellement, pour les plus geek, installer ce-dit serveur).

    Ce sont 2 questions de trop pour la plupart des gens. Quand on leur dit, je suis sur Signal, rejoins moi, les gens ne se posent pas la question de savoir quel logiciel installer, ni où créer leur compte. C'est "naturel".

    • [^] # Re: Mauvaise question...

      Posté par  . Évalué à 1 (+1/-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  (site Web personnel) . Évalué à 7 (+10/-5).

      Le problème de XMPP du point de vue utilisateur lambda, c'est qu'il faut faire, au minimum, 2 choix :
      - le logiciel à utiliser (et il y en a pléthore)
      - le serveur sur lequel sera héberger notre compte (et potentiellement, pour les plus geek, installer ce-dit serveur).

      Ce sont 2 questions de trop pour la plupart des gens. Quand on leur dit, je suis sur Signal, rejoins moi, les gens ne se posent pas la question de savoir quel logiciel installer, ni où créer leur compte. C'est "naturel".

      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  . Évalué à 8 (+7/-1). Dernière modification le 30/01/21 à 14:34.

      Et si l'erreur c'était ça ? Combien de personnes choisisse un véhicule pour le moteur qu'il y a sous le capot ? Un smartphone pour son processeur ? Réponse : 1% (je l'accord, c'est une state au doigt mouillé).

      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  . Évalué à 3 (+1/-0).

        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 ?

        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  (site Web personnel) . Évalué à 6 (+3/-0).

      Combien de personnes choisisse un véhicule pour le moteur qu'il y a sous le capot ?

      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 :-)

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Mauvaise question...

        Posté par  . Évalué à 2 (+1/-1).

        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  (site Web personnel) . Évalué à 10 (+8/-0).

    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  (site Web personnel) . Évalué à 9 (+9/-2).

      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  (site Web personnel) . Évalué à 5 (+3/-0).

        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  . Évalué à 5 (+5/-1).

      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.

  • # Matrix vs XMPP

    Posté par  . Évalué à 6 (+6/-1).

    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  (site Web personnel) . Évalué à 5 (+4/-1).

      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  . Évalué à 4 (+1/-0).

        Maintenant, si les gens insistent pour utiliser des clients et/ou serveurs pas mis à jour depuis le siècle dernier, on y peut quoi?

        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  . Évalué à 1 (+1/-1). Dernière modification le 01/02/21 à 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  . Évalué à 3 (+2/-1).

          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.

          Ce commentaire passe-t-il les trois tamis de Socrate ? -- je ne moinsse pas les conversations auxquelles je participe

          • [^] # Re: Matrix vs XMPP

            Posté par  . Évalué à 4 (+3/-1). Dernière modification le 01/02/21 à 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  . Évalué à 3 (+2/-0).

              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 ?

              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  (site Web personnel) . Évalué à 4 (+2/-0).

              un core obligatoire minimaliste et une multitude d'options

              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  . Évalué à 3 (+1/-0). Dernière modification le 02/02/21 à 10:28.

                Comme le noyau Linux ? Je croyais que faire des monolithes, c'était mal :)

                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.

                Pour avoir monté un serveur XMPP […] j'étais déjà à plus de 80% des tests de compliance.

                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  (site Web personnel) . Évalué à 7 (+6/-1). Dernière modification le 02/02/21 à 13:40.

      • 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

      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 ?

      • 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.

      Ç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  . Évalué à -2 (+0/-3).

        Ç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.

        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 …

        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é ?

        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  (site Web personnel) . Évalué à 4 (+3/-1). Dernière modification le 02/02/21 à 15:57.

          Tu dis toi même qu'il faut que les 2 clients implémentent les mêmes XEP, et au moins pour certaines,

          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 ?

          Me semble difficile de commencer ta phrase par un simple "ça c'est faux" du coup.

          Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.

          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 …

          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  . Évalué à -3 (+0/-4).

            Si ce qui est affirmé plus haut est faux, et je le démonte dans mon commentaire.

            À 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  (site Web personnel) . Évalué à 3 (+2/-0).

    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  (site Web personnel) . Évalué à 2 (+0/-0).

      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  (site Web personnel) . Évalué à 2 (+0/-0).

      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  (site Web personnel) . Évalué à 2 (+1/-0).

        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  (site Web personnel) . Évalué à 2 (+0/-0).

          Si j'utilise une allow list, qu'est-ce que je mets dedans ? Ça revient presque à désactiver la fédération.

          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  (site Web personnel) . Évalué à 3 (+1/-0).

      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  (site Web personnel) . Évalué à 3 (+2/-0).

        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  (site Web personnel) . Évalué à 3 (+1/-0).

          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 ?

          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  (site Web personnel) . Évalué à 3 (+1/-0).

          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.

          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

          De plus, alors que les utilisateurs acceptent de recevoir de temps à autre du spam dans leur boîte mail

          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.

Envoyer un commentaire

Suivre le flux des commentaires

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