Configuring Synapse

server_name

Этот параметр устанавливает общедоступный домен сервера.

server_name будет отображаться в конце имён пользователей и адресов комнат, созданных на вашем сервере. Например, если server_name был установлен как example.com, имена пользователей на вашем сервере будут иметь формат @user:example.com.

В большинстве случаев следует избегать использования специфических для Matrix поддоменов, таких как matrix.example.com или synapse.example.com, как server_name, по тем же причинам, по которым вы не использовали бы [email protected] в качестве своего адреса электронной почты. Смотрите здесь для информации о том, как разместить Synapse на поддомене, сохраняя при этом чистый server_name.

server_name нельзя будет изменить позже, поэтому важно настроить его правильно перед запуском Synapse. Он должен быть в нижнем регистре и может содержать явно указанный порт.

Для этой опции нет значения по умолчанию.

pid_file

Настройка pid_file в конфигурационном файле Synapse определяет путь к файлу PID (идентификатор процесса). Этот параметр указывает, куда записывать файл, содержащий идентификатор процесса Synapse, когда сервер запускается.

Файл PID (обычно с расширением .pid) содержит числовой идентификатор процесса, который позволяет операционной системе и администратору системы легко управлять и контролировать процесс сервера. Вот для чего предназначена настройка pid_file:

1. Управление процессом: Файл PID является способом идентификации запущенного процесса Synapse. Он содержит числовой идентификатор (PID) этого процесса. Это позволяет операционной системе отслеживать, останавливать и управлять процессом сервера.
2. Остановка сервера: Если необходимо остановить сервер Synapse (например, для обновления конфигурации или перезапуска), вы можете использовать файл PID для отправки команды операционной системе на завершение процесса сервера. Например, команда kill -TERM $(cat /путь/к/pid-файлу.pid) может быть использована для остановки сервера с помощью файла PID.
3. Мониторинг и журналирование: Файл PID также может использоваться мониторинговыми и журнальными системами для отслеживания активности сервера и обнаружения проблем.
4. Проверка статуса: Файл PID может использоваться скриптами и инструментами для проверки статуса сервера Synapse, чтобы убедиться, что он работает корректно.

public_baseurl

public_baseurl — это настройка в конфигурационном файле Synapse, которая определяет общедоступный базовый URL-адрес, который клиенты используют для доступа к вашему серверу Homeserver (без учета _matrix/...). Этот URL-адрес представляет собой адрес, который пользователь может ввести в поле «Пользовательский URL Homeserver» (или подобное) в своем клиенте Matrix. Этот параметр играет важную роль в настройке доступа клиентов к вашему серверу.

Вот некоторые важные аспекты настройки public_baseurl:

1. Общедоступный URL: Этот URL-адрес используется для доступа клиентами к вашему серверу Matrix. Он должен быть доступным из Интернета и позволять клиентам установить соединение с вашим сервером.
2. Reverse Proxy (обратный прокси): Если вы используете Synapse с обратным прокси (например, Nginx или Apache), то public_baseurl должен указывать на URL-адрес, по которому клиенты могут достичь Synapse через этот прокси. Обратный прокси принимает запросы от клиентов и перенаправляет их к Synapse.
3. HTTP-слушатель клиента Synapse: Если у вас нет обратного прокси и Synapse настроен на прослушивание HTTP-запросов напрямую, то public_baseurl должен указывать на URL-адрес, по которому клиенты могут достичь Synapse напрямую через HTTP. В этом случае, Synapse самостоятельно обрабатывает запросы от клиентов.

serve_server_wellknown

serve_server_wellknown — это настройка в конфигурационном файле Synapse, которая позволяет серверу Synapse предоставлять информацию о своем обслуживании на определенном пути .well-known/matrix/server. Эта информация используется другими серверами Matrix для установления соединения с вашим сервером. Важно знать, что по умолчанию эта опция выключена (false).

Вот как работает serve_server_wellknown и для чего он используется:

• Порт по умолчанию (8448): По умолчанию другие серверы Matrix будут пытаться связаться с вашим сервером на порту 8448. Однако в некоторых сетевых средах использование этого порта может быть неудобным или нежелательным.
• Конфигурация на порт 443: Если у вас есть маршрутизация с https://<server_name>/ на порт 443, на котором работает Synapse, вы можете включить опцию serve_server_wellknown. Когда эта опция включена, Synapse предоставит файл по пути https://<server_name>/.well-known/matrix/server.
• Файл .well-known/matrix/server: Файл .well-known/matrix/server содержит информацию о том, как устанавливать соединение с вашим сервером на порт 443 вместо порта 8448. Этот файл будет использоваться другими серверами Matrix, чтобы определить, на какой порт направлять трафик.

