Matrix 2.0 est disponible : un protocole qui permet de créer des applications de communication ouvertes, décentralisées et sécurisées

Qui surpasseraient les alternatives centralisées courantes

Matrix 2.0 est disponible. Le protocole permettrait de créer des applications de communication ouvertes, décentralisées et sécurisées. Cette nouvelle version s'articule autour de 4 principes : Connexion instantanée, lancement instantané et synchronisation instantanée (Simplified Sliding Sync), Authentification de nouvelle génération (OIDC natif), VoIP/vidéo multipartite chiffrée native de Matrix (MatrixRTC), et chiffrement invisible. Matthew Hodgson, co-fondateur de Matrix, affirme que "les applications construites sur Matrix 2.0 peuvent sérieusement surpasser les alternatives courantes."

Matrix fonctionnerait un peu comme le courrier électronique, mais de manière instantanée et sécurisée : il faut ouvrir un compte auprès d'un fournisseur, mais quel que soit le fournisseur, il est possible de parler à des personnes utilisant d'autres fournisseurs. De la même manière qu'Outlook ou Thunderbird avec le même compte de messagerie, il est possible d'utiliser différentes applications Matrix pour le même compte Matrix.

Depuis sa création, l'objectif de Matrix a été de fournir un protocole permettant de créer des applications de communication ouvertes, décentralisées et sécurisées, plus performantes que les solutions centralisées classiques. Mais son parcours a été semé d'embûches : son équipe a essayé de faire fonctionner Matrix en 2014, puis la version bêta de Matrix 1.0 est sortie en 2019. Maintenant, ses développeurs veulent rendre Matrix rapide, utilisable et prêt pour le grand public avec Matrix 2.0.


Afin d'assurer la transition vers le grand public, Matrix 2.0 a été construit sur 4 principes :

1. Connexion instantanée, lancement instantané et synchronisation instantanée (Simplified Sliding Sync).
2. Auth de nouvelle génération (OIDC natif)
3. VoIP/vidéo multipartite chiffrée native de Matrix (MatrixRTC)
4. Chiffrement invisible.

Avec ce lancement de la version 2.0, Matrix peut désormais être utilisé pour créer des applications qui surpasseraient les alternatives courantes. Fait intéressant, Matrix 2.0 arrive dans un contexte où la décentralisation commence à s'accélérer. Par exemple, Bluesky a montré qu'il était possible de créer des applications sociales décentralisées suffisamment conviviales pour que les présidents les recommandent ; Elon Musk continue de détruire Twitter et de montrer l'importance de la décentralisation à tout le monde, et même Meta s'essaie aux médias sociaux décentralisés et à la communication décentralisée.


Voici l'état actuel de cette version :

1. Simplified Sliding Sync

Simplified Sliding Sync ou synchronisation coulissante simplifiée est la version finale de Sliding Sync - l'API qui permet la connexion, le lancement et la synchronisation instantanés dans Matrix 2.0. Pourtant l'API a connu de nombreuses itérations, mais cette version finale simplifie l'API Sliding Sync originale en supprimant entièrement le concept d'ordre de la liste des salles déterminé par le serveur, et en laissant le client trier la liste des salles selon ses besoins (tout en laissant le client paginer dans la liste des salles de manière incrémentielle, pour assurer une réactivité instantanée, quelle que soit la taille de votre liste de salles).

