Bonjour arn,
Je suis Guillaume et je fais partie de MedicationTime, une association corrézienne dont l’objet est, en partie et pour faire court, l’autonomisation individuelle et collective. Nous sommes proche de Ilico, un FAI associatif.
Sur le plan de l’autonomie numérique nous essayons d’utiliser des services basés sur des logiciels libres et surtout auto-hébergeables. Yunohost nous a permis depuis 4 ans d’auto-héberger notre nuage, nos sites web et nos mails. Nous avons également pu permettre à des assos de relocaliser leurs nuages ou leur hébergement web.
Nous nous attaquons actuellement à l’auto-hébergement de notre messagerie instantannée via matrix. Notre idée est de, au delà de notre usage interne, permettre aux membres des assos locales de connaître l’existence d’une alternative à whatsapp et à signal, entre autres et de pouvoir la tester.
Nous avons installé synapse via yunohost depuis quelques semaines et avons commencé à l’utiliser en interne via element (surtout via l’app Android, mais nous avons aussi installé l’interface web) pour « voir à quoi ça ressemble » et éprouver l’utilisation et les fonctionnalités.
Les ponts qui permettent de consulter les messages d’autres messageries sur element nous semblent être une fonctionnalité intéressantes pour permettre une transition dans le cadre associatif.
Mais après avoir installé l’app yunohost mautrix_signal, je suis un peu perdu dans la configuration et les différents modes de fonctionnement de ce pont…
J’étais partie sur l’idée que le pont permette à chaque user matrix de recevoir les messages de son signal sur element.
Mais il me semble comprendre que de votre côté, vous avez dédié un compte signal qui fait l’interface ?..
Seriez-vous d’accord pour que je vous pose quelques questions pour configurer ce pont et comprendre le fonctionnement du signalbot ?
individuellement : chaque personne peut bridger son propre compte signal en y connectant le bridge. Chacun de ses groupes signal est bridgé et son compte Matrix ajouté au salon-portail Matrix.
collectivement : une personne ou une association connecte son numéro de téléphone au bridge. Ce compte est ajouté à n’importe quel groupe devant être bridgé. Le groupe signal est bridgé et le compte Matrix qui a fait la demande est ajouté au salon-portail Matrix.
Techniquement :
Chaque personne invite le robot signal @signalbot:domain.tld et lance la commande !sg login
Chez ARN on ne veut pas que nos adhérents créent des comptes individuels chez whatsapp ou signal, donc on a choisi l’option 2. qui correspond à l’activation du mode relaybot : true
Quelques elements sur comment on a mis ça en place : https://wiki.arn-fai.net/documentation:sans-nuage.fr#passerelle_whatsapp
En prenant la manière 1, j’ai réussi à relier mon compte matrix à mon compte signal.
On va tester ça en interne pour éprouver un peu l’usage et cerner les blocages.
Je suis passé par notre interface web de Element pour pouvoir scanner le qrcode proposé pour relier les appareils. Éventuellement pour celles et ceux qui seraient en mode smartphone only, y a t’il une technique pour scanner un qrcode depuis un même appareil ?
J’ai une question technique sur la configuration de la passerelle :
pour l’instant dans l’idée de resteindre l’utilisation du pont aux comptes de notre serveur matrix, j’ai modifié les permissions dans le fichier config.yaml comme ceci :
permissions:
[NOTRE_DOMAIN_MATRIX]: user
'@[MON_USER]: [NOTRE_DOMAIN_MATRIX]': admin
est-ce que cette config est valide ?
Et une question plus côté ressources matérielles : j’ai vu à plusieurs endroits que le protocole matrix était un gros consommateur de RAM. La machine sur lequel tourne le notre n’en a pour l’instant que 10G (mais on peut l’étendre jusqu’a 32G d’après les specs).
Savez-vous à partir d’environ quel volume de comptes on risque d’atteindre des limites matérielles ?
Enfin sur le mode 2 via arn-messager, en regardant très vite, il me semble comprendre que vous avez déployé une machine virtuelle avec un android (et l’appli whatsapp) dedans.
Les briques arn-messager et machine virtuelle android peuvent elles devenir des apps yunohost ?
(désolé je pars dans tous les sens !)
Merci à vous
On a laissé tombé la VM android whatsapp. On fait tourner ca sur un vieux telephone qui doit etre allumé tous les 14 jours.
arnmessager peut et va devenir une app yunohost car on a eu une autre demande déjà.
Ah bin on a un smatphone dédié à l’asso (pour une satanée appli bancaire) donc si arn-messager devient une app yunohost je suis chaud pour tester ça !
Les 2 modes de connexion à signal peuvent co-habiter sur un même pont mautrix_signal ?
Et un collègue me demande si le chiffrement de bout en bout est tjs assuré quand il passe par le pont mautrix_signal? Après avoir lu vos articles il me semble que ce n’est pas le cas, je me plante ou pas ?
Le chiffrement de bout-en-bout est levé au niveau du bridge sur notre serveur et sur l’appli whatsapp. Il reste actif entre serveur et client via le chiffrement ssl. Mais ce n’est pas nécessairement un gros problème si vous faites confiance aux administrateur.ices de votre serveur. On peut distinguer deux cas :
tchat privé : un salon bridgé (whatsapp ou signal) où vous êtes seul côté matrix. Attention si vous invitez un compte d’un autre serveur matrix, il faut que vous ayez confiance en les administrateur.ices de cet autre serveur.
tchat public : un salon bridgé où n’importe qui peut entrer. Il faudrait que les gens utilisent un pseudonyme, et éviter qu’un compte d’un autre serveur matrix ne rentre. Dans tous les cas les numéros de téléphone de tous les comptes whatsapp peuvent être vus pas tout.es.
Le chiffrement end-to-bridge (du client au bridge) s’il est activé, permet d’éviter que les messages des groupes bridgés atterrissent en clair sur d’autres serveurs. Mais les métadonnées, incluant le numéro de téléphone des comptes whatsapp seront dans tous les cas copiés sur d’autres serveurs. Donc il vaut mieux ne pas inviter de comptes d’autres serveurs dans des salons bridgés. En d’autres termes, désactiver la fédération des salons bridgés.