Это может быть полезно, если вы хотите перенаправить трафик на более стандартный HTTPS-порт 443 вместо порта 8448. Важно следовать инструкциям и настраивать ваш сервер и маршрутизацию так, чтобы трафик мог корректно достичь Synapse через порт 443, если вы включаете serve_server_wellknown.

extra_well_known_client_content

extra_well_known_client_content — это настройка в конфигурационном файле Synapse, которая позволяет администраторам сервера добавлять произвольные пары ключ-значение в ответ .well-known для клиентов. Это может быть полезно для предоставления дополнительной информации или настроек клиентам, использующим ваш сервер Matrix.

Вот как работает extra_well_known_client_content:

• Кастомные ключи и значения: Вы можете определить произвольные ключи и значения в формате YAML. Эти ключи и значения будут добавлены в ответ .well-known/matrix/client вашего сервера.
• Обеспечение информации клиентам: Например, вы можете использовать эту настройку для предоставления информации о специфических функциях или настройках вашего сервера клиентам. Это может быть полезно для настройки клиентов или для передачи дополнительных данных клиентам, которые подключаются к вашему серверу.
• Необходимость настройки public_baseurl: Важно отметить, что для того чтобы Synapse предоставил ответ .well-known/matrix/client с использованием этой опции, необходимо предоставить корректное значение для настройки public_baseurl. Эта настройка указывает базовый URL-адрес сервера, который используется клиентами для доступа к серверу.

soft_file_limit

soft_file_limit — это настройка в конфигурационном файле Synapse, которая позволяет установить мягкий предел (soft limit) на количество файловых дескрипторов, которые Synapse может использовать. Файловые дескрипторы используются для управления открытыми файлами и сетевыми соединениями. Эта настройка определяет, сколько файловых дескрипторов может быть открыто Synapse’ом одновременно.

Вот как работает soft_file_limit:

• Значение 0: Если soft_file_limit установлено в 0 (по умолчанию), это означает, что Synapse должен установить мягкий предел на количество файловых дескрипторов равным жёсткому пределу (hard limit), который установлен для вашей системы операционной. Таким образом, Synapse будет использовать столько файловых дескрипторов, сколько позволяет жёсткий предел.
• Значение больше 0: Если soft_file_limit установлено в положительное число, это означает, что Synapse будет использовать не более указанного количества файловых дескрипторов. Например, если soft_file_limit установлено в 1000, Synapse будет пытаться ограничить свое использование файловых дескрипторов до 1000 или менее, даже если жёсткий предел позволяет больше.

Настройка soft_file_limit полезна, чтобы контролировать и ограничивать потребление ресурсов сервером Synapse, особенно в средах с ограниченными ресурсами или на серверах с высокой загрузкой. Это может помочь предотвратить исчерпание ресурсов и снизить нагрузку на сервер.

presense

presence — это настройка в конфигурационном файле Synapse, которая определяет, включено ли отслеживание присутствия (presence tracking) на вашем сервере Homeserver. Отслеживание присутствия позволяет пользователям видеть состояние (например, онлайн/оффлайн) других пользователей как на локальном сервере, так и на удаленных серверах Matrix.

Вот как работает presence:

• Включено (по умолчанию): Если presence установлено в true (что является значением по умолчанию), то отслеживание присутствия активно на вашем сервере. Это означает, что пользователи могут видеть состояние других пользователей, например, когда они в сети или оффлайн.
• Отключено (enabled: false): Если вы установите подопцию enabled в false, то отслеживание присутствия будет отключено на вашем сервере. Это означает, что пользователи не будут видеть состояние других пользователей, и сервер не будет отслеживать и сообщать о присутствии.

Отслеживание присутствия полезно для того, чтобы пользователи могли видеть, когда их контакты онлайн или оффлайн, и для создания функциональности, связанной с присутствием в приложениях Matrix.

По умолчанию presence включено, но вы можете отключить его, если это не требуется для вашего сервера или если вы хотите снизить нагрузку на сервер.

presence:
  enabled: false

require_auth_for_profile_requests

