Décidons collectivement de la politique de rétention, protection, fédération des données sur chat.sans-nuage.fr . Il y aura d’autres paramètres à optimiser pour améliorer notre maîtrise de la vie privée sur notre serveur Matrix. Cela devrait nous permettre de libérer de la place sur notre serveur, et d’éviter qu’il grossisse trop à l’avenir.
Pour le nettoyage de la DB synapse, il y a de nombreuses sources :
default_policy: → durées de rétention, si la date d’un message dépasse, il sera purgé
min_lifetime: 1d → non utilisé par synapse
max_lifetime: 180d → durée de rétention par défaut, i.e. si la durée n’a pas été définie explicitement dans le salon par l’admin
allowed_lifetime_min: 1d → non utilisé par synapse
allowed_lifetime_max: 1y → durée de rétention maximale autorisée sur le serveur
s (seconds), m (minutes), h (hours), d (days), w (weeks) and y (years))
Ces durées min_lifetime et max_lifetime peuvent donc être écrasée pour un salon donné par son administrateur. Mais si l’administrateur dépasse le maximum serveur, c’est la valeur allowed_lifetime_min qui sera utilisée lors de la purge.
Pour définir une valeur spécifique il faut envoyer un évèvement d’état m.room.retention
qui définisse ‹ max_lifetime ›.
J’ai regardé pour la fédération, si un autre serveur n’a pas activé la purge qui est expérimental, il gardera tout. Et s’il l’active mais en mettant le paramètre de purge à 100 ans par exemple, il gardera tout aussi.
Donc quelqu’un qui serait sur un autre serveur que moi pourrait voir des massages que je ne peux plus voir…
Ça confirme qu’il faut travailler avec une fédération de copains pour garder le contrôle sur les données.
Si on veut libérer de l’espace disque, il faut suivre ça:
the database engine won’t free up the disk space, it will start writing new data into where the purged data was.
If you want to reclaim the freed disk space anyway and return it to the operating system, the server admin needs to run VACUUM FULL; (or VACUUM; for SQLite databases) on Synapse’s database (see the related PostgreSQL documentation).
Il y a une commande pour supprimer un salon portail : !wa delete-portal . Mais elle n’est pas (encore) accessible via ARN-Messager.
Plus largement il faudrait en effet pouvoir supprimer tous les salons qui n’ont plus eu d’activité depuis X temps. Ce qui reviendrait, une fois la purge automatique implémentée, à supprimer tous le salons qui contiennent un nombre de messages <=1.
yo ! du coup pour supprimer un salon :sans-nuage.fr en tant qu’Admin, il y a une commande ?
Et aussi, c’est pas très pratique de ne pas pouvoir réduire le rang d’un autre Admin de salon… en fait là, pour le contexte, on a des camarades d’XR de mon coin qui se sont fait chouré leurs tél et les keuf ont eut accès à la conv sur Signal en fait… donc j’essaye de les encourager à passer à Matrix-Element (et adhérer à ARN aussi ce serait cool ahah)… bref
PS. Si possible j’aimerais d’ailleurs transitionner vers un nouveau compte matrix:sans-nuage.fr pour un truc plus anonyme - si c’est possible d’en créer un, puis je supprime l’actuel… merci !
J’ai oublié de rebondir, mais je serais pour qu’un compte sans-nuage permette d’avoir autant de compte matrix que désiré. Il suffit pour cela qu’on ouvre l’enregistrement aux personnes ayant une adresse mail @sans-nuage.fr Il faudra donc créer un alias mail puis l’utiliser pour créer un nouveau compte.
Et j’ai aussi pour idée d’avoir plusieurs serveurs Matrix pour plusieurs usages.
Plus de détails sur la proposition.
Ce seront donc des comptes hors SSO. La manière la plus propre de gérer serait d’autoriser l’inscription mais de restreindre aux adresses mail @sans-nuage.fr
Comme ça :
on n’a pas à gérer l’inscription et le MDP via synapse-admin
on peut voir à qui appartient le compte via les alias de mail yunohost
ça règle le problème des clients matrix qui gèrent pas le sso. Si quelqu’un veut en utiliser un il se créé un compte matrix supplémentaire hors sso.
J’ai vérifié, on n’est pas obligé d’utiliser un serveur de nom, synapse gère inscriptions mar mail en standalone.
Pour éviter que quelqu’un créé un compte avec un alias @sans-nuage puis change l’adresse mail pour filer le compte matrix à quelqu’un d’autre, on désactive le changement de 3PID.
enable_3pid_changes: false
On permet plusieurs comptes par personne, mais il ne faut pas qu’un utilisateur sans-nuage « offre » un compte Matrix à une autre personne. En effet la personne qui a le compte sans-nuage peut réinitialiser le MDP Matrix via sa boite mail, ce qui pose évidemment un gros problème de respect de la vie privée de l’autre personne à qui on offrirait le compte.
