Sommaire
Présentation
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.
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.
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.
À 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 :
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 :
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.
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!