require_auth_for_profile_requests — это настройка в конфигурационном файле Synapse, которая определяет, требуется ли аутентификация для получения данных профиля (аватаров, отображаемых имен) других пользователей через клиентский API. По умолчанию эта опция установлена в false, что означает, что аутентификация не требуется для получения данных профиля.

Вот как работает require_auth_for_profile_requests:

• Включено (true): Если require_auth_for_profile_requests установлено в true, то для получения данных профиля других пользователей через клиентский API будет требоваться аутентификация. Это означает, что только аутентифицированные пользователи с правами доступа смогут получать данные профиля других пользователей.
• Отключено (по умолчанию — false): Если эта настройка установлена в false (значение по умолчанию), то аутентификация не требуется для получения данных профиля. Это позволяет клиентам получать данные профиля других пользователей без необходимости входа в систему.

Обратите внимание, что данные профиля также доступны через API федерации, если на вашем сервере разрешено использование профилей через федерацию (с помощью настройки allow_profile_lookup_over_federation). Если эта настройка разрешена, то данные профиля могут быть доступны через другие серверы Matrix, даже если require_auth_for_profile_requests установлено в true.

Настройка require_auth_for_profile_requests полезна для управления доступом к данным профиля и может быть использована для ужесточения безопасности или для ограничения доступа к этим данным только аутентифицированным пользователям.

require_auth_for_profile_requests: true

limit_profile_requests_to_users_who_share_rooms

limit_profile_requests_to_users_who_share_rooms — это настройка в конфигурационном файле Synapse, которая позволяет установить требование, чтобы пользователь имел общие комнаты (был участником одной или нескольких комнат) с другим пользователем, чтобы получить информацию о его профиле. Эта проверка выполняется только для запросов от клиентов (Client-Server запросы).

Вот как работает limit_profile_requests_to_users_who_share_rooms:

• Включено (true): Если limit_profile_requests_to_users_who_share_rooms установлено в true, то для того чтобы пользователь мог получить информацию о профиле другого пользователя через клиентский API, он должен иметь общие комнаты с этим пользователем. Если пользователи не имеют общих комнат, они не смогут получить информацию о профиле друг друга.
• Отключено (по умолчанию — false): Если эта настройка установлена в false (значение по умолчанию), то она не ограничивает доступ к данным профиля на основе общих комнат. Пользователи могут получать информацию о профилях других пользователей независимо от того, имеют ли они общие комнаты.

Эта настройка полезна для управления конфиденциальностью и доступом к данным профиля. Когда она включена, она может помочь предотвратить несанкционированный доступ к данным профиля, требуя наличие общих комнат между пользователями, чтобы они могли видеть друг друга.

limit_profile_requests_to_users_who_share_rooms: true

include_profile_data_on_invite

include_profile_data_on_invite — это настройка в конфигурационном файле Synapse, которая позволяет установить, должны ли данные профиля пользователя быть включены в событие приглашения (invite event) для комнаты. По умолчанию эта опция установлена в true, что означает, что данные профиля пользователя будут включены в событие приглашения, независимо от других настроек.

Вот как работает include_profile_data_on_invite:

• Включено (true): Если include_profile_data_on_invite установлено в true, то данные профиля пользователя будут включены в событие приглашения для комнаты. Это означает, что другие участники комнаты смогут видеть данные профиля приглашенного пользователя, даже если он еще не присоединился к комнате.
• Отключено (false): Если эта настройка установлена в false, то данные профиля пользователя не будут включены в событие приглашения для комнаты. Это означает, что другие участники комнаты не будут видеть данные профиля приглашенного пользователя до тех пор, пока он не присоединится к комнате.

Эта настройка полезна для управления конфиденциальностью данных профиля приглашенных пользователей. Если вы хотите, чтобы данные профиля оставались конфиденциальными до момента присоединения пользователя к комнате, вы можете отключить эту опцию, установив ее в false.

include_profile_data_on_invite: false

allow_public_rooms_without_auth

allow_public_rooms_without_auth — это настройка в конфигурационном файле Synapse, которая определяет, разрешено ли доступ к общедоступному каталогу комнат сервера через клиентский API без аутентификации. По умолчанию эта опция установлена в false, что означает, что для доступа к каталогу комнат требуется аутентификация.

Вот как работает allow_public_rooms_without_auth:

• Включено (true): Если allow_public_rooms_without_auth установлено в true, то любой пользователь может обращаться к каталогу общедоступных комнат сервера через клиентский API без необходимости аутентификации. Это означает, что даже неаутентифицированные пользователи смогут просматривать и получать доступ к общедоступным комнатам на сервере.
• Отключено (по умолчанию — false): Если эта настройка установлена в false (значение по умолчанию), то доступ к каталогу комнат будет требовать аутентификации. Только аутентифицированные пользователи смогут просматривать и получать доступ к каталогу комнат.

