Matrix/Element

Element est une application libre de messagerie instantanée et voix sur basée sur le protocole Matrix.

La messagerie instantanée de confiance de l'Etat français , Tchap, repose sur Matrix/Element.

  • messagerie instantanée entre deux personnes ou pour un groupe
  • possibilité d’échanger photos, vidéos ou n’importe quel type de fichiers dans le fil de conversation
  • chiffrement des communications de bout en bout pour la messagerie via les protocoles OLM et MEGOLM;
  • plusieurs clients peuvent être utilisés simultanément avec la même identité ;
  • en installant son propre homeserver, on peut fonctionner complètement en autonome ou bien en rejoignant la fédération. Serveur et client libre et décentralisé (auto-hébergeable)
  • Multiplateforme ;
  • Connexions possibles avec d'autres messageries instantanées via des passerelles Matrix : envoi de SMS, de courriels, WhatsApp, XMPP,…
  • appels audio‐vidéo entre deux personnes ou bien audio et visio conférences entre plusieurs personnes via le logiciel jitsi;
  • Bonne qualité sonore, sans temps de latence (en fonction de la qualité de la connexion internet) ;
  • Partage d'écran ;

Compliqué du à la fédération :

  • Base d'utilisateur. inscription/sauvegarde/restauration facile.
  • Appels audio/visio pas vraiment expoitable en réseau mobile

Manquantes :

  • Messages audio dans le fil de conversation

Traduction de https://matrix.org/docs/guides/types-of-bridging et adaptation au contexte CHATONS.

Une idée fondamentale qui a motivé le développement de Matrix est la possibilité de communiquer entre différents réseaux de messagerie, libres comme ouverts. L'idée est que deux utilisateur.ice.s de deux réseaux différents discutent dans un salon qui est rendu accessible sur les deux réseaux grace à une passerelle. Plusieurs solutions techniques existent pour implémenter une passerelle entre deux réseaux (en Anglais “bridge”).

Types de salons "rooms"

Migrer des salons entre portail et salon raccord n'est pas pratique. En effet il n'y a pas de possibilité pour les utilisateurs de retirer les portails une fois créés. Le risque est donc de se retrouver avec un mélange d'utilisateurs de portails et raccords dans un salon.

Salons Portails "portal rooms"

La passerelle peut s'identifier elle-même sur le serveur du réseau tiers et contrôle des morceaux du domaine d'adressage des alias/identifiants de salons. Ainsi les utilisateur.ice.s Matrix rejoignent un salon du réseau tiers de manière transparente en rejoignant freenode_#wherever:matrix.org Le salon Matrix résultant est ponté automatiquement au seul salon cible sur le réseau tiers. Le controle d'accès des users Matrix est généralement géré par le réseau tiers. C'est la passerelle la plus puissante, qui permet l'intégration des deux réseaux la plus étroite et transparente. Il est possible pour un user Matrix de rejoindre un salon du réseau tiers, simplement en renseignant l'identifiant, sans manipulation complexe.

Salons Raccords "plumbed rooms"

Un salon Matrix existant peut etre raccordé à un ou plusieurs salons tiers en configurant une passerelle (qui peut etre auto-hébergé). Par exemple, #matrix:matrix.org est raccordé sur #matrix sur Freenode. Le controle d'accès des utilisateurs Matrix est nécessairement géré par le salon du coté Matrix. C'est utile pour relier différents réseaux via Matrix, meme dans le cas de réseaux privateurs pour lesquels le protocole n'est pas libre et/ou il n'y a pas d'accès admin aux serveurs pour mettre en place une passerelle de type portail.

Types de passerelles

Du plus simple au plus avancé

Passerelle reposant sur un robot

La manière la plus simple d'échanger des messages avec un réseau tiers est que la passerelle se connecte au réseau tiers en utilisant un (ou plusieurs) compte fictif appelé robot-passerelle. Par exemple on créé un compte WhatsAppBot ou WhatsAppBot[2] dont la passerelle connaît les identifiants. Ce robot relaie les messages entre les deux réseaux pour le compte des autres utilisateur.ice.s. L'expérience utilisateur est très mauvaise car toutes les méta-données concernant les messages sont perdues, en particulier leur expéditeur. C'est une méthode utilisée pour les réseaux privateurs centralisés des GAFAM tel que Telegram https://github.com/SijmenSchoon/telematrix

