Synapse |support| |development| |documentation| |license| |pypi| |python|

O Synapse é agora mantido ativamente em element-hq/synapse <https://github.com/element-hq/synapse>_

O Synapse é um homeserver de código aberto do Matrix <https://matrix.org/>_ desenvolvido de 2019 a 2023 como parte da Fundação Matrix.org. A Fundação Matrix.org não tem recursos para manter o Synapse e ele continua a ser desenvolvido pela Element <https://github.com/element-hq/synapse>; adicionalmente, você tem a escolha de outros homeservers Matrix <https://matrix.org/ecosystem/servers/>.

Veja a postagem no blog The future of Synapse and Dendrite <https://matrix.org/blog/2023/11/06/future-of-synapse-dendrite/>_ para mais informações.

================================================================================

Resumidamente, Matrix é um padrão aberto para comunicações na internet, suportando federação, criptografia e VoIP. Matrix.org tem mais a dizer sobre os objetivos do projeto Matrix <https://matrix.org/docs/guides/introduction>, e a especificação formal <https://spec.matrix.org/> descreve os detalhes técnicos.

.. contents::

Instalação e configuração

A documentação do Synapse descreve como instalar o Synapse <https://matrix-org.github.io/synapse/latest/setup/installation.html>. Recomendamos usar imagens Docker <https://matrix-org.github.io/synapse/latest/setup/installation.html#docker-images-and-ansible-playbooks> ou pacotes Debian do Matrix.org <https://matrix-org.github.io/synapse/latest/setup/installation.html#matrixorg-packages>_.

.. _federation:

O Synapse possui uma variedade de opções de configuração <https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html>_ que podem ser usadas para personalizar seu comportamento após a instalação. Há detalhes adicionais sobre como configurar o Synapse para federação aqui <https://matrix-org.github.io/synapse/latest/federate.html>_.

.. _reverse-proxy:

Usando um proxy reverso com Synapse

É recomendado colocar um proxy reverso como 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>_ na frente do Synapse. Uma vantagem de fazer isso é que você pode expor a porta https padrão (443) para clientes Matrix sem precisar executar o Synapse com privilégios de root. Para informações sobre como configurar um, veja a documentação do proxy reverso <https://matrix-org.github.io/synapse/latest/reverse_proxy.html>_.

Atualizando um Synapse existente

As instruções para atualizar o Synapse estão em the upgrade notes_. Por favor, verifique estas instruções, pois a atualização pode exigir etapas extras para algumas versões do Synapse.

.. _the upgrade notes: https://matrix-org.github.io/synapse/develop/upgrade.html

Dependências de plataforma

O Synapse usa várias dependências de plataforma, como Python e PostgreSQL, e visa seguir as versões upstream suportadas. Veja a política de descontinuação <https://matrix-org.github.io/synapse/latest/deprecation_policy.html>_ para mais detalhes.

Nota de segurança

O Matrix fornece dados brutos fornecidos pelo usuário em algumas APIs — especificamente os endpoints do repositório de conteúdo_.

.. _endpoints do repositório de conteúdo: https://matrix.org/docs/spec/client_server/latest.html#get-matrix-media-r0-download-servername-mediaid

Embora façamos um esforço razoável para mitigar ataques XSS (por exemplo, usando CSP_), um homeserver Matrix não deve ser hospedado em um domínio que hospeda outras aplicações web. Isso se aplica especialmente a compartilhar o domínio com clientes web Matrix e outras aplicações sensíveis como webmail. Veja https://developer.github.com/changes/2014-04-25-user-content-security para mais informações.

.. _CSP: https://github.com/matrix-org/synapse/pull/1021

Idealmente, o homeserver não deve simplesmente estar em um subdomínio diferente, mas em um domínio registrado_ completamente diferente (também conhecido como site de nível superior ou eTLD+1). Isso porque alguns ataques_ ainda são possíveis enquanto as duas aplicações compartilham o mesmo domínio registrado.

.. _domínio registrado: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-2.3

.. _alguns ataques: https://en.wikipedia.org/wiki/Session_fixation#Attacks_using_cross-subdomain_cookie

Para ilustrar com um exemplo, se seu Element Web ou outra aplicação web sensível estiver hospedada em A.example1.com, você deve idealmente hospedar o Synapse em example2.com. Alguma proteção é oferecida ao hospedar em B.example1.com, então isso também é aceitável em alguns cenários. No entanto, você não deve hospedar seu Synapse em A.example1.com.

Observe que tudo o que foi dito acima se refere exclusivamente ao domínio usado na configuração public_baseurl do Synapse. Em particular, não tem relação com o domínio mencionado em MXIDs hospedados naquele servidor.

Seguir este conselho garante que, mesmo que um XSS seja encontrado no Synapse, o impacto em outras aplicações será mínimo.

Testando uma nova instalação

A maneira mais fácil de testar sua nova instalação do Synapse é conectando-se a ela a partir de um cliente web.

A menos que você esteja executando uma instância de teste do Synapse em sua máquina local, em geral, você precisará habilitar o suporte a TLS antes de conseguir conectar-se com sucesso a partir de um cliente: veja Certificados TLS <https://matrix-org.github.io/synapse/latest/setup/installation.html#tls-certificates>_.

Uma maneira fácil de começar é fazer login ou registrar-se via Element em https://app.element.io/#/login ou https://app.element.io/#/register respectivamente. Você precisará alterar o servidor no qual está fazendo login de matrix.org e especificar uma URL do Homeserver de https://<server_name>:8448 (ou apenas https://<server_name> se estiver usando um proxy reverso). Se preferir usar outro cliente, consulte nossa lista de clientes <https://matrix.org/ecosystem/clients/>_.

Se tudo correr bem, você deve pelo menos conseguir fazer login, criar uma sala e começar a enviar mensagens.

.. _client-user-reg:

Registrando um novo usuário a partir de um cliente

Por padrão, o registro de novos usuários através de clientes Matrix está desabilitado. Para habilitá-lo:

1. Na seção de configuração de registro <https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#registration>_ defina enable_registration: true em homeserver.yaml.

2. Em seguida, ou:

   a. configure um CAPTCHA <https://matrix-org.github.io/synapse/latest/CAPTCHA_SETUP.html>_, ou b. defina enable_registration_without_verification: true em homeserver.yaml.

Recomendamos fortemente o uso de um CAPTCHA, especialmente se seu homeserver estiver exposto à internet pública. Sem ele, qualquer pessoa pode registrar livremente contas em seu homeserver. Isso pode ser explorado por atacantes para criar spambots visando o resto da federação Matrix.

Seu novo nome de usuário será formado em parte pelo server_name, e em parte por um localpart que você especifica ao criar a conta. Seu nome terá a forma de::

@localpart:my.domain.name

(pronunciado "at localpart on my dot domain dot name").