Использование allow_public_rooms_without_auth может влиять на уровень доступности и видимости общедоступных комнат на вашем сервере. Установка этой опции в true делает каталог комнат более открытым для общественности, но также может повысить риск злоупотребления или нежелательного контента, поскольку неаутентифицированные пользователи могут получить доступ к комнатам. Поэтому эту опцию следует использовать осторожно и в соответствии с требованиями вашего сервера.

allow_public_rooms_without_auth: true

allow_public_rooms_over_federation

allow_public_rooms_over_federation — это настройка в конфигурационном файле Synapse, которая определяет, разрешено ли другим серверам Homeserver получать каталог общедоступных комнат вашего сервера через механизм федерации. По умолчанию эта опция установлена в false, что означает, что доступ к каталогу общедоступных комнат другим серверам через федерацию запрещен.

Вот как работает allow_public_rooms_over_federation:

• Включено (true): Если allow_public_rooms_over_federation установлено в true, то другие серверы Homeserver могут запросить каталог общедоступных комнат вашего сервера через механизм федерации. Это означает, что другие серверы могут получать информацию о комнатах на вашем сервере через федерацию.
• Отключено (по умолчанию — false): Если эта настройка установлена в false (значение по умолчанию), то доступ к каталогу общедоступных комнат через федерацию будет запрещен для других серверов.

Использование allow_public_rooms_over_federation влияет на то, какие данные о комнатах на вашем сервере доступны через механизм федерации. Если вы разрешите эту опцию, другие серверы могут получать информацию о вашем каталоге общедоступных комнат через федерацию. Это может быть полезно, если вы хотите сделать комнаты вашего сервера видимыми для пользователей на других серверах Matrix. Однако следует помнить о безопасности и конфиденциальности при разрешении доступа через федерацию.

allow_public_rooms_over_federation: true

default_room_version

default_room_version — это настройка в конфигурационном файле Synapse, которая определяет версию комнаты, используемую по умолчанию для новых создаваемых комнат на данном сервере. Комнаты в Matrix могут использовать разные версии, и default_room_version устанавливает версию, которая будет использоваться для комнат, если не указано явным образом другое значение.

Примеры возможных значений default_room_version:

• Если вы хотите использовать версию комнаты 1 по умолчанию, установите default_room_version в "1".
• Если вы хотите использовать версию комнаты 2 по умолчанию, установите default_room_version в "2".

Таким образом, default_room_version позволяет определить, какая версия комнат будет создаваться, если клиент не указывает конкретную версию при создании комнаты.

Важно учитывать, что версии комнат могут включать разные функции и возможности, поэтому выбор версии комнаты зависит от требований вашего сервера и клиентов Matrix, с которыми он взаимодействует.

default_room_version: "8"

gc_thresholds

gc_thresholds — это настройка в конфигурационном файле Synapse, которая позволяет установить параметры порога сборки мусора (garbage collection) для Python. Сборка мусора — это процесс, при котором Python автоматически освобождает память, которая больше не используется, чтобы предотвратить утечку памяти и улучшить производительность.

Сборка мусора в Python управляется автоматически, но с помощью gc_thresholds вы можете влиять на параметры этого процесса, если это необходимо.

Эта настройка позволяет передать параметры порога сборки мусора, которые будут использоваться при вызове gc.set_threshold. Эти параметры определяют, как часто и в каком объеме будет выполняться сборка мусора

В примере под индексами располагаются:

• 0 — это параметр порога для первого поколения сборки мусора.
• 1 — параметр порога для второго поколения сборки мусора.
• 2 — параметр порога для третьего поколения сборки мусора.

Значения 700, 10 и 10 определяют, сколько объектов должно быть выделено перед запуском сборки мусора в каждом из поколений. Эти значения могут быть настроены в соответствии с требованиями вашего сервера и окружения.

Обратите внимание, что изменение параметров сборки мусора может повлиять на производительность и потребление ресурсов сервером, поэтому они должны быть настроены осторожно и основываться на профилировании и мониторинге производительности вашего сервера Synapse.

gc_thresholds: [700, 10, 10]

gc_min_interval