Passerelle reposant sur un robot-API pour la création d'utilisateurs virtuels

Certains réseaux tiers supportent l'injection de messages provenant de comptes fictifs / utilisateurs virtuels. Ce peut être utilisé pour représenter les utilisateur.ice.s Matrix avec un compte fictif sur le réseau tiers. Par exemple, Slack permet la création de robots distants sur demande. Ces robots peuvent alors créer des comptes fictifs aux utilisateurs Matrix qui sont alors affichés proprement dans les salons Slack comme des utilisateurs virtuels. Cependant, les comptes fictifs ne sont pas implémentés de la même manière que les comptes réels du réseau tiers, et n'ont pas les mêmes droits/accès aux méta-données et notifications temps-réel du réseau (sémantique). Ainsi, ils n'ont pas de présence, de profil, ne peuvent pas être contactés en message privé (MP), et leur identifiant ne peut pas être auto-complété, par exemple pour être pingé. Ils ne voient pas non plus quand quelqu'un est entrain d'écrire. C'est la méthode utilisée pour la passerelle Slack matrix-appservice-slack https://github.com/matrix-org/matrix-appservice-slack

Passerelle marionnette simple

C'est une passerelle permettant une intégration plus étroite. La passerelle s'identifie sur le réseau tiers comme étant un logiciel client tiers. L'utilisateur Matrix doit donc posséder un compte sur le réseau tiers. La passerelle créé des “marionnettes” Matrix des utilisateurs du réseau tiers. Autrement dit chaque utilisateur du réseau tiers se voit attribuer un compte fictif Matrix avec lequel l'utilisateur Matrix discute. A chaque salon du réseau tiers est associé un salon miroir Matrix. Les utilisateurs côté réseau tiers ont l'impression de discuter avec le compte de l'utilisateur Matrix du réseau tiers et ne peuvent pas savoir que tout est mis en miroir sur Matrix. Toute la sémantique (méta-données et notifications) du réseau tiers est disponible pour la passerelle via le protocole/API du logiciel client et peut donc être mise en miroir sur Matrix. Cependant, la passerelle doit gérer le processus d'authentification du réseau tiers pour que l'utilisateur Matrix se connecte à son compte sur le réseau tiers. C'est la méthode utilisée par les passerelles IRC (si vous la configurez pour se connecter au serveur IRC avec votre compte IRC réel). https://github.com/matrix-org/matrix-appservice-irc , télégram https://github.com/matrix-org/matrix-appservice-tg et git https://github.com/matrix-org/matrix-appservice-gitter

Passerelle marionnette double

Dans le cas d'une marionnette simple, la passerelle “tire les ficelles” sur le réseau tiers pour le compte de l'utilisateur Matrix. Donc ce qui se passe sur Matrix est répercuté sur le réseau tiers. Dans l'idéal on aimerait aussi que ce que l'utilisateur fait sur le réseau tiers avec son compte tiers soit également répercuté sur Matrix. Par exemple si l'utilisateur lit un message depuis l'appli WhatsApp, on aimerait que ce message soit marqué comme lu dans la conversation Matrix miroir. Pour cela, la passerelle doit pouvoir tirer les ficelles de la partie Matrix du miroir. Et donc manipuler le compte Matrix de l'utilisateur en fonction de ce que le compte tiers de l'utilisateur fait. C'est la méthode ultime pour une passerelle personnelle, car toute la sémantique (méta-données et notifications) est précisément mise-en-miroir sur chaque réseau. A l'inverse, dans le cas d'un robot-relai, le compte côté réseau tiers et celui côté Matrix ne représentent pas un et un seul même utilisateur “ne font pas un”. La difficulté côté Matrix est qu'il faut trouver une manière élégante pour que la passerelle se connecte au compte Matrix de l'utilisateur (délégation de jetons d'accès). Les difficultés sont spécifiques aux limitations de chaque réseau tiers. Par exemple, la plupart des réseaux tiers ne permettent pas de représenter un autre utilisateur Matrix que celui fournissant son compte tiers (voir robot-relai hybride). Matrix-puppet-bridge était le premier projet pour de tels passerelles https://github.com/matrix-hacks/matrix-puppet-bridge#examples Les passerelles mautrix sont les plus performantes à ce jour pour les réseaux privateurs des GAFAM tels que Telegram, WhatsApp, Facebook (Messenger). https://docs.mau.fi/bridges/index.html Voir aussi celles de https://github.com/Sorunome/mx-puppet-bridge

