Matrix on Nicolas Guilloux

Le Bridge Signal pour Matrix

Thu, 08 Apr 2021 00:00:00 +0000

Matrix est un protocole de messagerie instantanée. La suite de ce ticket considère que vous connaissez les bases et notamment le glossaire. Je vous conseille fortement d’aller lire le tutoriel précédent : Matrix sur NixOS

Signal Messenger

Le bridge Signal supporte les conversations de groupe et les messages directs. Toutefois, toute conversation chiffrée ne sera pas supportée.
La petite particularité sur ce bridge est que Signal ne dispose pas d’une API. Ainsi, il va falloir utiliser une image Docker qui va simuler un accès Web à Signal.

Voici la configuration que je préconise :

{ config, lib, ... }:

let
 bridgeFolder = "/var/lib/mautrix-signal";

 toListIfExists = path:
 if (lib.pathExists path) then
 [ path ]
 else
 [];
in {
 # Signal daemon
 virtualisation.oci-containers.containers.signald = {
 image = "docker.io/finn/signald";
 volumes = [ "${bridgeFolder}/signald:/signald" ];
 extraOptions = [ "--network=host" ];
 };

 # Signal bridge
 virtualisation.oci-containers.containers.mautrix-signal = {
 image = "dock.mau.dev/tulir/mautrix-signal";
 extraOptions = [ "--network=host" ];
 dependsOn = [ "signald" ];
 volumes = [
 "${bridgeFolder}/data:/data"
 "${bridgeFolder}/signald:/signald"
 ];
 };

 # Add configuration to Matrix server
 services.matrix-synapse.app_service_config_files = toListIfExists "${bridgeFolder}/data/registration.yaml";
}

Si on résume, toutes les données sont stockées dans /var/lib/mautrix-signal. On ajoute les images Docker qui permettent de lancer le bridge.

L’image signald est le daemon pour pouvoir simuler une interface Web auprès de notre application Signal. C’est nécessaire pour pouvoir récupérer les messages en toute sécurité vu que Signal ne dispose pas d’API.
C’est aussi pour cela qu’on doit partager le volume où sont stockées toutes les informations (comme les avatars) entre le daemon et le bridge.

On va dès maintenant configurer ce dernier en éditant en tant que root le fichier /var/lib/mautrix-signal/data/config.yaml… Enfin faite votre nixos-rebuild switch pour lancer le bridge.

On va changer différentes clés dans le fichier, je vais lister ce les clés qui ont changé :

homeserver:
 address: http://localhost:8008
 domain: server_name
 verify_ssl: false

signal:
 socket_path: /signald/signald.sock
 outgoing_attachment_dir: /signald/attachments
 avatar_dir: /signald/avatars
 data_dir: /signald/data

bridge:
 permissions:
 "*": user
 "@pseudo:server_name": admin

homeserver.address : Votre serveur Matrix, pas besoin de passer par internet, il est disponible en local
homeserver.domain : C’est le server_name, vous devriez maintenant savoir ce que c’est :)
homeserver.verify_ssl : Comme on est dans une boucle locale, pas besoin de vérifier le SSL
signal.socket-path : Socket pour dialoguer avec le daemon
signal.outgoing_attachment_dir : Répertoire du daemon où sont mis les pièces jointes
signal.avatar_dir : Répertoire du daemon où sont mis les avatars
signal.data_dir : Répertoire du daemon où sont mis les autres données utiles aux bridges
bridge.permissions : Ce sont les permissions. Pour ma part, j’ai mis "*": user pour que tous les utilisateurs puissent utiliser le bridge, et enfin "@pseudo:server_name": admin pour que votre utilisateur puisse l’administrer

Une fois ça fait, pensez à redémarrer votre image docker docker restart mautrix-signal et faites ensuite un petit nixos-rebuild switch. Normalement, matrix-synapse se redémarrera car le fichier registration.yaml existera.

Vous pouvez maintenant constater que vous pouvez parler au bot dans votre client Matrix en ouvrant une conversation avec @signalbot:server_name.
Celui-ci devrait accepter votre invitation. Vous pouvez alors lui demander de l’aide comme il le propose.

A partir d’ici vous avez plusieurs choix, car vous pouvez :