gc_min_interval — это настройка в конфигурационном файле Synapse, которая определяет минимальное время в секундах между сборками мусора (garbage collection, GC) для каждого поколения. Эта настройка гарантирует, что сборка мусора не будет выполняться слишком часто, независимо от установленных порогов GC.

• Первое значение 1s указывает, что должно пройти как минимум 1 секунда между последовательными сборками мусора для поколения 0.
• Второе значение 10s указывает, что должно пройти как минимум 10 секунд между последовательными сборками мусора для поколения 1.
• Третье значение 30s указывает, что должно пройти как минимум 30 секунд между последовательными сборками мусора для поколения 2.

Эта настройка помогает управлять частотой сборки мусора для каждого поколения, чтобы избежать излишней нагрузки на процессор и память сервера. Значения gc_min_interval могут быть настроены в соответствии с требованиями вашего сервера и его производительностью.

gc_min_interval: [1s, 10s, 30s]

filter_timeline_limit

filter_timeline_limit — это настройка в конфигурационном файле Synapse, которая определяет максимальное количество событий, которые будут возвращены в временной линии (timeline) при выполнении операций получения и синхронизации (get и sync). Временная линия представляет собой последовательность событий в комнате.

Эта настройка влияет на количество событий, которые могут быть получены клиентами при запросах на получение данных о комнатах. Например, при выполнении операции синхронизации клиент может запросить события из комнаты, и filter_timeline_limit определит, сколько из них будет возвращено.

Примеры значений filter_timeline_limit:

• Если filter_timeline_limit установлено в 100, то операции получения и синхронизации будут возвращать не более 100 событий из временной линии.
• Если filter_timeline_limit установлено в -1, это означает, что нет верхнего ограничения на количество возвращаемых событий, и будут возвращены все доступные события.

Настройка filter_timeline_limit полезна для управления объемом данных, которые клиенты могут получать при выполнении операций. Это может быть важно для управления производительностью сервера и снижения нагрузки при работе с большими комнатами или большими объемами данных.

filter_timeline_limit: 100

block_non_admin_invites

block_non_admin_invites — это настройка в конфигурационном файле Synapse, которая определяет, должны ли блокироваться приглашения в комнаты для пользователей на этом сервере, за исключением тех, которые отправлены администраторами локального сервера. По умолчанию эта опция установлена в false, что означает, что приглашения в комнаты не блокируются.

Вот как работает block_non_admin_invites:

• Включено (true): Если block_non_admin_invites установлено в true, то приглашения в комнаты для пользователей на этом сервере будут блокироваться, за исключением тех, которые отправлены администраторами лестничного сервера. Другими словами, только администраторы сервера будут иметь возможность отправлять приглашения в комнаты.
• Отключено (по умолчанию — false): Если эта настройка установлена в false, то приглашения в комнаты для пользователей на сервере не будут блокироваться, и любой пользователь сможет отправлять приглашения.

Эта настройка может быть полезной, если вы хотите ограничить возможность отправки приглашений в комнаты на вашем сервере и дать эту возможность только администраторам для более тщательного контроля над этой функцией.

block_non_admin_invites: false

enable_search

enable_search — это настройка в конфигурационном файле Synapse, которая определяет, разрешен ли поиск сообщений в новых сообщениях на сервере. По умолчанию эта опция установлена в true, что означает, что новые сообщения будут индексироваться и доступны для поиска.

Вот как работает enable_search:

• Включено (true): Если enable_search установлено в true, то новые сообщения будут индексироваться и пользователи смогут выполнять поиск сообщений на сервере с помощью соответствующих клиентских приложений.
• Отключено (false): Если эта настройка установлена в false, то новые сообщения не будут индексироваться для поиска, и пользователи будут получать ошибки при попытке выполнить поиск сообщений. Функциональность поиска будет отключена на сервере.

Отключение поиска может быть полезным в случаях, когда поиск сообщений не требуется или когда необходимо снизить нагрузку на сервер. Однако следует помнить, что отключение поиска может сделать сообщения менее доступными для пользователей, и они не смогут легко находить нужные сообщения.

enable_search: true

ip_range_blacklist

ip_range_blacklist — это настройка в конфигурационном файле Synapse, которая предотвращает отправку исходящих запросов на указанные IP-адресные диапазоны CIDR (Classless Inter-Domain Routing). Если эта настройка не указана, то по умолчанию блокируются запросы на частные IP-адресные диапазоны.

Что это означает:

