Passage de Conduit (serveur matrix) en beta, retour rapide

Services Messagerie collaborative
1

Bonjour,

Les gens qui suivent l’actualité autour de Matrix ont peut être vu l’annonce, conduit, un serveur Matrix écrit en Rust, vient d’annoncer une version beta. Jusqu’à maintenant, le code du serveur n’était pas consideré comme suffisant pour se connecter à la fédération, mais ce n’est plus le cas.

Mon chef m’ayant dit « ça serait bien de proposer d’héberger des serveurs matrix », j’ai tenté de voir ce que ça donne, et j’ai fait une installation hier sur un domaine de test, et je pense que ça peut intéresser des gens ici.

L’infra du boulot pour Conduit

Mon travail consiste surtout à aider les projets libres sponsorisés pour mon employeur. Et il y a ~1 an, on a réussi à convaincre la hiérarchie de sortir des dollars US pour avoir accès à une infra moderne basé sur des conteneurs (en l’occurrence, Openshift Dedicated). Je fait d’habitude mes tests sur des VMs, mais la, je suis parti sur ça.

Les machines qui font tourner nos programmes sont des m5.xlarge de chez Amazon EC2, donc 4 CPU (visiblement, du Intel Xeon Platinum 8000, jusquà 3.1 Ghz), 16G de ram.

Comme Conduit est écrit en Rust et que les fonctionnalités dans les programmes Rust se font surtout à la compilation (pas de plugins ni rien que je sache), j’ai choisi de recompiler le binaire via tout le système de CI intégré d’Openshift. Sans rentrer dans les détails, je lance un conteneur Fedora, j’y installe Cargo (l’outil de compilation/gestion de paquet de Rust), je fait un clone du code, et je lance cargo build --release. Ensuite, je copie le binaire ailleurs et je fait le ménage avant de déployer tout ça sur l’infra.

La gestion des certificats et d’un reverse proxy est prise en charge par l’infrastructure, donc je ne vais pas détailler ce point. Mais si j’avais du déployer sur une machine normale, j’aurais du rajouter un reverse proxy, qui reste assez classique, et qui est largement documenté.

Pour indiquer ou se trouve le serveur, j’ai du aussi rajouter une entrée SRV dans le DNS pour tout faire passer par le port 443, et j’ai du aussi m’y prendre à 3 fois, parce que j’avais pas les yeux en face des trous.

La compilation

Premier retour, ça prends 25 minutes de compiler tout ça de 0, et les graphiques d’usage des ressources me disent que ça monte jusqu’à 8G de ram (et 5 unités de consommations de CPU, cad un CPU virtuel dans le cas présent, donc un hyperthread sur la machine). Le système repart de 0 à chaque fois à dessein, mais je suppose qu’une compilation incrémentale sans tout effacer est beaucoup plus rapide.

Je me concentre sur la partie CPU/RAM car le réseau est rarement (pour moi) un facteur limitant, mais il faut sans doute compter 100 à 200M de téléchargement de code. Le binaire une fois compilé fait 30M, ce qui me parait beaucoup (je me souviens de distribution Linux avec X11 sur une dizaine de disquettes, donc 10 M), mais c’est largement acceptable pour un binaire quasiment statique.

Il faut sans doute aussi prévoir un peu d’espace disque pour la compilation. Je n’ai pas de chiffres, mais on peut compter quelques gigas à mon avis, sur la base de la compilation d’autres outils en Rust.

Pour les gens moins frileux que moi, je conseille de regarder l’image docker et/ou de pousser à faire des paquets pour une distribution.

La configuration

La configuration est simple. Il y a un fichier config.toml d’exemple, mais on peut aussi passer par une configuration via des variables d’environnement (ce qui a causé un bug intéressant à débuguer).

La configuration est simple, mais la doc est inexistante pour le moment. Il y a de la documentation sur le déploiement (via docker-compose), mais pas plus.

