La version 2.0 de Matrix, le protocole ouvert de communication sécurisé et décentralisé, vient d'être publiée et apporte plusieurs améliorations en termes de convivialité et de performance.
Matrix existe depuis plus de 9 ans maintenant, offrant une norme ouverte pour une communication sécurisée et décentralisée sur le Web ouvert - et c'est tout un parcours pour arriver là où nous en sommes aujourd'hui. À l'heure actuelle, selon les rapports d'utilisation opt-in de Synapse, il y a au total 111 873 374 ID matriciels sur le réseau public, couvrant 17 289 201 pièces, réparties sur 64 256 serveurs. Ce chiffre ne fait qu'effleurer la surface, car nous estimons que 66 % des serveurs du réseau public ne communiquent pas leurs statistiques et qu'il existe également de nombreux et énormes réseaux privés de serveurs. Nous avons parcouru un long chemin depuis la création de Matrix HQ en tant que première salle sur le réseau public actuel, le 13 août 2014 
Pendant ce temps, l'écosystème Matrix a continué à se développer de manière incroyable - avec un grand nombre de clients indépendants, de bots et de ponts mûrissant en écosystèmes propres, de nouvelles entreprises entières se formant autour du protocole, et des organisations allant de projets open source à des gouvernements, des ONG et des entreprises Fortune 100 adoptant Matrix comme moyen d'exécuter leur propre communication sécurisée, décentralisée, basée sur des normes et auto-souveraine.
Le monde a plus que jamais besoin de Matrix. Chaque jour, l'importance de la décentralisation devient plus douloureusement évidente, alors que nous voyons concrètement les risques terrifiants des services Internet centralisés - que ce soit par la prise de contrôle des entreprises, la censure d'État, la surveillance généralisée, les fermetures d'Internet, le capitalisme de surveillance ou le spectre de gigantesques violations de données centralisées. Il a été extraordinaire de voir le monde basculer en faveur de la décentralisation depuis que nous construisons Matrix, et notre mission n'a jamais été aussi importante.
D'une part, nous avons l'impression de nous rapprocher de notre objectif, qui est de fournir la couche de communication manquante pour le web ouvert. La loi sur les marchés numériques (DMA) de l'Union européenne est un grand pas dans cette direction - une réglementation qui impose aux grands fournisseurs de messagerie centralisée d'interopérer s'ils veulent opérer dans l'Union européenne. Nous avons travaillé d'arrache-pied pour que cela devienne une réalité, notamment en participant pour la première fois à l'IETF dans le cadre du groupe de travail MIMI, en démontrant concrètement comment (par exemple) Android Messages pourrait parler Matrix en natif afin d'interopérer avec d'autres services, tout en préservant le chiffrement de bout en bout.
D'autre part, Matrix s'est souvent concentré sur la résolution des problèmes difficiles de la décentralisation, du chiffrement de bout en bout décentralisé et des complexités logistiques liées au soutien d'un réseau de communication public hétérogène massif et de l'écosystème hétérogène qui l'entoure. Il est juste de dire qu'au début, notre objectif était de faire quelque chose qui fonctionnait, puis plus tard, nous nous sommes concentrés sur quelque chose qui fonctionnait et s'adaptait correctement... mais nous n'avions pas réussi à nous assurer que Matrix fournisse les éléments de base nécessaires pour créer des applications de communication hyper rapides et hyper efficaces qui ont le potentiel de surpasser les services de messagerie centralisés traditionnels...
...jusqu'à aujourd'hui !
Matrix 2.0
Lors du FOSDEM, nous avons annoncé l'idée de Matrix 2.0 - une série d'énormes changements en termes de convivialité et de performance de Matrix, comprenant Sliding Sync (connexion/lancement/synchronisation instantanés), Native OIDC (authentification standard), Native Group VoIP (conférence vocale et vidéo cryptée de bout en bout à grande échelle) et Faster Joins (état de la salle paresseux lorsque votre serveur rejoint une salle).
Nous sommes heureux d'annoncer qu'à partir d'aujourd'hui, tout le monde peut commencer à jouer avec ces fonctionnalités de Matrix 2.0. Il y a encore du travail à faire pour les intégrer formellement dans la spécification, mais nous les mettons à la disposition des gens pour qu'ils puissent en faire l'expérience dès maintenant. Développeurs : surveillez cet espace pour des mises à jour sur le front de la spécification.
En pratique, cela signifie que des implémentations des quatre piliers de Matrix 2.0 sont disponibles aujourd'hui et que vous pouvez les utiliser pour faire fonctionner un client Matrix 2.0 au quotidien. Le travail ici a été mené principalement par Element, qui a utilisé son nouveau client Element X comme banc d'essai pour les nouvelles fonctionnalités de Matrix 2.0 et pour prouver que les nouvelles API sont basées sur une utilisation réelle et peuvent concrètement créer une application qui commence à surpasser iMessage, WhatsApp et Telegram en termes de convivialité et de performance... tout en bénéficiant du fait qu'elle est construite à 100 % sur Matrix.
matrix-rust-sdk et Element X
La mission de Matrix 2.0 a été de faire un grand pas en avant en termes de performances, de convivialité et de stabilité dans le monde réel - et cela signifie utiliser une base de code client réelle comme cobaye pour s'assurer que le nouveau protocole est adapté. matrix-rust-sdk a été le principal véhicule pour cela, avec Element X en tant qu'application pilotant principalement les nouvelles fonctionnalités (bien que d'autres clients construits sur matrix-rust-sdk, tels que Fractal 5, puissent automatiquement bénéficier de ce travail s'ils le souhaitent).
Pour savoir de quoi il retourne, le mieux est sans doute de vous rendre sur le blog de lancement d'Element X et de lire tout ce qui s'y rapporte ! Mais du point de vue de Matrix, il s'agit d'un jour phare en ce qui concerne l'existence d'un client Matrix qui surpasse empiriquement les clients traditionnels en termes de convivialité et de performance : cela montre que Matrix est effectivement viable pour alimenter la communication de milliards d'utilisateurs, si nous en avons l'occasion.
Du point de vue du client, cela a signifié l'implémentation de Sliding Sync (MSC3575) dans matrix-rust-sdk - et ensuite la création du tout nouveau crate matrix-sdk-ui afin d'exposer des API de plus haut niveau pour aider les applications à piloter efficacement leur interface utilisateur, sans que chaque application n'ait à réinventer la roue et à risquer de se tromper. Le nouveau crate UI fournit des API pour gérer efficacement une liste de salle lazy-loaded, des timelines de salle lazy-loaded (y compris les éditions, les réactions, les agrégations, les rédactions, etc), et même quand l'application doit afficher un spinner de synchronisation ou non. En conséquence, la grande majorité des tâches lourdes peut être gérée dans matrix-rust-sdk, ce qui permet à la couche applicative de se concentrer sur l'interface utilisateur plutôt que sur les rouages de Matrix - et les améliorations de performance (par exemple, la mise en cache de la liste des salles et de la timeline) peuvent toutes être gérées en un seul endroit, au bénéfice de tous les clients utilisant le SDK.
Il s'agit d'une avancée considérable par rapport à l'ancienne époque de Matrix, où chaque client n'avait d'autre choix que de passer beaucoup de temps à créer à la main sa propre chronologie et sa propre logique de chiffrement (même si, bien sûr, les clients sont toujours les bienvenus s'ils le souhaitent !) - mais pour ceux qui veulent des blocs de construction de plus haut niveau, matrix-rust-sdk fournit maintenant une excellente base pour expérimenter avec les clients de Matrix 2.0. Il convient de noter que la bibliothèque évolue encore rapidement et que de nombreuses API ne sont pas stables à long terme. L'API Sliding Sync et les UI crates sont encore sujets à des changements significatifs, et alors que le crypto crate et son implémentation E2EE sous-jacente vodozemac sont assez stables, des fonctionnalités telles que E2EE Backup sont encore ajoutées au niveau supérieur de matrix-rust-sdk (et de là Element X).
Afin de relier matrix-rust-sdk à Element X, l'équipe Element a fini par contribuer à des liaisons asynchrones annulables à uniffi, le générateur de liaisons linguistiques de Mozilla, de sorte que vous pouvez maintenant appeler matrix-rust-sdk directement à partir de Swift, Kotlin et (en théorie) d'autres langages, avec une sémantique asynchrone/await non bloquante magnifiquement simple. Cela semble être une pile assez impressionnante pour faire du développement multiplateforme moderne - donc même si vous avez un projet qui n'est pas nativement en Rust, vous devriez être en mesure de vous appuyer sur matrix-rust-sdk si vous le souhaitez ! Nous espérons que d'autres projets suivront le modèle Rust + Swift/Kotlin pour leurs besoins de performances extrêmes
Sliding Sync
Le changement le plus important dans Matrix 2.0 est la proposition d'une toute nouvelle API de synchronisation appelée Sliding Sync (MSC3575). L'objectif de Sliding Sync est de s'assurer que l'application a la possibilité de charger les données absolument essentielles au rendu de son interface utilisateur visible - en s'assurant que les opérations qui ont toujours été horriblement lentes dans Matrix (connexion et synchronisation initiale, lancement et synchronisation incrémentale) sont instantanées, quel que soit le nombre de pièces dans lesquelles l'utilisateur se trouve ou la taille de ces pièces.
Alors que matrix-rust-sdk implémente à la fois Sync v2 (l'API actuelle de Matrix 1.8) et Sliding Sync, Element X n'implémente délibérément que Sliding Sync, afin de se concentrer exclusivement sur l'obtention de l'interface utilisateur la plus rapide possible (et généralement d'exercer l'API). Par conséquent, pour utiliser Element X, vous devez utiliser un serveur domestique supportant Sliding Sync, ce qui signifie (pour l'instant) utiliser un proxy sliding-sync qui ajoute le support Sliding Sync aux serveurs domestiques existants. Vous pouvez consulter l'excellent tutoriel de Thib pour savoir comment démarrer (ou Element Server Suite fournit des paquets de l'équipe Element).
L'implémentation de Sliding Sync dans matrix-rust-sdk a été un véritable parcours du combattant. Depuis que nous avons présenté la toute première implémentation au FOSDEM, deux problèmes majeurs sont apparus. Pour un peu de contexte : la conception originale de Sliding Sync était fortement inspirée par l'architecture de Discord - où le serveur calcule une liste ordonnée d'un grand nombre d'éléments (votre liste de salles, dans le cas de Matrix) ; le client indique quelle fenêtre de la liste il est en train d'afficher ; et le serveur envoie des mises à jour au client au fur et à mesure que l'affichage change. L'utilisateur fait ensuite défiler la liste, en faisant glisser la fenêtre vers le haut ou vers le bas, et le serveur envoie les mises à jour appropriées - d'où le nom de Sliding Sync.
Sliding Sync a été motivé à l'origine par notre travail sur Matrix Low Bandwidth - car il n'est pas logique d'avoir un protocole de ligne fantaisiste qui peut fonctionner sur un modem 2400 bauds... si la première chose que l'application essaie de faire est de télécharger une réponse de synchronisation initiale de 100MB Sync v2, ou d'ailleurs une réponse de synchronisation incrémentale de 10MB après avoir été hors ligne pendant quelques jours (10MB prend 9 heures pour se déplacer sur un modem 2400 bauds, pour ceux qui ont raté les années 80). Au lieu de cela, vous souhaitez clairement n'envoyer que l'essentiel au client, quelle que soit la taille de son compte, et c'est ce que fait Sliding Sync.
Le premier défaut mineur de ce plan est que le serveur ne dispose pas nécessairement de toutes les données dont il a besoin pour ordonner la liste des chambres. L'ordre des salles dépend des événements visibles les plus récents dans une salle, et si la salle est cryptée de bout en bout, le serveur n'a aucun moyen de savoir quels événements seront visibles pour un client donné ou non. Il ne sait pas non plus quelles salles contiennent des mentions cryptées, et nous ne voulons pas divulguer les métadonnées des mentions au serveur, ni concevoir des mentions de mots clés. MSC3575 a donc proposé quelques contorsions compliquées pour permettre au client de modifier l'ordre côté client sur la base de sa connaissance supérieure de l'ordre (étant donné que la plupart des clients auraient de toute façon besoin de synchroniser toutes les salles cryptées, afin de les indexer et de rechercher des notifications de mots clés, etc.) En attendant, l'ordre pourrait être "suffisamment bon" même sans ces ajustements.
La deuxième petite faille dans le plan était qu'après avoir implémenté Sliding Sync dans Element X, il s'est avéré que l'expérience utilisateur sur mobile de chargement incrémental des entrées de la liste des salles depuis le serveur au fur et à mesure que l'utilisateur fait défiler la liste n'est tout simplement pas assez bonne, en particulier en cas de mauvaise connectivité - et la dernière chose que nous voulons faire est de concevoir un support pour une mauvaise connectivité dans Matrix. Les utilisateurs de téléphones portables ont été formés à s'attendre à pouvoir faire défiler rapidement des listes infinies de dizaines de milliers de photos dans leur galerie de photos, ou de dizaines de milliers d'e-mails dans leur client de messagerie, sans jamais voir un seul espace réservé, même pour une image. Ainsi, si le temps d'aller-retour du réseau vers votre serveur est de 100 ms et que Sliding Sync fonctionne infiniment vite, vous finirez toujours par afficher un espace réservé pendant quelques images (6 images, à 60 images par seconde, pour être précis) si l'utilisateur commence à faire défiler rapidement la liste de ses pièces. Et d'un point de vue empirique, cela n'a rien d'extraordinaire - l'équipe d'iOS, qui date de 2007, a beaucoup à se reprocher en ce qui concerne la définition des attentes des utilisateurs !
La façon la plus évidente de résoudre ces deux problèmes est donc d'extraire davantage de données en arrière-plan, afin d'anticiper le défilement de l'utilisateur. En fait, il s'avère que nous avons besoin de faire cela de toute façon, et en effet d'extraire toutes les données de la salle pour que la recherche de salle soit instantanément réactive ; attendre 100 ms ou plus pour parler au serveur chaque fois que l'utilisateur essaie de rechercher sa liste de salles n'est pas amusant du tout, et il s'avère que de nombreux utilisateurs naviguent dans leur liste de salles entièrement par la recherche plutôt que par le défilement. En conséquence, l'implémentation de Sliding Sync dans matrix-rust-sdk a fini par maintenir une liste de "toutes les salles", qui commence par synchroniser les détails de la roomlist pour les N salles les plus récentes, puis s'étend en arrière-plan pour synchroniser toutes les autres. À ce stade, nous ne faisons plus vraiment glisser une fenêtre : il s'agit plutôt d'une synchronisation incrémentale avec QoS.
Donc, pour faire court : bien que l'implémentation actuelle de Sliding Sync dans matrix-rust-sdk et Element X fonctionne empiriquement très bien, elle a fini par être un peu trop compliquée et nous nous attendons à des simplifications assez significatives dans un futur proche, basées sur les meilleures pratiques trouvées avec les clients qui l'utilisent. Surveillez cet espace pour les mises à jour, bien qu'il soit probable que la forme actuelle de MSC3575 prévaudra dans une certaine mesure afin de prendre en charge les environnements à faible bande passante où l'ordre des listes de salles et la latence de la recherche de salles sont moins importants que la préservation de la bande passante. Pour l'instant, nous continuerons donc à utiliser le proxy de synchronisation glissante comme moyen d'expérimenter rapidement l'API au fur et à mesure de son évolution.
VoIP native pour l'appel de groupe Matrix
Autre pilier de Matrix 2.0, les appels VoIP de groupe Matrix sont enfin disponibles en natif (MSC3401) ! Tout comme Sliding Sync a été développé en utilisant Element X comme banc d'essai, Element Call a été le cobaye pour la mise en œuvre d'appels vocaux/vidéo de groupe évolutifs et entièrement cryptés de bout en bout dans Matrix, en s'appuyant sur matrix-js-sdk. Aujourd'hui, Element Call a enfin réussi à le faire fonctionner, avec un chiffrement de bout en bout (et intégré dans Element X, d'ailleurs) !
À l'instar de Sliding Sync, ce projet a été un véritable parcours du combattant. Les premières implémentations d'Element Call suivaient strictement la norme MSC3401, en utilisant la conférence à maillage complet pour que chaque participant passe effectivement un appel à tous les autres participants - décentralisant ainsi la conférence et évitant le besoin d'un serveur de conférence "focus"... mais limitant la conférence à 7 ou 8 participants en raison de la duplication de la vidéo envoyée nécessaire. Dans Element Call Beta 2, le chiffrement de bout en bout a été activé ; facile, étant donné qu'il s'agit simplement d'une série d'appels 1:1.
C'est alors que la véritable aventure a commencé : mettre en œuvre une unité de renvoi sélectif (SFU) qui peut être utilisée pour passer à des centaines d'utilisateurs - ou plus. Le premier pas inattendu a été fait par Sean DuBois, chef de projet de l'impressionnante pile Pion WebRTC pour Golang, qui a écrit une preuve de concept appelée sfu-to-sfu pour démontrer la viabilité des SFU en cascade hétérogènes et décentralisées, comme indiqué dans le document MSC3898. Cela permettrait non seulement de faire passer les appels sur un seul foyer à des centaines d'utilisateurs, mais aussi de partager les conférences entre tous les foyers participants, offrant ainsi la première vidéoconférence décentralisée hétérogène au monde. Element a pris l'implémentation sfu-to-sfu, l'a connectée à Element Call on a branch, et l'a renommée waterfall.
Cependant, lorsque Sean a contribué pour la première fois à sfu-to-sfu, il nous a dit que si Matrix était sérieux au sujet des SFU, nous devrions jeter un coup d'œil à LiveKit - une startup open source pas très différente d'Element qui était occupée à construire les meilleurs SFU de leur catégorie au-dessus de Pion. Et bien que la cascade ait bien fonctionné comme preuve de concept, il est devenu de plus en plus évident qu'il y avait beaucoup de travail à faire pour régler le contrôle de la congestion, la correction des erreurs, la mise en œuvre du cryptage de bout en bout, etc. que l'équipe LiveKit avait déjà passé des années à faire. Element a donc contacté l'équipe LiveKit et a commencé à expérimenter ce qu'il faudrait faire pour mettre en œuvre un SFU compatible avec Matrix au-dessus du moteur LiveKit.
Le résultat final a été Element Call Beta 3, qui est un hybride intéressant entre MSC3401 et la signalisation existante de LiveKit : la signalisation de haut niveau de l'appel (son existence, son appartenance, sa durée, etc.) est annoncée par Matrix - mais la signalisation WebRTC réelle est gérée par LiveKit, fournissant un support pour des centaines d'utilisateurs par appel.
Enfin, aujourd'hui marque la sortie d'Element Call Beta 4, qui réintègre le chiffrement de bout en bout via le SFU LiveKit (actuellement en utilisant un secret statique partagé, mais dans un futur proche, il supportera le chiffrement de bout en bout négocié par Matrix avec les clés de l'expéditeur) - et inclut également un rafraîchissement visuel complet. Les prochaines étapes comprennent le retour de la prise en charge du maillage complet ainsi que du SFU, pour les environnements sans SFU, et la mise à jour de tous les MSC pour reconnaître le modèle de signalisation hybride sur lequel la réalité a convergé lors de l'utilisation de LiveKit. En attendant, rendez-vous sur https://call.element.io pour l'essayer, ou lisez plus à ce sujet dans l'article du blog Element X Ignition !
Open ID Connect en natif
Enfin, nous sommes fiers d'annoncer que le projet visant à remplacer les vénérables API d'authentification existantes de Matrix par le standard industriel Open ID Connect dans Matrix 2.0 a fait un grand bond en avant aujourd'hui, matrix-authentication-service étant désormais disponible pour ajouter le support Native OIDC à Synapse, ainsi qu'à Element X qui implémente désormais l'enregistrement, la connexion et la gestion des comptes via Native OIDC (avec le support hérité uniquement pour la connexion/la déconnexion).
Il s'agit d'une étape cruciale dans l'amélioration de la sécurité et de la maintenabilité de l'authentification de Matrix, et vous pouvez lire tout cela dans cet article dédié, expliquant la raison d'être de l'adoption d'OpenID Connect pour toutes les formes d'authentification dans Matrix, et ce que vous devez savoir sur la transition.
Conclusion
Une énorme quantité de travail a été consacrée à Matrix 2.0 jusqu'à présent - qu'il s'agisse de l'implémentation de la synchronisation glissante dans matrix-rust-sdk et le proxy sliding-sync, matrix-authentication-service et toute l'infrastructure OIDC native sur les serveurs et les clients, l'intégralité d'Element Call et son travail sous-jacent matrix-js-sdk et SFU, ou même Faster Joins dans Synapse, qui a été livré en janvier dernier.
Cela a été un sprint assez stressant pour tout mettre en place, et un grand merci à tous ceux qui ont contribué - à la fois l'équipe d'Element, mais aussi les contributeurs à d'autres projets comme matrix-rust-sdk qui ont été pris dans le feu croisé. Nous avons également été ravis de constater le niveau de soutien, la qualité des tests et l'excellent retour d'information de la part de l'ensemble de la communauté, qui s'est enthousiasmée pour la promesse de Matrix 2.0.
Du côté de la Fondation, nous aimerions remercier les membres dont le soutien financier a été essentiel pour fournir la bande passante permettant de progresser sur Matrix 2.0 - et pour ceux qui veulent aider à accélérer Matrix, en particulier ceux qui construisent commercialement au-dessus de Matrix, veuillez envisager d'adhérer à la Fondation en tant que membre ! Par ailleurs, au cas où vous l'auriez manqué, nous sommes ravis d'accueillir Josh Simmons en tant que directeur général de la Fondation, chargé de gérer le programme d'adhésion à la Fondation et, d'une manière générale, d'assurer la croissance du financement de la Fondation au profit de l'ensemble de la communauté Matrix. Matthew et Amandine continuent de diriger l'ensemble du projet (en plus de leur travail à Element), avec le soutien des trois autres gardiens indépendants, mais Josh travaille à temps plein exclusivement à la gestion de la fondation à but non lucratif et à la collecte de fonds pour soutenir Matrix.
En parlant de financement, nous devons mentionner que nous avons dû interrompre des travaux dans d'autres domaines en raison du manque de fonds pour Matrix - en particulier lorsque nous nous sommes concentrés sur le lancement réussi de Matrix 2.0. Les principaux projets de nouvelle génération, dont Third Room, P2P Matrix et Low Bandwidth Matrix, ont tous été mis en pause, à moins d'un changement majeur de circonstances. Si vous avez de l'argent et que vous êtes intéressé par un monde où les projets expérimentaux de nouvelle génération de Matrix progressent et où les personnes qui y travaillent en font leur travail quotidien, prenez contact avec la Fondation.
Quelles sont les prochaines étapes ?
Bien qu'il s'agisse de la première version utilisable des implémentations de Matrix 2.0, il reste encore beaucoup de travail à faire :
En dehors du travail sur Matrix 2.0, d'autres éléments importants se profilent à l'horizon :
Bienvenue donc dans le nouveau monde de la Matrice 2.0. Nous espérons que vous êtes aussi enthousiastes que nous et nous remercions tous ceux qui continuent à utiliser Matrix et à l'enrichir. C'est le début d'une nouvelle ère !
Matthew, Amandine et toute l'équipe de Matrix.
Pendant ce temps, l'écosystème Matrix a continué à se développer de manière incroyable - avec un grand nombre de clients indépendants, de bots et de ponts mûrissant en écosystèmes propres, de nouvelles entreprises entières se formant autour du protocole, et des organisations allant de projets open source à des gouvernements, des ONG et des entreprises Fortune 100 adoptant Matrix comme moyen d'exécuter leur propre communication sécurisée, décentralisée, basée sur des normes et auto-souveraine.
Le monde a plus que jamais besoin de Matrix. Chaque jour, l'importance de la décentralisation devient plus douloureusement évidente, alors que nous voyons concrètement les risques terrifiants des services Internet centralisés - que ce soit par la prise de contrôle des entreprises, la censure d'État, la surveillance généralisée, les fermetures d'Internet, le capitalisme de surveillance ou le spectre de gigantesques violations de données centralisées. Il a été extraordinaire de voir le monde basculer en faveur de la décentralisation depuis que nous construisons Matrix, et notre mission n'a jamais été aussi importante.
D'une part, nous avons l'impression de nous rapprocher de notre objectif, qui est de fournir la couche de communication manquante pour le web ouvert. La loi sur les marchés numériques (DMA) de l'Union européenne est un grand pas dans cette direction - une réglementation qui impose aux grands fournisseurs de messagerie centralisée d'interopérer s'ils veulent opérer dans l'Union européenne. Nous avons travaillé d'arrache-pied pour que cela devienne une réalité, notamment en participant pour la première fois à l'IETF dans le cadre du groupe de travail MIMI, en démontrant concrètement comment (par exemple) Android Messages pourrait parler Matrix en natif afin d'interopérer avec d'autres services, tout en préservant le chiffrement de bout en bout.
D'autre part, Matrix s'est souvent concentré sur la résolution des problèmes difficiles de la décentralisation, du chiffrement de bout en bout décentralisé et des complexités logistiques liées au soutien d'un réseau de communication public hétérogène massif et de l'écosystème hétérogène qui l'entoure. Il est juste de dire qu'au début, notre objectif était de faire quelque chose qui fonctionnait, puis plus tard, nous nous sommes concentrés sur quelque chose qui fonctionnait et s'adaptait correctement... mais nous n'avions pas réussi à nous assurer que Matrix fournisse les éléments de base nécessaires pour créer des applications de communication hyper rapides et hyper efficaces qui ont le potentiel de surpasser les services de messagerie centralisés traditionnels...
...jusqu'à aujourd'hui !
Matrix 2.0
Lors du FOSDEM, nous avons annoncé l'idée de Matrix 2.0 - une série d'énormes changements en termes de convivialité et de performance de Matrix, comprenant Sliding Sync (connexion/lancement/synchronisation instantanés), Native OIDC (authentification standard), Native Group VoIP (conférence vocale et vidéo cryptée de bout en bout à grande échelle) et Faster Joins (état de la salle paresseux lorsque votre serveur rejoint une salle).
Nous sommes heureux d'annoncer qu'à partir d'aujourd'hui, tout le monde peut commencer à jouer avec ces fonctionnalités de Matrix 2.0. Il y a encore du travail à faire pour les intégrer formellement dans la spécification, mais nous les mettons à la disposition des gens pour qu'ils puissent en faire l'expérience dès maintenant. Développeurs : surveillez cet espace pour des mises à jour sur le front de la spécification.
En pratique, cela signifie que des implémentations des quatre piliers de Matrix 2.0 sont disponibles aujourd'hui et que vous pouvez les utiliser pour faire fonctionner un client Matrix 2.0 au quotidien. Le travail ici a été mené principalement par Element, qui a utilisé son nouveau client Element X comme banc d'essai pour les nouvelles fonctionnalités de Matrix 2.0 et pour prouver que les nouvelles API sont basées sur une utilisation réelle et peuvent concrètement créer une application qui commence à surpasser iMessage, WhatsApp et Telegram en termes de convivialité et de performance... tout en bénéficiant du fait qu'elle est construite à 100 % sur Matrix.
matrix-rust-sdk et Element X
La mission de Matrix 2.0 a été de faire un grand pas en avant en termes de performances, de convivialité et de stabilité dans le monde réel - et cela signifie utiliser une base de code client réelle comme cobaye pour s'assurer que le nouveau protocole est adapté. matrix-rust-sdk a été le principal véhicule pour cela, avec Element X en tant qu'application pilotant principalement les nouvelles fonctionnalités (bien que d'autres clients construits sur matrix-rust-sdk, tels que Fractal 5, puissent automatiquement bénéficier de ce travail s'ils le souhaitent).
Pour savoir de quoi il retourne, le mieux est sans doute de vous rendre sur le blog de lancement d'Element X et de lire tout ce qui s'y rapporte ! Mais du point de vue de Matrix, il s'agit d'un jour phare en ce qui concerne l'existence d'un client Matrix qui surpasse empiriquement les clients traditionnels en termes de convivialité et de performance : cela montre que Matrix est effectivement viable pour alimenter la communication de milliards d'utilisateurs, si nous en avons l'occasion.
Du point de vue du client, cela a signifié l'implémentation de Sliding Sync (MSC3575) dans matrix-rust-sdk - et ensuite la création du tout nouveau crate matrix-sdk-ui afin d'exposer des API de plus haut niveau pour aider les applications à piloter efficacement leur interface utilisateur, sans que chaque application n'ait à réinventer la roue et à risquer de se tromper. Le nouveau crate UI fournit des API pour gérer efficacement une liste de salle lazy-loaded, des timelines de salle lazy-loaded (y compris les éditions, les réactions, les agrégations, les rédactions, etc), et même quand l'application doit afficher un spinner de synchronisation ou non. En conséquence, la grande majorité des tâches lourdes peut être gérée dans matrix-rust-sdk, ce qui permet à la couche applicative de se concentrer sur l'interface utilisateur plutôt que sur les rouages de Matrix - et les améliorations de performance (par exemple, la mise en cache de la liste des salles et de la timeline) peuvent toutes être gérées en un seul endroit, au bénéfice de tous les clients utilisant le SDK.
Il s'agit d'une avancée considérable par rapport à l'ancienne époque de Matrix, où chaque client n'avait d'autre choix que de passer beaucoup de temps à créer à la main sa propre chronologie et sa propre logique de chiffrement (même si, bien sûr, les clients sont toujours les bienvenus s'ils le souhaitent !) - mais pour ceux qui veulent des blocs de construction de plus haut niveau, matrix-rust-sdk fournit maintenant une excellente base pour expérimenter avec les clients de Matrix 2.0. Il convient de noter que la bibliothèque évolue encore rapidement et que de nombreuses API ne sont pas stables à long terme. L'API Sliding Sync et les UI crates sont encore sujets à des changements significatifs, et alors que le crypto crate et son implémentation E2EE sous-jacente vodozemac sont assez stables, des fonctionnalités telles que E2EE Backup sont encore ajoutées au niveau supérieur de matrix-rust-sdk (et de là Element X).
Afin de relier matrix-rust-sdk à Element X, l'équipe Element a fini par contribuer à des liaisons asynchrones annulables à uniffi, le générateur de liaisons linguistiques de Mozilla, de sorte que vous pouvez maintenant appeler matrix-rust-sdk directement à partir de Swift, Kotlin et (en théorie) d'autres langages, avec une sémantique asynchrone/await non bloquante magnifiquement simple. Cela semble être une pile assez impressionnante pour faire du développement multiplateforme moderne - donc même si vous avez un projet qui n'est pas nativement en Rust, vous devriez être en mesure de vous appuyer sur matrix-rust-sdk si vous le souhaitez ! Nous espérons que d'autres projets suivront le modèle Rust + Swift/Kotlin pour leurs besoins de performances extrêmes
Sliding Sync
Le changement le plus important dans Matrix 2.0 est la proposition d'une toute nouvelle API de synchronisation appelée Sliding Sync (MSC3575). L'objectif de Sliding Sync est de s'assurer que l'application a la possibilité de charger les données absolument essentielles au rendu de son interface utilisateur visible - en s'assurant que les opérations qui ont toujours été horriblement lentes dans Matrix (connexion et synchronisation initiale, lancement et synchronisation incrémentale) sont instantanées, quel que soit le nombre de pièces dans lesquelles l'utilisateur se trouve ou la taille de ces pièces.
Alors que matrix-rust-sdk implémente à la fois Sync v2 (l'API actuelle de Matrix 1.8) et Sliding Sync, Element X n'implémente délibérément que Sliding Sync, afin de se concentrer exclusivement sur l'obtention de l'interface utilisateur la plus rapide possible (et généralement d'exercer l'API). Par conséquent, pour utiliser Element X, vous devez utiliser un serveur domestique supportant Sliding Sync, ce qui signifie (pour l'instant) utiliser un proxy sliding-sync qui ajoute le support Sliding Sync aux serveurs domestiques existants. Vous pouvez consulter l'excellent tutoriel de Thib pour savoir comment démarrer (ou Element Server Suite fournit des paquets de l'équipe Element).
L'implémentation de Sliding Sync dans matrix-rust-sdk a été un véritable parcours du combattant. Depuis que nous avons présenté la toute première implémentation au FOSDEM, deux problèmes majeurs sont apparus. Pour un peu de contexte : la conception originale de Sliding Sync était fortement inspirée par l'architecture de Discord - où le serveur calcule une liste ordonnée d'un grand nombre d'éléments (votre liste de salles, dans le cas de Matrix) ; le client indique quelle fenêtre de la liste il est en train d'afficher ; et le serveur envoie des mises à jour au client au fur et à mesure que l'affichage change. L'utilisateur fait ensuite défiler la liste, en faisant glisser la fenêtre vers le haut ou vers le bas, et le serveur envoie les mises à jour appropriées - d'où le nom de Sliding Sync.
Sliding Sync a été motivé à l'origine par notre travail sur Matrix Low Bandwidth - car il n'est pas logique d'avoir un protocole de ligne fantaisiste qui peut fonctionner sur un modem 2400 bauds... si la première chose que l'application essaie de faire est de télécharger une réponse de synchronisation initiale de 100MB Sync v2, ou d'ailleurs une réponse de synchronisation incrémentale de 10MB après avoir été hors ligne pendant quelques jours (10MB prend 9 heures pour se déplacer sur un modem 2400 bauds, pour ceux qui ont raté les années 80). Au lieu de cela, vous souhaitez clairement n'envoyer que l'essentiel au client, quelle que soit la taille de son compte, et c'est ce que fait Sliding Sync.
Le premier défaut mineur de ce plan est que le serveur ne dispose pas nécessairement de toutes les données dont il a besoin pour ordonner la liste des chambres. L'ordre des salles dépend des événements visibles les plus récents dans une salle, et si la salle est cryptée de bout en bout, le serveur n'a aucun moyen de savoir quels événements seront visibles pour un client donné ou non. Il ne sait pas non plus quelles salles contiennent des mentions cryptées, et nous ne voulons pas divulguer les métadonnées des mentions au serveur, ni concevoir des mentions de mots clés. MSC3575 a donc proposé quelques contorsions compliquées pour permettre au client de modifier l'ordre côté client sur la base de sa connaissance supérieure de l'ordre (étant donné que la plupart des clients auraient de toute façon besoin de synchroniser toutes les salles cryptées, afin de les indexer et de rechercher des notifications de mots clés, etc.) En attendant, l'ordre pourrait être "suffisamment bon" même sans ces ajustements.
La deuxième petite faille dans le plan était qu'après avoir implémenté Sliding Sync dans Element X, il s'est avéré que l'expérience utilisateur sur mobile de chargement incrémental des entrées de la liste des salles depuis le serveur au fur et à mesure que l'utilisateur fait défiler la liste n'est tout simplement pas assez bonne, en particulier en cas de mauvaise connectivité - et la dernière chose que nous voulons faire est de concevoir un support pour une mauvaise connectivité dans Matrix. Les utilisateurs de téléphones portables ont été formés à s'attendre à pouvoir faire défiler rapidement des listes infinies de dizaines de milliers de photos dans leur galerie de photos, ou de dizaines de milliers d'e-mails dans leur client de messagerie, sans jamais voir un seul espace réservé, même pour une image. Ainsi, si le temps d'aller-retour du réseau vers votre serveur est de 100 ms et que Sliding Sync fonctionne infiniment vite, vous finirez toujours par afficher un espace réservé pendant quelques images (6 images, à 60 images par seconde, pour être précis) si l'utilisateur commence à faire défiler rapidement la liste de ses pièces. Et d'un point de vue empirique, cela n'a rien d'extraordinaire - l'équipe d'iOS, qui date de 2007, a beaucoup à se reprocher en ce qui concerne la définition des attentes des utilisateurs !
La façon la plus évidente de résoudre ces deux problèmes est donc d'extraire davantage de données en arrière-plan, afin d'anticiper le défilement de l'utilisateur. En fait, il s'avère que nous avons besoin de faire cela de toute façon, et en effet d'extraire toutes les données de la salle pour que la recherche de salle soit instantanément réactive ; attendre 100 ms ou plus pour parler au serveur chaque fois que l'utilisateur essaie de rechercher sa liste de salles n'est pas amusant du tout, et il s'avère que de nombreux utilisateurs naviguent dans leur liste de salles entièrement par la recherche plutôt que par le défilement. En conséquence, l'implémentation de Sliding Sync dans matrix-rust-sdk a fini par maintenir une liste de "toutes les salles", qui commence par synchroniser les détails de la roomlist pour les N salles les plus récentes, puis s'étend en arrière-plan pour synchroniser toutes les autres. À ce stade, nous ne faisons plus vraiment glisser une fenêtre : il s'agit plutôt d'une synchronisation incrémentale avec QoS.
Donc, pour faire court : bien que l'implémentation actuelle de Sliding Sync dans matrix-rust-sdk et Element X fonctionne empiriquement très bien, elle a fini par être un peu trop compliquée et nous nous attendons à des simplifications assez significatives dans un futur proche, basées sur les meilleures pratiques trouvées avec les clients qui l'utilisent. Surveillez cet espace pour les mises à jour, bien qu'il soit probable que la forme actuelle de MSC3575 prévaudra dans une certaine mesure afin de prendre en charge les environnements à faible bande passante où l'ordre des listes de salles et la latence de la recherche de salles sont moins importants que la préservation de la bande passante. Pour l'instant, nous continuerons donc à utiliser le proxy de synchronisation glissante comme moyen d'expérimenter rapidement l'API au fur et à mesure de son évolution.
VoIP native pour l'appel de groupe Matrix
Autre pilier de Matrix 2.0, les appels VoIP de groupe Matrix sont enfin disponibles en natif (MSC3401) ! Tout comme Sliding Sync a été développé en utilisant Element X comme banc d'essai, Element Call a été le cobaye pour la mise en œuvre d'appels vocaux/vidéo de groupe évolutifs et entièrement cryptés de bout en bout dans Matrix, en s'appuyant sur matrix-js-sdk. Aujourd'hui, Element Call a enfin réussi à le faire fonctionner, avec un chiffrement de bout en bout (et intégré dans Element X, d'ailleurs) !
À l'instar de Sliding Sync, ce projet a été un véritable parcours du combattant. Les premières implémentations d'Element Call suivaient strictement la norme MSC3401, en utilisant la conférence à maillage complet pour que chaque participant passe effectivement un appel à tous les autres participants - décentralisant ainsi la conférence et évitant le besoin d'un serveur de conférence "focus"... mais limitant la conférence à 7 ou 8 participants en raison de la duplication de la vidéo envoyée nécessaire. Dans Element Call Beta 2, le chiffrement de bout en bout a été activé ; facile, étant donné qu'il s'agit simplement d'une série d'appels 1:1.
C'est alors que la véritable aventure a commencé : mettre en œuvre une unité de renvoi sélectif (SFU) qui peut être utilisée pour passer à des centaines d'utilisateurs - ou plus. Le premier pas inattendu a été fait par Sean DuBois, chef de projet de l'impressionnante pile Pion WebRTC pour Golang, qui a écrit une preuve de concept appelée sfu-to-sfu pour démontrer la viabilité des SFU en cascade hétérogènes et décentralisées, comme indiqué dans le document MSC3898. Cela permettrait non seulement de faire passer les appels sur un seul foyer à des centaines d'utilisateurs, mais aussi de partager les conférences entre tous les foyers participants, offrant ainsi la première vidéoconférence décentralisée hétérogène au monde. Element a pris l'implémentation sfu-to-sfu, l'a connectée à Element Call on a branch, et l'a renommée waterfall.
Cependant, lorsque Sean a contribué pour la première fois à sfu-to-sfu, il nous a dit que si Matrix était sérieux au sujet des SFU, nous devrions jeter un coup d'œil à LiveKit - une startup open source pas très différente d'Element qui était occupée à construire les meilleurs SFU de leur catégorie au-dessus de Pion. Et bien que la cascade ait bien fonctionné comme preuve de concept, il est devenu de plus en plus évident qu'il y avait beaucoup de travail à faire pour régler le contrôle de la congestion, la correction des erreurs, la mise en œuvre du cryptage de bout en bout, etc. que l'équipe LiveKit avait déjà passé des années à faire. Element a donc contacté l'équipe LiveKit et a commencé à expérimenter ce qu'il faudrait faire pour mettre en œuvre un SFU compatible avec Matrix au-dessus du moteur LiveKit.
Le résultat final a été Element Call Beta 3, qui est un hybride intéressant entre MSC3401 et la signalisation existante de LiveKit : la signalisation de haut niveau de l'appel (son existence, son appartenance, sa durée, etc.) est annoncée par Matrix - mais la signalisation WebRTC réelle est gérée par LiveKit, fournissant un support pour des centaines d'utilisateurs par appel.
Enfin, aujourd'hui marque la sortie d'Element Call Beta 4, qui réintègre le chiffrement de bout en bout via le SFU LiveKit (actuellement en utilisant un secret statique partagé, mais dans un futur proche, il supportera le chiffrement de bout en bout négocié par Matrix avec les clés de l'expéditeur) - et inclut également un rafraîchissement visuel complet. Les prochaines étapes comprennent le retour de la prise en charge du maillage complet ainsi que du SFU, pour les environnements sans SFU, et la mise à jour de tous les MSC pour reconnaître le modèle de signalisation hybride sur lequel la réalité a convergé lors de l'utilisation de LiveKit. En attendant, rendez-vous sur https://call.element.io pour l'essayer, ou lisez plus à ce sujet dans l'article du blog Element X Ignition !
Open ID Connect en natif
Enfin, nous sommes fiers d'annoncer que le projet visant à remplacer les vénérables API d'authentification existantes de Matrix par le standard industriel Open ID Connect dans Matrix 2.0 a fait un grand bond en avant aujourd'hui, matrix-authentication-service étant désormais disponible pour ajouter le support Native OIDC à Synapse, ainsi qu'à Element X qui implémente désormais l'enregistrement, la connexion et la gestion des comptes via Native OIDC (avec le support hérité uniquement pour la connexion/la déconnexion).
Il s'agit d'une étape cruciale dans l'amélioration de la sécurité et de la maintenabilité de l'authentification de Matrix, et vous pouvez lire tout cela dans cet article dédié, expliquant la raison d'être de l'adoption d'OpenID Connect pour toutes les formes d'authentification dans Matrix, et ce que vous devez savoir sur la transition.
Conclusion
Une énorme quantité de travail a été consacrée à Matrix 2.0 jusqu'à présent - qu'il s'agisse de l'implémentation de la synchronisation glissante dans matrix-rust-sdk et le proxy sliding-sync, matrix-authentication-service et toute l'infrastructure OIDC native sur les serveurs et les clients, l'intégralité d'Element Call et son travail sous-jacent matrix-js-sdk et SFU, ou même Faster Joins dans Synapse, qui a été livré en janvier dernier.
Cela a été un sprint assez stressant pour tout mettre en place, et un grand merci à tous ceux qui ont contribué - à la fois l'équipe d'Element, mais aussi les contributeurs à d'autres projets comme matrix-rust-sdk qui ont été pris dans le feu croisé
. Nous avons également été ravis de constater le niveau de soutien, la qualité des tests et l'excellent retour d'information de la part de l'ensemble de la communauté, qui s'est enthousiasmée pour la promesse de Matrix 2.0.Du côté de la Fondation, nous aimerions remercier les membres dont le soutien financier a été essentiel pour fournir la bande passante permettant de progresser sur Matrix 2.0 - et pour ceux qui veulent aider à accélérer Matrix, en particulier ceux qui construisent commercialement au-dessus de Matrix, veuillez envisager d'adhérer à la Fondation en tant que membre ! Par ailleurs, au cas où vous l'auriez manqué, nous sommes ravis d'accueillir Josh Simmons en tant que directeur général de la Fondation, chargé de gérer le programme d'adhésion à la Fondation et, d'une manière générale, d'assurer la croissance du financement de la Fondation au profit de l'ensemble de la communauté Matrix. Matthew et Amandine continuent de diriger l'ensemble du projet (en plus de leur travail à Element), avec le soutien des trois autres gardiens indépendants, mais Josh travaille à temps plein exclusivement à la gestion de la fondation à but non lucratif et à la collecte de fonds pour soutenir Matrix.
En parlant de financement, nous devons mentionner que nous avons dû interrompre des travaux dans d'autres domaines en raison du manque de fonds pour Matrix - en particulier lorsque nous nous sommes concentrés sur le lancement réussi de Matrix 2.0. Les principaux projets de nouvelle génération, dont Third Room, P2P Matrix et Low Bandwidth Matrix, ont tous été mis en pause, à moins d'un changement majeur de circonstances. Si vous avez de l'argent et que vous êtes intéressé par un monde où les projets expérimentaux de nouvelle génération de Matrix progressent et où les personnes qui y travaillent en font leur travail quotidien, prenez contact avec la Fondation.
Quelles sont les prochaines étapes ?
Bien qu'il s'agisse de la première version utilisable des implémentations de Matrix 2.0, il reste encore beaucoup de travail à faire :
- L'activation de Native OIDC sur matrix.org et la fourniture d'outils de migration vers Native OIDC pour les homeservers existants en général.
- Retravailler Sliding Sync sur la base des leçons apprises en l'implémentant dans matrix-rust-sdk
- Stabilisation et maturation des MSC de Matrix 2.0 jusqu'à ce qu'ils puissent être approuvés et fusionnés dans la spécification.
- Ajouter des sauvegardes cryptées à matrix-rust-sdk
- Réintroduction du support full-mesh pour les appels VoIP natifs du groupe Matrix
- Organiser une grande fête de lancement de Matrix 2.0 une fois que la spécification sera disponible !
En dehors du travail sur Matrix 2.0, d'autres éléments importants se profilent à l'horizon :
- L'ajout de Rust matrix-sdk-crypto à matrix-js-sdk, à partir duquel tous les SDK clients officiels de Matrix.org utiliseront (enfin !) la même implémentation E2EE stable et performante.
- Poursuite de la contribution de Matrix au groupe de travail MIMI de l'IETF pour l'interopérabilité de la loi sur les marchés numériques.
- Travail sur le MLS pour la prochaine génération d'E2EE
- Outils et capacités de modération de la prochaine génération
- Portabilité des comptes et comptes multihommes
- ...et bien d'autres choses encore.
Bienvenue donc dans le nouveau monde de la Matrice 2.0. Nous espérons que vous êtes aussi enthousiastes que nous et nous remercions tous ceux qui continuent à utiliser Matrix et à l'enrichir. C'est le début d'une nouvelle ère !
Matthew, Amandine et toute l'équipe de Matrix.
Et vous ?
Que pensez-vous de cette nouvelle version de Matrix ? Quelles sont les nouveautés que vous trouvez intéressantes ?Voir aussi
Lancement officiel de la première version stable du protocole de communication sécurisé Matrix et de la fondation Matrix.org L'infrastructure du protocole de communication sécurisé Matrix piratée, le hacker parle et expose de mauvaises pratiques de sécurité qui l'ont aidé P2P Matrix, un protocole ouvert et un réseau de communication pour la communication décentralisée et chiffrée, une alternative à Slack, WhatsApp, Discord et autres ?