• Если вы установите ip_range_blacklist на конкретные CIDR-диапазоны IP-адресов, то Synapse не будет отправлять исходящие запросы к серверам, которые находятся в этих диапазонах. Это может быть полезно, если вы хотите ограничить обмен данными с определенными сетями или серверами.
• По умолчанию Synapse блокирует исходящие запросы на частные IP-адресные диапазоны, чтобы предотвратить отправку данных на адреса, которые не предназначены для публичного доступа.
• Примечание: 0.0.0.0 и :: всегда находятся в чёрном списке, независимо от того, указаны ли они явно, так как они соответствуют нероутабельным адресам.

Настройка ip_range_blacklist применяется к исходящим запросам для федерации (межсерверному взаимодействию), серверам идентификации, серверам уведомлений (push servers) и проверке валидности ключей для событий приглашений от третьих лиц.

Эта настройка может быть полезна для управления безопасностью и ограничения доступа к определенным сетям или серверам через Synapse. Однако следует использовать её осторожно и только в случае реальной необходимости.

ip_range_blacklist:
  - '127.0.0.0/8'
  - '10.0.0.0/8'
  - '172.16.0.0/12'
  - '192.168.0.0/16'
  - '100.64.0.0/10'
  - '192.0.0.0/24'
  - '169.254.0.0/16'
  - '192.88.99.0/24'
  - '198.18.0.0/15'
  - '192.0.2.0/24'
  - '198.51.100.0/24'
  - '203.0.113.0/24'
  - '224.0.0.0/4'
  - '::1/128'
  - 'fe80::/10'
  - 'fc00::/7'
  - '2001:db8::/32'
  - 'ff00::/8'
  - 'fec0::/10'

ip_range_whitelist

ip_range_whitelist — это настройка в конфигурационном файле Synapse, которая определяет список IP-адресных диапазонов CIDR, которые разрешены для использования в федерации, серверах идентификации, серверах уведомлений (push servers) и для проверки валидности ключей для событий приглашений от третьих лиц. В противоположность настройке ip_range_blacklist, которая блокирует определенные IP-адресные диапазоны, ip_range_whitelist разрешает только указанные IP-адресные диапазоны.

Значение по умолчанию пустой список.

ip_range_whitelist:
   - '192.168.1.1'

listeners

Настройка listeners в конфигурационном файле Synapse определяет порты и их настройки, на которых Synapse будет слушать входящие подключения и выполнять определенные функции. Вот подробное описание параметров listeners и их подопций:

listeners:
  - port: 8008
    tag: http
    bind_addresses: ['::', '0.0.0.0']
    type: http
    tls: false
    x_forwarded: true
    request_id_header: "X-Request-ID"
    resources:
      - names: [client, consent, metrics, federation]
        compress: true
  - port: 8448
    type: metrics
    tls: true
    resources:
      - names: [metrics]
        compress: false

Здесь приведен пример с двумя слушателями:

1. Первый слушатель (порт 8008) с настройками для HTTP:
   • port: Порт, на котором Synapse будет слушать входящие HTTP-запросы.
   • tag: Алиас для порта в имени логгера. Если установлен, то алиас будет заменять порт в логах.
   • bind_addresses: Список локальных адресов, на которых Synapse будет слушать входящие соединения. В данном случае, он будет слушать все доступные локальные интерфейсы.
   • type: Тип слушателя, в данном случае, HTTP.
   • tls: Установите в true, чтобы включить TLS (шифрование) для этого слушателя.
   • x_forwarded: Установите в true, чтобы использовать заголовок X-Forwarded-For как IP-адрес клиента, полезно при использовании Synapse за реверс-прокси.
   • request_id_header: Заголовок, извлекаемый из каждого входящего запроса, который используется в качестве основы для идентификации запроса. Этот параметр полезен, когда Synapse работает за реверс-прокси.
   • resources: Список ресурсов, которые будут размещены на этом порту HTTP.
2. Второй слушатель (порт 8448) с настройками для метрик:
   • port: Порт, на котором Synapse будет слушать метрики.
   • type: Тип слушателя, в данном случае, метрики.
   • tls: Установите в true, чтобы включить TLS (шифрование) для этого слушателя.

Каждый слушатель может иметь свои собственные подопции, такие как tag, bind_addresses, type, tls, и другие, в зависимости от его назначения и требований вашего сервера.

Параметр resources определяет список ресурсов, доступных на данном порту HTTP. Эти ресурсы могут включать в себя различные API, а также статические и дополнительные ресурсы.

