Bonjour,
Quelques petits éléments qui pourraient vous intéresser :
« Idée de scinder l’UX entre deux use-case »
Pour information, Treebal (https://www.treebal.green/) est une messagerie basée sur Matrix qui a déjà travaillé sur la séparation de use-case vie privée / vie pro : ils ont implémenté un client qui utilise 2 comptes sur la même interface, l’un dédié au privé, l’autre dédié au pro. Peut-être que ça peut vous servir pour votre réflexion ?
« Dendrite, son successeur, a refusé une PR qui ajoutait le support OpenID »:
Il n’est pas encore certain que dendrite soit vraiment le successeur de Synapse. Des discussions qu’on a eu avec Element, dendrite serait peut-être plus destiné à un environnement de type « embarqué » car il a une faible empreinte mémoire, et ne serait pas destiné à remplacer complètement synapse. A prendre avec des pincettes.
Quelques éléments pour se motiver à croire en Matrix :
Le gouvernement français utilise Matrix pour sa messagerie entre agents de la fonction publique : https://www.tchap.gouv.fr
Et de mon côté, au niveau professionnel, je fais partie d’une équipe qui est en train de pousser Matrix comme moyen de rendre interopérable les messagerie de santé (EIMIS — beta.gouv.fr). On a d’ailleurs approché Gematik pour travailler avec eux.
Donc oui, il faut croire en Matrix, c’est le sens de l’évolution des messageries instantanées !
De manière générale, je suis très intéressé par le sujet de l’identification/annuaire car c’est un sujet épineux quand on travaille avec Matrix.
Je me permets d’étayer un peu les critiques que j’avais publiées sur mon compte Mastodon, en essayant de produire une liste un peu plus exhaustive et détaillée.
Chiffrement non fonctionnel
Voilà un exemple de problème que je rencontre de temps en temps sur Matrix :
J’ouvre un nouveau DM avec une personne, impossible de lire ses messages. Et parfois c’est l’inverse : l’autre personne ne peut soudainement plus lire ce que je lui envoie. Et pas seulement pour les nouveaux DMs ! Ça peut arriver avec n’importe qui.
Alors heureusement, je n’ai généralement ce problème qu’une ou deux fois par mois alors que j’utilise Matrix quotidiennement. On reste quand même très loin de l’expérience XMPP avec lequel je devais me battre avec chaque contact entre le support OMEMO, OpenPGP, côté client, côté serveur, côté expéditeur et côté destinataire (le grand n’importe quoi ).
Notifications fantômes
Matrix/Element ne sait pas gérer les threads correctement : à chaque fois qu’une personne poste dans un thread, il y a une chance sur deux que ça laisse une notification fantôme à toutes les personnes dans le canal.
Le seul moyen de retirer la notification : clic droit sur le canal → marquer comme lu. Mais c’est temporaire, au bout d’environ 10 minutes elle réapparaîtra, pour finalement disparaître seulement quelques heures ou jours plus tard. C’est vraiment à se demander s’ils ont testé leur fonctionnalité avant de la déployer.
Mauvaise gestion des DMs
Comme sur toute messagerie instantanée, il m’arrive régulièrement de recevoir des messages privés. Les canaux des messages privés ne disparaissent pas avec le temps. Alors au bout de quelques années, j’ai plus de 100 canaux de DMs inutilisés qui s’affichent dans mon interface.
Et comme avec Discord ou n’importe quelle autre messagerie moderne, on pourrait s’attendre que la personne avec qui j’ai discuté en dernier apparaisse en haut. Mais non, du tout : elle est en 45e position dans la liste, derrière plein de gens avec qui j’ai discuté une fois il y a deux ans. Pratique, n’est-ce pas ?
Avec un paramètre de rétention de messages de 6 mois (qui efface périodiquement les messages après un certain temps), je me retrouve avec 90 canaux complètement vides, mais qui sont quand même là, à polluer mon interface.
Alors il est possible de quitter les canaux inactifs : lorsqu’on ne discute plus avec quelqu’un, on peut faire clic droit → quitter le salon, et le canal disparaît (et ça envoie une notification à votre correspondant·e, au passage). Vous imaginez faire ça pour 200 contacts ? Même Mattermost gère ça mille fois mieux.
Support OpenID
Oui, c’est pour ça, c’est une question de roadmap, même si j’en reste très frustré car ça nous bloque pas mal.
Migration d’un serveur impossible
Avez-vous déjà regardé la base de données de votre serveur Matrix ?
Avec Synapse : le nom de domaine de votre serveur est écrit et répété partout dans la BDD, ce qui n’est non seulement pas optimisé, mais en plus pas du tout pratique pour migrer un serveur vers un nouveau nom de domaine. J’ai l’impression qu’ils ne connaissent pas le concept de clés étrangères en BDD et c’est très inquiétant. J’ose espérer qu’il y a du mieux du côté de Dendrite.
En fait, leur base de données est tellement une usine à gaz qu’ils ont même développé des outils pour l’optimiser, à exécuter de temps en temps pour gagner un peu d’espace disque.
Les « espaces » Matrix
Ça, c’est une fonctionnalité qui est bien tombée à l’eau. Personne ne les utilise, à l’exception de quelques enthousiastes de Matrix. Ils ont essayé de la réformer à deux reprises, mais ce n’est toujours pas ça. La seule fonctionnalité qu’ils apportent, c’est cette sorte de « filtrage » de canaux par groupe, pas du tout intuitive et qui apporte beaucoup de confusion à l’usage par des personnes non habituées au logiciel.
La gestion des rôles dans les espaces est aussi bancale que dans les canaux classiques, alors que pour le coup, il serait sans doute plus intéressant de se pencher sur la gestion des rôles du côté de Discord.
La RAM
Nous avons une instance qui accueille environ 200 personnes, dont à peu près 10 personnes actives. Nous avons paramétré Synapse pour qu’il refuse de se connecter à de tros gros canaux, et utilisons assez peu la fédération de manière générale.
Notre instance consomme actuellement 540 Mo. C’est plus que notre service Mail, plus que Nextcloud, plus que Nitter qui gère un trafic cent fois supérieur, c’est presque autant que l’usine à gaz qui nous sert d’éditeur de documents collaboratifs tout pété (aussi appelée « Collabora »).
J’entends qu’il y a la fédération, que ça complique beaucoup de choses niveau performance… mais quand même, envoyer et recevoir du contenu textuel et quelques images, c’est pas censé pomper autant, si ?
Malheureusement, pour tous ces bugs et défauts de conception, j’ai l’impression que ce n’est pas une collaboration inter-CHATONS qui nous aidera… C’est à Matrix/New Vector d’améliorer leurs logiciels et de réparer leurs bugs.
Et je précise que non, je ne vais pas créer un ticket pour chaque bug que je rencontre : Synapse est à 1400 tickets ouverts, Element en a 3500, je m’attends donc à ce que mon ticket soit perdu dans leur mer de tickets, et j’ose espérer que des bugs aussi critiques et persistents que ceux-là soient déjà remontés depuis des mois.
Un fork demanderait énormément d’énergie car l’équipe derrière Matrix est salariée, donc très active. Un soft fork serait trop chronophage à maintenir, et un hard fork serait carrément chaotique à gérer pour suivre la parité des fonctionnalités et l’interopérabilité avec le projet original.
Les serveurs d’identité, ça aussi c’est un bon gros défaut de Matrix pour moi… Je ne connais personne qui utilise la fonctionnalité de découverte de contacts, et le fait que matrix.org soit le serveur d’identité par défaut est un énorme problème de vie privée. J’aurais souhaité que cette fonctionnalité n’ait jamais existé
Oui, alors… perso, je m’en fiche que le gouvernement français ou allemand utilise Matrix ou non, je cherche juste :
un logiciel de messagerie instantanée libre qui marche sur toutes les plateformes (desktop et mobile)
avec des fonctionnalités de base de la messagerie instantanée moderne : threads, réactions, DMs…
avec une interface accessible et intuitive
qui marche : c’est-à-dire, qui permette d’envoyer et de recevoir des messages.
Et si Matrix ne respecte pas 2 de ces quatre critères, je n’ai personnellement aucune utilité à lui donner. Et j’ai l’impression que c’est hyper compliqué de le trouver, ce logiciel de messagerie qui marche…
(Voilà, c’est bon, j’ai fini mon rant, je range le sel )
@neil Je me demande si tu as oublié la fédération dans ta liste aux parents Noël ou pas.
Si ce n’est pas le cas, je propose Mattermost, qui a très peu de bugs, est très complet, est proche de Discord/Slack. Son interface n’est pas très intuitive, mais très adaptée au travail d’équipe.
Tu l’as mentionné en disant « Même Mattermost », donc je suppose que tu ne le portes pas spécialement dans ton cœur ceci dit ^^
En vrai, j’ai omis un petit point important dans cette liste. On n’a pas nécessairement besoin de la fédération, mais juste de OpenID connect pour avoir un SSO… or, c’est une fonctionnalité payante de mattermost et je trouve ça très dommage car sinon nous aurions sans doute adopté la solution !
Je sais qu’il y a des combines pour utiliser Keycloak ou Gitlab avec, mais c’est du bidouillage.
Et pour keycloak, je te confirme que la bidouille ne fonctionne plus, c’est ce qu’on faisait sur notre instance à LaToileScoute, et une mise à jour de Keycloak a corrigé le problème de config qui permettait cette bidouille. C’est pour ça qu’on a pris la décision de fermé le service après l’été. Là on a une instance de keycloak obsolète juste pour garder l’accès à Mattermost, et une autre pour le reste de nos outils…
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.
Hah, c’est malin ! Je me sens coupable d’avoir été si critique, maintenant Désolé d’avoir été un peu brut de décoffrage.
Et merci beaucoup pour cette réponse vraiment enrichissante
Du coup : comment peut-on vous aider pour améliorer l’UX de Element ? Vous avez l’air d’être déjà au courant de toutes les reproches qu’on peut lui faire, et j’imagine que si votre équipe de devs est à fond sur ce bug des notifications fantômes depuis 6 mois, ce ne sont pas trois CHATONS de chez nous qui vont pouvoir régler le bug en un après-midi.
Comme on est plusieurs à utiliser Matrix et à se retrouver au camp CHATONS (@GautGaut a suggéré un atelier dédié à Matrix) c’est peut-être l’occasion d’essayer de travailler sur quelque chose qui vous sera utile / qui réponde à vos besoins. Peut-être des tests UX supplémentaires, ou la constitution de demandes de fonctionnalités qui nous seraient utiles dans nos cas d’utilisation ?
J’en profite pour te souhaiter la bienvenue sur le forum @bnjbvr, c’est sympa d’avoir passé le cap de la création de compte pour partager ton point de vue un peu plus de l’intérieur. Même si dans les projets open source on a plus souvent accès à ces infos, il faut pas mal farfouiller et c’est chouette d’avoir une telle synthèse !
Merci pour ses messages très intéressant autour de Matrix !
Chez RésiLien ainsi que pour le projet P4Pillon, nous testons depuis peu de temps Conduit pour l’instant nous pourrons pas faire de retour précis de ce qui se passe bien ou non. Mais en tout cas, je les trouves très ouvert et organisé la page des issues permet de suivre les bugs et de pouvoir contribuer si besoin @neil
Salut ! Réponse très rapide. Aucun problème pour être critique, je suis moi-même bien conscient des problèmes, à titre personnel du moins ; et travailler dessus, ce que je vois c’est que ça prend du temps (notamment pour bien refaire les choses une fois que l’on a mieux identifié les contraintes, les besoins et les attentes).
Du coup : comment peut-on vous aider pour améliorer l’UX de Element ?
C’est gentil de proposer, là j’atteins un peu mes limites (encore une fois, ce n’est pas mon rôle chez Element). À mon sens, je pense que le plus utile à l’heure actuelle serait de tester et faire des retours sur les nouvelles solutions : ElementX iOS qui est déjà sorti ; la prochaine version d’Element Web qui d’après le ticket mentionné ci-dessus devrait avoir une bien meilleure gestion des notifications, déjà testable avec une version Nightly d’Element, etc. Je vais tâcher d’aiguiller la demande en interne, pour voir s’il y a des contributions supplémentaires pour lesquelles un peu d’aide serait utile.
J’ai peur que se lancer dans une recherche générale sur l’UX ne fasse que remonter et appuyer des problèmes existants, pour lesquelles l’équipe serait déjà au courant, et que ça ait pour seul effet de jeter un peu d’huile sur le feu. Malgré tout, je pense que ça peut être un bon exercice, si vous vous en sentez l’envie, et que le plus important c’est de vous faire plaisir aussi Quitte à ouvrir des nouveaux tickets, ou aller mettre des +1 dans des tickets existants en précisant la nature des problèmes (et c’est là toute la difficulté du travail d’UX : il s’agit de mettre le doigt sur les problèmes, en se retenant de mettre en avant des solutions, vu que c’est un travail à part entière de définir des bonnes solutions).
Voilà, j’essaie de rediriger la demande rapidement en interne.
Réunions en ligne à venir pour donner suite aux ateliers.
Quelqu’un avait-il pris des notes ? Sur le Paperboard on avait noté pour l’UX :
Clients recommandés
Fluffychat (multi-comptes en beta, champ de recherche de l’instance, plutôt que d’avoir à la taper à la main)
SchildiChat (mode simple style whatsapp/signal qui ne sépare pas les salons individuels et de groupe)
Element (plutôt pour un usage tchat d’équipe)
Syphon
Tensor
Suivre aussi Treebal qui a une UX intéressante mais mono-appareil et non fédéré https://www.treebal.green/
Configurer le Client Web pour recommander nos serveurs (de messagerie et d’identité)
Créer joinmatrix.chatons.org : une liste de serveurs Matrix avec leurs caractéristiques (chiffrement, rétention des données, configuration par défaut).
tu peux supprimer deuxfleurs de la liste, ça évitera aux utilisateurs de se retrouver « devant un mur ».
les inscriptions sur l’instance deuxfleurs ne sont pas fermées mais sur demande car on ne sait pas faire en autonomie ajd.
Gautgaut tu peux enlever Deuxfleurs de cette liste si tu juges que deuxfleurs n’y a pas sa place à cause de sa politique d’inscription. Je ne m’y oppose pas et je comprends ton raisonnement d’un point de vue UX. Quant à l’annuaire, je ne crois pas qu’il y ait une option pour dire que l’inscription ne se fait pas selon le processus traditionnel de l’app.
J’aimerais par contre revenir sur la raison de notre listing sur cette page de wiki, elle n’est pas de notre fait. De mémoire, il y a eu un article dans Usbek et Rica sur Matrix, une des personnes interviewée mentionne CHATONS et le journaliste met un lien vers cette page wiki. Problème, à l’époque elle est adressée uniquement aux sysadmin, pour installer synapse, et non aux usagers usageres pour utiliser une app et trouver un hébergeur.
Une bonne âme (je ne sais plus qui mais merci à elle) s’est empressée d’éditer le wiki pour que les lecteurs lectrices d’Usbek et Rica ne tombent pas sur une page qui leur sera incompréhensible. Cette personne a donc récupéré depuis l’annuaire les différents CHATONS ayant publié un service Matrix et les a reporté sur le wiki, sans mention du processus d’inscription (sur demande ou en autonomie), tout comme c’est le cas aujourd’hui.
Matrix étant sujet au spam et relativement consommateur en ressources, on ne peut pas sereinement laisser les inscriptions en accès libre. De sorte que, les inscriptions sont bien ouvertes sur notre instance, mais sur demande, et pas via le formulaire d’inscription de Matrix. Idéalement nous aurions un SSO qui indiquerait à l’utilisateur utilisatrice la marche à suivre pour avoir un compte, la démarche à suivre, mais nous n’avons rien de tel pour le moment.
Tu peux retrouver un historique sur cette histoire d’article en cherchant « matrix usbek Rica » dans le moteur de recherche du forum.
Bonjour @GautGaut,
Je viens de vérifier. L’instance Matrix d’Hadoly est bien indiquée en inscription obligatoire sur la fiche Chatons. Y a-t-il un autre endroit où ce service pourrait être déclaré en inscription libre ?
J’ajoute que j’ai à titre personnel une instance Matrix sur https://zinz.dev . Vous verrez que je la présente comme une instance ouverte sur la page d’accueil, or ça fait plus d’un an que j’ai fermé à clé. Une vague d’alt-right spammant et remplissant mes disques de pédopornographie a suffi à me dégoûter – très efficaces ces cons ! Faut lister tous les usager⋅es par nombre de média décroissant avec l’API brute de Synapse, et afficher toutes ces p*tains d’images, pour supprimer à la main chaque spammeur (ici pas besoin d’écriture inclusive). Sinon bah t’es méga-hors-la-loi hein, ils sont en accès libre avec le bon lien HTTP les médias !
On est en plein dans le calvaire de la modération. Plus le service donne de moyens d’expression, plus c’est la guerre. Visio-conférence : risque minimal. Micro-blogage et discussion instantanée : risque maximal. Donc adieu web ouvert, je t’aime, mais je n’ai pas le temps de te modérer…
Côté CLUB1 on est bien sur une instance à inscriptions ouvertes. Mais… justement, en se moment on a de multiples bugs avec Synapse et notre base de donnée est en surpoids ! Peut-être que c’est aussi dû à des usages malveillants, on n’est pas sûr.
D’ailleurs, j’en profite pour faire un petit appel à l’aide, si jamais d’autres CHATONS ont de l’expérience sur ce sujet, vous pouvez passer sur notre room : #technique:club1.fr (Une opération de maintenance est prévue ce WE du 26-27 Août)
Découverte des serveurs ouverts depuis le site de la fondation Matrix
Autre petit point intéressant remarqué par @n-peugnet :
C’est une décision intéressante qui va dans le sens de la décentralisation mais donne aussi plus de responsabilités aux serveurs ouverts listés.
Avenir côté CLUB1
De notre côté on est partagés : Ça fait plaisir d’accueillir et de faire découvrir Matrix ainsi que notre serveur par cette porte d’entrée. Mais d’un autre côté, c’est le service qui nous apporte le plus de bugs et d’utilisation CPU (Matrix est notre seul service ouvert).
Peut être que l’on va plus tard s’approcher du fonctionnement de DeuxFleurs, en se basant sur un échange par email au préalable. Nous réfléchissions aussi à un mode « sur invitation » comme le fait Riseup.
Concernant Domaine Public, ça semble correct ! Notre instance est pour l’instant ouverte à tous·tes (on se pose parfois la question de restreindre les accès à cause des énormes ressources demandées par Matrix, mais pour l’instant c’est bien ouvert).
Pour celleux qui ont des problèmes avec leur serveur synapse je vous invite à rejoindre ce salon pour qu’on puisse s’entraider
C’était @ljf . Quelqu’un arriverait à modifier l’URL pour séparer les serveurs à inscription libre, gratuite sur demande ou payante ?
Sinon alternative plus simple c’est peut-être qu’on se maintienne à jour sur https://joinmatrix.org/servers/
Si personne ne s’y oppose, je ferai une PR sur leur github avec les réponses que j’aurai obtenues ici.
On pourrait ensuite intégrer dans le wiki des chatons leur tableau traduit en français.
!
).
)
appelé 
), 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).
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.)
J’espère que ça répond à certaines interrogations et que ça sera utile pour agrémenter votre réflexion.
, c’est sympa d’avoir passé le cap de la création de compte pour partager ton point de vue un peu plus de l’intérieur. Même si dans les projets open source on a plus souvent accès à ces infos, il faut pas mal farfouiller et c’est chouette d’avoir une telle synthèse !
, je suis fan 
.
Quitte à ouvrir des nouveaux tickets, ou aller mettre des +1 dans des tickets existants en précisant la nature des problèmes (et c’est là toute la difficulté du travail d’UX : il s’agit de mettre le doigt sur les problèmes, en se retenant de mettre en avant des solutions, vu que c’est un travail à part entière de définir des bonnes solutions).
D’ailleurs, j’en profite pour faire un petit appel à l’aide, si jamais d’autres CHATONS ont de l’expérience sur ce sujet, vous pouvez passer sur notre room :