Matrix existe depuis plus de 9 ans maintenant, offrant une norme ouverte pour une communication scurise et dcentralise 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 rseau public, couvrant 17 289 201 pices, rparties sur 64 256 serveurs. Ce chiffre ne fait qu’effleurer la surface, car nous estimons que 66 % des serveurs du rseau public ne communiquent pas leurs statistiques et qu’il existe galement de nombreux et normes rseaux privs de serveurs. Nous avons parcouru un long chemin depuis la cration de Matrix HQ en tant que premire salle sur le rseau public actuel, le 13 aot 2014
Pendant ce temps, l’cosystme Matrix a continu se dvelopper de manire incroyable – avec un grand nombre de clients indpendants, de bots et de ponts mrissant en cosystmes propres, de nouvelles entreprises entires 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’excuter leur propre communication scurise, dcentralise, base sur des normes et auto-souveraine.
Le monde a plus que jamais besoin de Matrix. Chaque jour, l’importance de la dcentralisation devient plus douloureusement vidente, alors que nous voyons concrtement les risques terrifiants des services Internet centraliss – que ce soit par la prise de contrle des entreprises, la censure d’tat, la surveillance gnralise, les fermetures d’Internet, le capitalisme de surveillance ou le spectre de gigantesques violations de donnes centralises. Il a t extraordinaire de voir le monde basculer en faveur de la dcentralisation 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 marchs numriques (DMA) de l’Union europenne est un grand pas dans cette direction – une rglementation qui impose aux grands fournisseurs de messagerie centralise d’interoprer s’ils veulent oprer dans l’Union europenne. Nous avons travaill d’arrache-pied pour que cela devienne une ralit, notamment en participant pour la premire fois l’IETF dans le cadre du groupe de travail MIMI, en dmontrant concrtement comment (par exemple) Android Messages pourrait parler Matrix en natif afin d’interoprer avec d’autres services, tout en prservant le chiffrement de bout en bout.
D’autre part, Matrix s’est souvent concentr sur la rsolution des problmes difficiles de la dcentralisation, du chiffrement de bout en bout dcentralis et des complexits logistiques lies au soutien d’un rseau de communication public htrogne massif et de l’cosystme htrogne qui l’entoure. Il est juste de dire qu’au dbut, notre objectif tait de faire quelque chose qui fonctionnait, puis plus tard, nous nous sommes concentrs sur quelque chose qui fonctionnait et s’adaptait correctement… mais nous n’avions pas russi nous assurer que Matrix fournisse les lments de base ncessaires pour crer des applications de communication hyper rapides et hyper efficaces qui ont le potentiel de surpasser les services de messagerie centraliss traditionnels…
…jusqu’ aujourd’hui !
Matrix 2.0
Lors du FOSDEM, nous avons annonc l’ide de Matrix 2.0 – une srie d’normes changements en termes de convivialit et de performance de Matrix, comprenant Sliding Sync (connexion/lancement/synchronisation instantans), Native OIDC (authentification standard), Native Group VoIP (confrence vocale et vido crypte 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 fonctionnalits de Matrix 2.0. Il y a encore du travail faire pour les intgrer formellement dans la spcification, mais nous les mettons la disposition des gens pour qu’ils puissent en faire l’exprience ds maintenant. Dveloppeurs : surveillez cet espace pour des mises jour sur le front de la spcification.
En pratique, cela signifie que des implmentations 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 fonctionnalits de Matrix 2.0 et pour prouver que les nouvelles API sont bases sur une utilisation relle et peuvent concrtement crer une application qui commence surpasser iMessage, WhatsApp et Telegram en termes de convivialit et de performance… tout en bnficiant 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 rel – et cela signifie utiliser une base de code client relle comme cobaye pour s’assurer que le nouveau protocole est adapt. matrix-rust-sdk a t le principal vhicule pour cela, avec Element X en tant qu’application pilotant principalement les nouvelles fonctionnalits (bien que d’autres clients construits sur matrix-rust-sdk, tels que Fractal 5, puissent automatiquement bnficier 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’implmentation de Sliding Sync (MSC3575) dans matrix-rust-sdk – et ensuite la cration 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 rinventer la roue et risquer de se tromper. Le nouveau crate UI fournit des API pour grer efficacement une liste de salle lazy-loaded, des timelines de salle lazy-loaded (y compris les ditions, les ractions, les agrgations, les rdactions, etc), et mme quand l’application doit afficher un spinner de synchronisation ou non. En consquence, la grande majorit des tches lourdes peut tre gre dans matrix-rust-sdk, ce qui permet la couche applicative de se concentrer sur l’interface utilisateur plutt que sur les rouages de Matrix – et les amliorations de performance (par exemple, la mise en cache de la liste des salles et de la timeline) peuvent toutes tre gres en un seul endroit, au bnfice de tous les clients utilisant le SDK.
Il s’agit d’une avance considrable par rapport l’ancienne poque de Matrix, o chaque client n’avait d’autre choix que de passer beaucoup de temps crer la main sa propre chronologie et sa propre logique de chiffrement (mme si, bien sr, 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 exprimenter avec les clients de Matrix 2.0. Il convient de noter que la bibliothque 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 implmentation E2EE sous-jacente vodozemac sont assez stables, des fonctionnalits telles que E2EE Backup sont encore ajoutes au niveau suprieur 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 gnrateur de liaisons linguistiques de Mozilla, de sorte que vous pouvez maintenant appeler matrix-rust-sdk directement partir de Swift, Kotlin et (en thorie) d’autres langages, avec une smantique asynchrone/await non bloquante magnifiquement simple. Cela semble tre une pile assez impressionnante pour faire du dveloppement multiplateforme moderne – donc mme 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 esprons que d’autres projets suivront le modle Rust + Swift/Kotlin pour leurs besoins de performances extrmes 
Sliding Sync
Le changement le plus important dans Matrix 2.0 est la proposition d’une toute nouvelle API de synchronisation appele Sliding Sync (MSC3575). L’objectif de Sliding Sync est de s’assurer que l’application a la possibilit de charger les donnes absolument essentielles au rendu de son interface utilisateur visible – en s’assurant que les oprations qui ont toujours t horriblement lentes dans Matrix (connexion et synchronisation initiale, lancement et synchronisation incrmentale) sont instantanes, quel que soit le nombre de pices dans lesquelles l’utilisateur se trouve ou la taille de ces pices.
Alors que matrix-rust-sdk implmente la fois Sync v2 (l’API actuelle de Matrix 1.8) et Sliding Sync, Element X n’implmente dlibrment que Sliding Sync, afin de se concentrer exclusivement sur l’obtention de l’interface utilisateur la plus rapide possible (et gnralement d’exercer l’API). Par consquent, 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 dmarrer (ou Element Server Suite fournit des paquets de l’quipe Element).
L’implmentation de Sliding Sync dans matrix-rust-sdk a t un vritable parcours du combattant. Depuis que nous avons prsent la toute premire implmentation au FOSDEM, deux problmes majeurs sont apparus. Pour un peu de contexte : la conception originale de Sliding Sync tait fortement inspire par l’architecture de Discord – o le serveur calcule une liste ordonne d’un grand nombre d’lments (votre liste de salles, dans le cas de Matrix) ; le client indique quelle fentre 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 dfiler la liste, en faisant glisser la fentre vers le haut ou vers le bas, et le serveur envoie les mises jour appropries – 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 premire chose que l’application essaie de faire est de tlcharger une rponse de synchronisation initiale de 100MB Sync v2, ou d’ailleurs une rponse de synchronisation incrmentale de 10MB aprs avoir t hors ligne pendant quelques jours (10MB prend 9 heures pour se dplacer sur un modem 2400 bauds, pour ceux qui ont rat les annes 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 dfaut mineur de ce plan est que le serveur ne dispose pas ncessairement de toutes les donnes dont il a besoin pour ordonner la liste des chambres. L’ordre des salles dpend des vnements visibles les plus rcents dans une salle, et si la salle est crypte de bout en bout, le serveur n’a aucun moyen de savoir quels vnements seront visibles pour un client donn ou non. Il ne sait pas non plus quelles salles contiennent des mentions cryptes, et nous ne voulons pas divulguer les mtadonnes des mentions au serveur, ni concevoir des mentions de mots cls. MSC3575 a donc propos quelques contorsions compliques pour permettre au client de modifier l’ordre ct client sur la base de sa connaissance suprieure de l’ordre (tant donn que la plupart des clients auraient de toute faon besoin de synchroniser toutes les salles cryptes, afin de les indexer et de rechercher des notifications de mots cls, etc.) En attendant, l’ordre pourrait tre « suffisamment bon » mme sans ces ajustements.
La deuxime petite faille dans le plan tait qu’aprs avoir implment Sliding Sync dans Element X, il s’est avr que l’exprience utilisateur sur mobile de chargement incrmental des entres de la liste des salles depuis le serveur au fur et mesure que l’utilisateur fait dfiler la liste n’est tout simplement pas assez bonne, en particulier en cas de mauvaise connectivit – et la dernire chose que nous voulons faire est de concevoir un support pour une mauvaise connectivit dans Matrix. Les utilisateurs de tlphones portables ont t forms s’attendre pouvoir faire dfiler 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 rserv, mme pour une image. Ainsi, si le temps d’aller-retour du rseau vers votre serveur est de 100 ms et que Sliding Sync fonctionne infiniment vite, vous finirez toujours par afficher un espace rserv pendant quelques images (6 images, 60 images par seconde, pour tre prcis) si l’utilisateur commence faire dfiler rapidement la liste de ses pices. 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 dfinition des attentes des utilisateurs !
La faon la plus vidente de rsoudre ces deux problmes est donc d’extraire davantage de donnes en arrire-plan, afin d’anticiper le dfilement de l’utilisateur. En fait, il s’avre que nous avons besoin de faire cela de toute faon, et en effet d’extraire toutes les donnes de la salle pour que la recherche de salle soit instantanment ractive ; 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’avre que de nombreux utilisateurs naviguent dans leur liste de salles entirement par la recherche plutt que par le dfilement. En consquence, l’implmentation de Sliding Sync dans matrix-rust-sdk a fini par maintenir une liste de « toutes les salles », qui commence par synchroniser les dtails de la roomlist pour les N salles les plus rcentes, puis s’tend en arrire-plan pour synchroniser toutes les autres. ce stade, nous ne faisons plus vraiment glisser une fentre : il s’agit plutt d’une synchronisation incrmentale avec QoS.
Donc, pour faire court : bien que l’implmentation actuelle de Sliding Sync dans matrix-rust-sdk et Element X fonctionne empiriquement trs bien, elle a fini par tre un peu trop complique et nous nous attendons des simplifications assez significatives dans un futur proche, bases sur les meilleures pratiques trouves avec les clients qui l’utilisent. Surveillez cet espace pour les mises jour, bien qu’il soit probable que la forme actuelle de MSC3575 prvaudra 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 prservation de la bande passante. Pour l’instant, nous continuerons donc utiliser le proxy de synchronisation glissante comme moyen d’exprimenter 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 dvelopp en utilisant Element X comme banc d’essai, Element Call a t le cobaye pour la mise en uvre d’appels vocaux/vido de groupe volutifs et entirement crypts de bout en bout dans Matrix, en s’appuyant sur matrix-js-sdk. Aujourd’hui, Element Call a enfin russi le faire fonctionner, avec un chiffrement de bout en bout (et intgr dans Element X, d’ailleurs) !
l’instar de Sliding Sync, ce projet a t un vritable parcours du combattant. Les premires implmentations d’Element Call suivaient strictement la norme MSC3401, en utilisant la confrence maillage complet pour que chaque participant passe effectivement un appel tous les autres participants – dcentralisant ainsi la confrence et vitant le besoin d’un serveur de confrence « focus »… mais limitant la confrence 7 ou 8 participants en raison de la duplication de la vido envoye ncessaire. Dans Element Call Beta 2, le chiffrement de bout en bout a t activ ; facile, tant donn qu’il s’agit simplement d’une srie d’appels 1:1.
C’est alors que la vritable aventure a commenc : mettre en uvre une unit de renvoi slectif (SFU) qui peut tre utilise 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 appele sfu-to-sfu pour dmontrer la viabilit des SFU en cascade htrognes et dcentralises, 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 confrences entre tous les foyers participants, offrant ainsi la premire vidoconfrence dcentralise htrogne au monde. Element a pris l’implmentation sfu-to-sfu, l’a connecte Element Call on a branch, et l’a renomme waterfall.
Cependant, lorsque Sean a contribu pour la premire fois sfu-to-sfu, il nous a dit que si Matrix tait srieux au sujet des SFU, nous devrions jeter un coup d’il LiveKit – une startup open source pas trs diffrente d’Element qui tait occupe construire les meilleurs SFU de leur catgorie 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 rgler le contrle de la congestion, la correction des erreurs, la mise en uvre du cryptage de bout en bout, etc. que l’quipe LiveKit avait dj pass des annes faire. Element a donc contact l’quipe LiveKit et a commenc exprimenter ce qu’il faudrait faire pour mettre en uvre un SFU compatible avec Matrix au-dessus du moteur LiveKit.
Le rsultat final a t Element Call Beta 3, qui est un hybride intressant entre MSC3401 et la signalisation existante de LiveKit : la signalisation de haut niveau de l’appel (son existence, son appartenance, sa dure, etc.) est annonce par Matrix – mais la signalisation WebRTC relle est gre par LiveKit, fournissant un support pour des centaines d’utilisateurs par appel.
Enfin, aujourd’hui marque la sortie d’Element Call Beta 4, qui rintgre 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 ngoci par Matrix avec les cls de l’expditeur) – et inclut galement un rafrachissement 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 reconnatre le modle de signalisation hybride sur lequel la ralit 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 vnrables 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 dsormais disponible pour ajouter le support Native OIDC Synapse, ainsi qu’ Element X qui implmente dsormais l’enregistrement, la connexion et la gestion des comptes via Native OIDC (avec le support hrit uniquement pour la connexion/la dconnexion).
Il s’agit d’une tape cruciale dans l’amlioration de la scurit et de la maintenabilit de l’authentification de Matrix, et vous pouvez lire tout cela dans cet article ddi, 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 consacre Matrix 2.0 jusqu’ prsent – qu’il s’agisse de l’implmentation 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’intgralit d’Element Call et son travail sous-jacent matrix-js-sdk et SFU, ou mme 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 enthousiasme pour la promesse de Matrix 2.0.
Du ct 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 acclrer Matrix, en particulier ceux qui construisent commercialement au-dessus de Matrix, veuillez envisager d’adhrer 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 gnral de la Fondation, charg de grer le programme d’adhsion la Fondation et, d’une manire gnrale, 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 indpendants, 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 concentrs sur le lancement russi de Matrix 2.0. Les principaux projets de nouvelle gnration, 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 intress par un monde o les projets exprimentaux de nouvelle gnration 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 premire version utilisable des implmentations 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 gnral.
- Retravailler Sliding Sync sur la base des leons apprises en l’implmentant dans matrix-rust-sdk
- Stabilisation et maturation des MSC de Matrix 2.0 jusqu’ ce qu’ils puissent tre approuvs et fusionns dans la spcification.
- Ajouter des sauvegardes cryptes matrix-rust-sdk
- Rintroduction du support full-mesh pour les appels VoIP natifs du groupe Matrix
- Organiser une grande fte de lancement de Matrix 2.0 une fois que la spcification sera disponible !
En dehors du travail sur Matrix 2.0, d’autres lments 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 mme implmentation E2EE stable et performante.
- Poursuite de la contribution de Matrix au groupe de travail MIMI de l’IETF pour l’interoprabilit de la loi sur les marchs numriques.
- Travail sur le MLS pour la prochaine gnration d’E2EE
- Outils et capacits de modration de la prochaine gnration
- Portabilit des comptes et comptes multihommes
- …et bien d’autres choses encore.
Bienvenue donc dans le nouveau monde de la Matrice 2.0. Nous esprons que vous tes aussi enthousiastes que nous et nous remercions tous ceux qui continuent utiliser Matrix et l’enrichir. C’est le dbut d’une nouvelle re !
Matthew, Amandine et toute l’quipe de Matrix.