Обратите внимание, что в конфигурации также можно указать Unix-сокеты, что позволяет Synapse слушать на локальном уровне через файловый сокет, а не через сетевой порт.

Подробное описание listeners на официальном сайте.

manhole_settings

Настройка manhole_settings в конфигурационном файле Synapse используется для определения параметров соединения с manhole, который предоставляет доступ к внутренней консоли (отладке) сервера Synapse. Вот подробное описание подопций manhole_settings:

• username: Имя пользователя для доступа к manhole. По умолчанию установлено в ‘matrix’, но вы можете изменить его на желаемое значение.
• password: Пароль для доступа к manhole. По умолчанию установлен в ‘rabbithole’, но вы можете установить свой пароль для повышения безопасности.
• ssh_priv_key_path и ssh_pub_key_path: Путь к закрытому и открытому ключу SSH, используемому для шифрования трафика manhole. Если эти параметры не установлены, то будут использованы жестко закодированные и несекретные ключи, что может позволить перехватывать трафик, если он передается по открытым сетям.

Настройка manhole позволяет администраторам сервера Synapse получать доступ к консоли сервера для отладки и анализа, что может быть полезно в случае нештатных ситуаций или для выполнения диагностики. Однако следует обеспечить безопасность доступа к manhole, изменяя имя пользователя и пароль по умолчанию и, при необходимости, настраивая ключи SSH для шифрования трафика.

manhole_settings:
  username: manhole
  password: mypassword
  ssh_priv_key_path: CONFDIR/id_rsa
  ssh_pub_key_path: CONFDIR/id_rsa.pub

dummy_events_threshold

dummy_events_threshold — это настройка в конфигурационном файле Synapse, которая определяет порог (количество экстремальных событий для продвижения вперед) в комнате, при достижении которого Synapse будет отправлять событие org.matrix.dummy_event. Это событие используется для уменьшения количества экстремальных событий в комнате.

Объяснение:

• Экстремальные события (forward extremities) — это события в комнате, которые ещё не были обработаны серверами, и которые могут быть отправлены на другие серверы в ходе федерации. Когда в комнате слишком много экстремальных событий, расчет состояния этой комнаты может стать дорогостоящей операцией.
• Для предотвращения такой ситуации Synapse отправляет событие org.matrix.dummy_event, которое фактически не несет полезной информации и служит только для уменьшения количества экстремальных событий в комнате.
• dummy_events_threshold определяет количество экстремальных событий в комнате, при достижении которого Synapse начнет отправлять события org.matrix.dummy_event. Значение по умолчанию — 10.

Изменение этой настройки может быть полезным, если у вас есть комнаты с большим количеством экстремальных событий, и вы хотите управлять производительностью и распределением нагрузки на сервере. Например, увеличение значения dummy_events_threshold может уменьшить частоту отправки событий org.matrix.dummy_event, что может быть полезно в крупных комнатах с высокой активностью.

dummy_events_threshold: 10

delete_stale_devices_after

delete_stale_devices_after — это настройка в конфигурационном файле Synapse, которая позволяет настроить автоматическое удаление устаревших (неактивных) устройств (девайсов) пользователей. Если эта настройка установлена, Synapse будет запускать фоновую задачу ежедневно для выхода из учетных записей и удаления устройств, которые не использовались в течение заданного временного периода.

Объяснение:

• delete_stale_devices_after — это параметр, в который можно установить определенную продолжительность времени, выраженную в формате длительности (например, «1d» для одного дня или «7d» для одной недели).
• Если этот параметр установлен, то Synapse будет периодически проверять активность устройств пользователей. Устройства, которые не были доступны в течение заданной продолжительности, будут помечены как устаревшие и удалены.
• Значение по умолчанию для этой настройки — отсутствие длительности (no duration), что означает, что устройства не будут автоматически удаляться.
• Обратите внимание, что эта задача всегда выполняется в главном процессе Synapse, независимо от значения параметра run_background_tasks_on, так как в настоящее время воркеры не имеют возможности удалять устройства.

Использование delete_stale_devices_after может быть полезным для управления активными сеансами пользователей и предотвращения накопления неиспользуемых устройств в системе. Вы можете настроить эту опцию в зависимости от ваших требований к безопасности и управлению устройствами пользователей.

delete_stale_devices_after: 1y

email

Настройка email в конфигурационном файле Synapse предназначена для настройки отправки электронных писем (email) из Synapse. Вот подробное описание подопций этой настройки:

