Développer un bridge entre une MIS et Matrix

Si vous êtes un éditeurs de Messagerie Instantanée de Santé (MIS) et que vous souhaitez la rendre interopérable avec le protocole Matrix, vous devrez développer un pont (bridge) entre votre MIS et Matrix.

Différents types de salons

• Portal rooms / salon de portail
  Les ponts peuvent s'enregistrer comme contrôlant des morceaux d'espace de noms d'alias de salon, permettant aux utilisateurs de Matrix de rejoindre des salons distants de manière transparente : par exemple le pont IRC/Matrix contrôle tous les salons dont le nom commence par #freenode_.....:matrix.org. Par exemple si l'utilisateur saisie :
  /join #freenode_#wherever:matrix.org
  Le salon Matrix ainsi rejoint est généralement automatiquement reliée au salon distant cible : dans cet exemple #wherever sur le réseau IRC freenode.
  Le contrôle d'accès pour les utilisateurs de Matrix est généralement géré par le côté du réseau distant de la salon. C'est ce qu'on appelle un "salon de portail", et est utile pour rejoindre des salons distants sans aucune configuration nécessaire.

• Plumbed rooms
  Alternativement, un salon Matrix existant peut être raccordé à un ou plusieurs salons distants spécifiques en configurant un pont (qui peut être géré par n'importe qui). Par exemple, #matrix:matrix.org est relié à :

  • #matrix sur Freenode (IRC)
  • matrixdotorg/#matrix sur Slack
  • etc.
    Le contrôle d'accès pour les utilisateurs de Matrix est nécessairement géré par le côté Matrix du salon. Ceci est utile pour utiliser Matrix pour relier différentes communautés.

Différents types de bridges

• Bridgebot-based bridges

La façon la plus simple d’échanger des messages avec une MIS est d’avoir la connexion de pont dans le réseau de la MIS en utilisant un ou plusieurs utilisateurs prédéfinis appelés bots de pont (Ex : MatrixBridge). Ces bots relaient le traffic vers Matrix au nom des utilisateurs de la MIS. L'expérience utilisateur n'est pas terrible car toutes les métadonnées sur les messages et les expéditeurs sont perdues.

• Bot-API (aka Virtual user) based bridges

Pour les MIS supportant l'existence d’utilisateurs « faux » ou « virtuels » : ces pseudo-utilisateurs peuvent être utilisés côté MIS pour représenter les utilisateurs Matrix. Cependant, ces utilisateurs virtuels ne sont pas de vrais utilisateurs sur la MIS, donc ils n’ont pas de présence, de profil et ne peuvent pas être contacté par message direct, etc. Ils n’ont également aucun moyen de recevoir des notifications ou d’autres informations plus riches qui peuvent ne pas être disponibles via les API bot.

• Simple puppeted bridge

Le pont se connecte à la MIS comme s’il s’agissait d’un véritable client tiers pour cette MIS. Par conséquent, l’utilisateur Matrix doit déjà avoir un compte valide sur cette MIS. En échange, l’utilisateur Matrix manipule son utilisateur distant, de sorte que les autres utilisateurs de la MIS ne sont même pas conscients qu’ils parlent à un utilisateur via Matrix. La sémantique complète de la MIS est disponible au pont pour l’exposer dans Matrix. Cependant, le pont doit gérer le processus d’authentification pour connecter l’utilisateur au pont distant.

• Double-puppeted bridge

C'est le même principe de "manipulation" de compte que dans le type Simple puppeted bridge, mais la manipulation se fait cette fois-ci dans les 2 sens. C’est le saint-graal des ponts, car le compte Matrix et le compte tiers sont représentés avec exactitude sur leurs réseaux respectifs, avec toutes les métadonnées des utilisateurs intactes. Il peut y avoir cependant certaines limitations, notamment en fonction des capacités de la MIS.

• Hybrid Relaybot Puppet Bridge

Ce type de pont est une combinaison de simple puppeted bridge ou double qui tente de résoudre le problème de la représentation d’autres utilisateurs au moyen de la technique du Bridgebot.