Créer un compte de zéro en utilisant la commande register +33xxxxxxxxx. Si vous n’avez pas signal sur votre téléphone, cela permettra de tout recevoir sur Matrix directement.
Lier votre compte déjà existant, relié à votre téléphone, et forward tous les messages à Matrix en tapant link et en scannant le QR Code.

Une fois connecté, attendez un peu et vous allez recevoir plein d’invitations :) Bien joué, tout devrait fonctionner !

Le Bridge Telegram pour Matrix

Mon, 05 Apr 2021 00:00:00 +0000

Telegram Messenger

Le bridge de Telegram supporte quasiment toutes les fonctionnalités. La configuration est quasiment la même que pour Mautrix Facebook hormis un léger changement au niveau de la configuration d’une API.
Je n’ai volontairement pas suivi la configuration proposée par NixOS car je n’ai jamais réussi à la faire fonctionner, et je souhaite avoir une installation cohérente. Comme NixOS ne propose pas de module pour Mautrix Facebook, Mautrix Telegram et Mautrix Signal, je préfère les configurer de la même manière.

Voici la configuration que je préconise :

{ config, lib, ... }:

let
 bridgeFolder = "/var/lib/mautrix-telegram";

 toListIfExists = path:
 if (lib.pathExists path) then
 [ path ]
 else
 [];
in {
 # Telegram bridge
 virtualisation.oci-containers.containers.mautrix-telegram = {
 image = "dock.mau.dev/tulir/mautrix-telegram";
 extraOptions = [ "--network=host" ];
 volumes = [ "${bridgeFolder}/data:/data" ];
 };

 # Add configuration to Matrix server
 services.matrix-synapse.app_service_config_files = toListIfExists "${bridgeFolder}/data/registration.yaml";
}

Si on résume, toutes les données sont stockées dans /var/lib/mautrix-telegram. On ajoute l’image docker qui permet de lancer le bridge.

On va dès maintenant le configurer en éditant en tant que root le fichier /var/lib/mautrix-telegram/data/config.yaml… Enfin faite votre nixos-rebuild switch pour lancer le bridge.

Dans un premier temps, il faut faire une application sur le site de Telegram pour récupérer un ID et un hash qui serviront au bridge pour interagir avec l’API. Pour ce faire, allez sur cette page d’aide de Telegram et suivez les instructions pour récupérer le api_id et le api_hash.

On va changer différentes clés dans le fichier, je vais lister ce les clés qui ont changé :

homeserver:
 address: http://localhost:8008
 domain: server_name
 verify_ssl: false

telegram:
 api_id: #ApiId#
 api_hash: #ApiHash#

bridge:
 permissions:
 "*": user
 "@pseudo:server_name": admin

homeserver.address : Votre serveur Matrix, pas besoin de passer par internet, il est disponible en local
homeserver.domain : C’est le server_name, vous devriez maintenant savoir ce que c’est :)
homeserver.verify_ssl : Comme on est dans une boucle locale, pas besoin de vérifier le SSL
telegram.api_id : ID fourni par Telegram sur le site
telegram.api_hash : Hash fourni par Telegram sur le site
bridge.permissions : Ce sont les permissions. Pour ma part, j’ai mis "*": user pour que tous les utilisateurs puissent utiliser le bridge, et enfin "@pseudo:server_name": admin pour que votre utilisateur puisse l’administrer

Une fois ça fait, pensez à redémarrer votre image docker docker restart mautrix-telegram et faites ensuite un petit nixos-rebuild switch. Normalement, matrix-synapse se redémarrera car le fichier registration.yaml existera.

Vous pouvez maintenant constater que vous pouvez parler au bot dans votre client Matrix en ouvrant une conversation avec @telegrambot:server_name.
Celui-ci devrait accepter votre invitation. Vous pouvez alors lui demander de l’aide comme il le propose. Pour lier votre compte, faites !tg login et suivez les instructions.

Une fois connecté, attendez un peu et vous allez recevoir plein d’invitations :) Bien joué, tout devrait fonctionner !

Le Bridge Facebook pour Matrix

Mon, 29 Mar 2021 00:00:00 +0000

Facebook Messenger

