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

Posté par  . Édité par M5oul, Benoît Sibaud, palm123, Davy Defaud, Nÿco, Amandine, Dreammm et Bruno Michel. Modéré par Bruno Michel. Licence CC By‑SA.
66
20
juil.
2017
Internet

Matrix est un projet libre (licence Apache v2) définissant une nouvelle base (un ensemble d’API HTTP) pour une communication décentralisée, fédérée et temps réel.

TL;DR Pour se faire une idée rapidement, le plus simple est de cliquer ici et de voir immédiatement à quoi cela ressemble en pratique : accès au salon LinuxFr via le client Riot.

Logo de matrix.org

Sommaire

Présentation

Architecture de Matrix

Matrix propose de la communication décentralisée, mais ce n’est pas de la communication distribuée (contrairement à Tox, par exemple), donc pour fonctionner cela nécessite quand même au moins un serveur (plusieurs serveurs pouvant être fédérés) que l’on appelle communément « homeserver ».

La question que l’on peut se poser directement, c’est la différence avec XMPP : j’en parle un peu plus loin dans la dépêche.

Identité et serveurs

Un utilisateur se connecte sur son homeserver via un client au moyen d’un identifiant unique appelé matrix user ID (MXID) qui est de la forme @username:homeserver.tld et d’un mot de passe.

Les MXID sont cependant prévus d’être mis un peu en retrait par rapport aux 3rd party ID (3PID) qui correspondent aux adresses de courriel ou aux numéros de téléphone.

Les serveurs d’identité (qui sont optionnels) permettent de faire le lien entre MXID et 3PID.

Enfin, il y a les Application Services qui permettent de faire la passerelle avec d’autres protocoles (IRC, Slack, Skype, Lync, etc.).

Salons de discussions et serveurs

Les discussions entre utilisateurs se passent dans des salons, par exemple le salon #matrix:matrix.org où se trouvent les développeurs de Matrix (qui est très fréquenté et très actif).
Cependant :

  • #matrix:matrix.org n’est qu’un alias spécifique au homeserver matrix.org, et n’importe qui peut lui donner un autre alias correspondant à son propre homeserver (par exemple #newmatrix:example.com). Le vrai identifiant du salon est en effet un nombre aléatoire ;
  • les messages échangés dans un salon sont stockés sur chacun des homeservers des utilisateurs participant au salon.

La conséquence, c’est que si le homeserver matrix.org disparaît demain, les utilisateurs inscrits sur matrix.org (donc avec une adresse type @user:matrix.org) ne pourront plus se connecter, mais les participants de #matrix:matrix.org continueront comme si de rien n’était (sauf qu’ils remarqueront que les utilisateurs de matrix.org ne sont pas là). De nouveaux participants pourront même rejoindre le salon via un autre alias (#newmatrix:example.com).

Le principe de la fédération

Une analogie possible serait de comparer au fonctionnement des courriels :

  • chaque fournisseur de messagerie électronique est indépendant, avec ses utilisateurs et son serveur conservant les courriels ;
  • si le fournisseur de messagerie électronique n’est pas ouvert vers l’extérieur, les utilisateurs peuvent communiquer entre eux et les courriels restent sur le serveur ;
  • si le fournisseur de messagerie électronique est ouvert vers l’extérieur, les utilisateurs peuvent communiquer avec des utilisateurs d’autres fournisseurs, et les courriels échangés se retrouvent alors sur les serveurs respectifs.

Matrix fonctionne de la même manière :

  • chaque homeserver est indépendant, avec ses utilisateurs et son serveur conservant les salons de discussions (avec leurs messages échangés) ;
  • si le homeserver n’est pas fédéré, les utilisateurs ne peuvent communiquer qu’entre eux et les salons de discussions restent sur le serveur ;
  • si le homeserver est fédéré, les utilisateurs peuvent communiquer avec des utilisateurs d’autres homeservers, et les salons de discussions impliquant des utilisateurs de différents homeservers se retrouvent répliqués sur les homeservers respectifs.

Matrix network

Tout comme pour les courriels, il n’y a donc pas de dépendance particulière à un homeserver en particulier, en tout cas en ce qui concerne les salons.

