URL: https://linuxfr.org/users/outs/journaux/pas-seul-dans-la-matrice Title: Pas seul dans la matrice Authors: Joris R Date: 2015年02月15日T17:10:41+01:00 License: CC By-SA Tags: matrix, chat, xmpp, irc, protocole et lwn Score: 51 En lisant d'un œil distrait le flux RSS de [LWN](http://lwn.net/) je suis tombé sur un [article](http://lwn.net/Articles/632572/) sur un nouveau protocole nommé [Matrix](http://matrix.org/). Bon je suis moyennement convaincu par la pertinence du nom mais bon passons. Donc l'idée est d'avoir un nouveau protocole de discussion de groupe (style IRC) fonctionnant avec une fédération de serveur. Là normalement vous vous dites : "Encore un nouveau protocole de *chat*, pourquoi ne pas utiliser XMPP ou IRC ?". Bon déjà vous faites ce que vous voulez (et moi aussi), et les mecs peuvent bien créer un nouveau protocole si ça leur chante. Bon après je trouve qu'ils ont trouvé un concept qui enfonce les deux concurrents sus-cités. Si j'essaye de résumer ce que j'ai compris : - il y a un ensemble de serveur qui communiquent entre eux, sans autorité centrale - les utilisateurs sont enregistrés à un serveur donné (jusqu'ici c'est comme XMPP) - la fonction de base c'est d'avoir desgroupes de discussion (un *MUC/channel* quoi) - les serveurs gèrent de manière distribué l'historique (complet) des MUC sous la forme d'un graphe orienté acyclique de message (un peu comme git) - quand un utilisateur envoie un message à son serveur, le message est inscrit dans le graphe, puis le graphe est fusionné entre les serveurs - après la fusion des graphes, les serveurs envoient les nouveaux messages à leurs utilisateurs respectifs. Du coup on se retrouve avec gestion vraiment décentralisé (sans *single point of failure*) de MUC avec historique. Et c'est une chose qui n'est pas faisable avec XMPP ou IRC (sans modification profonde de leurs fonctionnement actuel évidement). C'est plutôt utile : par exemple plus besoin de rester AFK dans un chan IRC juste pour savoir ce qu'il ci passe, pas de perte non plus quand il y a un problème technique quelconque , pas de netsplit entre les serveurs (enfin plus exactement on peut retomber sur un état fusionné), on peut monter son propre serveur (en authentifiant les employés de sa boite par exemple) mais quand même participer dans tout les autres serveur et pas besoin de se prendre la tête avec cette hydre à douze têtes qu'est XMPP avec son obligation de s'abonner entre utilisateur (qui n'est qu'une des multiple façon dont on peut vouloir fonctionner). Pour troller un peu, je trouve l'approche beaucoup plus élégante qu'XMPP. Perso, ce qui me gène avec l'*Extensible Messaging and Presence Protocol* c'est justement son coté *extensible* : genre le système de MUC est complétement défini à coté du système de discussion normale. Alors que la discussion normale ne permet pas réunir plus de deux personnes, franchement ICQ le faisait déjà au millénaire précédent... Alors que si un protocole est conçu pour gérer la discussion à plusieurs de base, c'est trivial de rajouter une fonction de message privé sur la base définie. Mais là ils ont fait l'inverse et ça se sent quand on utilise les MUC. Et puis vraiment cette histoire de rendre le protocole extensible c'est gentil, mais au final on se retrouve avec une galaxie de logiciels client et serveur dont aucun ne gère proprement le même ensemble de fonctionnalités. Après si on compare avec IRC, ben c'est simple dans IRC il n'y a pas de décentralisation, pas de gestion de l'identité et pas d'historique des *channel*. Alors évidement il y a des solutions pour pallier ça mais c'est toujours des fonctions rajoutées par dessus le protocole de base. Voilà pour ce que j'en ai compris, perso je suis bien emballé par le concept de base. Reste à voir comment ça va prendre. D'ailleurs tout ça est encore en *alpha*.