Salut tout le monde 
Spoiler alert
Je suis depuis peu employé chez New Vector, l’entreprise qui fait le produit Element, basé sur le protocole Matrix. Cependant, cela fait des années que je suis fan du projet de Matrix (au moins 4 ans), et j’ai aussi par ailleurs un collectif, pseudo-CHATONS, delire point party, sur lequel j’héberge une instance de Synapse/ElementWeb/plusieurs bridges. Je vais tâcher de répondre de manière la plus objective possible, et avec le minimum de prosélytisme. Je viens vous parler en vous donnant mon avis personnel et en apportant mes connaissances (limitées) sur les sujets mentionnés ici. Je vous épargne le blabla chiant complet, mais en gros je ne représente pas la boîte, je ne fais pas de promesses sur le futur, tout ça tout ça 
Des serveurs Matrix
- Dendrite, le serveur Matrix écrit en Go, n’est pas le remplaçant long-terme de Synapse (serveur Matrix écrit en Python). C’est une seconde implémentation. Cela permet de valider que la spécification du protocole Matrix permet une vraie interopérabilité, et que Synapse/les clients se comportent tel que la spec le requiert, et ne sont pas trop suradaptés les uns pour les autres.
- Synapse va continuer d’exister. Pour moi, son avantage principal c’est qu’il est écrit dans un langage accessible, qui fait qu’il est facile et rapide d’y ajouter des nouvelles fonctionnalités, d’expérimenter avec. Le contrepoint de cela, c’est que :
- c’est un langage interprété avec gestion de la mémoire automatique, et ces deux aspects ont nécessairement un impact sur l’usage mémoire (les ramasse-miettes/GCs ont tendance à garder jalousement la mémoire système allouée + c’est malheureusement trop facile d’avoir des « fuites » mémoires, en cas de références cycliques + l’interprétation nécessite de garder beaucoup de données sur l’état actuel du programme en RAM).
- sans aller à dire que l’optimisation n’est pas une priorité du tout dans Synapse, je ne pense pas (et c’est bien une interprétation personnelle de la situation) que c’est là l’objectif d’avoir le serveur le plus rapide du monde avec Synapse.
- Si vous voulez vous y intéresser, il est possible de gagner en scalabilité en ajoutant des processus de travail Synapse (workers). Cela ne règlera pas les problèmes de consommation RAM (a priori cela augmenterait la consommation de RAM), mais pourrait rendre les traitements plus rapides, pour des instances très actives.
- Ces deux projets, Synapse et Dendrite, sont principalement portés par Element en effet ; pour autant, ils restent des projets open-sources communautaires et pour lesquels les contributions sont bienvenues.
- Il existe aussi un projet entièrement communautaire de réécriture d’un serveur Matrix en Rust
appelé Conduit. Je ne sais pas à quel point Conduit implémente la spec, et cela pourrait poser des problèmes de compatibilité, mais pour autant ça pourrait valoir le coup de tester.
De l’authentification
De ce que j’en sais, OIDC est sur la feuille de route d’Element et de Synapse, et plusieurs projets commencent à l’intégrer. En tous cas, ça va arriver. Toutes les questions auxquelles vous avez pensé, ainsi que toutes les autres, sont sur ce site, si vous aimez les détails. En gros, ça arrive doucement dans Synapse, pas encore dans Dendrite.
Des notifications fantômes
OUI ! C’est un des soucis les plus pénibles avec Element Web, en témoignent les commentaires dans ce ticket. On utilise Element en interne (no shit sherlock), et autant vous dire qu’on est les premier.e.s à en souffrir. L’équipe Web travaille dessus à fond, il y a plusieurs propositions d’extension du protocole pour gérer ça proprement (et oui, des fois il y a des bugs dans le protocole). Impossible de vous dire quand ça va être réglé, mais ça fait partie des problèmes les plus remontés, et tout le monde en souffre. Je croise les doigts que ça aille vite.
De la gestion des DMs
Pour ce qui est du chiffrement, j’ai envie de dire un truc pas utile, mais : décentralisation + chiffrement E2EE + multi-devices = tout est 100x plus compliqué. Le seul espoir que je peux apporter est un petit éclairage sur le context actuel :
- Les clients actuels, Element pour Android / iOS / Web, utilisaient historiquement du code différent pour gérer le chiffrement. Donc tout était réimplementé, et il pouvait y avoir des bugs sur une plateforme (mais pas les autres). Cette approche demande plus d’efforts, présente plus de risques, bref, ça ne pouvait pas durer.
- Par la suite, des gens ont commencé à réécrire un SDK (du code pour que des devs puissent écrire des applications avec Matrix) en Rust qui gère vraiment bien le chiffrement ; après tout, c’était un projet soirée/week-end d’un des devs de l’équipe chiffrement chez Element. Un seul projet pour le chiffrement, c’est des efforts d’implémentation partagés, un seul endroit où tester et réparer les choses, et comme c’est en Rust on a des perfs solides, bref, que du bon.
- Récemment, la partie crypto a été extraite du SDK, et a été incorporée dans les clients historiques ; donc tout le monde utilise le chiffrement en Rust depuis quelques semaines (si vous avez vu une notification vous dire « l’app est désormais plus sécurisée » c’est en référence à ça).
- Il y a un gros gros projet de réécriture d’Element pour en améliorer l’UX et les performances : Element X. Si vous avez un téléphone sous iOS, vous pouvez déjà l’essayer en alpha ; elle nécessite de s’inscrire sur une liste d’attente et d’avoir un serveur compatible (avec sliding sync, qui nécessite un serveur proxy pour fonctionner à l’heure actuelle). Dans quelques temps, on devrait avoir un équivalent sur Android, et beaucoup plus tard, en Web. Ces apps sont résolument plus modernes, plus rapides (la synchro à l’ouverture est instantanée
), et incluent la même partie de chiffrement bien plus robuste. A l’heure actuelle, elles ne sont pas équivalentes en termes de fonctionnalités, mais répondent très bien au besoin de « réseau social privé » (discussion entre ami.e.s).
Tout ce pavé pour dire « wait and see » 
Les choses s’améliorent vraiment, on a vu le nombre d’erreurs s’écrouler quand Element iOS est passé au chiffrement avec Rust, donc à titre personnel j’ai espoir que ça va continuer de s’améliorer. (Et comme c’est l’équipe dans laquelle je travaille, j’ai aussi conscience de ce qu’on est capable d’accomplir.)
En attendant, voici une petite bidouille quand les messages de quelqu’un ne peuvent pas être déchiffrés par quelqu’un d’autre. La personne qui a envoyé le message peut entrer la commande /discardsession puis Entrée, dans le champ de message, d’un client Element (Web ou Android). Cela invalide la session de chiffrement et en recréé une autre, ce qui force un re-partage des clés et permet de débloquer pas mal de situations cassées. Les messages précédents ne seront pas déchiffrés pour autant, mais ça permet de repartir sur des bases saines 🤷♂
Je ne vais pas revenir sur tous les points soulevés qui ne vont pas, ce n’est pas vraiment mon travail et mon rôle ici. Ma conclusion sera que, comme beaucoup de logiciels libres, Synapse et Element ont commencé en mode démo technique qui fait des trucs super cools, mais sans prêter trop d’attention à l’expérience utilisateur.ice. C’est en train de changer complètement, avec des UX designers à temps plein (sur les nouvelles apps notamment), et ça se ressent beaucoup dans Element X à mon avis.
Voilà, c’était ma petite note d’espoir 
J’espère que ça répond à certaines interrogations et que ça sera utile pour agrémenter votre réflexion.