Passerelle marionnette à robot-relai hybride

Il s'agit d'une combinaison entre les passerelles marionnette simple et double. Une telle passerelle essaie de permettre à plusieurs utilisateurs Matrix d'être représenté sur le réseau tiers via un seul compte tiers. Elle exploite la méthode de robot-passerelle.

Passerelle serveur-à-serveur

Certains réseaux tiers (IRC,XMPP,SIP,SMTP,NNTP,GnuSociql, etc.), tout comme Matrix, supportent la fédération, libre ou controlée. C'est-à-dire que ces réseaux sont composés de plusieurs sous-réseaux hébergés sur différents serveurs et noms de domaines. Les utilisateurs ayant un compte sur un sous-réseau peuvent communiquer avec les utilisateurs d'un autre sous-réseau à condition que les deux serveurs soient fédérés, c-à-d qu'ils acceptent de communiquer entre eux. La manière la plus élégante de ponter ces réseaux entre eux est que la passerelle se comporte comme un serveur fédéré du réseau tiers. Ainsi tous les utilisateurs et salons de Matrix sont directement accessibles depuis le réseau tiers et vice-versa. Il suffit pour un utilisateur Matrix de préfixer le pseudo d'un utilisateur ou l'identifiant d'un salon tiers par le nom de son serveur pour lancer la conversation. Voir salons-portail.

Passerelle à sens-unique

Des passerelles d'un réseau tiers vers Matrix sont utilisés pour suivre des actualités, comme par exemple https://github.com/turt2live/matrix-appservice-instagram ou github.

Passerelle sidecar

La passerelle est un client tiers pour le réseau tiers. Seul un utilisateur Matrix peut voir les conversations du réseau tiers. Les permissions sont gérées par le réseau tiers, pas par Matrix. Voir bitlbee. https://matrix.org/docs/guides/types-of-bridging/#sidecar-bridge

L'implémentation serveur Matrix synapse propose une API d'administration plutôt complète, accessible aux URL débutant par /_synapse/. Cette API est documentée sur la documentation officielle de synapse. Les requêtes et les réponses sont formattées en JSON pour la plupart et interprétables automatiquement grâce à l'outil jq. Pour employer aisément la commande, nous proposons la fonction bash suivante.

function synadm { curl -X "$1" -H "Content-Type: application/json" -H "Authorization: Bearer $SYNAPSE_TOKEN" "https://$SYNAPSE_HS/_synapse/admin/$2" "${@:3}" }
# Avant usage, exporter les variables suivantes (le token doit être associé à un compte administrateur) :
export SYNAPSE_HS=matrix.monchaton.org
export SYNAPSE_TOKEN=XXX

Il existe des outils d'administration alternatifs tels que synadm en Python, présentant les fonctionnalités de l'API Synapse avec plus d'abstraction encore.

A titre d'exemple, la fonction permet de manipuler les utilisateurs et les salons :

# Afficher les profils dont le nom contient un mot-clé
synadm GET 'v2/users?name=bot' | jq
# Afficher uniquement les mxid (pour export ou traitement automatique)
synadm GET 'v2/users?name=bot' | jq -r '.users[].name'
# Profil basique d'un compte donné
synadm GET v2/users/@user:monchaton.org | jq
# Informations de connexion du compte
synadm GET v1/whois/@user:monchaton.org | jq
# Toutes les IP connues du compte
synadm GET v1/whois/@user:monchaton.org |  jq '.devices[].sessions[].connections | map(.ip) | unique'
# Salons rejoints par le compte
synadm GET v1/users/@user:monchaton.org/joined_rooms | jq
# Réinitialiser un mot de passe
synadm POST v1/reset_password/@user:monchaton.org -d '{"new_password": "<mdp aleatoire>", "logout_devices": true}'
# Désactiver un compte
synadm POST v1/deactivate/@user:monchaton.org -d '{"erase": true}'
# Bloquer un compte silencieusement (shadow ban)
synadm POST v1/users/@user:monchaton.org/shadow_ban