• smtp_host: Имя хоста исходящего SMTP-сервера для отправки электронных писем. По умолчанию установлено в ‘localhost’.
• smtp_port: Порт на почтовом сервере для исходящей SMTP. По умолчанию используется порт 465, если параметр force_tls установлен в true, в противном случае — порт 25.
• smtp_user и smtp_pass: Имя пользователя и пароль для аутентификации на SMTP-сервере. По умолчанию аутентификация не выполняется.
• force_tls: По умолчанию Synapse подключается через обычный текстовый протокол и затем, при необходимости, переходит к TLS через STARTTLS. Если этот параметр установлен в true, TLS используется с самого начала (Implicit TLS), и параметр require_transport_security игнорируется. Это рекомендуется включать, если это поддерживается вашим почтовым сервером.
• require_transport_security: Установите в true, чтобы требовать защищенного TLS-транспорта для SMTP. По умолчанию Synapse подключается через обычный текстовый протокол и затем переключается на TLS через STARTTLS, если SMTP-сервер поддерживает это. Если этот параметр установлен, Synapse откажется от подключения, если сервер не поддерживает STARTTLS.
• enable_tls: По умолчанию, если сервер поддерживает TLS, он будет использоваться, и сервер должен предоставить действительный сертификат для ‘smtp_host’. Если этот параметр установлен в false, TLS не будет использоваться.
• notif_from: Определяет адрес «От кого» при отправке электронных писем. Должен быть установлен, если включена отправка электронных писем. Может содержать замещающие переменные, такие как ‘%(app)s’, которые будут заменены на имя приложения.
• app_name: Задает значение по умолчанию для замещающей переменной ‘%(app)s’ в notif_from и заголовках электронных писем. По умолчанию установлено в ‘Matrix’.
• enable_notifs: Установите в true, чтобы включить отправку уведомлений по электронной почте для сообщений, которые пользователь пропустил. По умолчанию отключено.
• notif_for_new_users: Установите в false, чтобы отключить автоматическую подписку на уведомления по электронной почте для новых пользователей. По умолчанию включено.
• client_base_url: Пользовательский URL для клиентских ссылок в уведомлениях по электронной почте. По умолчанию ссылки будут основаны на «https://matrix.to».
• validation_token_lifetime: Настроивает время, в течение которого ссылка на проверку по электронной почте будет действительной после отправки. По умолчанию 1 час.
• invite_client_location: Местоположение веб-клиента, на которое следует направлять пользователей при приглашении. Это передается на сервер идентификации как ключ org.matrix.web_client_location. По умолчанию не установлено.
• subjects: Заголовки для электронных писем, отправляемых из Synapse, с возможностью использования замещающих переменных, таких как ‘%(app)s’, ‘%(person)s’, ‘%(room)s’ и других. Каждый заголовок определяется для определенного типа уведомления (например, «message_from_person_in_room», «invite_from_person_to_room» и т. д.).

Настройка email позволяет администраторам настраивать отправку уведомлений по электронной почте для различных событий и действий на сервере Synapse.

email:
  smtp_host: mail.server
  smtp_port: 587
  smtp_user: "exampleusername"
  smtp_pass: "examplepassword"
  force_tls: true
  require_transport_security: true
  enable_tls: false
  notif_from: "Your Friendly %(app)s homeserver <[email protected]>"
  app_name: my_branded_matrix_server
  enable_notifs: true
  notif_for_new_users: false
  client_base_url: "http://localhost/riot"
  validation_token_lifetime: 15m
  invite_client_location: https://app.element.io

  subjects:
    message_from_person_in_room: "[%(app)s] You have a message on %(app)s from %(person)s in the %(room)s room..."
    message_from_person: "[%(app)s] You have a message on %(app)s from %(person)s..."
    messages_from_person: "[%(app)s] You have messages on %(app)s from %(person)s..."
    messages_in_room: "[%(app)s] You have messages on %(app)s in the %(room)s room..."
    messages_in_room_and_others: "[%(app)s] You have messages on %(app)s in the %(room)s room and others..."
    messages_from_person_and_others: "[%(app)s] You have messages on %(app)s from %(person)s and others..."
    invite_from_person_to_room: "[%(app)s] %(person)s has invited you to join the %(room)s room on %(app)s..."
    invite_from_person: "[%(app)s] %(person)s has invited you to chat on %(app)s..."
    password_reset: "[%(server_name)s] Password reset"
    email_validation: "[%(server_name)s] Validate your email"