Note : en ce qui concerne les serveurs d’identité (c’est optionnel), pour  l’instant, il vaut mieux rester sur ceux de matrix.org.

Héberger un utilisateur n’est pas anodin, tout comme quelqu’un peut abuser de sa messagerie, un utilisateur de votre homeserver peut rejoindre un salon très fréquenté et surcharger ainsi votre homeserver (qui devra répliquer le salon).
Cependant, si votre homeserver est rapide (processeur puissant et beaucoup de mémoire vive, ou pas beaucoup de charge), les utilisateurs de votre homeserver auront de meilleures performances pour se connecter et échanger des messages (même si les messages envoyés mettront du temps à être répliqués sur les autres homeservers surchargés).

Différence avec XMPP

La FAQ de Matrix présente elle‐même les différences avec XMPP : What is the difference between Matrix and XMPP?.

Mais, essentiellement, on peut dire que :

  • XMPP est une spécification pour qu’un système puisse échanger des messages. Elle peut être étendue par un ensemble « d’extensions » élémentaires, dont la plupart sont optionnelles ;
  • Matrix est une spécification pour qu’un système puisse stocker des données arbitraires (« events ») et définit un moyen de synchroniser et résoudre les conflits entre les serveurs fédérés. Il n’y a pas de spécifications d’extensions comme XMPP, mais Matrix inclut nativement beaucoup plus de fonctionnalités (ils parlent eux‐mêmes de « kitchen sink ») afin de garantir que les différents clients disposent de fonctionnalités compatibles.

La relation entre XMPP et Matrix est abordée un peu plus loin dans Concurrence avec les autres protocoles décentralisés.

Implémentations

Matrix n’est qu’une spécification, et il y a pleins d’implémentations différentes de serveurs et de clients disponibles. Mais, notons en particulier :

  • Synapse est l’implémentation de référence actuelle du serveur (appelée usuellement homeserver) et son futur remplaçant est Dendrite (qui semble être environ 300 fois plus rapide !). Il est aussi sous licence Apache v2 ;
  • Riot est un client multi‐plate‐forme qui semble être de loin le plus populaire (fonctionne sous un navigateur, sous iOS, sous Android et sous forme d’application indépendante sur votre bureau). Il est aussi sous licence Apache v2.

Fonctionnalités

À terme, les solutions autour de Matrix permettraient de remplacer Skype, Whatsapp, Signal, Slack et Discord car voici les fonctionnalités incluses :

  • appels audio‐vidéo entre deux personnes ou bien audio et visio conférences entre plusieurs personnes ;
  • messagerie instantanée entre deux personnes ou pour un groupe, incluant la possibilité d’échanger photos, vidéos ou n’importe quel type de fichiers ;
  • chiffrement des communications de bout en bout ;
  • plusieurs clients peuvent être utilisés simultanément avec la même identité ;
  • en installant son propre homeserver, on peut fonctionner complètement en autonome ou bien en rejoignant la fédération.

Note : Cela pourra efficacement concurrencer Slack et Discord quand les fonctionnalités autour des groupes d’utilisateurs seront implémentées.
Note 2 : Des fonctionnalités autour de l’IoT et de la VR sont aussi prévues, mais je n’ai pas vraiment eu le temps de voir où cela en était.

Le problème

Remarquons tout de même que le fait de rassembler tous les usages dans un seul logiciel ou protocole a un effet de bord gênant : on est poussé à utiliser la même identité pour tout. Avec plusieurs logiciels il est plus naturel de jongler avec plusieurs identités pour éviter de mélanger (par exemple identité professionnelle sous Slack, identité gamer sous Discord, identité personnelle sous Whatsapp et identité publique sous IRC).
Pour l’instant le multi‐utilisateur est encore à l’étude.

Tutoriel d’installation

Vous pouvez suivre cet excellent tutoriel : Run your end‐to‐end encrypted chat server using Matrix and Riot.

Par défaut, Matrix et Synapse utilise le serveur STUN de Google (issue 501) car c’est utile pour faire fonctionner l’audio‐vidéo si vous êtes derrière une box de FAI, par exemple.