Bon, qu’on se le dise, j’aimerai bien partir de Facebook mais beaucoup de personnes ne veulent pas par simplicité. Même si ça m’embête pour des raisons évidentes, je dois rester dessus car j’ai vraiment des personnes que j’aime beaucoup qui refusent de passer sur d’autres plateformes.
C’est d’ailleurs un intérêt de ce bridge : je vais désinstaller toutes les applications Facebook, ma seule interaction sera via Matrix.

Dans un premier temps, on va préparer notre base de données afin d’y stocker les données utiles au bridge. Pour le moment, celui-ci ne supporte que PostgreSQL. Ca tombe bien, on a déjà une BDD disponible via le serveur Synapse. Aussi, on va pouvoir facilement créer un user et une base.

sudo -u postgres psql
CREATE ROLE "mautrixfacebook" WITH LOGIN PASSWORD 'VotreMotDePasseUnique';
CREATE DATABASE "mautrixfacebook" WITH OWNER "mautrixfacebook" TEMPLATE template0 LC_COLLATE = "C" LC_CTYPE = "C";
\q

Une fois fait, on va pouvoir préparer notre module qui va démarrer l’image docker du bridge. On va aussi câbler ce bridge à notre instance Matrix.

{ config, lib, ... }:

let
 bridgeFolder = "/var/lib/mautrix-facebook";

 toListIfExists = path:
 if (lib.pathExists path) then
 [ path ]
 else
 [];
in {
 # Facebook bridge
 virtualisation.oci-containers.containers.mautrix-facebook = {
 image = "dock.mau.dev/tulir/mautrix-facebook";
 extraOptions = [ "--network=host" ];
 volumes = [ "${bridgeFolder}/data:/data" ];
 };

 # Add configuration to Matrix server
 services.matrix-synapse.app_service_config_files = toListIfExists "${bridgeFolder}/data/registration.yaml";
}

Si on résume, toutes les données sont stockées dans /var/lib/mautrix-facebook. On ajoute l’image docker qui permet de lancer le bridge.
La partie où on relie notre bridge à notre serveur est commentée pour le moment car le fichier en question sera généré par le bridge, et donc n’existe pas avant d’avoir bien parametré le bridge.

On va dès maintenant le configurer en éditant en tant que root le fichier /var/lib/mautrix-facebook/data/config.yaml… Enfin faite votre nixos-rebuild switch pour lancer le bridge.

On va changer différentes clés dans le fichier, je vais lister les clés qui ont changé :

homeserver:
 address: http://localhost:8008
 domain: server_name
 verify_ssl: false

appservice:
 database: postgres://mautrixfacebook:VotreMotDePasseUnique@127.0.0.1/mautrixfacebook

bridge:
 permissions:
 "*": user
 "@pseudo:server_name": admin

homeserver.address : Votre serveur Matrix, pas besoin de passer par internet, il est disponible en local
homeserver.domain : C’est le server_name, vous devriez maintenant savoir ce que c’est :)
homeserver.verify_ssl : Comme on est dans une boucle locale, pas besoin de vérifier le SSL
appservice.database : Lien vers *votre base de données. Pensez à changer le mot de passe pour celui que vous avez utilisé au dessus.
bridge.permissions : Ce sont les permissions. Pour ma part, j’ai mis "*": user pour que tous les utilisateurs puissent utiliser le bridge, et enfin "@pseudo:server_name": admin pour que votre utilisateur puisse l’administrer

Une fois ça fait, pensez à redémarrer votre image docker docker restart mautrix-facebook et faites ensuite un petit nixos-rebuild switch. Normalement, matrix-synapse se redémarrera car le fichier registration.yaml existera.

Vous pouvez maintenant constater que vous pouvez parler au bot dans votre client Matrix en ouvrant une conversation avec @facebookbot:server_name.
Celui-ci devrait accepter votre invitation. Vous pouvez alors lui demander de l’aide comme il le propose. Pour lier votre compte, faites login <email> avec l’email de votre compte Facebook bien entendu ! Suivez ce qu’il vous dit, il va vous demander votre mot de passe et potentiellement votre code de double authentification.

Une fois connecté, attendez un peu et vous allez recevoir plein d’invitations :) Bien joué, tout devrait fonctionner !

