Matrix 2.0 : L'avenir de Matrix

La version 2.0 du protocole de communication sécurisé s'étoffe de plusieurs nouvelles fonctionnalités

Matrix 2.0 : L'avenir de Matrix, la version 2.0 du protocole de communication sécurisé s'étoffe de plusieurs nouvelles fonctionnalités

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.


[QUOTE]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 à...