Il n’y a pas encore d’outil d’administration en ligne de commande. Donc pour créer un compte, il faut changer la configuration (ouvrir l’ouverture de compte), relancer le serveur, faire le compte via un client matrix, et rechanger la configuration (pour refermer l’ouverture de compte). C’est assez fastidieux.

La consommation de ressources

J’ai installé ça hier, et pour le moment, la consommation en CPU est proche de 0 (les graphs me parle de 10e-4 unités de CPU), et la consommation de ram tourne autour de 20M. L’outil en Go que j’utilise à coté pour la gestion des certificats prends 30M de ram, et la base de donnée est sur le disque (ça utilise sqlite par défaut, mais il y a d’autres backend disponible à la compilation), donc tout me prends moins de 100 M de ram.

Comme j’ai pas encore fait grand chose, les chiffres ne sont pas vraiment significatif. Je vais aller voir ce que ça donne en traînant dans des salons divers

À titre de comparaison, j’ai aussi une instance Synapse pour moi même sur une machine pas cher de Scaleway (1 CPU atom à 1.7G, 4G de ram). Je fais tourner une Fedora 34 dessus, j’utilise les paquets de la distribution et j’ai exactement 1 utilisateur, moi avec 2 clients.

Htop m’affiche les chiffres suivants pour la consommation mémoire:

  • postgresql ~125M
  • synapse ~233M
  • apache ~22M

La base postgresql prends 1.3G sur le disque, après ~1 an d’utilisation à traîner sur ~5 ou 6 salons irc sans trafic énorme. Le répertoire avec les médias fait 618 M.

Au niveau du CPU, Synapse ne dépasse pas les 3% à vide, ce qui est acceptable.

Il est vrai qu’en comparant Conduit sur Sqlite avec Synapse sur Postgresql, je compare des pommes et des oranges. Mais dans la mesure ou Sqlite est la configuration par défaut de Conduit, et que la doc de Synapse dit « non à Sqlite, sauf pour des tests », je pense que la comparaison est valable.

Conclusion rapide

Pour le moment, Conduit me parait pas mal. Les points qui m’ont fait raler sur synapse sont sa consommation de ressources à mon sens excessive (par comparaison au serveur XMPP que j’ai sur le même serveur, c’était quand même x10) et sa documentation complète mais assez confuse à l’époque, notamment sur le fait d’avoir à la fois un fichier .well-known/matrix/server et les enregistrements SRV (alors que l’un ou l’autre suffisent), et le détail de l’option nocanon dans Apache.

Il reste encore beaucoup à faire (documentation, outils d’admin, et sans doute divers fonctionnalités), et je suppose que vu la philosophie Rust vis à vis des backends et vu les backends, il faut sans doute faire une croix sur ses données quand on veut passer de sqlite à sled ou heed (et aussi faire une croix sur d’éventuelles sauvegardes), mais la bêta reste encourageante, notamment pour les gens qui ne se vautrent pas dans le luxe au niveau de la ram (càd moi quand je sort une carte arm du placard par rapport à moi au boulot avec mon petit cluster à 106G de mémoire).

4 « J'aime »
2

Suite de mon aventure.

Donc visiblement, mes ratages de DNS ont fait que j’étais incapable de rejoindre un paquet de serveurs. Par contre, sur le serveur de @fouine , c’était bon.

Je ne sais pas pourquoi, mais pour aller sur les salons de GNOME ou d’Ansible (tout les 2 chez EMS), ça passe par un serveur matrix-federation.matrix.org. On m’a pourtant dit « c’est des infras séparés ».
Et ce bout du réseau avait l’air coincé sur une entrée DNS incorrect, qui visiblement a expiré après 24h.

Donc ce soir, j’ai pu rejoindre des salons plus conséquents.

J’ai pu constaté 3 choses.

Primo, Conduit ne supporte que les salons en version 5 ou 6. C’est écrit en violet/vert/jaune sur fond noir mais pas trop dans le code. Donc je me fait jeter des salons de GNOME, qui sont en version 1.

Secundo, rejoindre un gros salon (250 à 1000 personnes) affiche un message d’erreur « erreur 504, gateway timeout ». Je suppose que c’est un réglage sur le serveur haproxy que j’utilise, mais c’est bon à garder en tête. L’opération continue en arrière plan, donc rien de grave.