Matrix sur NixOS

Fri, 26 Mar 2021 00:00:00 +0000

Comme beaucoup de personnes, j’ai beaucoup de messageries qui ont su évoluer (ou pas) dans le temps. Et chacune de ces messageries apporte ses avantages et ses inconvénients, et la plupart des gens ne veulent pas toutes les avoir. Et j’en fais partie !

Aussi, j’ai toujours reluqué Matrix de loin. Les seules fois où j’avais abordé ce standard, j’ai été très déçu à cause de la lenteur de celui-ci et aussi le fait que ce soit extrêmement intimidant au niveau sécurité.

Finalement, j’ai décidé de me lancer en entendant parler de Beeper qui permettait de centraliser plein de protocoles au même endroit. J’ai été déçu de voir que c’était très payant pour une utilisation domestique. Et j’ai remarqué par mon don incroyable de lecture de la seule et unique page disponible que Beeper était une application basée sur Matrix et la notion de bridges. Donc, en théorie, on peut faire la même chose sans payer.

Qu’est-ce que Matrix

Matrix est un standard OpenSource pour construire une messagerie sécurisée en temps réel et décentralisée. Beaucoup de buzz words, on va expliquer tout ça.

C’est un standard, ce qui veut dire que Matrix n’est pas un logiciel mais simplement une liste de fonctionnalités à implémenter afin de supporter le protocole. C’est un peu comme si on parlait d’un mixeur, qui est la fonctionnalité, ce qui ne l’empêche pas d’avoir un nom donné par la marque ou par les utilisateurs. Le mixeur de mes parents s’appelle Bob.
Une messagerie sécurisée en temps réel, c’est assez simple à comprendre.
Pour le côté décentralisé, ça veut dire que un seul et unique serveur n’est pas souverain du réseau. Ainsi, installer un serveur chez vous permettra d’avoir accès au service sur votre réseau. Matrix implémente aussi un système pour faire dialoguer les serveurs entre eux, comme ça votre serveur ne reste pas dans son coin et pourra dialoguer avec le monde extérieur.

On a parlé plus haut des bridges, et ça c’est une des fonctionnalités de Matrix. Le principe est qu’on peut ajouter un genre de plugin qui joue le rôle d’interface avec quelque chose d’autre. Ouais c’est un peu abstrait, mais concrètement un bridge peut se charger en temps réel de relayer les messages d’une autre messagerie par exemple.

Installation du serveur

J’ai rassemblé tous mes efforts pour que tout fonctionne dans un dossier de mon installation NixOS. Il peut varier dans le temps, j’actualiserais le tutoriel et les liens vers ma configuration en fonction des updates.

Le serveur Synapse

Tout commence d’abord par installer Synapse qui est un serveur Matrix. Matrix étant un standard, Synapse est une implémentation de celui-ci. Si vous êtes déjà perdu, relisez le point précédent ;)

Ici, NixOS nous a bien facilité la tâche vu qu’une configuration est disponible, donc on peut aller très vite.

services.matrix-synapse = {
 enable = true;
 server_name = "matrix.nicolasguilloux.eu";
 registration_shared_secret = "UnSecretTemporaire";
 # enable_registration = true;

 listeners = [
 {
 port = 8008;
 bind_address = "::1";
 type = "http";
 tls = false;
 x_forwarded = true;
 resources = [
 {
 names = [ "client" "federation" ];
 compress = false;
 }
 ];
 }
 ];
};

# For the registration of a user
services.matrix-synapse.registration_shared_secret = "UnSecretTemporaire";
environment.systemPackages = [ pkgs.matrix-synapse ];

Il faut s’assurer que l’option server_name correspond bien à l’adresse finale du serveur. C’est important pour faire dialoguer le monde extérieur avec notre instance. Si jamais vous vous lancez dans l’installation et que cette adresse est fausse, il faudra tout recommencer.

Ici, on n’utilise qu’un seul port : le 8008. C’est celui conseillé dans la documentation. Vous remarquerez qu’il n’y a pas de SSL, c’est parce que mon serveur sera exposé à travers un Reverse Proxy géré par Nginx. On va voir ça après.