Pour l’instant, pour être vraiment indépendant de Google ou si vous voulez traverser un pare‐feu difficile (typiquement dans une entreprise), vous pouvez installer un serveur TURN. Voici comment faire avec Synapse et coturn.

Riot, un client populaire

Afin de vous faire une idée de Matrix et Riot, rien de plus facile que d’aller sur l’application Web Riot pour, par exemple, accéder au salon #riot:matrix.org regroupant les développeurs et la communauté Riot (pas de création de compte requise) ou se créer un compte et ensuite discuter avec l’agent conversationnel (chat bot) @riot-bot:matrix.org. Cela permet de se faire une idée des possibilités avant d’installer l’application sur votre bureau ou sur votre téléphone mobile.

Je vous invite d’ailleurs à venir faire un tour ici pour discuter de la dépêche : accès au salon LinuxFr via le client Riot.

Riot client

À noter que Riot n’est pas encore complètement finalisé, mais qu’il y a une certaine attention aux détails. Par exemple, l’implémentation des notifications poussées est intéressante : Riot’s magical push notifications in iOS.

En revanche, l’application Riot sous Android peut être très gourmande en énergie lorsque Google Cloud Messaging n’est pas disponible (par exemple, en utilisant F-Droid sans installer les GApps), car dans ce cas‐là les notifications poussées ne fonctionnent pas.

Le projet peut‐il réussir ?

La notion de réussite est bien entendu toute relative. Mais, dans le cas d’un outil de communication, la réussite peut se mesurer à la taille du réseau (loi de Metcalfe), car l’outil n’a que peu d’utilité s’il n’y a pas grand monde avec qui communiquer (et il sera alors inévitable que son développement stagne ou périclite).

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

Note : Il y aussi le succès chinois impressionnant de WeChat, mais son succès est plus difficile à analyser du fait de la politique d’intervention chinoise.

Des messageries instantanées tentent actuellement de percer en se lançant sur le créneau du chiffrement (ou de la vie privée) : Signal ou Telegram.

Note : Chiffrement n’entraîne pas forcément l’impossibilité de censure, comme on vient de le voir avec Telegram qui accepte de supprimer des contenus terroristes.

Si l’on regarde les caractéristiques qui définissent Matrix, on peut se demander si ce sera suffisant pour réussir :

  • logiciel libre : à fonctionnalité équivalente, je ne suis même pas sûr que cela pèse significativement dans la balance par rapport à d’autres facteurs (marketing, par exemple) ;
  • décentralisé : je ne connais aucun logiciel ayant vraiment réussi grâce à sa fonctionnalité de décentralisation ;
  • intégration des fonctions de plusieurs logiciels : le risque est certainement d’être moyen ou bon partout mais pas exceptionnel sur un point en particulier (« Jack of all trades, master of none ») ;
  • interopérable : on pourrait presque penser que c’est un handicap car cela ne pousse pas les utilisateurs à changer.

On peut citer les succès et échecs relatifs du protocole XMPP, de logiciels interopérables comme Trillian ou Pidgin, de Google+ ou Google Hangouts. Cependant, il y a d’autres contre‐exemples comme Facebook Messenger, Apple Facetime, Slack ou Discord, dont les succès ont peut‐être plus à voir avec une expérience utilisateur excellente (en particulier au niveau intégration) qu’avec une technique excellente.

Une des leçons à retenir avec XMPP, est le cas Google Talk. L’un des dangers avec un protocole ouvert c’est qu’un des acteurs utilise la technologie pour attirer les utilisateurs pour ensuite en profiter pour pousser leur propre technologie en parallèle (qui sera, bien entendu, bien mieux compatible avec ses propres services). Et c’est peut‐être exactement ce qu’a fait sciemment ou inconsciemment Google Talk.

Au niveau de la concurrence, outre les protocoles XMPP, IRC et SIP, voici donc quelques logiciels dont les fonctions sont actuellement plus ou moins couvertes par Matrix :
Skype, Whatsapp, Signal, Slack, Discord, Tox, Ring, Wire, SecuShare (Psyc), Zyptonite, Wickr, Telegram, Ricochet, ChatSecure, MatterMost, Mumble, Jitsi, Threema, Briar, Viber, Facetime, Google Hangouts, Google Duo, Mastodon, Facebook Messenger, Semaphor, Trello, Ricochet, OnionShare, Kik, SnapChat, Asana, HipChat, TeamSpeak, Delta Chat, BlueJeans, Jabber

