Journal Qui veux débattre Messagerie Instantané au Jardin Entropique

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
5
6
juin
2015

Jardin Entropique ? WTF ? Ben c'est un Festival qu'on organise a Rennes le W/E 2015-06-26 to 28 thématique FLOSS, Hacker, DIY, Maker voire meme NumericoNumerique c'est pour dire a quel point ca ratisse large (bref voila pour l'autopromo…)

http://jardin-entropique.eu.org/

Au programme de l’événement, j'aimerais attirer votre attention sur le projet Matrix !

Connaissez vous la matrice ? la N-ieme messagerie unifié et décentralisé ?

J'ai pas mal de sympathie pour ce projet et ses membres, car j'ai l'impression que le problème de la messagerie n'est tjr pas réglée..

A ce jour j'ai tendance a me cantonner a IRC (irc://irc.freenode.net/#breizh-entropy ) et XMPP (qui remplissent tres bien leur job) un peu de WebRTC mais j'ai aussi envie d’expérimenter des choses differentes (en parlant de techno extraterrestre GNUnet sera aussi présenté au #JardinEntropique aussi)

Bref pour les curieux, pour vous donner un avant gout :

https://matrix.org/blog/2015/02/04/back-from-fosdem/

Et pour ceux qu'ils veulent quitter le monde réel pour entrer dans la matrice quelles sont vos envies et attentes d'un systeme de messagerie (ou alertes signalitique iot etc) ?

  • # Ça ca parler de Matrix ou de l'IM en général au final ?

    Posté par  (site web personnel) . Évalué à 3.

    J'ai l'impression que le débat va plutôt tourner autour de Matrix.
    Néanmoins je trouve ça dommage de voir un énième protocole de messagerie apparaitre… comme si on en avait pas assez.

    • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

      Posté par  . Évalué à 1.

      L'idée c'est de présenter Matrix pour expliquer pourquoi un nouveau protocole, ce qu'il a de différent mais aussi d'ouvrir le débat et de discuter avec ceux qui auraient des questions/doutes/désaccords avec notre initiative. Surtout que nos specs sont flexibles et qu'il doit avoir l'adhésion du plus grand nombre pour avoir du succès, donc nous sommes ouverts aux retours/commentaires/suggestion de tous :)

      • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

        Posté par  . Évalué à 4.

        Je crois que l’idée derrière le commentaire d’edhelas c’est ça :

        Standards

      • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

        Posté par  . Évalué à 3.

        Je suis quand même de l’avis des autres, à première vue encore un autre protocole de messagerie instantané n’est pas souhaitable, et cela pour plusieurs raisons.
        - Encore un autre.
        - L’effet réseau est quelque chose de très difficile à faire démarrer même en ayant de bons arguments.
        - XMPP offre déjà un protocole de messagerie instantané qui permet beaucoup de choses, et pour le reste il permet d’en ajouter plus tard le support avec les XEP.
        - Une nouvelle dilution des compétences, des réseaux.

        Je reste toujours ouvert à des alternatives bien entendu, simplement dans le cas présent j’ai du mal à voir comment un protocole peut faire mieux qu’XMPP.

        Donc si tu pouvais expliquer en quelques lignes les avantages de matrix sur XMPP, ça serait intéressant de lancer également le débat ici.

        • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

          Posté par  . Évalué à 2.

          Oui XMPP est une bonne base, mais on essaie de prendre un angle d'approche différent: Matrix est un système de synchronisation de données, n'importe quel type de données, Matrix y est agnostique (messages instantanés, signalisation d'appel WebRTC, données d'IoT…). C'est une architecture distribuée dans laquelle les données sont persistées, n'importe qui peut déployer son serveur et garder le contrôle de ses données. En fait Matrix peut être considérée comme une grande base de données éventuellement cohérente.
          L'idée c'est d'être pragmatique (APIs HTTP) et avoir une baseline de fonctionnalités qui correspondent à celles qui sont indispensables ds la messagerie d'aujourd'hui: historique par défaut, chat de groupe par défaut, échange de n'importe que type de fichier. Matrix permet aussi de l'encodage bout en bout.
          Le mieux c'est d'aller jeter un œil sur http://matrix.org et chatter sur https://matrix.org/beta/#/ pour entrer en contact avec les experts. Ou bien sûr venir nous voir au Jardin Entropique :)

          • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

            Posté par  . Évalué à 1.

            Merci pour cette réponse

            Je n'arrive pas à accéder au site http://matrix.org (erreur 504), c'est bien dommage puisque j'ai pas mal de questions sur le sujet.

            Un intéressant commentaire à vous :

            Il faut noter que Matrix et XMPP résolvent différents problèmes. Matrix est dans les faits une base de donnée éventuellement synchronisée avec fédération ouverte et sémantique de pubsub : tout est question de synchronisation d’états.
            XMPP est centré sur de la messagerie fédérée, envoyant des stanzas tout autour plutôt que de synchroniser l’historique de conversation. En fait Matrix n’a même pas le concept d’envoi de message dans la fédération en tant que tel, la seule chose que tu peux faire c’est synchroniser la structure de données de l’historique.
            Donc pour nous Matrix n’est même pas une compétition de XMPP : tu veux un historique de conversation décentralisé? Utilise Matrix. Tu préfères du transfert de message rapide et « stateless »? Utilise XMPP.
            On est aussi en train de développer, entres autres, un bridge XMPP<->Matrix, pour que XMPP puisse fédérer avec Matrix (ainsi qu’un bridge SIP et d’autres), donc ce n’est pas comme si on voulait à tout prix fragmenter encore plus l’écosystème, au contraire : l’idée de Matrix est de défragmenter tout ça et faire interopérer les protocoles qui existent!

          • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

            Posté par  (site web personnel) . Évalué à 9.

            Matrix y est agnostique (messages instantanés, signalisation d'appel WebRTC, données d'IoT…)

            Pour la signalisation d'appels WebRTC il y a Jingle dans XMPP avec entre autres :

            Jingle est déjà implémenté dans de nombreux clients tel que Jappix (via WebRTC) ou Jitsi (https://jitsi.org/).

            Pour l'IoT :

            Avec des intérêt par des industriels tel que Cisco (http://blogs.cisco.com/ioe/beyond-mqtt-a-cisco-view-on-iot-protocols).

            C'est une architecture distribuée dans laquelle les données sont persistées, n'importe qui peut déployer son serveur et garder le contrôle de ses données.

            Je chipote un peu mais c'est également le cas de XMPP.

            historique par défaut

            chat de groupe par défaut

            échange de n'importe que type de fichier

            Matrix permet aussi de l'encodage bout en bout.

            XMPP supporte l'authentification SASL, le chiffrement est maintenant obligatoire entre les serveurs (voir l'initiative https://xmpp.net/) et très souvent sur les clients (via StartTLS). Pour du chiffrement bout en bout des normes comme OTR sont maintenant largement déployés sur les clients XMPP (même si je trouve ça pas très très propre sur le coté protocolaire).

            Je me suis penché sur Matrix il y a quelques semaines, car je me suis demandé qu'est ce qui pouvait pousser un groupe de développeurs à vouloir réinventer un nouveau protocole pour une énième fois alors que XMPP semble offrir tout ce qu'il faut.

            Mais bon j'ai bien eu l'impression qu'il s'agissait plus d'une envie de repartir sur une nouvelle base au lieu de prendre le chemin de la difficulté et d'avoir à travailler avec la XSF pour améliorer/compléter XMPP.

            Si c'est l'interconnexion avec le Web qui les embêtes :

            Et même :

            Oui, lire des normes c'est compliqué, et on est pas toujours d'accord avec ce qui est écrit. Mais quand le protocole est utilisé par des dizaines de serveurs utilisés par des universités, entreprises, multinationales, gouvernements, particulier; des centaines de clients sur toutes les plateformes et a plus de 15 ans d'ancienneté avec plusieurs RFC à l'IETF c'est plus compliqué de mettre tout le monde d'accord :) Pour le reste j'ai déjà écrit un commentaire là dessus il y a quelques jours http://linuxfr.org/nodes/105862/comments/1606599.

            Le dernier point que je voulais aborder concerne l'une des spécificités de Matrix : fonctionner en HTTP.
            Je pense que cette décision est une grave erreur, pourquoi ? Car HTTP amène un overhead énorme (oui c'est considérable quand il s'agit de gérer des listes de 400 contacts avec plusieurs dizaines de connections, des salons et des messages dans tous les sens). De plus cantonner un protocole "social/IM" au Web uniquement a une conséquence terrible : c'est compliqué de faire autre chose que du Web.

            Le Web n'est qu'une petite partie d'Internet. Donc quand on base un protocole sur des technologies Web (HTTP en l'occurence) c'est plus difficile d'en sortir.

            Et quand je vois ça dans la documentation de Matrix (http://matrix.org/docs/howtos/client-server.html) :

            Getting live state
            This will block waiting for an incoming event, timing out after several seconds. Even if there are no new events (as in the example above), there will be some pagination stream response keys. … If it has been a long period of inactivity, there may be LOTS of events waiting for the user. In this case, you may wish to get all state instead and then resume getting live state from a newer end token.

            C'est ce qu'on appelle plus communément du long-polling, j'ouvre une requête HTTP, le serveur me répond quand il a quelque-chose à dire et j'en renvoie une autre derrière. Croyez moi sur des grosses charges ça ne tiens pas. Si vous voulez avoir du temps réel faite du socket (pure TCP ou WebSocket), encore une fois vous vous compliquez la vie et vous allez compliquer la vie des clients qui souhaiteraient faire du "vrais" temps réel et qui devront le simuler en utilisant des librairies comme Curl pour recréer un système évènementiel derrière.

            • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

              Posté par  (site web personnel) . Évalué à 1.

              Je te remercie pour toutes ces précisions… sinon ca me semble un prerequis de pouvoir communiquer sur http
              quitte a faire du TCP over http ou je ne sais quelle horreur…
              Car on ne peux dire que la tendance des usages d'internet (du moins en france) soit a l'ouverture…

              Peut etre meme prendre un peu d'avance en se remettant au minitel (surtout depuis que le reseau est down) ;(

              Une autre idée qui me trote par la tête , pensez vous qu'il est possible de faire de passerelles et/ou emuler des services existants sans changer les applications clientes … je m'explique en hackant plus ou moins son OS (mobile) il me semblerait possible d'utiliser un client farcebook par example et rediriger le trafic vers sur son instance cloud perso supportant les meme APIs … au final l'experience utilisateur reste inchangée (reste qd meme la partie Auth, crypto a hijacker et je passe sur l'aspect legal d'un tel usage car si ca peut etre benefique dans ce cas ca pourrait ne pas l'etre dans un autre…)

              Bref je m’égare un peu de la messagerie instantanée mais la problématique est du même ordre … il me semble d'ailleurs que ce w/e @nitot de cozycloud a insisté sur ce point … mais on en reparlera dans un autre contexte.

              gpg:0x467094BC

            • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

              Posté par  . Évalué à 2.

              (writing in English to avoid further google translate confusion; apologies. also, my phone lost my first attempt to answer this so apologies for terseness)

              Edhelas: thanks for list of XEPs. I think you are missing the point: the current typical dialect of XMPP revolves around 1:1 IMs and XEP-45 MUCs. If I am talking in a MUC with JID foo@bar.com and the server(s) at bar.com go down, i lose the whole conversation - including the conversation history if it's implementing XEP-313. This is a major design flaw: conversations should be owned by the people participating in them; not any single party or vendor. Plus with a decentralised approach you get offline operation and merging history after netsplits for free.

              You could implement these semantics on top of XMPP, which is what FMUC and BuddyCloud do - but you are effectively creating a whole new dialect (with very limited compatible server and client implementations, increasing fragmentation) just using XMPP as a basic message passing transport. So we decided to skip XMPP altogether and just use plain HTTP API with a higher set of baseline functionality (whilst still being extensible), rather than arbitrarily build on XMPP given the end result wouldn't be compatible with normal MUCs and XMPP IMs anyway. (We also only discovered the BC and FMUC XEPs after designing and launching Matrix).

              I'm sorry that the existence of Matrix seems to upset some people who have successfully invested in XMPP. If XMPP works for you, then we're very happy and we're not stopping you. And we'll provide an XMPP s2s to Matrix bridge to let you enjoy Matrix too.

              In terms of your concerns on HTTP long polling: with HTTP/2 it's really not that bad and only slightly worse than websockets. And anyway we only mandate plain HTTP as a baseline protocol for compatibility - if you want to put JSON or capn proto over WS or COAP or MQTT or whatever than go for it :)

              Edhelas: this is the third time we've had the same discussion - if it still doesn't make sense please tell me what is confusing so we don't get stuck in groundhog day…

              • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

                Posté par  (site web personnel) . Évalué à 1.

                Edhelas: thanks for list of XEPs. I think you are missing the point: the current typical dialect of XMPP revolves around 1:1 IMs and XEP-45 MUCs. If I am talking in a MUC with JID foo@bar.com and the server(s) at bar.com go down, i lose the whole conversation - including the conversation history if it's implementing XEP-313. This is a major design flaw: conversations should be owned by the people participating in them; not any single party or vendor. Plus with a decentralised approach you get offline operation and merging history after netsplits for free.

                Sur l'idée d'avoir des MUC décentralisés je te l'accorde c'est bien sympa et en effet sur XMPP c'est pas pensé comme ça. Mais encore une fois ce sont des choses qui peuvent être imaginés et étendues sans soucis.

                Concernant le fait de perdre l'historique si le serveur tombe, ce n'est pas totalement vrais. MAM permet de garder un historique sur notre propre serveur, même si le serveur distant n'est plus disponible.

                You could implement these semantics on top of XMPP, which is what FMUC and BuddyCloud do - but you are effectively creating a whole new dialect (with very limited compatible server and client implementations, increasing fragmentation) just using XMPP as a basic message passing transport. So we decided to skip XMPP altogether and just use plain HTTP API with a higher set of baseline functionality (whilst still being extensible), rather than arbitrarily build on XMPP given the end result wouldn't be compatible with normal MUCs and XMPP IMs anyway. (We also only discovered the BC and FMUC XEPs after designing and launching Matrix).

                C'est ici que je ne suis pas d'accord avec toi. XMPP (Extensible Messaging and Presence Protocol) n'est pas/plus Jabber. Aujourd'hui le "cœur Jabber" n'est plus qu'une petite partie du protocole, mais je te l'accorde ici aussi, oui ça a été construit "par dessus" donc il y a encore l'état d'esprit du protocole original.

                Par ailleurs, XMPP n'a pas vocation a être implémenté dans sa totalité par les clients et serveurs, libre à vous de choisir/casser ce qui vous plait, ou pas, dans XMPP. Mais le fait de garder une architecture commune permet de limiter la difficulté quand il s'agira de construire les "ponts" entre les réseaux.

                I'm sorry that the existence of Matrix seems to upset some people who have successfully invested in XMPP. If XMPP works for you, then we're very happy and we're not stopping you. And we'll provide an XMPP s2s to Matrix bridge to let you enjoy Matrix too.

                Et je pense qu'il y aura également des transports XMPP vers le réseau Matrix :) Ce n'est pas la première fois qu'on essayera de créer un pont en utilisant une interface Web, je viens de packager 2 librairies (pour le réseau Skype et QQ) qui passent par une interface Web pour interagir avec leurs réseaux respectifs (voir http://edhelas.movim.eu/blog/?post/2015/06/06/Packaging%2C-d%C3%A9ploiement-et-int%C3%A9gration-de-nouveaux-transports-XMPP) .

                In terms of your concerns on HTTP long polling: with HTTP/2 it's really not that bad and only slightly worse than websockets. And anyway we only mandate plain HTTP as a baseline protocol for compatibility - if you want to put JSON or capn proto over WS or COAP or MQTT or whatever than go for it :)

                HTTP/2 est encore très loin d'être déployé et utilisé partout, mais en effet les avancées faites vont considérablement réduire la signalisation et le temps de latence lors de l'échange des données.

                Dans mon projet j'ai fait le chemin inverse, je suis partit du long polling HTTP pour aller vers les WebSockets, puis sur du Socket simple. Pensez aussi aux mobiles, le long-polling implique systématiquement un "ping" pour savoir si la ressource est encore disponible, le mobile/navigateur risque donc d'envoyer des centaines/milliers de requêtes quotidiennement pour simplement garder une connexion ouverte sur le serveur.

                Edhelas: this is the third time we've had the same discussion - if it still doesn't make sense please tell me what is confusing so we don't get stuck in groundhog day…

                Oui nous en avons déjà parlé mais sans avoir le temps de creuser exactement les points où nous n'étions pas d'accord. Je sais que je donne des fois l'impression d'être quelqu'un de têtu mais je trouve dommage d'avoir un explosion de protocoles d'IM (tant libre que propriétaires) et de passer notre temps a écrire des librairies de transports alors qu'il existe déjà tout ce qu'il faut comme standard dans la nature.

                Ne pas être d'accord ou essayer de penser "hors de la boite" est super, c'est d'ailleurs l'essence même de ce que fait le logiciel libre. Mais ce qui caractérise aussi le libre c'est l'utilisation des standards. On a réussit à se mettre d'accord sur beaucoup d'entre elles, mais ça bloque pour l'IM/social et ça fait maintenant 5 ans que je pense que XMPP a la possibilité de devenir une norme universelle au même niveau que IMAP/SMTP/POP ont fait ce qu'on appelle aujourd'hui "l'email".

                D'ailleurs ce qui est rigolo c'est qu'une fois qu'une norme arrive a émerger, l'innovation tend à se faire finalement plus sur les clients avec le temps. IMAP/SMTP/POP ça n'a pas fondamentalement changé depuis des années, pourtant on a eu Outlook, Thunderbird, les webmails, les clients mobiles avec plein d'interfaces… pareil pour le Web, pendant des années on s'est tapé dessus pour normaliser tout ça et au final, une fois que tout le monde s'est mis d'accord (HTML5…) on a vu ce que ça a donné : des applications web dynamiques, des systèmes d'exploitation (FirefoxOS), des intégrations poussées (notification, visio-conférence…) sur toutes les plateformes inimaginables.

                Donc oui les normes c'est chiant, mais on fait avec. Je vais te faire une confidence, je n'aime pas particulièrement certains trucs dans XMPP, j'ai déjà eu des échanges assez mouvementés avec la XSF (comme sur certains problèmes relatifs à PubSub http://wiki.xmpp.org/web/PubSubIssues ou sur les Bookmarks http://mail.jabber.org/pipermail/standards/2014-April/028833.html), mais bon je fais avec. Mais je préfère prendre du temps pour discuter, proposer des corrections et faire évoluer tout ça. Et finalement le temps que je vais prendre pour "casser des choses" dans XMPP sera tout autant de temps gagné pour les autres projets qui souhaitent intégrer ces fonctionnalités/changements.

                • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

                  Posté par  (site web personnel) . Évalué à 2.

                  Pensez aussi aux mobiles, le long-polling implique systématiquement un "ping" pour savoir si la ressource est encore disponible, le mobile/navigateur risque donc d'envoyer des centaines/milliers de requêtes quotidiennement pour simplement garder une connexion ouverte sur le serveur.

                  Malheureusement il faut aussi souvent faire du heart beating pour ne pas perdre une oueb chaussette, c'est moins lourd, mais bon…

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

          • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            Matrix peut être considérée comme une grande base de données éventuellement cohérente.

            Éventuellement cohérente ?
            Sérieusement ?

        • [^] # Re: Ça ca parler de Matrix ou de l'IM en général au final ?

          Posté par  (site web personnel) . Évalué à 2.

          L’effet réseau est quelque chose de très difficile à faire démarrer même en ayant de bons arguments.

          Justement, l'un des points forts de Matrix est qu'il permet de réutiliser une identité qui existe déjà ailleurs pour s'authentifier dans le réseau. Pas besoin de créer un nouveau compte.

          j’ai du mal à voir comment un protocole peut faire mieux qu’XMPP.

          Ben il suffit d'observer. XMPP c'est super hein, techniquement on peut faire plein de trucs avec, yapluka déployer. Sauf que c'est ce yapluka qui me chagrine, et qui fait qu'en pratique très peu de personnes font, et XMPP n'est toujours pas le protocole qui domine le domaine. On pourrait dire que c'est IRC qui reste le protocole majoritaire des salons de discussion publics (voire même privés), avec Slack qui commence doucement à lui manger des parts (surtout dans les privés). Il n'y a pas encore de protocole d'IM un poil ouvert qui soit majeur, pour le microblogage encore moins, pour la diffusion d'informations il y a très clairement RSS+HTTP qui se fait doucement manger par Twitter…

          Bref, XMPP est tip top techniquement mais il n'a pas su être suffisamment convaincant pour devenir une référence (dans le sens "Nan mais allo quoi, tu fais de la messagerie instantanée/des salons de discussion/du pubsub/de la communication entre entités en général mais t'utilises pas XMPP"). De ce point de vue j'ai du mal à voir comment Matrix fera la différence cela dit, mais pourquoi pas !

Suivre le flux des commentaires

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