Tertio, la conso mémoire a décollé. J’ai rejoint le salon #users:ansible.im, avec 1078 personnes au compteur, et la consommation de ram est passé à 400 M. La conso CPU est correcte, le conteneur a fait un petit pique à 66 millièmes de CPU, mais je pense que ça va. Je rappelle que c’est un Xeon qui tape fort, je ne vais pas tenter ça sur une de mes RPi 1 asthmatique.

Et la base de données sqlite a une taille de 82 M (et 4.5M sur le répertoire media) maintenant.

Je n’ai pas le courage de rejoindre le même salon depuis mon serveur perso pour comparer, car je suis sur que foutre en l’air le serveur un vendredi soir n’est pas une bonne idée. Mais j’irais faire une comparaison un jour.

3

Très intéressant merci. J’attends beaucoup de ce serveur en Rust, pour espérer avoir un bon serveur Matrix moins gourmand en ressources que Synapse.

4

Il faut aussi bien voir que 5 ou 6, ça inclue ni 1, 2, 3, ou 4. Mais surtout, ça n’inclue pas les salons en version 7 (stabilisé mi juin 2021, disponible dans Synapse 15 jours après dans la version 1.37.0, ni en version 8, (dispo dans une version de synapse sorti il y a 25 jours, officiellement dans la spécification 2 jours avant). Et il se trouve que ce matin, un admin a mis à jour le salon #autohebergement:matrix.underworld.fr vers la version 8. Donc je me suis fait virer du salon, car Conduit ne peux pas rejoindre le salon. L’ironie de la marche forcé vers la mise à jour ne m’as pas échappé.

Au delà de mon agacement passager (car au final, je veux juste tester conduit), je comprends qu’il est sans doute sain de mettre à jour de temps en temps pour le bien de la fédération.

Mais la dominance d’un acteur dans l’écosystème (New Vector) avec sensiblement plus de ressources que le reste de l’écosystème rends tout ça problématique. Le fait de déclarer une fonctionnalité stable au moment ou elle est stable dans Synapse fait que les serveurs alternatifs vont soit avoir du retard tout le temps, soit avoir besoin de mettre autant de moyen qu’une boite financé à la hauteur de 10 millions d’euros sur 2 ans (ici, ici).

Je comprends l’envie de ne rajouter dans la spécification que ce qui a été implémenté, pour éviter d’avoir des surprises, mais dans un système distribué comme Matrix, c’est une pratique qui va plus fortement bénéficier l’acteur dominant.

Et il semble que ça n’est pas prêt de s’arrêter. Par exemple, il suffit d’aller voir le code de Synapse aujourd’hui pour voir que le code d’une fonctionnalité hors de la spécification stable est déjà la (MSC2716) et donc qu’une version 9 va à terme arriver (en fait, elle est la depuis hier et dans Synapse aussi).

Il y a bien des discussions pour améliorer ça via une MSC, mais de ce que je comprends, ça ne va pas régler le souci fondamental, à savoir que tout les serveurs de la fédération doivent être au même niveau. Et la mise à niveau implique de constamment tout mettre à jour, ce qui place la charge de travail sur les hébergeurs indépendants. Par exemple, mon serveur personnel a longtemps été coincé sur la version 1.26, car le paquet Fedora était bloqué sur une dépendance. Pour moi, utiliser un paquet de la distribution est une bonne pratique, l’alternative étant de gérer moi même le déploiement (et la gestion des versions, et les bugs, etc), mais du coup, ça mets plus de temps à mettre à jour.

Je vais être franc, ce coup des versions de salon, ça calme vachement mon hardeur. Je ne doute pas qu’à terme, Conduit va supporter les fonctionnalités (qui n’ont pas l’air spécialement complexe), mais je suis pas sur de voir comment un projet avec 1 personne financé qui code va réussir à suivre un projet avec 4 personnes salariées (estimation à la louche mais plus précise) sur le long terme si la tendance à rajouter des fonctions à tout va continue.

5

Éventuellement, je sais qu’il a un autre serveur léger en Go (j’ai plus le nom en tête, mais je crois que c’est Dendritte). Cela pourrait être un bon élément à comparer avec Conduit.

Sinon, cette réflexion me conforte dans l’idée de ne pas ouvrir mon serveur Matrix au public, mais c’est un autre sujet.

6

Oui, Dendrite. C’est une bonne idée, comme ça, je pourrais dire que j’ai tenté tout les serveurs valables, mais je ne vais pas pousser ce que je pourrais qualifier de masochisme latent jusqu’à tenter de déployer Construct. J’ai rien contre le C++, j’ai un ami qui est un programme en C++, mais j’ai le sentiment que ça ne va pas être viable vu que le dernier commit date de février 2021.

1 « J'aime »
7

J’ai tenté Dendrite (et j’ai failli faire un poste de forum avec comme titre « Fast and Furious 3, Tokyo Dendrift »).

J’ai repris le même type d’installation (en fait, j’ai copié la configuration, et j’ai changé 2/3 trucs)
Pour comparer avec Conduit sur les chiffres:

  • la compilation est plus rapide (15 minutes, utilise 1 ou 2 CPU au max, avec 1.6G de ram). J’ai passé un peu de temps à comprendre pourquoi ça échoue avec go 1.16 (une vague histoire de vcs), mais ça passe sans souci après.
  • les 3 binaires utiles (dendrite, create-account, generate-keys) font 55M au total, et l’image non nettoyé fait 3.4G, donc il faut garder ça de libre
  • à vide, le serveur prends ~20 Mo de ram

Sur les détails moins chiffrables, la configuration est beaucoup plus longue. Le fichier de config fait 392 lignes, vu que l’architecture de dendrite est d’avoir des processus séparés pour chaque bout du serveur (une architecture basé sur des micro services), tout en gardant la possibilité de compiler ça aussi sous forme d’un serveur monolitique (donc tout dans 1 seul binaire et process).

Du coup, chaque serveur a son bout de configuration. Le serveur qui gère l’api media, celui qui gère l’API /sync, etc. Et chaque service a la config pour la base de données et pour la localisation des autres services, ce qui rends le fichier un chouia plus gonflé, comme on peut le voir. Rien d’insurmontable, mais c’est un chouia plus de travail pour passer de la configuration par défaut (sqlite) à Postgresql, vu qu’il faut modifier 10 fois la config. Je conseille donc l’usage d’un outil adapté, que ça soit un coup de sed un peu brut, ou d’utiliser un gestionnaire de configuration avec un système de template.

Par flemme, et dans un premier temps, j’ai pris sqlite. Le fichier de config parle de performance 20 à 30% plus lente, mais mon but était de valider l’installation.

Et j’ai en effet validé que ça se lance, mais j’ai réussi à me planter.

Parlons d’abord des bonnes choses. Dendrite est un peu plus mature que Conduit, vu que le logiciel m’a affiché au lancement un message d’erreur lisible disant « il n’y a pas de clé privé » (Conduit aussi, mais pas dans le contexte de mon cluster pour une raison que j’ignore). J’ai donc ni une ni deux choisi de créer le fichier au lancement du conteneur (via initContainers). Et j’ai relancé, et ça a fonctionné.

Ensuite, j’ai fait un tour dans le conteneur, j’ai lancé create_user, et j’ai rajouté un utilisateur sans rien faire d’autre, un bon point par rapport à Conduit.

Ça, c’est les bonnes choses.

Pour tester, j’ai vite vu que la plupart des clients disponibles sur Fdroid ne permettent pas d’avoir plusieurs comptes. J’ai donc installé Fluffychat et Syphon sur mon téléphone (vu que j’ai Element pour mon compte perso, Schdlichat pour Conduit), et aucun des 2 n’a réussi à aller sur un salon, pour des raisons obscures. J’ai tenté avec Schildichat sur mon PC portable depuis Flathub, et j’ai réussi à aller un peu plus loin, mais pas très loin non plus. Donc j’ai commencé à aller sur le conteneur pour tenter d’y voir plus clair.

En regardant les graphs, j’ai vu que la conso de ram a décollé. J’ai tenté de rejoindre le même salon irc #users:ansible.im, et ça a assez vite pris plus de 1G de ram, soit facilement 2 fois plus que conduit. Et contrairement à Conduit, ça n’a pas fini par marcher, car après 10 minutes de moulinette, Dendrite était encore en train de traiter les evenements du salon.

Et durant mon essai nocturne, la machine ou le conteneur a été assigné a été déclaré « non viable » par le cluster, et donc les conteneurs ont bougés ailleurs automatiquement, la VM retiré du pool, puis automatiquement réinstallé. L’automatisation, c’est formidable sauf quand ça me prends pas en compte.

Et c’est la que je me suis aperçu que la création de clé privée écrase la clé à chaque fois, car le code actuel ne vérifie rien. Pour être clair, c’est ma faute, j’aurais du vérifier ça mais j’avais la flemme.

Donc pour le moment, le serveur tourne, mais n’est pas exactement fonctionnel sans doute à cause de l’histoire de la clé privé, et j’ai fini par me coucher.

La suite pour moi va être de corriger mon bug (donc ne pas écraser la clé privé (je suppose qu’un -f bien placé suffit), peut être d’envoyer un patch pour ça upstream (ou mieux, de ne pas avoir à faire la clé privé à la main alors que dendrite pourrait le faire sans intervention lors du premier lancement), et de passer à Postgresql, afin d’être sur d’avoir des performances correctes.

Donc je tiens le groupe au courant pour la suite de mes aventures.

1 « J'aime »
8

:slight_smile: Alors pour le passage en v8, c’était un accident :slight_smile: irréversible par contre

9

Bah, c’était une bonne chose, vu que ça a permis de mettre en avant le souci (et vaut mieux découvrir ça maintenant que plus tard).

Le fait que ça soit irréversible, je peux comprendre. Le fait que ni Synapse, ni les clients ne vérifient ça, c’est pas cool. La specification sur les upgrades parle vaguement du souci vers la fin:

The experience for clients could be improved by awareness of the m.room.version event and 
querying a capabilities API (e.g. /versions?) to determine whether a room has been upgraded newer 
than the server can support. If so, a client could say: “Your server must be upgraded to continue to 
participate in this room” (and manually prevent the user from trying to speak).

Mais j’ai pas trouvé de bugs sur ce sujet. Et en regardant la spécification, les clients peuvent savoir ce que le serveur supporte ( point 6.1 de la version 0.6.1 de la spécification Client-Server, ici ), mais pas les autres serveurs, donc pas les autres clients, donc un admin ne peut pas savoir si /upgrade va avoir des conséquences négatives.

10

Donc, suite et fin (ou presque). J’ai fini par terminer l’installation de Dendrite avec Postgresql.

Niveau ram, c’est beaucoup mieux qu’avec sqlite. Ça ne dépasse pas les 300 Mega pour le moment, même dans un gros salon comme ceux que j’ai tenté ( ~1000 personnes sur irc).

Niveau CPU, c’est pas encore ça. Au début, c’était à 500m d’un CPU (donc 50% d’un CPU), puis ça retombe, puis quand je tente de revenir en arrière sur un salon, ça remonte vers 1.

Niveau usage, Fluffychat continue à me donner des erreurs, mais j’ai réussi à rejoindre les salons quand même. Pour une raison que je ne comprends pas, j’ai des messages « failed to parse member event », et je ne sais pas si c’est Fluffychat ou Dendrite le probléme. Je suppose que le souci sont mes magouilles avec la clé privée sur ce salon en particulier.

J’ai réussi à parler avec moi même, pas eu de souci pour aller ailleurs même si c’est pas aussi immédiat que je voudrais.

Donc si on regarde les chiffres, on peut se dire « Dendrite s’en sort pas mal ». Mais il faut aussi regarder du coté de Postgresql. Et la, ça donne 230 Mo de ram, avec une conso du CPU qui fait des pics synchronisés ceux de Dendrite avec 1 à 2 unités de CPU.

Du coup, il faut compter 530 M, et des pics à 2 ou 3 unités de CPU pendant ~10 minutes pour rejoindre un salon de taille conséquente (et encore, 1000, ça va, y a 25 000 personnes sur le salon #matrix:matrix.org, 14 000 sur un salon sur Genshi Impact, et un paquet de salons sur divers crypto-monnaies qui sont entre 6000 et 10000).

Pour le fun, j’ai tenté de rejoindre le plus gros salon, et ça fait qulques minutes que l’interface web mouline (depuis 21h27, pour être exacte). Mais aucun pic de ressources sur le serveur, donc je suppose que c’est encore en train de tenter de faire le tour des serveurs.

11

Donc après plus d’une heure, Dendrite n’a pas réussi à rejoindre le salon. J’ai entre temps été chercher une pizza et pour finir sur une victoire, j’ai tenté de rejoindre le même salon avec Conduit.

Et… ça a mis du temps. Genre 20 à 30 minutes. Ça aussi pris de la ram (la, le serveur prends 1G de ram), mais ça a fini par arriver. Le CPU n’a jamais dépassé 0.25%. Aprèe redémarrage du serveur (nouveau commit), on reste à 600M de mémoire occupé.

Sur le point de finir ce post de forum pour de bon, je vais jeter un oeil sur Dendrite au cas ou. Et dans un rebondissement digne des meilleurs productions télés, je vois que les logs s’agitent, et que la ram décolle (vers 4G) avant de retomber à 600 M. Et en regardant les logs, Dendrite est encore en train de s’agiter sur des serveurs divers et variés. Et à prendre 0.5 CPU du coté de Dendrite, 0.5 CPU du coté de Postgresql.

Et finalement, après facilement 3 à 4h d’attente (il est 1h du matin, je suis parti prendre à manger vers 21h40), Dendrite a réussi à rentrer dans le salon.

Ensuite, je sais pas si ça marche parce que j’ai attendu, ou parce que j’est changé le timeout du proxy entrant (passage à 20 minutes). Dendrite est à 700M de ram, et Postgresql est à 400M.
Et le CPU a grimpé, mais jamais au dessus de 1.

12

Suite et fin de mes tests.

J’ai lancé element web sur 2 navigateurs (Firefox 91 et Firefox nightly), un connecté sur Dendrite, un connecté sur Conduit, les 2 sur les mêmes 3 salons (#users:ansible.com, #community:ansible.im, #matrix:matrix.org), et j’ai attendu tout le weekend en regardant les graphs (mais juste de temps en temps, je vous rassure, j’ai aussi été voir Luca chez une amie).

Les ressources

  • Conduit a une consommation mémoire et CPU assez constante et prévisible. Sur les 2j de mon test, il est resté entre 930M et 1.05G, avec des pics CPU qui vont de 0 à 3% et la consommation disque à la fin est de 392M (db et media compris).

  • Dendrite et PostgreSQL utilise 678 M sur le disque (/var/lib/postgres). La base en même fait 574 M, le reste étant surtout dans les journaux de transactions. Le dossier /var/lib/dendrite prends 521M, divisé en 397M de logs et 124M pour les medias.

  • Dendrite a parfois des pics de consommation de ram (jusqu’à 3.2G, mais en general à 2G), et de CPU (jusqu’à 80%, mais en general 30 à 50%) assez réguliers. De ce que je vois, c’est tout les 2/3h pendant 30 minutes à 1h, mais c’est assez variable. Je ne sais pas exactement pourquoi, j’imagine soit le ramasse miette de Go, soit les divers tentatives de se connecter à des serveurs morts (vu que les logs parlent beaucoup de ça). Vu que mon portable est resté dans mon sac tout l’après midi, j’écarte le fait que ça vienne d’un client.

Le reste

  • Pour une raison que je vais devoir investiguer sur mes heures de travail, le noeud qui fait tourner Conduit et Dendrite s’est fait réinstaller encore une fois (comme le dit la chanson). J’ai pu donc constater le temps de remise à niveau en cas de reboot inopiné, et j’ai le sentiment que Conduit a été un peu plus rapide, mais pas de beaucoup, sans doute parce qu’il a été relancé plus vite (conteneur plus petit, 1 seul process etc). Aucun n’a fini avec un DB corrompu, ce qui est plutôt bien.

  • Dendrite a un moment m’a affiché les messages dans le désordre. Je ne sais pas pourquoi, mais c’était pas dans l’ordre chronologique. Ça n’a concerné qu’une infime partie des messages (genre 2 sur les 2j, au début), sans doute lors de la synchronisation initiale. Mais ça me parait un bug curieux. Ce n’est pas un probléme client, vu que c’est le même des 2 cotés (et j’ai testé sur les clients mobiles, l’affichage été le même)

Conclusion

Conduit est fonctionnel, bien que moins que Dendrite, et même si je trouve que la consommation mémoire est excessive pour 3 salons, j’imagine qu’il y a une bonne raison pour ça qui m’échappe.

Dans l’état actuel, je pense qu’il reste encore réservé aux gens qui veulent expérimenter, mais me parait beaucoup plus prometteur que Dendrite pour des usages de serveurs personnels (ou en petit groupe).

Ensuite, j’ai pas testé avec plusieurs personnes en même temps, et peut être que les perfs s’écroulent dans ce cas (même si j’ai des doutes).

13

Bon, j’ai dit conclusion, mais après 1 semaine d’usage, il faut quand même que je pointe:

  • la consommation de Dendrite est retombé vers 200M. Il y a toujours des pics vers 1G quand je lance Element Web, mais ç’est mieux qu’avant
  • Conduit a grimpé à 1.5G.

Sinon, j’ai pas eu de souci entre temps

1 « J'aime »
14

Bonjour,

Quelques précisions sur le devenir des différents projets, ayant moi-même traîné dans le monde rust/matrix :

  • Conduit est essentiellement porté par une personne, Timo, le financement est plutôt sain, on y retrouve une bourse du ministère de l’éducation Allemand, et la société Famedly (téléconsultation et autres services médicaux en Allemagne, ils aident le client FluffyChat également). Je pense qu’il y a dans la communauté des gens capable de maintenir/reprendre Conduit en cas de problème, mais certainement avec un rythme d’avancé bien moindre. La cible était avant tout les cartes embarquée (raspberry, odroid etc.)
  • Dendrite est la prochaine cible de vector/matrix-org. Ca n’est pas dit clairement, mais Niel est l’un de leurs employé, et un pilier de matrix. Sur le papier c’est un meilleur choix dans un contexte « entreprise », il devrait remplacer Synapse (un jour…)
15

Ensuite, si je regarde le nombre de commit sur tout les projets depuis le 1er septembre, on voit qu’il y a eu 8 commits sur dendrite, 32 sur conduit, et 138 sur Synapse.

Pour Conduit, il faut aussi sans doute compter les commits sur ruma, et ça semble en effet bouger aussi vite que Synapse (modulo le fait que ruma fait plus que serveur, et qu’il y a aussi principalement 1 personne dessus).

Par contre, Dendrite, même si je rajoute les commits sur les libs go comme gomatrixserverlib et gomatrix, on reste toujours à 8.

Il semble que le focus pour le moment de Dendrite soit sur pinecone, et yggdrasil, donc parti sur les plans de retirer les serveurs et de passer en P2P plus qu’un usage « entreprise ».

Je ne sais pas si c’est parce que le fait d’avoir améliorer les perfs de Synapse a réduit la pression pour bosser sur Dendrite, ou si il y a autre chose qui pousse à retourner bosser sur les propositions de Matrix en P2P (demande clients, bourse de recherche, préparation du FOSDEM, etc), je suppose qu’il faut attendre quelques mois pour voir si il y a eu mise en pause temporaire du projet ou pas.