Enfin, même Amazon vient de se lancer sur le créneau avec son Anytime (sans doute pour imiter le succès de WeChat).

Certains ont tenté de comparer les différentes solutions entre elles :

On voit donc que le chemin semble relativement ardu pour Matrix, ils n’ont clairement pas choisi la voie la plus facile (et c’est tout à leur honneur).

Mais il semblerait que l’engouement soit là ; si l’on regarde ces deux graphiques :

Nombre d’utilisateurs
Total du trafic

Encore un autre standard ?

Je mets le lien vers le fameux comics XKCD, car de toutes façons il y aura toujours quelqu’un pour le faire :
Standards

Les développeurs de Matrix (et à ce stade presque tous les développeurs) sont conscients de ce comics et des écueils associés. Ils ont quand même le mérite de tenter de résoudre le problème plutôt que de juste se satisfaire de l’état existant.

Concurrence avec les autres protocoles décentralisés et passerelles

Les protocoles décentralisés ne sont pas vraiment en « concurrence » les uns avec les autres au sens traditionnel du terme.
La plupart des développeurs travaillant sur le thème de la décentralisation partagent souvent la même idéologie et les mêmes objectifs, souvent en opposition avec toute une industrie essayant de garder leurs utilisateurs en otages dans leurs silos respectifs (cf. discussion sur le sujet).

Du coup, la valeur d’un réseau décentralisé est à évaluer (loi de Metcalfe) en fonction de l’ensemble des utilisateurs des réseaux décentralisés (pour peu qu’il existe des passerelles entre les réseaux).

Ainsi, Matrix peut fonctionner avec des passerelles (bridges) permettant de communiquer avec d’autres réseaux et protocoles (comme IRC ou XMPP) : Matrix Application Services.

XKCD Matrixified v2

Pourriel

On peut affirmer sans trop se tromper que le courriel indésirable, autrement appelé pourriel ou spam en anglais, est un des fléaux qui empoisonnent l’utilisation du courrier électronique.
Cela atteint un tel point qu’il devient difficile d’héberger son propre serveur de messagerie, car on peut être rapidement placé sur liste noire (« blacklisté ») par les principaux fournisseurs de messagerie électronique (Gmail par exemple). La conséquence indirecte est que cela a tendance à concentrer les pouvoirs dans un nombre plus restreint de fournisseurs (et donc à dé‐fédérer).

Actuellement, il n’y a pas grand‐chose de disponible pour lutter contre les abus (pourriels, propagande, messages injurieux, alternative factsfake news et autres). Il n’y a même rien en développement si ce n’est une grosse réflexion sur ce qu’il faudrait faire. Si vous avez des idées sur le sujet, c’est le moment idéal pour participer.

Mais cela pourrait être un axe très intéressant de développement car c’est un problème contre lequel butte tous les grands acteurs comme Google, Facebook ou Twitter (à l’aide de milliers de modérateurs).

Conclusion

Pour mon cas d’utilisation (discussions informelles entre amis et avec la famille), l’état actuel est complètement utilisable. Un soin particulier a en effet été apporté pour que l’interface utilisateur soit accessible et pas trop confuse. Du coup, je n’ai pas eu de difficulté particulière à convaincre des utilisateurs à me rejoindre (ils ont juste eu à aller sur leur magasin d’application favori et de télécharger l’application).

Limitations

Pour vous donner une idée un peu concrète des limitations actuelles, voici quelques exemples de soucis que j’ai rencontrés pour mon cas d’utilisation (cependant, d’autres personnes auraient sans doute choisi de souligner d’autres choses plus importantes à leurs yeux).

Pour celui qui administre un homeserver, la gestion est encore très manuelle :

