Matrix pour décentraliser Skype, Whatsapp, Signal, Slack et Discord

• # cool

  Posté par fwhcat le 20 juillet 2017 à 20:45. Évalué à 3.

  

  Salut,

  article bien détaillé.

  On croise les pieds pour que ça ait plus de succès que le défunt XMPP ^{^} (troll inside).

  • [^] # Re: cool

    Posté par SaintGermain le 20 juillet 2017 à 20:48. Évalué à 4.

    

    Est-ce une coïncidence que la dépêche soit publiée presque un vendredi ?
    Je m'attends à ce que cela trolle bien fort en tout cas. ;-)

• # Grosse limitation à la fédération

  Posté par Maclag le 20 juillet 2017 à 22:35. Évalué à 10.

  

  Les 2 premiers commentaires spéculent sur l'arrivée d'une question trollesque, alors je vais mettre les pieds dans le plat, comme ça ce sera fait.

  Je ne commenterai pas trop sur le protocole lui-même. En tant qu'utilisateur final, le protocole, je ne le comprends pas plus que celui de XMPP. Ce qui m'intéresse c'est ce qu'on arrive à faire avec.
  Je commenterai donc plus l'expérience utilisateur et administrateur.

  Le client Riot est effectivement très abouti compte tenu de son jeune âge, et est plutôt efficace. J'apprécie particulièrement la recherche de salon intégrée qui permet de chercher sur son propre serveur et sur matrix.org simplement et les appels vidéo qui marchent de n'importe quelle plateforme à n'importe quelle plateforme (tant qu'on reste en 1:1 pour l'instant, ce qui n'est pas si mal).

  Mais côté administrateur…
  Je loue un modeste Kimsufi sur lequel j'ai installé Yunohost. J'utilise Movim, Nextcloud, Rainloop, et Riot, avec le serveur Synapse qui va bien.
  Au moment où j'écris, ils sont tous à leur charge habituelle, c'est-à-dire:

  Quasiment négligeable pour tout le monde, sauf Synapse qui prend 100% du CPU d'un coeur et 40% de la RAM à lui tout seul!
  Et ça, c'est sans rejoindre un gros salon.
  J'ai essayé une fois de rejoindre le salon "HQ Matrix".
  Jamais réussi à avoir l'affichage du salon sur Riot. Le serveur était à genoux.

  J'ai eu un mal de chien à quitter le salon aussi: j'avais des messages d'erreur à répétition.

  En demandant sur le salon Yunohost, heureusement moins fréquenté, j'ai appris que je suis un privilégié: il y a belle lurette que d'autres serveurs "pas assez puissants" n'arrivent même plus à accéder à la liste de salons publics du serveur matrix.org, donc il ne peuvent plus y faire de recherche d'autres salons!

  Et c'est bien le problème de Matrix: si vous voulez accéder à tous les salons, il FAUT ABSOLUMENT avoir un serveur bien calibré! Chaque salon est répliqué sur tous les serveurs ayant au moins un participant, et il semble qu'ils passent leur temps à se synchroniser les-uns aux-autres. Quand il y en a 3 impliqué dans le salon, c'est pas un souci. Quand il y en a plusieurs milliers, il faut tenir la cadence!

  J'ai donc cherché une discussion ou un rapport de bug pour savoir quelle serait la solution à ce problème, et j'ai trouvé!
  https://github.com/matrix-org/synapse/issues/2255

  Résumé: il suffit que l'administrateur interdise purement et simplement à ses utilisateurs de se connecter à des salons trop fréquentés!
  Et c'est proposé par l'un des deux principaux instigateurs de Matrix!

  Et c'est pour moi une forte incitation à recentraliser les utilisateurs sur le plus gros serveur disponible.
  Imaginons que le nombre de participants au salon HQ Matrix ne cesse de grandir, à la fin: il ne restera qu'une poignée de serveurs capables d'y accéder?

  Matrix dans sa version actuelle est un réseau destiné à tourner à plusieurs vitesses:
  -les gros serveurs populaires
  -les petits serveurs mis à l'écart

  • [^] # Re: Grosse limitation à la fédération

    Posté par SaintGermain le 20 juillet 2017 à 22:52. Évalué à 4.

    

    Bizarre j'ai aussi un tout petit kimsufi et cela tourne sans problème je n'ai pas tenté de joindre Matrix HQ cependant, je ne suis pas fou !).
    Est-ce que tu as bien réglé le paramètre SYNAPSE_CACHE_FACTOR ?

    En tout cas, le nouveau serveur Dendrite semble beaucoup plus efficace. C'est une des priorités importantes du projet (ils en parlent encore dans leur dernier post sur leur blog)

    • [^] # Re: Grosse limitation à la fédération

      Posté par Maclag le 21 juillet 2017 à 01:18. Évalué à 4.

      

      Je ne dis pas que ça tourne mal, je dis que ça tourne "fort" avant même de participer à des gros salons. La plupart du temps je n'ai aucun souci avec.

      Si tu fais un petit htop sur ton serveur, tu pourrais être surpris.

      Même si Dendrite est plus efficace, je reste sceptique sur la réplication systématique de tous les salons. Dans le post que tu cites, ils parlent de développer Dendrite, ils ne disent absolument pas si ça résoudra le problème pour les petits serveurs.

      • [^] # Re: Grosse limitation à la fédération

        Posté par SaintGermain le 21 juillet 2017 à 08:33. Évalué à 3.

        

        Voici mon htop (Atom N2800 avec 4 Go de RAM):
        

        Mais bon effectivement je ne l'utilise pas beaucoup, on est juste 3 utilisateurs pour l'instant. Cela m'étonne quand même que cela mette à genoux ton Kimsufi.

        Tu peux faire toi aussi un htop et me dire dans quel contexte tu l'utilises (combien d'utilisateurs, quel genre de salon) ?

        Sinon pour Dendrite, je crois avoir lu qu'ils ont constaté des gains de performance (à configuration égale je suppose) de 300x. Donc oui cela devrait améliorer les choses pour les petites machines.

        • [^] # Re: Grosse limitation à la fédération

          Posté par Maclag le 21 juillet 2017 à 16:26. Évalué à 7. Dernière modification le 21 juillet 2017 à 16:28.

          

          Mon serveur tourne aussi sur un N2800, et j'ai 2Go de RAM.

          Il y a 4 comptes sur mon serveur, mais apparemment je suis le seul qui ait jamais lancé un client!

          J'ai fait quelques tests ce matin:
          -J'avais un salon en bridge sur IRC, ~200 utilisateurs (mais je ne sais pas si ça compte les utilisateurs IRC, ni l'impact)
          -J'avais un salon avec un nombre décent d'utilisateur (>1200), je ne sais pas combien de serveurs impliqués
          -Un autre salon ~100 utilisateurs

          Charge CPU initiale: tombée à "seulement" 37%
          Empreinte Mémoire: 42%

          J'ai ensuite tenté de quitter presque tous les salons:
          -J'ai dû m'y prendre à 4 reprises pour quitter le salon IRC à 200 utilisateurs. J'avais des erreur "CORS"
          -J'ai dû m'y prendre à une bonne dizaine de reprises pour le salon à 1200 utilisateurs. Je pense qu'un utilisateur lambda aurait conclu plus tôt que c'est impossible de le quitter. Pendant que j'essaie de le quitter, le CPU est monté à 114%
          -Les autres salons n'ont pas posé de problème

          J'ai maintenant uniquement le salon Yunohost, <100 utilisateurs, un salon pour utilisateurs internes (donc avec rien dedans, vu que les autres ne se sont jamais connectés), et RIEN d'autre.

          Charge CPU: oscille entre 0.9% et 37% depuis que je la surveille (quelques minutes)
          EDIT: Emprunte Empreinte mémoire: 42%
          [c'est promis, je vais lui rendre la mémoire empruntée…]

          Je vais avoir du mal à comparer avec mon usage XMPP parce que je ne pense pas qu'aucun salon soit si gros, mais j'ai:
          le salon jabberfr sur le serveur éponyme
          le salon officiel de Movim
          le salon officiel de SàT
          le salon XSF sur le serveur xmpp.org
          le salon de support de Yunohost
          les 3 autres utilsateurs (très faible activité)
          je suis abonné à divers noeuds pubsub, mais je ne croule pas sous les publications

          Metronome est à 0.0 sur le CPU (négligeable) et 0.5% sur la RAM
          Movim (le démon PHP) est à 0.0% sur le CPU et 1.0% sur la RAM

          Si quelqu'un m'indique un gros salon XMPP fait pour tester la charge, je prends.

          • [^] # Re: Grosse limitation à la fédération

            Posté par SaintGermain le 21 juillet 2017 à 16:40. Évalué à 0.

            

            Tu ne veux pas aller faire un tour sur le salon LinuxFR pour éviter de polluer la discussion ici ?
            Ce serait plus pratique.

            Sinon tu as changé le paramètre SYNAPSE_CACHE_FACTOR ? Cela devrait améliorer les choses pour la RAM (pour peu que tu ne fréquentes pas des salons trop fréquentés).

            Sinon au niveau de la charge CPU, c'est vraiment bizarre comparé à ce que j'ai. Pour moi tant que je ne fais rien, c'est vraiment presque à zéro tout le temps. Il faudrait enlever ton salon Yunohost pour voir si c'est le cas pour toi aussi (je ne peux malheureusement pas aller sur le salon Yunohost car j'essaye de garder mon serveur hors du réseau de fédération, tant que je n'ai pas fini mes tests).

            • [^] # Re: Grosse limitation à la fédération

              Posté par ZeroHeure le 08 août 2017 à 17:44. Évalué à 3.

              

              L'intéret des commentaires c'est d'apporter de l'info. Ça ne pollue en rien!

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Grosse limitation à la fédération

                Posté par SaintGermain le 08 août 2017 à 18:54. Évalué à 0.

                

                Désolé, mais les commentaires ne sont pas le meilleur endroit pour résoudre un problème technique.
                Je doute que cela intéresse grand monde si on commence à poster des logs.

                À la limite, on peut revenir ensuite pour poster la conclusion. Mais de toute façon maclag ne semble pas trop intéressé par la résolution de son problème (j'ai posé deux fois la question pour le SYNAPSE_CACHE_FACTOR, pas eu de réponse).

                • [^] # Re: Grosse limitation à la fédération

                  Posté par Maclag le 09 août 2017 à 00:30. Évalué à 5.

                  

                  À la limite, on peut revenir ensuite pour poster la conclusion. Mais de toute façon maclag ne semble pas trop intéressé par la résolution de son problème (j'ai posé deux fois la question pour le SYNAPSE_CACHE_FACTOR, pas eu de réponse).

                  Paradoxal:
                  Tu me demandes de ne pas poster ici puis tu me reproches de ne pas avoir posté.

                  Ben pour ton info, j'ai essayé toutes les valeurs de 0.1 à 0.5, sans succès (et je n'ai pas les logs ni les détails, parce que là pour moi ça date déjà un peu).

                  Je me suis déjà pointé plusieurs fois sur le salon linuxfr et n'y ai vu personne (peut-être à cause du décalage horaire, je suis en Amérique du Nord).

                  De ton côté tu as écrit explicitement que tu n'as pas de problème, mais…

                  je ne peux malheureusement pas aller sur le salon Yunohost car j'essaye de garder mon serveur hors du réseau de fédération, tant que je n'ai pas fini mes tests

                  Tu ne crois pas que c'est une utilisation très particulière et particulièrement réductrice de ton serveur? C'est ce que tu utilises comme référence pour me dire que ce que j'ai moi est anormal?

                  • [^] # Re: Grosse limitation à la fédération

                    Posté par SaintGermain le 09 août 2017 à 08:32. Évalué à 0.

                    

                    Paradoxal: Tu me demandes de ne pas poster ici puis tu me reproches de ne pas avoir posté.

                    Je poste ici vu que personne ne t'a vu sur le salon Matrix linuxfr (pas de maclag) et que tu continues à poster ici.

                    Je me suis déjà pointé plusieurs fois sur le salon linuxfr et n'y ai vu personne (peut-être à cause du décalage horaire, je suis en Amérique du Nord).

                    Tu es un peu gonflé je trouve, cela ne donne pas vraiment envie de t'aider.
                    Tu crois quoi ? Que l'on est plusieurs en hotline à attendre que tu te connectes pour t'aider en direct ? Tu te connectes sur le salon, tu ne vois personne et tu repars vexé sans même poser ta question en te disant que c'est nul et que personne ne veut t'aider ?

                    Pour info c'est comme IRC ou une liste de diffusion, tu poses ta question et tu attends patiemment que quelqu'un réponde. Astuce (par forcément nécessaire) tu peux poser ta question directement à quelqu'un (moi par exemple) et je reçois un email qui me préviens que quelqu'un s'est adressé à moi (c'est assez chouette et je ne sais pas si c'est possible avec IRC).

                    Ben pour ton info, j'ai essayé toutes les valeurs de 0.1 à 0.5, sans succès (et je n'ai pas les logs ni les détails, parce que là pour moi ça date déjà un peu).

                    Il faudrait avoir la consommation mémoire en fonction du facteur SYNAPSE_CACHE_FACTOR. Normalement cela devrait avoir un impact sur la RAM utilisée. Sinon ce n'est pas normal et il faut ouvrir un bogue.

                    Il faudrait enlever ton salon Yunohost pour voir si c'est le cas pour toi aussi (je ne peux malheureusement pas aller sur le salon Yunohost car j'essaye de garder mon serveur hors du réseau de fédération, tant que je n'ai pas fini mes tests […]

                    Tu ne crois pas que c'est une utilisation très particulière et particulièrement réductrice de ton serveur? C'est ce que tu utilises comme référence pour me dire que ce que j'ai moi est anormal?

                    Je ne sais pas si tu fais exprès d'être si peu accommodant ? Je n'ai pas de contrat de maintenance avec toi et en plus je n'ai rien à voir avec l'équipe Matrix, je suis juste un gars qui essaye de t'aider et tu m'envoies bouler car je ne peux/veux pas avoir exactement la même configuration que toi.

                    Pour déboguer, il faudrait que l'on ait une configuration un peu similaire. Le plus simple (c'est un peu la base en débogage) est de partir d'une configuration de base (sans extensions, sans salon, sans rien) et de voir où l'on se trouve déjà. Ensuite on peu rajouter petit à petit des éléments et voir où cela coince.

                    De plus je ne suis pas le seul sur le salon linuxfr a faire tourner un Synapse. Donc d'autres sont sur des salons aussi chargés voire plus que Yunohost et n'ont pas de problèmes. Ces personnes aussi peuvent t'aider.
                    Par exemple erdnaxeli (commentaire tout en bas de cette page) tourne aussi avec un kimsufi, est abonné à Matrix HQ (10 000 personnes environ) et n'a pas de problème.

                    • [^] # Re: Grosse limitation à la fédération

                      Posté par Maclag le 09 août 2017 à 16:12. Évalué à 5.

                      

                      Tu es un peu gonflé je trouve, cela ne donne pas vraiment envie de t'aider.

                      Euh, mais je ne t'ai pas demandé de m'aider. Je dis que les petits serveurs ont des limitations, apparemment reconnues par le concepteur qui propose de carrément brider les serveurs, et c'est toi qui vient dire ici que c'est certainement que MON serveur est mal configuré, puis qu'il vaudrait mieux que je poste mes problèmes ailleurs, et circulez y'a rien à voir!

                      Tu crois quoi ? Que l'on est plusieurs en hotline à attendre que tu te connectes pour t'aider en direct ? Tu te connectes sur le salon, tu ne vois personne et tu repars vexé sans même poser ta question en te disant que c'est nul et que personne ne veut t'aider ?

                      Je ne crois rien du tout. Je n'attendais pas grand chose, et au cas où tu lirais mal: je ne me suis pas plains du manque de réponse, je n'ai écrit nulle part "c'est nul", j'ai juste dit que je n'ai vu personne sur le salon.

                      D'ailleurs je commence à me demander si nous parlons du même: quand je cherche un salon linuxfr sur matrix.org, je ne trouve justement que le salon IRC sur Freenode.

                      Pour info c'est comme IRC ou une liste de diffusion, tu poses ta question et tu attends patiemment que quelqu'un réponde. Astuce (par forcément nécessaire) tu peux poser ta question directement à quelqu'un (moi par exemple) et je reçois un email qui me préviens que quelqu'un s'est adressé à moi (c'est assez chouette et je ne sais pas si c'est possible avec IRC).

                      Dernière activité sur ce que je vois: Mardi 25 juillet. Échange entre 2 personnes pour savoir si le salon était mort.
                      Ça doit être les vacances (et ça n'est un reproche à personne).

                      Je ne te reproche pas de ne pas résoudre mon problème. Ce que je te reproche, c'est ça:

                      Tu ne veux pas aller faire un tour sur le salon LinuxFR pour éviter de polluer la discussion ici ?
                      Ce serait plus pratique.

                      Mais de toute façon maclag ne semble pas trop intéressé par la résolution de son problème (j'ai posé deux fois la question pour le SYNAPSE_CACHE_FACTOR, pas eu de réponse).

                      Alors bon:

                      Je ne sais pas si tu fais exprès d'être si peu accommodant ? Je n'ai pas de contrat de maintenance avec toi et en plus je n'ai rien à voir avec l'équipe Matrix, je suis juste un gars qui essaye de t'aider et tu m'envoies bouler car je ne peux/veux pas avoir exactement la même configuration que toi.

                      Tu es juste un gars qui écrit d'abord que mes problèmes sont certainement dus à ma config parce que chez toi, l'empreinte mémoire est faible, alors qu'en réalité tu n'es pas sur la fédération, tu me demandes ensuite de ne plus poster mes problèmes ici, mais tu te permets de revenir dire que je ne suis pas intéressé par la solution parce que je ne poste plus ici.

                      Tu ne fais peut-être pas partie de l'équipe Matrix, mais tu sembles quand même bien déterminé à en cacher les problèmes.

                      Je rappellerai encore une fois que les concepteurs de Matrix, eux, semblent trouver mes problèmes normaux. On propose de brider les utilisateurs sur les petits serveurs parce qu'un gros salon mettra le serveur à genoux, et on nous dit d'attendre Dendrite.

                      C'est bien toi qui tente de convaincre que le problème, ça ne peut être autre chose que mes réglages, avec une motivation qui m'échappe.

                      De plus je ne suis pas le seul sur le salon linuxfr a faire tourner un Synapse. Donc d'autres sont sur des salons aussi chargés voire plus que Yunohost et n'ont pas de problèmes. Ces personnes aussi peuvent t'aider.

                      Le salon Yunohost n'est pas un gros salon, loin de là.

                      Par exemple erdnaxeli (commentaire tout en bas de cette page) tourne aussi avec un kimsufi, est abonné à Matrix HQ (10 000 personnes environ) et n'a pas de problème.

                      Effectivement:

                      Et concernant les problème de perf, ça tourne sur un kimsufi à 15€/mois (certes c'est pas le 1er à 2€ par mois) sans aucun soucis, même en rejoignant des grosses rooms comme Matrix HQ (et j'utilise toujours SQLite…). Par contre sur un raspberry pi c'est sûr que ça va galérer.

                      Il semble bien confirmer qu'il faut un serveur suffisamment gros. Un petit serveur ne peut donc pas accéder aux gros salons.
                      C'est une limitation qui est tout simplement avérée.

                      Tu vas l'admettre ou écrire encore et encore que je suis le problème?

                      • [^] # Re: Grosse limitation à la fédération

                        Posté par SaintGermain le 09 août 2017 à 16:41. Évalué à 0.

                        

                        et c'est toi qui vient dire ici que c'est certainement que MON serveur est mal configuré

                        Je n'ai jamais dit cela. Je pense que tu l'as rêvé. J'ai juste trouvé cela bizarre et je cherchais à t'aider pour voir si on arrivait à trouver le soucis. Mais si tu viens juste ici râler sans vouloir l'aide de quiconque, tant mieux, je m'abstiens.

                        puis qu'il vaudrait mieux que je poste mes problèmes ailleurs

                        Oui les commentaires ici ne sont pas le meilleur endroit pour résoudre un problème technique.

                        D'ailleurs je commence à me demander si nous parlons du même: quand je cherche un salon linuxfr sur matrix.org, je ne trouve justement que le salon IRC sur Freenode.

                        Je n'avais pas entré le salon linuxfr dans l'annuaire, c'est ma faute (depuis corrigé). Cependant l'adresse est donnée dans le premier paragraphe.

                        Tu es juste un gars qui écrit d'abord que mes problèmes sont certainement dus à ma config parce que chez toi, l'empreinte mémoire est faible, alors qu'en réalité tu n'es pas sur la fédération, tu me demandes ensuite de ne plus poster mes problèmes ici, mais tu te permets de revenir dire que je ne suis pas intéressé par la solution parce que je ne poste plus ici.

                        Encore une fois tu l'as rêvé, je n'ai jamais dit que tes problèmes sont certainement dus à ta config. J'ai juste trouvé cela bizarre et je proposais de t'aider à résoudre le problème.
                        Ensuite pour t'aider plus efficacement, je propose de t'aider sur le salon, car dans les commentaires c'est plus compliqué.
                        Il faut arrêter de voir le mal partout.

                        Il semble bien confirmer qu'il faut un serveur suffisamment gros. Un petit serveur ne peut donc pas accéder aux gros salons.
                        C'est une limitation qui est tout simplement avérée.

                        Un kimsufi à 15 euros par mois, il n'y a que des Atom N2800 à 4Go de proposé.
                        Ton serveur c'est un N2800 avec 2 Go de proposé.

                        Donc ton serveur c'est un PETIT serveur et le sien c'est un GROS serveur c'est ça ?

                        Tu vas l'admettre ou écrire encore et encore que je suis le problème?

                        Tu as juste gagné que je ne vais certainement pas t'aider maintenant. Tu es le bienvenu sur le salon, mais ce n'est pas moi qui vais t'aider.
                        C'est vraiment des commentaires comme le tien qui ne me donne plus envie du tout de proposer des dépêches ou d'aider les gens.

  • [^] # Re: Grosse limitation à la fédération

    Posté par freem le 21 juillet 2017 à 09:35. Évalué à 10.

    

    Si j'ai bien compris, tu peux dire "J'ai un serveur kimsufipa", c'est ça?

  • [^] # Re: Grosse limitation à la fédération

    Posté par Amandine le 29 juillet 2017 à 20:45. Évalué à 2.

    

    En effet Synapse n'est pas le serveur le plus efficace, un PoC devenu produit… Le serveur deuxième generation 'Dendrite' est mieux pensé et sera plus adapté. https://github.com/matrix-org/dendrite

    • [^] # Re: Grosse limitation à la fédération

      Posté par Sufflope (site web personnel) le 30 juillet 2017 à 00:15. Évalué à 2.

      

      On appelle ça un MVP maintenant :-D

      • [^] # Re: Grosse limitation à la fédération

        Posté par freem le 02 août 2017 à 15:17. Évalué à 2.

        

        Amusant. Du coup, on peut dire que Microsoft à été en avance sur leur temps, quand ils ont sorti Windows 98 et Windows Millenium?

• # Excellent article, bravo!

  Posté par Ririsoft le 20 juillet 2017 à 22:58. Évalué à 4.

  

  Bravo et merci pour cet article. La bonne dose de détails, une prise de recule, une mise en perspective. Un des meilleurs articles de l'année sans aucun doute.

  • [^] # Re: Excellent article, bravo!

    Posté par SaintGermain le 20 juillet 2017 à 23:09. Évalué à 8.

    

    Merci ! ;-)

    Mais j'ai repris quand même pas mal d'informations sur les sites de Matrix et Riot, donc le mérite revient aussi et surtout à eux.
    Donc si l'article vous plaît, essayez de leur verser une petite obole.

    Un truc que j'ai oublié de préciser et qui me semble très important : si vous vous engagez à leur verser de l'argent (via Patreon ou Liberapay), vous aurez accès à un support privilégié (entre autres choses).

    C'est personnellement la première fois que je vois cela dans le logiciel libre (donations récurrentes + support privilégié) et je trouve l'idée à première vue assez bonne.

• # Logo de Matrix en introduction

  Posté par M5oul (site web personnel) le 21 juillet 2017 à 00:43. Évalué à 2.

  

  J’y pense : ça serait bien qu’il y ait le logo de Matrix (pas le film, hein !) en dessus de l’introduction.

  • [^] # Re: Logo de Matrix en introduction

    Posté par SaintGermain le 21 juillet 2017 à 11:11. Évalué à 2.

    

    Bonne remarque. Est-ce qu'un modérateur pourrait remplacer le logo par celui-ci (provenant de matrix.org) :
    

    • [^] # Re: Logo de Matrix en introduction

      Posté par Benoît Sibaud (site web personnel) le 21 juillet 2017 à 11:30. Évalué à 4.

      

      Corrigé, merci.

      • [^] # Re: Logo de Matrix en introduction

        Posté par SaintGermain le 21 juillet 2017 à 11:31. Évalué à 1.

        

        Merci, je voyais plutôt cela comme icône (celui en haut à gauche), mais cela va aussi comme cela !

• # chiffrage !!?

  Posté par Naabster le 21 juillet 2017 à 07:08. Évalué à 5.

  

  Le chiffrage, c’est évaluer le coût de quelque chose, il n'y a aucun, mais vraiment aucun rapport avec le chiffrement…

  • [^] # Re: chiffrage !!?

    Posté par SaintGermain le 21 juillet 2017 à 07:25. Évalué à 2.

    

    Oui tu as tout à fait raison, si un modo pouvait corriger…

  • [^] # Re: chiffrage !!?

    Posté par Benoît Sibaud (site web personnel) le 21 juillet 2017 à 08:10. Évalué à 4.

    

    Corrigé, merci.

• # Point de vue d'un développeur XMPP

  Posté par Goffi (site web personnel, Mastodon) le 21 juillet 2017 à 12:04. Évalué à 10.

  

  Salut,

  bon malgré mes vacances je reste un peu en ligne :). Merci pour cette dépêche détaillée.

  Je vais donner mon point de vue d'un dév très impliqué dans XMPP, comme les lecteurs réguliers de ce site le savent peut-être.

  Côté technique, je pense que le projet est intéressant, mais pas exceptionnel. La réplication des données risque de poser un problème de mise à l'échelle (ce qui semble se confirmer en lisant cette dépêche et par des échos que j'ai eu de gens ayant des difficultés à joindre des gros salons sur des petites machines type Raspberry Pi), et je ne vois rien qui ne pourrait être implémenté avec XMPP.

  Mais côté forme, c'est un des rares, et je pense même le seul projet contre lequel j'ai une dent, et je pousse pourtant à la coopération entre les projets libres. La raison est simple, pour se faire connaître, et dès le début (j'ai connu Matrix à leur présentation lors de leur premier FOSDEM) ils ont cherché à taper sur XMPP et sa communauté. Attention, je n'ai rien contre les critiques techniques (j'en fais moi-même, XMPP a ses défauts comme tout), mais là on a vraiment eu le sentiment qu'il fallait essayer d'appuyer sur la tête du voisin pour nager à la surface, et c'est le seul projet qui m'a donné ce sentiment malgré les tonnes de projets existants, ce qui a eu des effets jusqu'ici même. Et avec leur budget marketing qui semble très important, cela a provoqué une ambiance délétère dont on se serait bien passé.

  Maintenant que ce projet commence à être connu, la situation s'est nettement améliorée, mais ce n'est pas tout à fait fini pour autant, leur FAQ en particulier, qui a pourtant déjà été complétée suite à une réponse de la communauté, reste un cas d'école de mauvaise foi. Je l'ai déjà fait remarquer, on m'a promis de le corriger, mais force est de constater que c'est toujours là.

  Sur le plan politique (qu'on oublie un peu trop souvent), j'attends de voir ce que ça va donner.

  Enfin pour la comparaison avec XMPP, il est absolument ridicule de comparer les fonctionnalités avec la base RFC de XMPP. les RFCs sont volontairement très réduites et minimales, et toutes les extensions (et non la plupart) sont optionnelles. C'est une force et certainement pas une faiblesse. XMPP a bien plus de fonctionnalités que Matrix.

  XMPP est capable de négocier les fonctionnalités disponibles et de s'adapter. Il est évident qu'un client XMPP qui se concentre sur, disons, le partage de fichier, n'a pas forcément besoin des fonctionnalités de blogage.

  Aujourd'hui le nombre de serveurs et de clients est réduit pour Matrix, ou du moins se base sur un nombre réduit d'implémentations (je n'ai pas vérifié, mais je ne serais pas étonné que les clients bureau/téléphone soient des ports de la version web à coups d'Electron ou similaire). On en reparlera si le succès est là et que les implémentations se multiplient, il y aura inévitablement des problèmes de compatibilité et de fonctionnalités non implémentées ou implémentées un peu différemment.

  Bref, encore une fois je n'ai rien contre la technologie elle-même, et je souhaite qu'on puisse communiquer entre les différents protocoles, mais diplomatiquement ils ont très mal commencé et ça a l'air de se tasser (même si on attend toujours pour la FAQ). À mon sens (forcément biaisé), ça n'apporte strictement rien par rapport à XMPP, c'est un énorme désavantage de ne pas avoir le système d'extensions, et cela semble lourd à l'usage (à voir ce que ça va donner avec Dentrite). Par contre leur logiciel a l'air léché ce qui est une bonne chose et sans doute la raison du succès (avec la com). Ceci dit, une dizaine de dév à plein temps (jusqu'ici) c'est énorme, et ça explique le résultat rapide.

  En comparaison, un projet comme Movim, certes plus ancien, a été fait par principalement une seule personne sur son temps libre, et je n'ai pas l'impression qu'il a beaucoup à envier.

  • [^] # Re: Point de vue d'un développeur XMPP

    Posté par SaintGermain le 21 juillet 2017 à 12:50. Évalué à 4.

    

    Je trouve que c'est quand même un point fondamental (pourquoi Matrix n'est par parti de XMPP) que je suis personnellement incapable d'expliquer correctement.
    J'avoue que je me sentais un peu incompétent à écrire le passage sur XMPP donc j'ai tout simplement recopié ce qui était écrit dans leur FAQ. Mais cela me semblait important d'écrire quelque chose sur XMPP plutôt que rien. J'aurais peut-être dû contacter un dev de XMPP pour m'aider, désolé.

    Cependant même après ton message, il me semble que la différence fondamentale est bien que Matrix intègre (kitchen sink…) à la base beaucoup plus que XMPP ? Et du coup est clairement moins flexible au niveau des extensions ?
    Cela me rappelle un peu le débat micro-noyau et noyau monolithique.

    En tout cas j'ai jeté un oeil vite fait, et rien ne semble avoir bougé sur leur FAQ au niveau de XMPP depuis un moment. Un point que je ne comprends pas très bien, c'est pourquoi tu te refuses à proposer un changement (pull request) pour leur FAQ ?
    C'est je trouve assez constructif de leur part, d'essayer d'expliquer les différences avec XMPP. Et c'est risqué car du coup ils s'exposent aux critiques si ce n'est pas parfait (seuls ceux qui ne font rien ne font jamais d'erreurs).

    De mon point de vue, je vois deux approches : ou bien du côté XMPP vous faites aussi une FAQ pour expliquer les différences avec Matrix (et là vous allez voir les fanboys de Matrix rappliquer avec leurs critiques) ou bien vous mettez à jour leur FAQ pour corriger ce qui est faux.

    J'aurais bien proposé mon aide pour mettre à jour la FAQ, mais cela me semble vraiment très pointu techniquement.

    • [^] # Re: Point de vue d'un développeur XMPP

      Posté par Maclag le 21 juillet 2017 à 14:07. Évalué à 6.

      

      Je peux comprendre pourquoi on peut être tenté de repartir de zéro plutôt que de XMPP:
      1. XMPP n'est pas exempt de défauts, d'après le consensus général
      2. Il semble très difficile d'y faire bouger les choses, et maintenant que je suis un peu plus les discussions sur le salon XMPP, ça semble être une autre frustration largement partagée
      3. Ça ne peut plus faire un buzz monstre parce que ça ne sera pas nouveau

      Mais je pense que ce sont toutes de mauvaises raisons:
      1. Je ne pense pas que quiconque créera jamais un protocole parfait. XMPP a l'avantage de l'ancienneté. On apprend pas d'un projet en regardant le résultat qui marche, mais en regardant quels problèmes ont été rencontrés et comment on en est arrivé à la solution retenue. Du coup avoir l'expérience d'un dév qui utilise différents protocoles n'est peut-être pas aussi pertinent qu'un dév qui définit et affine un protocole pendant des années
      2. Avec un poids suffisant, quand les XEP se perdent dans les débats sans avancer, on peut implémenter des fonctions expérimentales sans demander aux autres. Il faut juste s'assurer de les mettre à jour pour suivre ce qui deviendra le standard. Je vois plus ça comme une question de moyens. Google n'a pas attendu le standard pour déployer sa solution voix/vidéo à l'époque et ils ont bien fait!
      3. Mastodon est la référence du buzz fait sur un "vieux" protocole. Il suffit de ne pas en faire un argument phare.

      Bref: je pense qu'un client comme Riot avec les mêmes fonctionnalités et multiplateforme basé sur XMPP plutôt que Matrix aurait eu tout autant de succès.

      Maintenant, de mon point de vue, la messagerie instantanée, les salons et les appels audio et/ou vidéo marchent sur toutes les plateformes. C'est ma "base" indispensable et suffisante pour mon cas d'utilisation.
      Mais je ne militerai pas pour Matrix tant que le problème de l'accès aux gros salons par des petits serveurs ne fera pas partie des priorités.
      Et aujourd'hui, je ne vois qu'une proposition d'enterrer le problème par l'exclusion.

      • [^] # Re: Point de vue d'un développeur XMPP

        Posté par SaintGermain le 21 juillet 2017 à 14:29. Évalué à 2.

        

        Bref: je pense qu'un client comme Riot avec les mêmes fonctionnalités et multiplateforme basé sur XMPP plutôt que Matrix aurait eu tout autant de succès.

        Ça on ne le saura malheureusement jamais. C'est quand même très regrettable.

        Mais je ne militerai pas pour Matrix tant que le problème de l'accès aux gros salons par des petits serveurs ne fera pas partie des priorités.

        Je sais que cela parle beaucoup de Dendrite, et que la sortie ne devrait pas trop tarder. À voir si cela résout ton problème.
        Par contre tu as vu mon htop sur mon kimsufi ? Synapse n'est vraiment pas gourmand chez moi…

    • [^] # Re: Point de vue d'un développeur XMPP

      Posté par Goffi (site web personnel, Mastodon) le 21 juillet 2017 à 14:08. Évalué à 7.

      

      Mon message n'était absolument pas dirigé contre toi, je trouve ta dépêche très bien, et la comparaison est un sujet compliqué, parce qu'il faut bien connaître les 2 environnements (d'ailleurs je ne connais pas suffisamment bien Matrix pour faire une comparaison technique poussée, j'espère avoir le temps un jour de regarder de plus près). Et c'est un projet qui fait parler de lui, c'est une très bonne chose de faire des dépêches travaillées sur le sujet, donc merci :)

      Cependant même après ton message, il me semble que la différence fondamentale est bien que Matrix intègre (kitchen sink…) à la base beaucoup plus que XMPP ? Et du coup est clairement moins flexible au niveau des extensions ?
      Cela me rappelle un peu le débat micro-noyau et noyau monolithique.

      Je pense que le débat micro-noyau/monolithique est plutôt applicable au débat décentralisé client/server contre 100% P2P, parce qu'au niveau des fonctionnalités XMPP est justement proche du fonctionnement de Linux, avec un noyau dur (les RFCs), et des modules dynamiques (les extensions).

      Au niveau des différence fondamentales, il n'y en a pas tant que ça, le système de réplication est parfaitement adaptable à XMPP. XMPP utilise XML ce qui est critiqué par certains (à tort à mon avis) sur TCP (ou autre), Matrix utilise HTTP qui a sa lourdeur.
      XMPP a des recommandations par années (les « compliance suite »), qui permet d'avoir une base commune pour les clients « modernes ».

      Par contre sur le plan politique (c'est pour ça que j'ai dis que j'attendais de voir), XMPP a beaucoup d'entreprises/associations et de particuliers impliqués (certains avec un but lucratif d'autre non), un système (par parfait certes) d'élection, de « council » (conseil), et des règles écrites (par exemple, il ne peut pas y avoir plus d'un certain pourcentage de membres de la même entreprise, je n'ai pas le chiffre exact en tête).
      
      Matrix souhaite un chemin similaire d'après ce que j'ai compris, mais est développé par des membres issus d'une même entreprise, avec un financement privé, une influence et une prise de décision très concentrée, et un but probablement lucratif.

      Pour moi la différence se situe plutôt là que sur le plan technique.

      En tout cas j'ai jeté un oeil vite fait, et rien ne semble avoir bougé sur leur FAQ au niveau de XMPP depuis un moment. Un point que je ne comprends pas très bien, c'est pourquoi tu te refuses à proposer un changement (pull request) pour leur FAQ ?

      À l'époque je n'avais pas (et ne voulais pas) de compte Github. Entre temps j'ai dû en faire un pour mon travail salarié, et je me suis résigné à en faire un autre pour contribuer à titre personnel à des projets dessus (que j'ai appelé goffi_contrib pour bien spécifier que c'était uniquement pour la contribution).

      Je pense aussi que je suis trop biaisé pour modifier ça moi même, et que c'est à eux de le faire de toute façon. De la même façon je ne touche pas à la page Wikipédia de SàT parce que Wikipédia demande aux gens impliqués de ne pas le faire, et pourtant je regrette que cette page est quasiment vide et n'est pas à jour.

      Et aussi (surtout), je n'ai pas le temps pour ce genre de choses annexe, même si au final écrire des commentaires comme ici est aussi long, mais j'ai vraiment un rythme de fou.

      C'est je trouve assez constructif de leur part, d'essayer d'expliquer les différences avec XMPP. Et c'est risqué car du coup ils s'exposent aux critiques si ce n'est pas parfait (seuls ceux qui ne font rien ne font jamais d'erreurs).

      Ah mais ça n'est pas ça le mal, c'est tout à fait légitime de faire ça, même de critiquer.

      Ce que je reproche c'est la manière dont ça a été fait, et dans la FAQ les réponses sont mises, mais toujours avec une formulation qui fait douter.

      Plutôt que de supprimer l'affirmation fausse que XMPP n'est pas « web-friendly », ils mettent une remarque entre parenthèses, dire que la synchronisation d'historique ou les passerelles sont des « second class citizen feature » (fonctionnalités de seconde zone) est un mensonge, c'est plein de « apparently », « questionable », il y a des guillemets autour de « fine » quand la communauté répond que ça marche avec un satellite à très faible débit.

      Sans oublier la phrase « The whole subject of XMPP vs Matrix seems to bring out the worst in people » (« le sujet de XMPP contre Matrix semble faire sortir le pire côté des gens ») qui laisse entendre que c'est la communauté XMPP qui a agit avec agressivité (il y a eu en effet quelques réponses sèches à la longue).

      • [^] # Re: Point de vue d'un développeur XMPP

        Posté par SaintGermain le 21 juillet 2017 à 14:59. Évalué à 3.

        

        Matrix souhaite un chemin similaire d'après ce que j'ai compris, mais est développé par des membres issus d'une même entreprise, avec un financement privé, une influence et une prise de décision très concentrée, et un but probablement lucratif.

        Je crois que la création de la fondation (à but non lucratif) censée diriger Matrix sera faite dans la semaine (cf. leur blog).

        Pour moi la différence se situe plutôt là que sur le plan technique.

        Je suis incapable de dire si c'est juste ou pas mais là je pense que l'on avance sur un terrain miné.

        Je pense aussi que je suis trop biaisé pour modifier ça moi même, et que c'est à eux de le faire de toute façon.

        À partir du moment où tu soumets juste une demande de modification, ils sont libres de la modifier et de l'accepter par la suite. Mais au moins il y aura une trace (les commentaires du pull request) s'ils font quelque chose de pas fair play. Et ils t'encouragent en plus à proposer un pull request, donc il ne faut vraiment pas s'inquiéter de ton avis biaisé à mon avis.

        Mais là de mon point de vue ils ont fait le premier pas officiel (même si mal fait) en tentant d'expliquer les différences. Et comme cela nécessite un effort commun pour le faire (XMPP + Matrix), ce serait chouette si quelqu'un de XMPP pouvait faire le second pas officiellement (via pull request plutôt qu'un message dans un blog).

        Ce que je reproche c'est la manière dont ça a été fait, et dans la FAQ les réponses sont mises, mais toujours avec une formulation qui fait douter.

        Peut-être qu'ils ont tout simplement pas envie de ré-éditer encore une fois leur FAQ et d'être encore sous le feu des critiques ? Plutôt que d'itérer jusqu'à ce qu'ils écrivent quelque chose qui convienne aux devs de XMPP, ils attendent peut-être que les devs leur disent directement ce qu'ils doivent écrire (via pull request…).

        Et effectivement répondre aux commentaires sur le sujet prend à mon avis est moins efficace que de faire le pull request.
        J'attends avec impatience pour pouvoir enfin bien comprendre les différences avec XMPP ! ;-)

      • [^] # Re: Point de vue d'un développeur XMPP

        Posté par freem le 21 juillet 2017 à 15:21. Évalué à 2.

        

        XMPP utilise XML ce qui est critiqué par certains (à tort à mon avis) sur TCP (ou autre), Matrix utilise HTTP qui a sa lourdeur.

        Heu… ouai, je vois pas le rapport la…

        XML c'est un format de données, qu'il faut ensuite envoyer via un protocole réseau, tandis que HTTP un protocole réseau… Si ça se trouve, XMPP (j'en sais rien de rien, hein) balance ses données par HTTP aussi…

        HTTP est lourd? Possible, mais… quelle version? Il semble y avoir un fossé non négligeable entre la 1.1 et la 2.0, même si je n'ai jamais vraiment cherché à comprendre leurs fonctionnements je le reconnais.

        • [^] # Re: Point de vue d'un développeur XMPP

          Posté par freem le 21 juillet 2017 à 15:39. Évalué à 3.

          

          Bon je me réponds à moi-même sur quelques points.
          Donc, XMPP est un protocole basé directement sur TCP dont les messages sont au format XML. Matrix, en revanche, est un protocole basé sur HTTP, lui-même sur-couche de TCP, dont les données sont formatées en JSon.
          Après, pour parler de performance, il faudrait déjà comparer les torchons, XMPP et HTTP, puis XML et JSon. Et aussi définir si l'important c'est le lag, ou le volume.

          • [^] # Re: Point de vue d'un développeur XMPP

            Posté par eingousef le 22 juillet 2017 à 02:11. Évalué à 0.

            

            Matrix, en revanche, est un protocole basé sur HTTP, lui-même sur-couche de TCP, dont les données sont formatées en JSon.

            [:vomi]

            *splash!*

    • [^] # Re: Point de vue d'un développeur XMPP

      Posté par Jehan (site web personnel, Mastodon) le 21 juillet 2017 à 15:02. Évalué à 9.

      

      c'est pourquoi tu te refuses à proposer un changement (pull request) pour leur FAQ

      Quand un logiciel cherche absolument à se placer en opposition, en "concurrent" plutôt qu'en ami, alors je comprends tout à fait la réticence à contribuer. Je connais ça aussi. Quand tu cherches tout pour que les divers logiciels libres s'améliorent tous ensemble tranquille, en harmonie, et que l'un se met à cracher sur les autres pour se mettre au dessus du lot (souvent parce qu'ils veulent faire leur beurre alors qu'ils arrivent sur un marché déjà saturé/bien rempli), c'est assez désagréable.

      En outre, on peut ne pas aimer la logique qui consiste en se comparer avec les autres sans cesse pour se promouvoir. Le truc, c'est que dans ce genre de comparatif, on peut souvent faire tricher les mots. Par exemple une fonctionnalité peut être implémentée, mais mal (bugs voire crashs constants, etc.), ou bien le voisin peut avoir plus de sous-fonctionnalités (mais on se limite à lister en surface), ou bien on peut avoir une GUI 1000 fois meilleure (ce qui est parfois subjectif en plus), ou bien le voisin peut l'avoir implémenté des années avant nous et on vient juste de la rajouter avec une micro-avancée et on se présente comme plus évolué, parfois on va même mettre dans la liste un truc noté "expérimental", voire encore dans la version de dév, on va "oublier" de lister certaines fonctionnalités absentes de notre côté, etc. etc. En gros ces comparaisons peuvent tout et rien dire, car elles sont bien moins factuelles qu'on ne veut le faire croire. Beaucoup de choses rentrent en compte dans une comparaison de fonctionnalités (simplicité d'utilisation, habitudes, contexte, depuis quand, limitations, bugs, usages inhabituels voire non prévus qui pourtant changent tout pour certains… et plein d'autres choses… tous ces petits détails qui font qu'on va préférer un logiciel à un autre, parfois/souvent subjectivement même).

      Et puis surtout, ces comparaisons sont faites en général pour se mettre en valeur vis à vis des autres logiciels, donc le biais va toujours dans un sens, en mettant de côté toutes les fonctionnalités importantes qui nous manquent, et en lissant les problèmes. Et on met de la mauvaise ambiance (ce dont les services marketing se foutent, mais dans les projets communautaires de logiciel libre, beaucoup d'entre nous aimeraient qu'on évite et qu'on fasse plutôt avancer les technos ensemble).

      C'est je trouve assez constructif de leur part, d'essayer d'expliquer les différences avec XMPP.

      Pour les raisons expliquées plus haut, je ne suis pas si sûr. Je trouve ça bien plus constructif de parler juste de soi. Cela n'empêche pas de voir l'existence des autres, voire de s'en inspirer (ou au contraire d'apprendre de leurs erreurs parfois) mais il n'est pas nécessaire de mettre les pieds dans le plat et de sans cesse se comparer à eux ou les dénigrer.

      du côté XMPP vous faites aussi une FAQ pour expliquer les différences avec Matrix

      Toujours pour les mêmes raisons, je ne trouverais pas cela constructif si les logiciels basés sur XMPP (ou pire la XSF elle-même) devait commencer à se comparer avec Matrix et pourquoi pas d'ailleurs dans ce cas à tous les autres qui font de la messagerie ou de l'échange de messages! Perso je trouve que le temps des gens est mieux dépensé en améliorant son logiciel plutôt qu'en essayant constamment de se comparer aux autres.

      Pour GIMP, c'est pareil, les gens veulent absolument nous comparer à Photoshop. Ensuite les gens pensent ce qu'ils veulent, mais du point de vue des développeurs, non on ne cherche absolument pas à être en compétition avec Photoshop. On a même un point de FAQ pour expliquer cela justement (plutôt qu'un point de FAQ pour comparer): https://www.gimp.org/docs/userfaq.html#are-you-trying-to-develop-a-photoshop-killer-app
      Les autres peuvent nous comparer s'ils veulent. Nous, on n'a pas que ça à faire. On fait notre propre logiciel avec nos propres idées. C'est pour moi 1000 fois plus constructif.
      D'ailleurs GIMP a aussi son Matrix-like, un logiciel libre qui base une partie de sa communication sur la haine de et les attaques à GIMP. Et malheureusement cela déteint évidemment en créant une communauté qui déverse pas mal de bile sur d'autres logiciels libres. Personnellement je trouve cela fatigant et même stressant (subir des attaques et des insultes pour contribuer à du logiciel libre, c'est parfois dur à encaisser et l'idée d'arrêter m'est passée par la tête plus d'une fois, heureusement pas trop longtemps). Donc je comprends vraiment bien l'état d'esprit des gens qui font du XMPP si Matrix et sa communauté se comporte pareil.
      D'un autre côté, on est en très bonne entente avec tous les autres logiciels de graphisme libre (que ce soit MyPaint, Darktable, RawTherapee, les diverses librairies…) avec qui on discute beaucoup sur IRC et lorsqu'on a l'occasion de se voir en vrai. Heureusement que tous les projets ne se basent pas sur la confrontation… Ce sont les moments où on se dit que c'est pas si mal parfois le logiciel libre, finalement.

      Je souhaite donc à SàT, Movim et aux autres projets XMPP de continuer longtemps et de s'améliorer, en collaborant avec les autres projets qui veulent coopérer sans friction. :-)
      Et franchement, je leur conseille pas de rentrer dans ces logiques tendues de comparer et d'opposer. Si vraiment Matrix a cette attitude et si elle en change un jour, alors coopérez avec eux ce jour là. Mais pour l'instant, tant qu'ils continuent, ignorez les.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Point de vue d'un développeur XMPP

        Posté par SaintGermain le 21 juillet 2017 à 15:18. Évalué à 2.

        

        Je t'accorde que ce n'est pas très constructif pour les développeurs (qui ont autre chose à faire).

        Si on suit ta logique, il faudrait presque effacer l'entrée XMPP dans leur FAQ et faire comme si cela n'existait pas ?
        Comme une FAQ est surtout là pour répondre aux questions fréquentes et que c'est l'une des premières questions que je me suis posé (et XMPP ?), à mon avis c'est pertinent de mettre la réponse en FAQ.

        Ils s'y sont peut-être mal pris par le passé, mais ne peut-on pas leur donner le bénéfice du doute (ou bien pardonner) et tenter de ramener tout le monde à table ?

        Si c'est perdu pour perdu et que les deux mondes sont irréconciliables, je peux proposer une entrée type « langue de bois » de la FAQ avec : « XMPP et Matrix poursuivent un objectif similaire mais avec une vision différente ou vice-versa, il est inutile de vouloir les comparer. »
        Mais je trouve que l'on y perd.

        • [^] # Re: Point de vue d'un développeur XMPP

          Posté par Jehan (site web personnel, Mastodon) le 21 juillet 2017 à 17:48. Évalué à 7.

          

          Si on suit ta logique, il faudrait presque effacer l'entrée XMPP dans leur FAQ et faire comme si cela n'existait pas ?

          Ne pas avoir d'entrée comparative entre 2 technologies dans une FAQ ne signifie pas ignorer l'existence de l'autre. On peut tout à fait reconnaître l'autre, avec ses qualités et défauts, sans pour autant devoir absolument faire de la comparaison hâtive. Pour le coup, je n'ai pas creusé le sujet des discussions entre les projets Matrix et XMPP, mais je viens au moins de jeter un œil au lien de la FAQ donné dans l'article. C'est vrai que ça m'a quand même l'air super orienté et avec aucune tentative d'être un minimum objectif.
          Ils ne font pas de comparaisons, ils ont juste une liste de trucs où ils disent en gros que XMPP fait de la merde sans détailler quoi que ce soit ni en quoi eux font mieux. En plus pour avoir moi-même hacké du XMPP pendant plusieurs années, je peux dire que la plupart des éléments de leur liste étaient déjà faux y a 10 ans. Notamment ils ont plusieurs éléments qui se résument en gros à "y a pas la fonctionnalité X sauf si on prend en compte la XEP qui permet X depuis 10 ans". C'est assez mesquin selon moi, et montre qu'ils n'ont pas compris comment marchait XMPP (ou ils font les idiots et prétendent ne pas comprendre).
          Je trouve pas ça constructif perso. Dorénavant je suis en dehors du monde XMPP et je souhaite à Matrix comme aux projets XMPP tout le bien du monde, mais c'est vrai que vu de l'extérieur, ils font un peu des coups bas.

          je peux proposer une entrée type « langue de bois »

          Ce n'est pas être langue de bois que de rester aimable.

          History synchronisation is very much a second class citizen feature
          Stanzas aren’t framed or reliably delivered without extensions. (See wiki.xmpp.org for an XMPP take on this)
          Multiple device support is limited. (Apparently Carbons and MAM help with this)

          Ça c'est langue de bois pour moi. Des affirmations d'une phrase sans aucun détail, sans contexte, qui disent juste que l'autre fait quelque chose de pas-bien (tout en admettant à demi-mot, à chaque fois avec une tournure de phrase un peu différente qu'y a en fait une solution).

          Du pas-langue-de-bois, c'est un article complet qui parle d'une seule fonctionnalité avec plusieurs paragraphes techniques sur la solution adoptée par Matrix pour répondre à une problématique X, et éventuellement quelques paragraphes qui étudient les solutions choisies par d'autres technologies et en quoi ils trouvaient que ça ne convenait pas pour eux, en listant les avantages et inconvénients de chaque solution (dont la leur), les choix et les compromis qu'il fallait faire et pourquoi. Le tout sans cracher sur les décisions des autres, et en prenant en compte aussi les raisons historiques. Car oui XMPP est plus vieux, oui certaines choses seraient à refaire maintenant, je suis sûr que beaucoup feraient différemment, mais c'est le cas de toutes les technos. Dans 10 ans, les auteurs de Matrix pourraient penser la même chose de certains de leurs choix — en tous cas j'espère, sinon ce serait bien triste quant à leur évolution technique — mais il faut bien avancer et pas sans cesse revenir en arrière et tout reprendre de zéro.
          Alors certes, c'est plus chronophage et sûrement moins sexy qu'une ligne d'accroche. Mais on veut du pas-langue-de-bois, moi je donne juste le chemin. :-)

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Point de vue d'un développeur XMPP

            Posté par SaintGermain le 21 juillet 2017 à 21:45. Évalué à 5.

            

            On va essayer d'être constructif avec toi et Goffi et de lancer une passerelle vers Matrix.

            Voici donc ma traduction approximative de la FAQ de Matrix.org sur XMPP dans le wiki de LinuxFR :
            https://linuxfr.org/wiki/xmpp_et_matrix

            Donc maintenant pour toi et Goffi (ou tout autre dev de XMPP) qui sont présents sur LinuxFR, vous avez juste à corriger directement sur le wiki.
            Cela devrait prendre à peine un peu plus de temps que répondre à mes commentaires.

            Ensuite je me charge de traduire en anglais, de faire le pull request, le suivi et tout et tout.

            Cela convient à tout le monde ?
            Si quelque chose de positif sort de cette discussion, j'en serai ravi.

            • [^] # Re: Point de vue d'un développeur XMPP

              Posté par Jehan (site web personnel, Mastodon) le 22 juillet 2017 à 11:30. Évalué à 4. Dernière modification le 22 juillet 2017 à 11:31.

              

              Tu n'as pas l'air de comprendre. On te dit que faire ce genre de comparaison n'est pas constructif. Si je pense être meilleur que toi (je ne le pense pas, c'est un exemple), et que je fais un point de FAQ sur mon site pour me comparer à toi, quel que soit le texte que j'y met, trouveras-tu vraiment cela constructif? Réfléchis juste deux secondes à cela. Le simple fait de faire ce type d'entrée de FAQ est puéril et mesquin.
              Si tu veux de la constructivité, demande leur de retirer cette entrée de FAQ, tout court.

              Ensuite si un jour, ils veulent vraiment comparer avec XMPP, j'ai expliqué comment: fonctionnalité par fonctionnalité avec de longs articles techniques, détaillés, le plus honnêtement possible et sans chercher à rabaisser XMPP. Pas une entrée de FAQ de 30 lignes qui parle de tout et de rien. Ce sera long à faire, ça leur prendra sûrement des heures d'écriture et d'étude comparative avec la solution XMPP, pour juste parler d'une unique fonctionnalité et c'est à eux de le faire pour expliciter leur choix (car c'est eux qui veulent absolument comparer, pas les autres). Mais personne n'a dit qu'une comparaison constructive est une chose aisée et rapide.
              Alternativement ils peuvent aussi ne pas chercher à se comparer à tout prix, et juste faire évoluer leur truc. Ça aussi, c'est constructif.

              Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

              • [^] # Re: Point de vue d'un développeur XMPP

                Posté par SaintGermain le 22 juillet 2017 à 18:28. Évalué à 1.

                

                C'est surtout que je n'avais pas compris (vu que tu ne l'avais pas explicitement dit) que la comparaison devait être faite à 100% par l'équipe Matrix sans l'aide des devs de XMPP.

                Du coup je ne trouve pas ton approche constructive, parce que tout simplement je crois qu'elle ne marchera pas (on peut essayer hein, on a rien à perdre).
                Si on demande juste à l'équipe Matrix de retirer l'entrée sur XMPP de la FAQ sans aucune autre argumentation que dire : « ce que vous avez écrit n'est pas juste, il vaut mieux le retirer », je suis pratiquement sûr que l'on va se faire envoyer balader.
                Et comme c'est une question fréquente, bah ils vont la laisser dans la FAQ (dont c'est quand même le but de répondre aux questions fréquentes) parce que sinon à chaque fois ils auront des commentaires sur XMPP quand ils parleront de Matrix (comme c'est le cas ici d'ailleurs).

                Alors que si on démonte proprement chaque point, au final Matrix aura le choix entre garder une entrée qui n'avance pas le schmilblick (vu que techniquement il n'y aura plus vraiment d'avantage à l'un ou à l'autre), refaire une entrée qui soit plus juste (i.e comme dit Goffi, que la différence est plus dans la politique/gouvernance) ou bien simplement retirer l'entrée.

                • [^] # Re: Point de vue d'un développeur XMPP

                  Posté par Maclag le 23 juillet 2017 à 20:49. Évalué à 10.

                  

                  Je pense que tu es plein de bonne volonté, et que tu dois trouver ça frustrant de ne pas trouver un terrain d'entente, mais essaie de te mettre à la place des acteurs XMPP une minute et repense à ce que tu leur demandes:

                  -L'équipe Matrix FUD sur XMPP (je ne sais pas si c'est volontaire, mais visiblement, c'est comme ça qu'ils l'ont perçu)
                  -Les acteurs XMPP protestent et répondent aux différents points soulevés
                  -L'équipe Matrix corrige certains points et en laissent d'autres non corrigés (même commentaire qu'au-dessus)
                  -Les acteurs XMPP te disent que tout n'est pas réglé
                  -Ta proposition: "si vous êtes pas contents, tapez-vous le boulot du comparatif et ensuite on demandera humblement à l'épuipe Matrix s'ils acceptent de reprendre votre contribution"

                  Si c'était moi, je n'aurais pas envie non plus d'aller bosser sur le comparatif. Je te dirais plutôt que c'est à l'équipe Matrix de faire le boulot en guise de bonne foi. Une fois qu'ils m'auraient convaincu de vouloir coopérer et non descendre XMPP pour mieux vendre Matrix, je serais revenu à la table pour discuter.

                  J'ajouterais mesquinement que les auteurs de Matrix se présentent eux-mêmes comme connaissant bien les protocoles existants par leur propre expérience, ce qui permet à Matrix de profiter de tous les avantages et éviter les défauts de conception. Du coup ils devraient être les meilleurs pour faire un comparatif, non?

                  Personnellement, je ne suis pas impliqué dans aucun protocole sauf comme utilisateur et admin de serveur familial.

                  Ces divisions, tant sur les choix techniques que sur la collaboration, me semblent regrettables.

                  • [^] # Re: Point de vue d'un développeur XMPP

                    Posté par SaintGermain le 23 juillet 2017 à 23:14. Évalué à 2.

                    

                    J'essaye justement de me mettre à leur place (à XMPP et à Matrix).

                    L'équipe Matrix : on nous pose régulièrement la question de la différence avec XMPP, donc on fait une FAQ à ce sujet. La FAQ n'est pas bonne et les gens d'XMPP sont mécontents On corrige comme on peut et ils sont limite encore plus mécontents. Plutôt que d'itérer ainsi et de s'enfoncer encore plus, on leur demande de modifier eux-même pour être sûr que cela leur convienne.

                    L'équipe XMPP : un nouveau venu refuse de partir de notre technologie et donne de mauvaises raisons dans leur FAQ. On leur dit qu'ils se sont trompés et de corriger leur FAQ. Ils corrigent mais c'est limite encore pire qu'avant. On veut bien leur donner le bénéfice du doute (quoique) mais faut pas pousser, on va pas faire leur travail pour eux.

                    Donc si chacun campe sur ses positions et ne fait aucun effort, il ne se passera rien.

                    Effort que peut faire Matrix : retenter une nouvelle version de leur FAQ sans aide de XMPP, et risquer de mettre encore plus le feu aux poudres (ou bien retirer purement et simplement la FAQ, mais du coup il faudra sans cesse répondre aux commentaire sur XMPP à chaque présentation de Matrix).
                    Effort que peut faire XMPP : corriger un minimum la FAQ de Matrix et se taper un boulot que l'on trouve inutile, désagréable et ingrat.

                    Si l'un et l'autre refuse de faire l'effort en premier, au final on fait quoi ? Rien ? Et du coup on aura toujours des gens mécontents, intervenant sur les présentations de Matrix et XMPP ? Peut-être qu'il faut juste se contenter de cela.

                    Sinon on peut aussi tenter la médiation, réunir tout le monde à la même table autour d'une bonne bière limonade et se rendre compte que tout le monde travaille dans le même sens. Mais c'est sans doute naïf et utopique.

              • [^] # Re: Point de vue d'un développeur XMPP

                Posté par Mildred (site web personnel) le 25 juillet 2017 à 10:13. Évalué à 7.

                

                Vouloir comparer est normal, ils arrivent après, XMPP existe, et les gens ont besoin de comprendre pourquoi ils doivent investir dans une nouvelle techno alors qu'il y avait XMPP qui ne demandait qu'a évoluer.

                C'est un peu comme Mir vs Wayland (d'ailleurs la FAQ de Mir sur Wayland était bien pourrie).

                Pour moi, Matrix voulait refaire de la messagerie, avec un style très orienté IRC. Ils voulaient aller vite. XMPP leur donnait l'impression de stagner donc ils ont voulu s'en abstraire pour aller plus vite et par raisons marketing De toute façon, ça n'avait plus la cote… et ils ont fait un protocole fait au plus rapide avec une couche HTTP+JSON parce qu'il y a plein de libs qui marchent bien pour ça, c'est tout.

                Il doit également y avoir des raisons techniques. Je pense que l'implémentation des utilisateurs et des salons de discussion est différente de XMPP et c'est souhaité. Si ils avaient dû reprendre XMPP, ils n'auraient peut être pas pu reprendre les mêmes groupchat et auraient fait leur truc séparé sans doute.

• # Décentralisation

  Posté par Anonyme le 21 juillet 2017 à 12:49. Évalué à 3.

  

  • décentralisé : je ne connais aucun logiciel ayant vraiment réussi grâce à sa fonctionnalité de décentralisation

  Mastodon a réussi à percer grâce au « marketing » autour la décentralisation. Le discours principal est : Twitter censure n’importe comment, alors que vous pouvez censurer selon vos propres critères sur Mastodon.

  • [^] # Re: Décentralisation

    Posté par Thomas Douillard le 21 juillet 2017 à 12:59. Évalué à 4.

    

    ou edonkey évidemment.

    • [^] # Re: Décentralisation

      Posté par SaintGermain le 21 juillet 2017 à 13:04. Évalué à 1.

      

      Excellent exemple effectivement, merci.

  • [^] # Re: Décentralisation

    Posté par SaintGermain le 21 juillet 2017 à 13:01. Évalué à 1.

    

    Ah ! Merci pour l'exemple !

    Bien que Matrix semble avoir près de deux fois plus d'utilisateurs que Mastodon, je ne suis pas sûr que l'on peut dire que Matrix ait pour l'instant « réussi » (après la notion de réussite est toute relative).

    Une question cependant : pour vendre quelque chose, est-ce qu'un slogan/discours qui se place en opposition est une bonne idée ?

    • [^] # Re: Décentralisation

      Posté par Jehan (site web personnel, Mastodon) le 21 juillet 2017 à 13:47. Évalué à 4.

      

      Bien que Matrix semble avoir près de deux fois plus d'utilisateurs que Mastodon

      La notion de nombres d'utilisateurs a un intérêt bien sûr, mais pas pour comparer l'utilisation. En fait il est plutôt question d'inscrits, j'imagine. Un grand nombre d'inscrits sert pour dire qu'un logiciel a éveillé la curiosité de/intéressé beaucoup de gens, pas s'ils sont restés et sont effectivement restés/devenus utilisateurs. Pour ça il faudrait plutôt le nombre d'utilisateurs "actifs" (à définir, souvent avec une notion de temps depuis dernière connexion).

      Comme très peu de personnes effacent réellement leur compte (un jour, ils se connectent plus, et c'est tout en général, quand ils arrêtent un service), ce nombre ne fait que grimper inlassablement et est donc totalement biaisé. On le voit bien sur ton graphique d'ailleurs. Cela veut dire aussi qu'un service plus ancien ayant beaucoup plus d'inscrits qu'un service récent n'est pas forcément un gage de quoi que ce soit (ICQ ou MySpace, doivent avoir un nombre énormes d'utilisateurs; je suis pas sûr qu'ils soient encore si utilisés en vrai). Ton second graphique (trafic quotidien) est déjà plus intéressant pour juger de la santé d'un tel service.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

• # décentraliser != home server

  Posté par EauFroide le 22 juillet 2017 à 14:29. Évalué à -1.

  

  Si un logiciel nécessite un serveur, alors il n'est pas décentralisé.
  Il faut appeler un chat un chat. (j'ai d'ailleurs trouvé le titre très putaclic)
  Si les gens doivent installer leur propre serveur, on perd 99,9% de la population.
  Et utiliser le serveur d'une assoc ou d'un pote revient au final au même (voir pire) que directement passer par facebook.

  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

  • [^] # Re: décentraliser != home server

    Posté par SaintGermain le 22 juillet 2017 à 18:18. Évalué à 5.

    

    Si un logiciel nécessite un serveur, alors il n'est pas décentralisé.

    Tu considères que l'email est une technologie centralisée ?

    Si les gens doivent installer leur propre serveur, on perd 99,9% de la population.

    Pourquoi les gens doivent installer leur propre serveur ? Tu as installé ton serveur pour pouvoir avoir un email ?

    Et utiliser le serveur d'une assoc ou d'un pote revient au final au même (voir pire) que directement passer par facebook.

    Tu as utilisé le serveur d'une assoc ou d'un pote pour avoir un email ?

    • [^] # Re: décentraliser != home server

      Posté par EauFroide le 22 juillet 2017 à 18:59. Évalué à -6. Dernière modification le 22 juillet 2017 à 19:02.

      

      Tu considères que l'email est une technologie centralisée ?

      L'e-mail façon GMAIL est clairement centralisé, l'e-mail façon RetroShare est décentralisé.
      Le premier nécessite des serveurs indépendant des clients, le second fusionne client et serveur (et ce sans interdire la mise en place de serveur).

      Pourquoi les gens doivent installer leur propre serveur ? Tu as installé ton serveur pour pouvoir avoir un email ?
      Tu as utilisé le serveur d'une assoc ou d'un pote pour avoir un email ?

      Appréhendes-tu se qu'est la décentralisation?

      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

      • [^] # Re: décentraliser != home server

        Posté par SaintGermain le 22 juillet 2017 à 20:52. Évalué à 10.

        

        L'e-mail façon GMAIL est clairement centralisé, l'e-mail façon RetroShare est décentralisé.

        Pardon ? Si Google s'arrête demain, on ne peut plus s'envoyer d'email du tout ?

        Appréhendes-tu se qu'est la décentralisation?

        Je pense, et toi tu fais la différence entre centralisé, décentralisé et distribué ?

        Où se trouve le principe de l'email dans la figure ci-dessous ?

        

        • [^] # Re: décentraliser != home server

          Posté par Kerro le 23 juillet 2017 à 20:40. Évalué à 1.

          

          Sur le schéma décentralisé, le nœud central me pose problème : s'il tombe, beaucoup de choses ne fonctionnent plus.
          Il faudrait que plusieurs chemins soient possibles, mais dans ce cas on a alors un schéma décentralisé avec des serveurs (ou certaines stations) distribués. Est-ce que cela correspond toujours à la même définition ?

          • [^] # Re: décentraliser != home server

            Posté par Maclag le 23 juillet 2017 à 20:57. Évalué à 6.

            

            Le schéma est volontairement simplifié. Dans un réseau décentralisé, il n'y a pas de noeud central.
            Les serveurs communiquent entre eux directement.

            Ce n'est peut-être pas évident pour Matrix tant matrix.org écrase largement les autres en termes de taille (nombre d'inscrits, quantité de salons accessibles), mais c'est bien l'idée.

            C'est même l'argument phare des salons Matrix: les salons sont répliqués sur tous les serveurs dont au moins un utilisateur est inscrit dans le salon, avec un identifiant local sur le serveur. Si matrix.org tombe, tous les utilisateurs hors matrix.org peuvent continuer à utiliser le salon comme si de rien n'était.

            • [^] # Re: décentraliser != home server

              Posté par EauFroide le 23 juillet 2017 à 23:59. Évalué à 1. Dernière modification le 24 juillet 2017 à 00:02.

              

              doublon (là c'est bug du cerveau déso :D)

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

            • [^] # Re: décentraliser != home server

              Posté par EauFroide le 24 juillet 2017 à 00:01. Évalué à -1. Dernière modification le 24 juillet 2017 à 00:02.

              

              Le schéma est volontairement simplifié. Dans un réseau décentralisé, il n'y a pas de noeud central.

              Il n'y a pas un nœud central mais des nœuds centraux, ça reste similaire.
              C'est le même soucis qu'avec XMPP (et linphone) : tu reste bloqué par la nécessite d'avoir un serveur où te connecter (celui d'une assoc, d'un pote, le tien).

              C'est même l'argument phare des salons Matrix: les salons sont répliqués sur tous les serveurs dont au moins un utilisateur est inscrit dans le salon, avec un identifiant local sur le serveur. Si matrix.org tombe, tous les utilisateurs hors matrix.org peuvent continuer à utiliser le salon comme si de rien n'était.

              Idem sur RetroShare.

              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

              • [^] # Re: décentraliser != home server

                Posté par Maclag le 24 juillet 2017 à 02:02. Évalué à 6.

                

                Peut-être que je ne suis pas suffisamment familier avec Retroshare, mais quand je vois la mise en avant du contrôle à distance avec des interfaces en ligne de commande, web ou android, et il faut connaître l'adresse IP et le port, à quel moment on accepte de dire que c'est un schéma client-serveur tout ce qu'il y a de plus banal?
                C'est juste que le serveur vient avec son interface par défaut et qu'on peut se mettre dessus directement?

                • [^] # Re: décentraliser != home server

                  Posté par EauFroide le 24 juillet 2017 à 02:42. Évalué à 1. Dernière modification le 24 juillet 2017 à 02:47.

                  

                  Tu parles de RetroShare ou de Matrixc là? ^ ^

                  Si tu parles de RetroShare alors c'est client-serveur tout en un (c'est du F2F, descendant du P2P). Par contre il n'y a pas de version mobile (android), sauf éventuellement sur nano-pc (raspberry pi, odroid, etc). La version android n'est qu'une interface permettant de contrôler le logiciel sur son desktop. (c'est un peu comme GearShift qui permet de diriger Transmission, ce n'est pas l'application elle-même)

                  Tu n'as pas besoin de connaître l’adresse IP ou le port de tes contactes, il y a un système de découverte qui fait que tant que tu as une connexion avec un contact, il va te transmettre les infos pour joindre les contactes que vous avez en commun. Tu peux aussi utiliser des DDNS, Tor Hidden Service ou I2P proxy.
                  Les salons/forums/chaînes sont dupliqués par tout ceux qui s'y abonnent et mis a disposition de partage de tout leur contact (qui deviennent eux même serveur s'ils s'abonnent et ainsi de suite).
                  Son principal défaut est son manque de Dev surtout côté android.

                  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

                  • [^] # Re: décentraliser != home server

                    Posté par Maclag le 24 juillet 2017 à 03:04. Évalué à 5.

                    

                    Oui mais du coup ça ne me semble pas très différent d'un Matrix (ou XMPP) avec une contrainte "chacun son serveur".

                    Si un ensemble client-serveur intégré Matrix (encore une fois ou XMPP) apparaissait avec une solution par défaut pour l'IP dynamique, en quoi cette solution serait différente de Retroshare?

                    Au lieu d'être dépendant d'une machine qu'on appelle serveur que tu vois comme un nœud central, tu es dépendant d'une machine que tu n'appelles pas nœud central, mais je ne vois pas où la dépendance est différente.

                    • [^] # Re: décentraliser != home server

                      Posté par EauFroide le 24 juillet 2017 à 04:51. Évalué à 1. Dernière modification le 24 juillet 2017 à 04:53.

                      

                      Si un ensemble client-serveur intégré Matrix (encore une fois ou XMPP) apparaissait avec une solution par défaut pour l'IP dynamique, en quoi cette solution serait différente de Retroshare?

                      Dans RetroShare et Tox ton identifiant est une clés publique PGP.
                      Pour Matrix je ne sais pas du tout, mais pour XMPP ton identifiant est lié a ton nom de domaine (par exemple eaufroide@jit.si).
                      Donc pour faire tourner XMPP il te faut une machine qui tourne h24 *1 + serveur xmpp, turn et autre joyeuseté + 1 nom de domaine.
                      Tout ça pour papoter avec deux potes.

                      Sur RetroShare et Tox tu ajoutes justes tes 2 potes et tu peux leur parler une fois que la connexion est établie (se qui est assez rapide sur Tox, un peu plus lent sur RetroShare voir parfois buggées avec les Tor Hidden Service). Quand tu as fini de papoter tu éteins ton logiciel et hop :)

                      Après ces réseaux ont des particularités différentes. Par exemple RetroShare, je suppose Tox aussi, sont très dynamique et donc les routes voir l'accès aux ressources changent énormément à travers le temps et la consommation de ressources (surtout réseau et RAM) y est aussi supérieur.

                      *1 h24 car tes deux potes auront ptete envie de papoter même si tu es parti dodo

                      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

                      • [^] # Re: décentraliser != home server

                        Posté par dani le 24 juillet 2017 à 18:54. Évalué à 1.

                        

                        Dans RetroShare et Tox ton identifiant est une clés publique PGP.

                        Voilà une des raisons pour lesquelles ces solutions ne pourront que rester confidentielles, limitées à quelques geeks.

                        Donc pour faire tourner XMPP il te faut une machine qui tourne h24 *1 + serveur xmpp, turn et autre joyeuseté + 1 nom de domaine.

                        Il faut bien un nom de domaine (encore qu'un dyndns ou équivalent peut tout à fait fonctionner), mais ni turn, ni h24 nécessaire. Tu peux très bien, si tu veux, démarrer ton serveur XMPP quand tu as envie de discuter avec ton pote. Bref, pas de différence avec RetroShare ou Tox à ce niveau

                        • [^] # Re: décentraliser != home server

                          Posté par EauFroide le 24 juillet 2017 à 20:59. Évalué à -1. Dernière modification le 24 juillet 2017 à 21:04.

                          

                          Voilà une des raisons pour lesquelles ces solutions ne pourront que rester confidentielles, limitées à quelques geeks.

                          Question de point de vue: je ne connais pas les numéros de téléphone des gens que j'sms.
                          Ici les mécanismes sont basé pour Tox sur des QRCodes et pour Retroshare sur des liens (clic droit => partager mon identité, l'autre clic gauche dessus et hop demande "d'amis")

                          Tu peux très bien, si tu veux, démarrer ton serveur XMPP quand tu as envie de discuter avec ton pote. Bref, pas de différence avec RetroShare ou Tox à ce niveau

                          Donc en gros je vais dire à ma copine (qui n'a pas de PC), "abandonne facebook qui nous espionne on va tchater sur XMPP, faut juste un compte chez quelqu'un (le serveur) qui va nous espionner, ou que je me casse (encore) la nenette a installer un enième serveur qu'il faudra entretenir et qui va bouffer ma bandwidth" (parce que ma copine voudra ptete papoter avec sa pote, ou sa mère, ou son amant caché premier ministre de finlande).

                          Si on veut proposer une alternative crédible à Facebook, Skype , Snapchat et compagnie, il faut être aussi facile d'utilisation et ne pas avoir les mêmes défauts (du genre dépendre de quelqu'un soumis aux lois du marché, d'un état quelconque ou d'une mauvaise conduite).

                          Note que je suis le premier a chercher comment remplacer facebook&skype dconc si vous avez une solution miracle allez-y partagez :P

                          Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

                          • [^] # Re: décentraliser != home server

                            Posté par Sufflope (site web personnel) le 24 juillet 2017 à 21:46. Évalué à 3.

                            

                            Ici les mécanismes sont basé pour Tox sur des QRCodes

                            Comment envoies-tu ton QRcode à la personne si géographiquement ou "politiquement" vous ne pouvez pas vous rencontrer physiquement ?

                            pour Retroshare sur des liens (clic droit => partager mon identité, l'autre clic gauche dessus et hop demande "d'amis")

                            Comment envoies-tu ton identité à l'autre pour qu'il clique gauche dessus ? Tu l'envoies à son "ID à la PGP" (que tu obtiens par quel moyen ?), ou il vient te la réclamer en se "connectant" à ton instance (dont il a trouvé l'adresse par… ?) ? Dans les deux cas, qui fait l’œuf, qui fait la poule ?

                            Donc en gros je vais dire à ma copine

                            https://xkcd.com/684/

                            Et sinon bah tu configures vos clients pour qu'ils aient une période de re-essai automatique d'envois d'au moins 24h et comme ça du moment que ton serveur-client-truc est allumé au moins une fois par jour les messages seront livrés. Ou tu mets pas 24h et durée infinie. De toute façon tant que tu démarres ton XMPPd au moins aussi souvent que ton Retroshare, ça marchera pareil avec le bon paramétrage, à moins que Retroshare ait un protocole transcendant l'espace-temps et livrant des messages à une instance inexistante ?

                            • [^] # Re: décentraliser != home server

                              Posté par EauFroide le 24 juillet 2017 à 22:05. Évalué à -2. Dernière modification le 24 juillet 2017 à 22:07.

                              

                              Comment envoies-tu ton QRcode à la personne si géographiquement ou "politiquement" vous ne pouvez pas vous rencontrer physiquement ?

                              Ça fait un moment que je ne l'ai plus testé, mais si je ne m'abuse tu peux aussi copier-coller ta clés.
                              Après si ton désire c'est de l'écrire sur un bout de papier avec un crayon, oui c'est grillé à ce niveau :P

                              Comment envoies-tu ton identité à l'autre pour qu'il clique gauche dessus ? Tu l'envoies à son "ID à la PGP" (que tu obtiens par quel moyen ?), ou il vient te la réclamer en se "connectant" à ton instance (dont il a trouvé l'adresse par… ?) ? Dans les deux cas, qui fait l’œuf, qui fait la poule ?

                              Dans RetroShare il est possible de discuter avec des gens qui ne sont pas dans sa liste de contacte. les tunnels transitent de pair en pairs. Je en sais pas si les liens RetroShare sont exportable sur le web, mais au sein même de retroshare tu peux les partager n'importe où (discution privée, salons, forum, chaine, etc).
                              Tes contactes (et n'importe qui ayant cliqué droit puis "copier la clés") peut repartager ta clés. Tu peux aussi la copier en brute et la partager n'importe où.

                              Et sinon bah tu configures vos clients pour qu'ils aient une période de re-essai automatique d'envois d'au moins 24h et comme ça du moment que ton serveur-client-truc est allumé au moins une fois par jour les messages seront livrés. Ou tu mets pas 24h et durée infinie.

                              L'ère moderne n'est plus aux mails différé mais aux discutions instantanées, à la VOIP, aux lives facebook/twitch/youtube.
                              Pour XMPP et Matrix ton serveur est obligé de tourner h24 sauf si tu es l'unique client de ton serveur (mais je doute que tes contactes facebook accepte de tous installer un serveur XMPP donc dépendance à des tiers (serveurs XMPP + hébergeur du nom de domaine) donc ils voient pas l’intérêt de quitter facebook)

                              Retroshare ait un protocole transcendant l'espace-temps et livrant des messages à une instance inexistante ?

                              Je ne suis pas un fin connaisseur, mais il me semble que lors de l'envoie d'un message (qui va transiter de pairs en pairs) il va se stoker dans le cache d'un ou plusieurs pairs en contact avec le destinataire. (d'où la conso de RAM). Il est probable que le message soit supprimé/perdu si tout les pairs le possédant coupe/reboot leur machine.

                              Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

                              • [^] # Re: décentraliser != home server

                                Posté par Maclag le 25 juillet 2017 à 00:48. Évalué à 6.

                                

                                Dans RetroShare il est possible de discuter avec des gens qui ne sont pas dans sa liste de contacte. les tunnels transitent de pair en pairs. Je en sais pas si les liens RetroShare sont exportable sur le web, mais au sein même de retroshare tu peux les partager n'importe où (discution privée, salons, forum, chaine, etc).

                                Je n'ai pas besoin de tout ça dans XMPP et/ou Matrix: je parle avec des gens qui ne sont pas dans ma liste de contact et qui sont dans les salons. J'ai du mal aussi à comprendre en quoi la possibilité de "partager tes identifiants" est présentée comme une fonctionnalité: tu peux aussi partager mon numéro de téléphone, mon adresse email, mon ID XMPP, mon ID Matrix.

                                L'ère moderne n'est plus aux mails différé mais aux discutions instantanées, à la VOIP, aux lives facebook/twitch/youtube.

                                Donc il faut être joignable 24/24 sinon tu ne peux pas communiquer? Et donc laisser son Retroshare (ou Tox) en marche 24/24!?

                                Pour XMPP et Matrix ton serveur est obligé de tourner h24 sauf si tu es l'unique client de ton serveur (mais je doute que tes contactes facebook accepte de tous installer un serveur XMPP donc dépendance à des tiers (serveurs XMPP + hébergeur du nom de domaine) donc ils voient pas l’intérêt de quitter facebook)

                                Comme je te le disais au-dessus, je ne vois pas ce qui empêcherait d'avoir un ensemble client-serveur Matrix ou XMPP tout intégré. Il resterait la question du nom de domaine à régler et à attribuer à une IP dynamique. Cela dit, je ne sais pas comment les protocoles gèrent les serveurs qui ne répondent pas

                                Mais personnellement, je préfère largement avoir un serveur perso avec XMPP et Matrix: je peux démarrer une conversation sur mon fixe, la continuer sur mon téléphone, puis la reprendre encore depuis mon ordi au bureau. Un certain nombre de mes documents sont accessibles H24 grâce à Nextcloud. Quand je ne suis pas connecté, on peut me laisser un message.

                                • [^] # Re: décentraliser != home server

                                  Posté par EauFroide le 25 juillet 2017 à 13:38. Évalué à 1.

                                  

                                  Je n'ai pas besoin de tout ça dans XMPP et/ou Matrix: je parle avec des gens qui ne sont pas dans ma liste de contact et qui sont dans les salons. J'ai du mal aussi à comprendre en quoi la possibilité de "partager tes identifiants" est présentée comme une fonctionnalité: tu peux aussi partager mon numéro de téléphone, mon adresse email, mon ID XMPP, mon ID Matrix.

                                  je repondais a quelqu'un qui pensait que si l'identifiant n'est pas de type mail alors il est trop complexe ;)

                                  Donc il faut être joignable 24/24 sinon tu ne peux pas communiquer?

                                  …
                                  Bon installer un serveur Linux XMPP (et je parie matrix) est compliqué (et necessite un pc).
                                  Le communs des mortel ne se fait pas chier a installer des serveurs.
                                  Donc si tu veux que ton encourage accepte de quitter facebook, ils vont devoir dependre du serveur de quelqu'un (par exemple framasoft).
                                  Si le service fonctionne 3h par jous ils vont te dire merde et retourner sur facebook.
                                  Si le service a les memes qualités et defauts que facebook, alors ils prefereront facebook (qui claque des millions de dollars pour être bien mieux intégré que les concurents).
                                  Donc sur Matrix et XMPP, si tu veux parler avec ta mere, ton voisin et co, il faut obligatoirement un serveur h24.
                                  Tox et RS ne necessitent PAS de serveurs.
                                  Si paul veut parler avec alice sur tox et RS il n'a besoin de rien, sur XMPP, Matrix, Skype,Facebook, il a besoin d'un serveur qui joue l'intermediaire.

                                  Comme je te le disais au-dessus, je ne vois pas ce qui empêcherait d'avoir un ensemble client-serveur Matrix ou XMPP tout intégré.

                                  C'est une question a poser aux communautés Matrix et XMPP.
                                  Note qu'il y a aussi la question de l'ouverture du NAT.
                                  Coté serveur XMPP, Yunohost boss sur un projet d'installation en 2 clic.

                                  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

                                  • [^] # Re: décentraliser != home server

                                    Posté par Maclag le 25 juillet 2017 à 23:10. Évalué à 4.

                                    

                                    Bon installer un serveur Linux XMPP (et je parie matrix) est compliqué (et necessite un pc).
                                    Le communs des mortel ne se fait pas chier a installer des serveurs.

                                    Je suis on ne peut plus d'accord.

                                    Donc si tu veux que ton encourage accepte de quitter facebook, ils vont devoir dependre du serveur de quelqu'un (par exemple framasoft).

                                    Toujours d'accord… ou alors ils achèteront une box pré-installée!

                                    Si le service fonctionne 3h par jous ils vont te dire merde et retourner sur facebook.

                                    Même moi je pense que j'abandonnerais avant de tomber à 3h…

                                    Si le service a les memes qualités et defauts que facebook, alors ils prefereront facebook (qui claque des millions de dollars pour être bien mieux intégré que les concurents).

                                    La notion de "qualités" et "défauts" et assez subjective, mais disons que je comprends l'idée.

                                    Donc sur Matrix et XMPP, si tu veux parler avec ta mere, ton voisin et co, il faut obligatoirement un serveur h24.

                                    Toujours d'accord, voire 2 si on a chacun un serveur.

                                    Tox et RS ne necessitent PAS de serveurs.
                                    Si paul veut parler avec alice sur tox et RS il n'a besoin de rien, sur XMPP, Matrix, Skype,Facebook, il a besoin d'un serveur qui joue l'intermediaire.

                                    Comment fais-tu depuis ton téléphone? ta tablette?
                                    De ce que j'ai vu:
                                    -soit tu commandes à distance une instance Retroshare, qui est donc ton serveur, qui doit être allumé chaque fois que tu veux utiliser ton téléphone, et tu retombes sur le besoin d'un serveur
                                    -soit ton instance est sur ton téléphone, et je doute qu'il arrivera à encaisser la duplication des salons (sans parler de la conso de données hors wifi…)
                                    -soit tu décides que tu n'as pas besoin de ça sur ton téléphone, mais alors tu es certainement un marché de niche plus réduit encore que les auto-hébergés, on est très très loin de l'utilisateur de FB lambda

                                    C'est une question a poser aux communautés Matrix et XMPP.
                                    Note qu'il y a aussi la question de l'ouverture du NAT.

                                    Plus j'y pense et moins j'y crois moi-même: il faut un nom de domaine, un gestionnaire d'IP dynamique, le serveur DNS qui va avec, comme tu le dis: il faut contourner le NAT, et il serait impossible d'avoir un 2ème appareil sur le même "compte". On ne fait que cumuler les problèmes.

                                    Coté serveur XMPP, Yunohost boss sur un projet d'installation en 2 clic.

                                    Ils font plus que juste bosser dessus: ça marche! J'ai installé Yunohost est c'est un vrai bonheur tant c'est simple.

                                    • [^] # Re: décentraliser != home server

                                      Posté par EauFroide le 26 juillet 2017 à 00:07. Évalué à 1. Dernière modification le 26 juillet 2017 à 00:09.

                                      

                                      il faut un nom de domaine, un gestionnaire d'IP dynamique, le serveur DNS qui va avec

                                      Tu peux plus simplement passer par netlib.re, mais ça le commun des mortels l'ignore ^ ^

                                      Comment fais-tu depuis ton téléphone? ta tablette?

                                      La triste réalité est que je ne sais pas, je suis encore et toujours à la recherche d'un truc pour remplacer facebook et skype.
                                      Peut-être du côté de Tox dont j'espère sincèrement qu'on verra enfin des logiciels hors du stade beta/alpha.

                                      De ce que j'ai vu:
                                      -soit tu commandes à distance une instance Retroshare, qui est donc ton serveur, qui doit être allumé chaque fois que tu veux utiliser ton téléphone, et tu retombes sur le besoin d'un serveur
                                      -soit ton instance est sur ton téléphone, et je doute qu'il arrivera à encaisser la duplication des salons (sans parler de la conso de données hors wifi…)
                                      -soit tu décides que tu n'as pas besoin de ça sur ton téléphone, mais alors tu es certainement un marché de niche plus réduit encore que les auto-hébergés, on est très très loin de l'utilisateur de FB lambda

                                      Retroshare n'est actuellement pas adapté à remplacer skype ni facebook. Le dev principale est en train de rédiger un papier pour expliquer le fonctionnement et permettre à d'autres futurs devs de créer plus facilement des surcouches de réseautage social mais reste à voir si des gens seront intéressés :) (j'en ferai un article quand son papier sera dispo :) )

                                      Ils font plus que juste bosser dessus: ça marche! J'ai installé Yunohost est c'est un vrai bonheur tant c'est simple.

                                      Ils ont changé les logiciels ? (quand j'ai testé goffi m'a fait remarqué que les logiciels étaient obsolètes et il me semble avoir vu une issue traîner à ce sujet)
                                      J'ai aussi voulu tester movim mais je n'ai rien compris :D

                                      Note que pour ta remarque de la possibilité de faire un tout en un client&serveur XMPP, ça doit être possible et "on" si ajoute la compatibilité avec Tor Hidden Service ou I2P proxy, on passe à travers les NAT et on a un hostname statique.

                                      Pour XMPP et Matrix je me pose aussi la question des clés :
                                      Admettons que Pauline@jit.si et Jacqui@g00gle.com veulent causer en OTR, est-ce les serveurs XMPP rattaché à chaque clients (jit.si et google) qui transmettent les clés? Si oui, est-ce réellement sécurisé (si je fais mon propre serveur XMPP, je peux MITM tout mes users ou alors je chope uniquement des meta data?)

                                      Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

              • [^] # Re: décentraliser != home server

                Posté par Psychofox (Mastodon) le 24 juillet 2017 à 09:11. Évalué à 7.

                

                Ça reste décentralisé. C'est juste que tu ne connais pas la signification de ce mot et que ce n'est pas le type d'archi que tu préfères.

                • [^] # Re: décentraliser != home server

                  Posté par EauFroide le 24 juillet 2017 à 13:47. Évalué à -8.

                  

                  Si on part par là, skype et facebook aussi sont décentralisés, ainsi que la totalité des gafams.

                  Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat

          • [^] # Re: décentraliser != home server

            Posté par Anonyme le 24 juillet 2017 à 17:56. Évalué à 2.

            

            Ça représente bien Internet pourtant.

• # RC ou IRC ?

  Posté par RyDroid le 24 juillet 2017 à 15:47. Évalué à 1.

  

  d’autres protocoles (RC, Slack, Skype, Lync, etc.).

  • IRC, non ?
  • Pas de point après "etc" il me semble au vu du contexte.

  • [^] # Re: RC ou IRC ?

    Posté par Benoît Sibaud (site web personnel) le 24 juillet 2017 à 17:54. Évalué à 4.

    

    Corrigé, merci. (etc. prend toujours un point)

• # Friture tueuse

  Posté par devnewton 🍺 (site web personnel) le 03 août 2017 à 13:57. Évalué à 8.

  

  D’un point de vue grand public, il semblerait que la plupart des protocoles, services et outils de communication ayant réussi dernièrement sont ceux ayant apportés une « killer feature » : ils ont apporté une réelle nouveauté, ou bien tellement amélioré quelque chose par rapport à l’existant que l’on peut parler de « rupture technologique ». Citons par exemple : Facebook, Skype, Instagram, Whatsapp, Snapchat

  C'est quoi les fritures tueuses en question?

  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

• # !! Point d'attention sur la confidentialité dans Riot

  Posté par Papey le 03 août 2017 à 17:58. Évalué à 3.

  

  La licence de Riot concernant la confidentialité est gênante.
  https://riot.im/privacy

  Il se réservent le droit de conserver les données autant qu'ils veulent sur leurs serveurs… Ils ne disent nulle part que les données issues des applications mobiles sont exclues de ces clauses. Du moins c'est comme ça que je l'avais lue il y a quelques semaines, et je ne peux pas y accéder d'où je suis pour vérifier si ça a changé. Pour moi c'est bloquant.

  • [^] # Re: !! Point d'attention sur la confidentialité dans Riot

    Posté par SaintGermain le 04 août 2017 à 11:11. Évalué à 1. Dernière modification le 04 août 2017 à 11:14.

    

    Il me semble que la page sur la vie privée n'est plus trop à jour.
    Tu as une case 'opt-out' pour la récolte des analytics dans les paramètres.

    Sinon comme le code des applications mobiles est libre, tu peux aller regarder dans le code ce qui est réellement récolté en cas d'opt-in et en cas d'opt-out.

• # Status

  Posté par erdnaxeli (site web personnel) le 04 août 2017 à 12:23. Évalué à 4.

  

  Matrix.org est (ou va devenir) une fondation à but non lucratif, principalement pour pouvoir accepter des dons (via le site de financement participatif patreon, mais aussi des sponsors de type entreprises).

  Personnellement j'ai mon propre serveur matrix depuis 6 mois, et ça marche du tonnerre. Je l'utilise principalement avec le bridge IRC, ce qui me donne un IRC plus moderne (envoie d'images, aperçu des liens, notifications push, …).

  Et concernant les problème de perf, ça tourne sur un kimsufi à 15€/mois (certes c'est pas le 1er à 2€ par mois) sans aucun soucis, même en rejoignant des grosses rooms comme Matrix HQ (et j'utilise toujours SQLite…). Par contre sur un raspberry pi c'est sûr que ça va galérer.

  Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.

Suivre le flux des commentaires

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