L’option registration_shared_secret est là uniquement pour enregistrer votre utilisateur administrateur. Il faudra bien penser à l’enlever, car elle permet de créer des utilisateurs un peu comme on veut en utilisant le dit mot de passe.

Et enfin, pas besoin d’importer le paquet de Synapse dans ceux de système hormis pour l’inscription d’un nouvel utilisateur via un terminal.

La base de données

Il faudra aussi configurer une base de données PostgreSQL pour le serveur.

# Manually configure PostgreSQL
# ref: https://www.foxypossibilities.com/2018/02/04/running-matrix-synapse-on-nixos/
services.postgresql.enable = true;
services.postgresql.initialScript = pkgs.writeText "synapse-init.sql" ''
 CREATE ROLE "matrix-synapse" WITH LOGIN PASSWORD '${config.secrets.matrix.database}';
 CREATE DATABASE "matrix-synapse" WITH OWNER "matrix-synapse"
 TEMPLATE template0
 LC_COLLATE = "C"
 LC_CTYPE = "C";
'';

Ici, mon mot de passe est défini bien au chaud dans la config. Pensez à mettre votre mot de passe. Vous pouvez aussi faire cette étape à la mano en allant tater sudo -u postgres psql.

Création de notre admin

Avant d’exposer sur Internet, on va déjà créer notre utilisateur admin puis désactiver la possibilité de s’enregistrer en utilisant les lignes de commandes. Comme ça, on ferme une porte !

Ici, rappelez vous la registration_shared_secret mis plus haut et simplement tapez la commande suivante

register_new_matrix_user --shared-secret "UnSecretTemporaire" http://localhost:8008

On suit donc tout ce qu’il nous dit comme il faut en prenant soin de mettre votre utilisateur Admin.

Le Reverse Proxy

On va maintenant configurer notre Reverse Proxy pour qu’il puisse être accessible du monde extérieur. C’est important aussi pour pouvoir dialoguer avec les autres serveurs.

let
 listenPort = port: ssl: {
 addr = "0.0.0.0";
 port = port;
 ssl = ssl;
 };
in
{
 # Open port
 networking.firewall.allowedTCPPorts = [ 8448 ];

 # Reverse proxy
 services.nginx.virtualHosts."matrix.nicolasguilloux.eu" = {
 enableACME = true;
 forceSSL = true;

 listen = [
 (listenPort 80 false)
 (listenPort 443 true)
 (listenPort 8448 true)
 ];

 locations."/_matrix" = {
 proxyPass = "http://[::1]:8008";
 };
 };
}

Ici, on voit que nous redirigeons tout vers notre serveur Synapse. On peut aussi voir qu’on utilise le port 8448. Il est important car c’est ce port qui est utilisé par la fédération des serveurs Matrix. Ainsi, un serveur lambda ira questionner notre serveur via ce port uniquement.

Une fois tout installé, vous pouvez d’ailleurs tester votre serveur pour voir s’il est bien accessible par la fédération.

Si vous avez tout bien fait, normalement vous devez pouvoir vous connecter sur Element.io, modifier le serveur d’accueil (le fameux server_name) et vous connecter.
Vous remarquerez alors que votre pseudo est pseudo:server_name. Par exemple, pour ma part, c’est nover:matrix.nicolasguilloux.eu.

Les Bridges

Une fois votre serveur fonctionnel, vous pouvez jouir de toutes les fonctionnalités de Matrix de base. Vous pouvez donc rejoindre des salons et discuter avec des personnes mêmes si elles ne sont pas sur votre serveur grâce à la magie de la fédération.

On va maintenant pouvoir ajouter des bridges qui vont être les interfaces entre un autre protocole et celui de Matrix. En plus simple : ça va permettre d’envoyer des messages en utilisant Matrix vers des destinataires comme Signal ou encore Messenger.

Ici, je ne vais passer en revue que les bridges que j’ai implémenté sur mon serveur. On notera que la plupart ont été conçu par la même personne et donc ont le préfix mautrix. On peut donc constater qu’ils se configurent quasiment de la même manière.
Je vais aussi essayer de trier l’ordre des bridges ci-dessous en fonction de leur difficulté à installer. Ça permettra de monter progressivement en difficulté.