Le chiffrement de bout en bout (e2e encryption) fonctionne sur le principe, mais il reste du travail pour que ce soit vraiment utilisable :

  • l’identité des participants d’un salon est (pour l’instant) toujours en clair ;
  • les métadonnées associées aux messages sont aussi (pour l’instant) toujours en clair ;
  • l’interface utilisateur pour échanger les clefs entre clients est encore très manuelle et assez pénible (issue #2996) ;
  • quelqu’un rejoignant en cours de route un salon chiffré n’a pas accès aux messages précédant son arrivée (issue #2286).

La visioconférence à plusieurs (trois personnes et plus) ne fonctionne pas très bien et nécessite que votre homeserver soit fédéré (mais la migration vers une solution autour de Jitsi est en cours) (issue #1869).

La gestion de groupes d’utilisateurs (afin de pouvoir concurrencer Slack et Discord) est prévue très prochainement, mais n’est pas encore disponible (issue #3842).

Le partage d’écran dans une discussion vidéo fonctionne mais n’est pas encore vraiment public (il faut cliquer sur le bouton vidéo en maintenant appuyée la touche majuscule) et il n’est pas encore possible de partager juste une fenêtre (issue #3025)

Il n’y a pour le moment rien pour lutter contre le pourriel, cela tombe bien, car il n’y en a pas encore. Ce serait presque une marque de reconnaissance, « un problème que l’on aimerait avoir », car cela signifierait que le succès est suffisamment indéniable pour que les spammeurs s’intéressent à Matrix.
En particulier, votre identité d’utilisateur (par exemple @nom:example.com) n’est pas très privée et se retrouve sur l’annuaire public des utilisateurs (user directory) dès que vous participez à un salon public (un peu comme si votre adresse de courriel se retrouvait dans un annuaire global public si vous êtes présent dans une liste de diffusion publique).

Enfin, il faut avouer que le nom « Matrix » n’est pas très « SEO‐Friendly » et évolue peut‐être en terrain miné. Si, par exemple, on cherche « Matrix IoT », on tombe sur un autre Matrix qui se présente comme « The World’s First IoT App Ecosystem ». De même, si l’on cherche « Matrix VR », on tombe sur plein de résultats qui n’ont rien à voir avec Matrix.org.

Aider le projet Matrix

Matrix est développé depuis 2014 sous l’impulsion initiale de deux employés de Amdocs : Matthew Hodgson et Amandine Le Pape (qui est inscrite sur LinuxFr !). Aujourd’hui, Matrix.org n’a pour l’instant pas de statut particulier (association à but non lucratif ou fondation, par exemple).

Matrix s’est développé très rapidement ces derniers temps, grâce au fait que onze personnes étaient payées ou sponsorisés par Amdocs (et aussi OpenMarket) pour travailler spécifiquement dessus. Cependant, la société a décidé dernièrement de réduire les fonds alloués de 60 %, ce qui met le projet soudainement dans une situation difficile.

Les développeurs font donc appel à la communauté pour pouvoir en partie financer le développement : A Call to Arms: Supporting Matrix!

Aller plus loin

  • # cool

    Posté par  . É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  . É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  . É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  . É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  . É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  . Évalué à 3.

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

          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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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

  • # Excellent article, bravo!

    Posté par  . É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  . É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  (site web personnel) . É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.

  • # chiffrage !!?

    Posté par  . É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…

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

    Posté par  (site web personnel, Mastodon) . É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  . É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  . É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  . É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  (site web personnel, Mastodon) . É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  . É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  . É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  . É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  . É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  (site web personnel, Mastodon) . É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  . É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  (site web personnel, Mastodon) . É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  . É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  (site web personnel, Mastodon) . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . Évalué à 4.

      ou edonkey évidemment.

    • [^] # Re: Décentralisation

      Posté par  . É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  (site web personnel, Mastodon) . É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  . É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  . É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  . É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  . É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 ?

          Decentralized_vs_distributed

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

            Posté par  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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  . É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  (Mastodon) . É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.

                  Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

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

                    Posté par  . É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  . Évalué à 2.

              Ça représente bien Internet pourtant.

  • # RC ou IRC ?

    Posté par  . É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.
  • # Friture tueuse

    Posté par  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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.