Le Simplified Sliding Sync est désormais implémentée nativement dans Synapse à partir de la version 1.114, et il n'est donc plus nécessaire d'exécuter un Sliding Sync Proxy pour utiliser l'API. En fait, le Sliding Sync Proxy est obsolète et l'ancien code Sliding Sync sera supprimé de matrix-rust-sdk dans un futur proche. Malheureusement, c'est sans la bande passante pour maintenir à la fois l'implémentation native Synapse et le proxy shim - et le proxy a inévitablement souffert de nombreuses limitations (par exemple, avoir à faire une synchronisation initiale v2 complète pour les nouvelles connexions, les ralentissant jusqu'à la performance v2 - ainsi que la duplication du stockage entre Synapse et le proxy).

En termes de performances, la synchro simplifiée native dans Synapse est meilleur. Fini donc le temps d'attente où l'application se synchronise, même en étant hors ligne depuis des semaines/mois ; fini le temps d'attente pour ouvrir une session.


2. Auth de nouvelle génération

Auth de nouvelle génération (Next Gen Auth) est la migration vers l'utilisation du standard industriel OpenID Connect comme API d'authentification dans Matrix 2.0, s'éloignant de l'API d'authentification personnalisée que Matrix a historiquement utilisée. Beaucoup de gens pensaient à tort qu'adopter OpenID Connect pour l'authentification signifiait des connexions sociales tierces ou l'authentification unique, mais ce n'est pas le cas pour Next Gen Auth.

Next Gen Auth remplace simplement les anciennes API d'authentification personnalisées de Matrix par des équivalents définis par l'OpenID Foundation ; après tout, Matrix est un protocole de communication, pas un protocole d'authentification. Cela permet des API d'authentification beaucoup plus matures et sécurisées - et l'accès à l'ensemble de l'écosystème du fournisseur d'identité OpenID, y compris la prise en charge de l'authentification à deux facteurs et de l'authentification à plusieurs facteurs, des jetons d'authentification matériels, des passkeys et des flux de connexion basés sur l'appareil (alias QR Login).

Les clients et les serveurs Matrix n'ont plus besoin d'implémenter l'ancienne surface d'API d'authentification Matrix, ce qui garantit que les utilisateurs ne transmettent le mot de passe de leur compte qu'à leur serveur d'authentification, plutôt que d'avoir à faire confiance à leurs clients pour le gérer en toute sécurité, ce qui est beaucoup plus pratique pour les gestionnaires de mots de passe (qui n'ont qu'à se rappeler comment s'authentifier auprès du serveur d'authentification, plutôt qu'auprès d'une myriade de clients différents). Il permet également de partager l'authentification entre les applications, et offre le rafraîchissement des access_tokens pour éviter que les access_tokens de longue durée ne traînent dans le coin, et à l'avenir, il supportera également les scopes OIDC afin de limiter l'accès de certains clients au compte.

En bref, Next Gen Auth est une transformation, et l'implémentation initiale à matrix-authentication-service (MAS) est prête à être déployée et utilisée par les administrateurs, mais elle n'est pas encore disponible sur matrix.org. L'un des avantages immédiats les plus évidents de Next Gen Auth est probablement la possibilité d'effectuer une connexion complète , y compris la mise en place d'un chiffrement de bout en bout, simplement en scannant un code QR sur un client existant. En d'autres termes, vous n'avez pas besoin de spécifier un serveur, ni votre nom d'utilisateur, ni le mot de passe de votre compte, ni votre clé de récupération - il vous suffit de scanner un code QR et c'est parti.


3. VoIP/vidéo native du groupe Matrix : MatrixRTC

MatrixRTC, c'est des conférences vocales et vidéo de groupe chiffrées de bout en bout sur Matrix. Historiquement, la VoIP de groupe dans Matrix s'est appuyée sur des systèmes de conférence tiers - ne fournissant aucun support pour le chiffrement de bout en bout de Matrix, ni d'ailleurs pour les identités d'utilisateur, la décentralisation ou le contrôle d'accès décentralisé de Matrix.

MatrixRTC offre donc un moyen standard d'établir des appels vidéo de groupe chiffrés de bout en bout à grande échelle via Matrix, en tirant parti de tous les avantages de l'infrastructure de chiffrement de bout en bout de Matrix, de l'identité des utilisateurs, des autorisations d'accès aux salles, etc. Il prend également en charge différentes piles média pour gérer la conférence média - aujourd'hui, l'implémentation principale utilise LiveKit SFU, mais il existe également une implémentation WebRTC expérimentale à maillage complet.

Element Call a été le moteur de MatrixRTC et, avec la v2, il est activé dans les versions d'Element Web/Desktop et d'Element X pour fournir un appel MatrixRTC natif intégré dans les applications : si vous appuyez sur le bouton d'appel vidéo, vous aurez maintenant la possibilité de lancer un appel MatrixRTC via Element Call plutôt que via Jitsi ou l'appel 1:1 hérité, et si la salle est chiffrée de bout en bout, toute la conférence le sera également.

Par ailleurs, MatrixRTC ne se limite pas à Element Call : Famedly a montré une interopérabilité expérimentale avec FluffyChat au FOSDEM en février, et Element a montré une interopérabilité expérimentale avec BigBlueButton en août. Étant donné que de plus en plus d'outils de conférence convergent vers LiveKit en tant que meilleur SFU de sa catégorie, c'est une opportunité extraordinaire d'utiliser Matrix et MatrixRTC pour assurer le chiffrement et la décentralisation de bout en bout et obtenir une interopérabilité voip/vidéo standardisée dès le départ.


Cela dit, il y a quelques mises en garde à l'heure actuelle :

• Il n'y a pas d'interopérabilité entre les appels voix/vidéo 1:1 de Matrix et MatrixRTC (et il n'est pas clair si/quand cela arrivera) - mais les clients Matrix 2.0 comme Element X utilisent exclusivement MatrixRTC pour la VoIP/vidéo, y compris pour les appels 1:1. Ceci afin de ne maintenir qu'une seule pile VoIP et d'obtenir gratuitement un support multi-appareils et multi-utilisateurs, même pour les appels 1:1.
• iOS 18 a cassé CallKit + WebRTC, donc Element X iOS a dû désactiver les appels MatrixRTC intégrés de manière native dans le système d'exploitation ; un problème de support est ouvert avec Apple pour essayer de le résoudre.
• Il y a également quelques problèmes initiaux à cause du volume de signalisation dans MatrixRTC exposant certains bugs de synchronisation. Cela signifie probablement que MatrixRTC devrait encore être considéré comme une version bêta pendant quelques jours jusqu'à ce que les correctifs atterrissent.

4. Chiffrement invisible

Le dernier pilier de Matrix 2.0 est le chiffrement invisible - rendant le chiffrement de bout en bout de Matrix aussi transparent et invisible que les alternatives centralisées (Signal, WhatsApp, iMessage, etc). Cela ne signifie pas que la sécurité est réduite de quelque manière que ce soit, bien au contraire. Il s'agit de :

1. Veiller à ce que les bogues de type "Unable To Decrypt" (UTD) ne se produisent jamais.
   
   
2. Exclure de Matrix les appareils ne portant pas de signature croisée. Le fait que Matrix ait jamais soutenu l'idée d'utilisateurs activant le chiffrement sur un dispositif sans prouver qu'ils en sont les propriétaires valides en le signant (en le vérifiant avec un autre dispositif, ou en fournissant leur clé de récupération/passkey) est un mauvais souvenir datant d'avant l'introduction de la signature croisée. Aujourd'hui, le fait qu'il existe des dispositifs sans signature croisée a pour effet de réduire la sécurité et de compliquer l'interface utilisateur et les implémentations avec de gros avertissements rouges effrayants chaque fois qu'un dispositif non vérifié se joint à une conversation. Au lieu de cela, la nouvelle norme permettra d'exclure complètement les dispositifs non vérifiés - ne pas chiffrer vers eux et ne pas déchiffrer à partir d'eux.
3. Résoudre les avertissements déroutants du "bouclier gris" : "L'authenticité de ce message ne peut être confirmée sur cet appareil" et autres avertissements similaires. Il s'agit d'avertissements évitables causés par des clés de message qui ne peuvent plus être retracées jusqu'à l'expéditeur d'origine - par exemple, si elles sont restaurées à partir d'une sauvegarde ou si le dispositif d'envoi d'origine a été supprimé. Ces problèmes devraient être corrigés avec la sauvegarde authentifiée et l'inclusion des clés de dispositif sur les événements Olm.
4. Passer à la confiance dès la première utilisation (TOFU). Cela signifie que même si vous n'avez pas explicitement vérifié un autre utilisateur, vous serez averti si son identité change (contrairement à ce qui se passait auparavant, où l'on n'en tenait pas compte). Une première implémentation a atterri dans matrix-rust-sdk il y a quelques semaines, et les avertissements appropriés au niveau de l'application devraient donc arriver sous peu - correspondant aux avertissements équivalents de Signal ou WhatsApp "l'identité de cet utilisateur a changé", bien qu'ils ne soient pas encore synchronisés entre les appareils.

La version 2.0 montre déjà des améliorations de la fiabilité et de la robustesse...