Nous en parlions lors du week-end de l’assemblée, Proxmox nous permet de plus facilement créer, sauvegarder et gérer des machines virtuelles.
Avec @GautGaut, nous avons échangé sur le cas de notre instance Matrix qui pose quelques soucis, de stockage, de nettoyage, de sauvegarde et de maintien au sein d’un Yunohost déjà bien occupé.
Nous avons évoqué de tenter la création d’une machine virtuelle Matrix dédiée basée sur le playbook Ansible que j’ai utilisé pour mon utilisation personnelle, nous permettant de facilement ajouter et gérer des bridges, petit à petit.
Pour moi on ne déploiera jamais les bridges insta, messenger et linkedin. Je resterais sur whatsapp, signal et telegram. Eventuellement discord #oneday
La question à régler impérativement avant même de créer une VM de test c’est celle de l’UX et du LDAP. Si on n’est plus sur le serveur sans-nuage (services sur inscriptions) on perd le LDAP principal. @Aleks m’avait dit que le LDAP yunohost était spécifique et qu’on ne pouvait donc pas envisager d’y connecter une autre VM.
Donc ça voudrait dire qu’on ne profiterait plus du SSO pour Element. C’était un avantage pour l’UX. Mais d’un autre côté la plupart des gens utilisent Matrix sur leur smartphone, où le SSO n’est pas utile. Peut-être qu’on pourrait simplement mettre en place une synchronisation de mdp entre le LDAP yunohost et le futur serveur Matrix.
De mon point de vue chacun a besoin de plusieurs comptes Matrix sur un ou plusieurs serveurs pour pouvoir séparer ses usages pro/perso/asso pseudonyme/identité réelle. Par exemple un compte sur un petit serveur avec des bridges whatsapp, signal, telegram pour un usage perso, et un compte sur un gros serveur pour un usage pseudonyme « type discord » sur des gros salons publics.
Je pense que ce projet devrait être discuté dans le groupe de travail Matrix des chatons que j’ai initié. On y avait discuté de mettre en place un gros serveur francophone.
Je nous invite aussi à relire les différents sujets Matrix sur ce forum et celui des chatons.
L’avantage du playbook, c’est de pouvoir ajouter les fonctions une par une.
Je ne suis pas d’accord sur l’usage de multi-comptes, bien que j’en comprenne l’idée. Est-ce que tu connais des personnes qui se déconnectent et reconnectent sur plusieurs comptes et serveurs afin de pouvoir échanger anonymement à différentes échelles ? Dans ce cas, quel intérêt de pouvoir communiquer entre les serveurs matrix ?
Un peu triste d’envisager de quitter l’app yuno… On multiplie les méthodes de déploiement/maintenance, bien que ça montre que le paquet yuno n’est pas au niveau face à cette recette de déploiement (comme pour nextcloud).
@GautGaut J’ai lu sur le chan matrix chatons que tu envisages d’ouvrir plus ou moins l’instance pour en faire une grosse instance… Je suppose que tu hésites.
Si je pense qu’on peut soit en ouvrant le port (déconseillé je pense) soit en montant un tunnel entre les 2 VM. Comme le pointe optogram, le format de la bdd ldap on peut s’y adapter puisque l’app yuno y arrive…
Même si j’en comprends l’intérêt vis à vis de la protection des données. Dans la réalité, je doute que ce sera adopté par le grand public de cette façon Je m’imagine très mal en Café HOP! accompagner une personne qui migre pour qu’elle se créer 2 comptes…
Ce n’est pas qu’une histoire de vie privée, surtout de construction du protocole Matrix qui fait que c’est aberrant en ressources si on ne respecte pas ça. Les serveurs individuels sont assez aberrant dans leur style aussi
J’avoue que depuis que Signal a introduit les pseudos je ne vois plus trop d’intérêt de recommander Matrix pour un usage perso. Sur mon téléphone je pense ne plus installer Element et simplement bridger des groupes que je veux avoir en mobile depuis whatsapp ou matrix. N’installer que Signal me fera économiser de la batterie. Ensuite j’ai mon compte asso/libre auquel je ne me connecte que depuis un Element-desktop. J’envisage encore de faire migrer des proches vers Signal mais plus vers Matrix. Le jour où Signal fera un faux-pas on sera prêt à prendre la relève. Par contre cette approche impliquerait de faire des dons à Signal.
Un peu triste d’envisager de quitter l’app yuno…
Je suis bien le premier attristé
Je pense que les paquets matrix-yunohost sont bien pour un certain usage mais vu l’usage de plus en plus important qu’on en fait ça devient juste. J’ai l’impression que tous les gens qui font du matrix « sérieusement » utilisent ce playbook. En même temps je ne sais pas si j’aurai la foi de me plonger dans ce truc…
Non j’aimerais juste que quelqu’un se dénonce pour le faire. S’il y avait un gros serveur on pourrait revoir le scope du notre. Comme ça nous on pourrait se concentrer sur les bridges et dire que notre instance n’est pas faite pour un usage de découverte de grosses commu et on éviterait ainsi que notre DB explose.
Ben le matrix-docker-ansible-playbook n’est pas compatible avec l’esprit yunohost vu que docker… Du coup je sais pas s’il y a un intérêt à déployer cette nouvelle VM sur yunohost ou sur debian.
J’avoue que tout ça est un peu la conséquence du fait que je me sens seul sur la maintenance de la stack matrix. Alors si @Optogram est prêt à prendre la relève via le playbook je suis preneur. Par contre il faut peser toutes les conséquences en termes de temps de maintenance que ça implique…
Je m’imagine très mal en Café HOP! accompagner une personne qui migre pour qu’elle se créer 2 comptes…
Pour ma part, elles seront en août, mais je serais disponible en pointillé.