matrix-org/synapseSynapse : homeserver Matrix écrit en Python/Twisted.
element-hq/synapse <https://github.com/element-hq/synapse>_Synapse est un serveur domestique (homeserver) open-source Matrix <https://matrix.org/>_ développé de 2019 à 2023 dans le cadre de la Matrix.org Foundation. La Matrix.org Foundation n'est pas en mesure d'assurer la maintenance de Synapse et il continue d'être développé par Element <https://github.com/element-hq/synapse>_ ; vous avez également le choix parmi d'autres serveurs domestiques Matrix <https://matrix.org/ecosystem/servers/>_.
Consultez le billet de blog The future of Synapse and Dendrite <https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite/>_ pour plus d'informations.
=========================================================================
En bref, Matrix est un standard ouvert pour les communications sur internet, supportant la fédération, le chiffrement et la VoIP. Matrix.org en dit plus sur les objectifs du projet Matrix <https://matrix.org/docs/guides/introduction>, et la spécification formelle <https://spec.matrix.org/> décrit les détails techniques.
.. contents::
La documentation de Synapse décrit comment installer Synapse <https://matrix-org.github.io/synapse/latest/setup/installation.html>. Nous recommandons d'utiliser les images Docker <https://matrix-org.github.io/synapse/latest/setup/installation.html#docker-images-and-ansible-playbooks> ou les paquets Debian de Matrix.org <https://matrix-org.github.io/synapse/latest/setup/installation.html#matrixorg-packages>_.
.. _federation:
Synapse dispose d'une variété d'options de configuration <https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html>_ qui peuvent être utilisées pour personnaliser son comportement après l'installation. Il y a des détails supplémentaires sur la façon de configurer Synapse pour la fédération ici <https://matrix-org.github.io/synapse/latest/federate.html>_.
.. _reverse-proxy:
Il est recommandé de placer un proxy inverse tel que nginx <https://nginx.org/en/docs/http/ngx_http_proxy_module.html>, Apache <https://httpd.apache.org/docs/current/mod/mod_proxy_http.html>, Caddy <https://caddyserver.com/docs/quick-starts/reverse-proxy>, HAProxy <https://www.haproxy.org/> ou relayd <https://man.openbsd.org/relayd.8>_ devant Synapse. Un avantage de faire cela est que vous pouvez exposer le port https par défaut (443) aux clients Matrix sans avoir à exécuter Synapse avec les privilèges root. Pour des informations sur la configuration d'un proxy inverse, consultez la documentation sur le proxy inverse <https://matrix-org.github.io/synapse/latest/reverse_proxy.html>_.
Les instructions pour mettre à jour Synapse se trouvent dans les notes de mise à jour_. Veuillez vérifier ces instructions car la mise à jour peut nécessiter des étapes supplémentaires pour certaines versions de Synapse.
.. _the upgrade notes: https://matrix-org.github.io/synapse/develop/upgrade.html
Synapse utilise un certain nombre de dépendances de plateforme telles que Python et PostgreSQL, et vise à suivre les versions amont supportées. Consultez la politique de dépréciation <https://matrix-org.github.io/synapse/latest/deprecation_policy.html>_ pour plus de détails.
Matrix sert des données brutes fournies par l'utilisateur dans certaines API -- en particulier les points de terminaison du dépôt de contenu_.
.. _content repository endpoints: https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid
Bien que nous fassions des efforts raisonnables pour atténuer les attaques XSS (par exemple, en utilisant CSP_), un serveur domestique Matrix ne devrait pas être hébergé sur un domaine hébergeant d'autres applications web. Cela s'applique particulièrement au partage du domaine avec des clients web Matrix et d'autres applications sensibles comme le webmail. Voir https://developer.github.com/changes/2014-04-25-user-content-security pour plus d'informations.
.. _CSP: https://github.com/matrix-org/synapse/pull/1021
Idéalement, le serveur domestique ne devrait pas simplement se trouver sur un sous-domaine différent, mais sur un domaine enregistré_ complètement différent (également appelé site de premier niveau ou eTLD+1). En effet, certaines attaques_ sont encore possibles tant que les deux applications partagent le même domaine enregistré.
.. _registered domain: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-2.3
.. _some attacks: https://en.wikipedia.org/wiki/Session_fixation#Attacks_using_cross-subdomain_cookie
Pour illustrer cela avec un exemple, si votre Element Web ou autre application web sensible est hébergé sur A.example1.com, vous devriez idéalement héberger Synapse sur example2.com. Un certain niveau de protection est offert en hébergeant sur B.example1.com à la place, ce qui est donc également acceptable dans certains scénarios. Cependant, vous ne devriez pas héberger votre Synapse sur A.example1.com.
Notez que tout ce qui précède se réfère exclusivement au domaine utilisé dans le paramètre public_baseurl de Synapse. En particulier, cela n'a aucun impact sur le domaine mentionné dans les MXID hébergés sur ce serveur.
Suivre ces conseils garantit que même si une faille XSS est découverte dans Synapse, l'impact sur les autres applications sera minimal.
La façon la plus simple d'essayer votre nouvelle installation Synapse est de s'y connecter depuis un client web.
Sauf si vous exécutez une instance de test de Synapse sur votre machine locale, en général, vous devrez activer le support TLS avant de pouvoir vous connecter avec succès depuis un client : voir les certificats TLS <https://matrix-org.github.io/synapse/latest/setup/installation.html#tls-certificates>_.
Un moyen simple de commencer est de se connecter ou de s'inscrire via Element sur https://app.element.io/#/login ou https://app.element.io/#/register respectivement. Vous devrez changer le serveur sur lequel vous vous connectez de matrix.org et spécifier à la place une URL de serveur domestique (Homeserver) de https://<server_name>:8448 (ou simplement https://<server_name> si vous utilisez un proxy inverse). Si vous préférez utiliser un autre client, référez-vous à notre liste des clients <https://matrix.org/ecosystem/clients/>_.
Si tout se passe bien, vous devriez au moins pouvoir vous connecter, créer une salle et commencer à envoyer des messages.
.. _client-user-reg:
Par défaut, l'enregistrement de nouveaux utilisateurs via les clients Matrix est désactivé. Pour l'activer :
Dans la section de configuration de l'enregistrement <https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#registration>_ définissez enable_registration: true dans homeserver.yaml.
Ensuite soit :
a. configurez un CAPTCHA <https://matrix-org.github.io/synapse/latest/CAPTCHA_SETUP.html>_, soit
b. définissez enable_registration_without_verification: true dans homeserver.yaml.
Nous recommandons fortement d'utiliser un CAPTCHA, en particulier si votre serveur domestique est exposé à l'internet public. Sans cela, n'importe qui peut librement enregistrer des comptes sur votre serveur domestique. Cela peut être exploité par des attaquants pour créer des spambots ciblant le reste de la fédération Matrix.
Votre nouveau nom d'utilisateur sera formé en partie à partir du server_name, et en partie à partir d'un localpart que vous spécifiez lors de la création du compte. Votre nom prendra la forme ::
@localpart:my.domain.name
(prononcé "at localpart on my dot domain dot name").
Comme lors de la connexion, vous devrez spécifier un « Custom server ». Spécifiez votre localpart souhaité dans la case « User name ».
La FAQ Admin <https://matrix-org.github.io/synapse/latest/usage/administration/admin_faq.html>_ inclut des conseils pour faire face à certains problèmes courants. Pour plus de détails, consultez la documentation plus large de Synapse <https://matrix-org.github.io/synapse/latest/>_.
Pour un support supplémentaire pour l'installation ou la gestion de Synapse, veuillez demander dans la salle de support communautaire |room|_ (depuis un compte matrix.org si nécessaire). Nous n'utilisons pas les issues GitHub pour les demandes de support, seulement pour les rapports de bugs et les demandes de fonctionnalités.
.. |room| replace:: #synapse:matrix.org
.. _room: https://matrix.to/#/#synapse:matrix.org
.. |docs| replace:: docs
.. _docs: docs
Les serveurs d'identité ont pour tâche de mapper les adresses email et autres identifiants tiers (3PID) aux identifiants Matrix, ainsi que de vérifier la propriété des 3PID avant de créer ce mapping.
Ce n'est pas là que les comptes ou les identifiants sont stockés - ceux-ci résident sur les serveurs domestiques. Les serveurs d'identité sont uniquement destinés à mapper les identifiants tiers aux identifiants Matrix.
Ce processus est très sensible en termes de sécurité, car il y a un risque évident de spam s'il est trop facile de s'inscrire à des comptes Matrix ou de collecter des données 3PID. À plus long terme, nous espérons créer un système décentralisé pour gérer cela (matrix-doc #712 <https://github.com/matrix-org/matrix-doc/issues/712>), mais en attendant, le rôle de gestion de l'identité de confiance dans l'écosystème Matrix est sous-traité à un groupe de partenaires écosystémiques de confiance connus, qui exécutent des « serveurs d'identité Matrix » tels que Sydent <https://github.com/matrix-org/sydent>, dont le rôle est purement d'authentifier et de suivre les connexions 3PID et de publier les clés publiques des utilisateurs finaux.
Vous pouvez héberger votre propre copie de Sydent, mais cela vous empêchera de joindre d'autres utilisateurs de l'écosystème Matrix via leur adresse email, et les empêchera de vous trouver. Nous recommandons donc pour l'instant d'utiliser l'un des serveurs d'identité centralisés sur https://matrix.org ou https://vector.im.
Pour réitérer : le serveur d'identité ne sera utilisé que si vous choisissez d'associer une adresse email à votre compte, ou d'envoyer une invitation à un autre utilisateur via son adresse email.
Nous accueillons les contributions à Synapse de la communauté ! Le meilleur endroit pour commencer est notre guide pour les contributeurs <https://matrix-org.github.io/synapse/latest/development/contributing_guide.html>. Cela fait partie de notre documentation plus large <https://matrix-org.github.io/synapse/latest>, qui inclut des informations pour les développeurs de Synapse ainsi que pour les administrateurs de Synapse. Les développeurs pourraient être particulièrement intéressés par :
le schéma de base de données de Synapse <https://matrix-org.github.io/synapse/latest/development/database_schema.html>_,les notes sur les détails d'implémentation de Synapse <https://matrix-org.github.io/synapse/latest/development/internal_documentation/index.html>_, andcomment nous utilisons git <https://matrix-org.github.io/synapse/latest/development/git.html>_.En plus de tout cela, rejoignez notre communauté de développeurs sur Matrix : #synapse-dev:matrix.org <https://matrix.to/#/#synapse-dev:matrix.org>_, avec de vrais humains !
.. |support| image:: https://img.shields.io/matrix/synapse:matrix.org?label=support&logo=matrix :alt: (get support on #synapse:matrix.org) :target: https://matrix.to/#/#synapse:matrix.org
.. |development| image:: https://img.shields.io/matrix/synapse-dev:matrix.org?label=development&logo=matrix :alt: (discuss development on #synapse-dev:matrix.org) :target: https://matrix.to/#/#synapse-dev:matrix.org
.. |documentation| image:: https://img.shields.io/badge/documentation-%E2%9C%93-success :alt: (Rendered documentation on GitHub Pages) :target: https://matrix-org.github.io/synapse/latest/
.. |license| image:: https://img.shields.io/github/license/matrix-org/synapse :alt: (check license in LICENSE file) :target: LICENSE
.. |pypi| image:: https://img.shields.io/pypi/v/matrix-synapse :alt: (latest version released on PyPi) :target: https://pypi.org/project/matrix-synapse
.. |python| image:: https://img.shields.io/pypi/pyversions/matrix-synapse :alt: (supported python versions) :target: https://pypi.org/project/matrix-synapse