# Lister les salons sur le serveur
synadm GET v1/rooms | jq
# Lister les salons sans limite
synadm GET 'v1/rooms?limit=9999999' | jq
# Informations générales sur un salon
synadm GET 'v1/rooms/!OhSiGLbNAQMVgDlMaF:monchaton.org' | jq
# Lister les membres d'un salon
synadm GET 'v1/rooms/!OhSiGLbNAQMVgDlMaF:monchaton.org/members' | jq
# Supprimer un salon localement (adapter le block et le purge)
synadm DELETE 'v1/rooms/!OhSiGLbNAQMVgDlMaF:monchaton.org' -d '{"block": false, "purge": true}'
# Vider l'historique de messages d'un salon (cache local)
synadm POST v1/purge_history/!OhSiGLbNAQMVgDlMaF:monchaton.org' -d "{\"purge_up_to_ts\":\"$(date -d-30days +%s000)\"}"

Un serveur synapse est gourmand en ressources, principalement en consommation disque et mémoire à travers sa base de données. Nettoyer régulièrement le serveur permet de conserver l'usage mémoire et la taille des tables à un niveau raisonnable (en 2021, un serveur synapse de taille moyenne doit consommer moins de 6Go de RAM et 100Go de disque, beaucoup moins s'il ne fédère pas avec de gros salons). Le guide de Levans est très complet pour le nettoyage d'un serveur Matrix, et quelques extraits adaptés sont proposés à suivre.

Supprimer les salons sans membre local :

# Récupérer tous les salons dans un fichier
synadm GET 'v1/rooms?limit=999999' > rooms.json
# Supprimer les salons vides (attention, l'exécution peut prendre plusieurs jours et consommer du CPU et de la RAM)
jq -r '.rooms | map(select(.joined_local_members == 0)) | .[].room_id' < rooms.json | xargs -ti $SHELL -ic "synadm DELETE 'v1/rooms/{}' -d '{\"purge\": true}'"

Nettoyer l'historique des salons remplis :

# D'abord extraire la liste des salons les plus remplis, à lancer sur le serveur PostgreSQL
> \copy (select room_id, count(*) as cnt from events group by room_id order by cnt desc) to '/tmp/rooms_to_clean' csv;
# Puis purger l'historique du top 10 jusqu'à -1 mois, attention les traitements sont lancés en parallèle
head -n 10 /tmp/rooms_to_clean | cut -d, -f1 | xargs -ti $SHELL -ic 'synadm POST \'v1/purge_history/{}\' -d "{\"purge_up_to_ts\":$(date -d-30days +%s000)}"'

Optimiser la table d'état (nécessite l'installation de synapse-compress-state) :

# D'abord extraire la liste des salons les plus lourds en table d'état, à lancer sur le serveur PostgreSQL
> \copy (select room_id, count(*) AS cnt from state_groups_state group by room_id order by cnt desc) to '/tmp/rooms_to_compress' csv;
# Puis compresser l'historique du top 100 (exporter les variables de connexion au serveur postgres au préalable)
# Cette commande ne modifie pas l'état en base et peut tourner pendant plusieurs jours
head -n 100 /tmp/rooms_to_compress | cut -d, -f1 | xargs -ti synapse-compress-state -p "host=$PGHOST port=5432 user=$PGUSER password=$PGPASSWORD dbname=$PGUSER" -r "{}" -o "{}.sql"
# Finalement exécuter tous les fichiers SQL
ls *.sql | xargs -ti psql -U$PGUSER -p 5432 -h $PGHOST $PGUSER -f '{}'

Si vous souhaitez automatiser les opérations de nettoyage, vous pouvez reprendre / vous inspirer du script proposé ici et l'appelé via une tâche cron de façon quotidienne pendant les heures creuses (en anglais).

Il ne s'agit pas de proposer une liste exhaustive car il est difficile d'avoir connaissance de toutes les instances déployées. Si vous êtes administrateur d'une instance et qu'elle n'est pas encore recensée, n'hésitez pas à l'ajouter. L'usage de cette liste est à la discrétion de toutes les personnes y ayant accès. Nous ne garantissons pas la qualité du service fourni par les liens ci-dessous.

* matrix.org (serveur par défaut hébergé par la fondation New Vector https://vector.im) https://matrix.org/docs/projects/try-matrix-now/

  • services/messagerie_instantanee/matrix.txt
  • Dernière modification: 2021/08/22 22:27
  • de nomagic