Hospedar seu Próprio Servidor Matrix

As pessoas hospedam o próprio Matrix para impedir que uma empresa fique com o histórico das suas conversas, e nisso a promessa se cumpre à risca. O que surpreende depois é a forma real do que foi instalado: um homeserver não é uma caixinha privada que por acaso fala chat. É um nó de replicação dentro de uma rede pública, e a federação se comporta muito mais como um protocolo de publicação do que a maioria dos administradores novatos espera.

Nada disso é argumento contra rodar o seu próprio — é o argumento para rodá-lo de forma deliberada. A privacidade que você ganha é real, mas específica: a custódia passa para você, a conta não pode ser encerrada por terceiros, e as questões legais caem sob a jurisdição que você escolheu, não a que uma empresa escolheu. A privacidade que você não ganha é igualmente específica, e quase tudo isso mora no espaço entre “as mensagens estão criptografadas” e “ninguém consegue saber quem fala com quem”. Este guia cobre as duas metades e depois os detalhes operacionais que decidem se o servidor ainda estará saudável daqui a um ano.

O que rodar seu próprio homeserver realmente muda

Comece separando as ameaças, porque um homeserver responde a algumas por completo, a outras só em parte, e a outras não responde nada. A tabela abaixo é a versão honesta da promessa, e vale a pena lê-la antes de escolher o hardware, não depois.

Leia as duas últimas linhas com atenção, porque é ali que as expectativas quebram. Se o seu objetivo é que ninguém consiga sequer confirmar que um serviço existe, o Matrix é a ferramenta errada, e um serviço onion chega mais perto do que você precisa. Se o seu objetivo é custódia, controle e jurisdição, um homeserver é um instrumento excelente, e o resto deste guia é sobre como operá-lo bem.

Federação é um protocolo de replicação vestido de protocolo de chat

Aqui está o mecanismo que explica a maioria das surpresas. Quando um dos seus usuários entra numa sala hospedada em outro lugar, o seu servidor não busca as mensagens sob demanda como um cliente de e-mail. Ele entra na sala como participante de um grafo de eventos distribuído e, a partir daí, puxa e armazena uma cópia dos eventos da sala, da sua composição de membros e de histórico de estado suficiente para validar o que vier depois. A partir desse momento, a sua máquina guarda uma réplica, e todo outro servidor participante guarda uma também.

As consequências correm nas duas direções, e nenhuma delas é intuitiva. Os dados que os seus usuários geram — nome de exibição, avatar, entradas e saídas, marcações de tempo, reações — são copiados para todo servidor que tenha um membro naquela sala, e permanecem no banco de dados deles independentemente do que você apague depois no seu. Uma redação é um pedido enviado aos pares, não uma ordem. Não existe “desenviar” numa federação de servidores operados de forma independente, e esperar isso é o mal-entendido mais comum sobre o protocolo.

Na outra direção, entrar em salas públicas grandes significa importar o histórico de outras pessoas para o seu disco. É por isso que um homeserver recém-instalado com três usuários pode carregar dezenas de gigabytes de banco de dados: não porque os seus três usuários escreveram muito, mas porque eles entraram em salas com cinquenta mil membros e anos de estado acumulado. Escolher as salas com critério é uma decisão de capacidade tanto quanto de privacidade.

O que a criptografia cobre, e o que fica exposto

O Matrix criptografa o conteúdo das mensagens com Megolm, e em salas privadas isso vem ativado por padrão. Isso protege a parte que mais preocupa as pessoas, e funciona de verdade — o seu servidor armazena um texto cifrado que ele mesmo não consegue ler, uma propriedade real e útil quando o servidor é hardware alugado. O envelope em torno da mensagem é outra história, e a lacuna é maior do que a maioria dos resumos admite.

Na prática: a criptografia protege o quê, a federação publica o quem, quando e com que frequência. Para a maioria das comunidades essa troca é perfeitamente aceitável, e a honestidade é o ponto principal. Para um modelo de ameaça em que o próprio grafo social é a parte sensível, um protocolo federado tem a forma estruturalmente errada, e nenhuma opção de configuração muda isso.

Synapse, Dendrite ou Conduit — o que realmente rodar

Três implementações importam na prática, e a escolha é muito mais uma decisão de recursos do que uma questão filosófica.

• Synapse é o servidor de referência, escrito em Python, e o único em que todo recurso funciona desde o primeiro dia. Também é o mais faminto: a memória cresce com o número e o tamanho das salas em que os seus usuários entram, e um servidor movimentado acaba precisando ser dividido em processos worker. Escolha-o quando você precisar que spaces, ferramentas de moderação, bridges e APIs de administração se comportem exatamente como documentado.
• Dendrite é a reescrita em Go. Visivelmente mais leve que o Synapse e perfeitamente utilizável num servidor pequeno, ao custo de alguma defasagem de recursos. Uma opção intermediária razoável quando o Synapse parece pesado para a quantidade de pessoas que você realmente tem.
• Conduit e o seu fork ativamente desenvolvido, o conduwuit, são escritos em Rust e distribuídos como um binário único com banco de dados embutido. Eles rodam um servidor de família ou de comunidade pequena no menor plano que vendemos sem reclamar. A contrapartida é um ecossistema menor: algumas ferramentas de administração e algumas bridges pressupõem o Synapse.

Para um primeiro servidor com um punhado de usuários, um software da família Conduit numa VPS pequena é o caminho menos doloroso até algo que funciona e continua barato. Para qualquer coisa que você espera que cresça — uma comunidade pública, uma empresa, um projeto com bridges — comece no Synapse e pule a migração, porque trocar de implementação depois é um exercício de exportar e reconstruir, não uma mudança de configuração.

A configuração de delegação que todo mundo erra

O Matrix separa o nome que aparece nos IDs de usuário da máquina que efetivamente serve o tráfego, e inverter isso é o erro permanente mais comum ao se autohospedar. O seu server_name é o domínio que aparece depois dos dois-pontos em todo ID de usuário do seu servidor. Ele passa a fazer parte da sua identidade na federação a partir do momento em que o primeiro evento é assinado, e não pode mais ser alterado depois sem abandonar todas as contas e salas daquela máquina.

A configuração que você quase sempre vai querer: o server_name é o seu domínio puro, enquanto o software roda num subdomínio. Você liga os dois por delegação, de uma de duas formas. A mais simples é um arquivo JSON estático servido em /.well-known/matrix/server no domínio puro, indicando o host real e a porta. A alternativa é um registro DNS, _matrix._tcp, apontando para o mesmo lugar. Sirva também o arquivo do lado cliente em /.well-known/matrix/client, para que os aplicativos encontrem o homeserver a partir de um único endereço.

Dimensionando com honestidade

O Matrix não é limitado por CPU em operação normal; é limitado por memória e pelo comportamento do banco de dados. Os números publicados para o Synapse são um piso útil: cerca de 2 GB de RAM para começar, por volta de 4 GB a partir de dez a cinquenta usuários ativos, e 8 GB ou mais acima de uma centena. Servidores da família Conduit ficam bem abaixo disso. O que esses números deixam de fora é que o consumo acompanha as salas em que se entrou, não as pessoas cadastradas — cinco usuários em cem salas públicas grandes custam muito mais do que cinquenta usuários num punhado de salas privadas.

Daí seguem duas regras práticas. Coloque o banco de dados em armazenamento rápido e dê a ele espaço para crescer, porque o padrão de escrita é pequeno e constante, não em picos. E não dimensione para a quantidade de usuários de hoje: dimensione para as salas em que esses usuários vão entrar no primeiro mês, que costuma ser onde mora a surpresa. O nosso plano de entrada carrega um servidor Conduit ou Dendrite pequeno sem esforço, enquanto uma instância Synapse para uma comunidade de verdade pertence a um plano intermediário ou superior — a página de hospedagem de chat lista os planos que recomendamos para cada um desses perfis.

O uptime importa mais aqui do que para a maioria das cargas de trabalho, porque um servidor de chat fora do ar não está apenas indisponível — ele está silenciosamente perdendo eventos que os pares vão tentar reenviar por um tempo e depois vão parar de oferecer. A federação é tolerante com minutos e implacável com dias.

O repositório de mídia é uma bomba de disco em câmera lenta

Toda imagem, vídeo e arquivo que passa por uma sala em que os seus usuários estão pode acabar em cache no seu disco, incluindo mídia remota que os seus próprios usuários nunca chegaram a abrir. A retenção padrão do Synapse mantém isso indefinidamente. O resultado é previsível e ainda assim pega gente de surpresa: um servidor cujo banco de dados está estável e cujo diretório de mídia cresce silenciosamente até o volume encher, momento em que o sintoma não é “disco cheio”, mas “o servidor está se comportando de forma estranha”.

Defina uma política de retenção para mídia remota logo no primeiro dia, não depois da primeira interrupção. O Synapse expõe configurações de retenção em homeserver.yaml, além de endpoints administrativos para depurar histórico antigo e arquivos em cache; o synapse-compress-state recupera uma quantidade surpreendente de espaço das tabelas de estado num servidor mais antigo. Fique de olho tanto no banco de dados quanto no caminho de mídia, e alerte com base no espaço livre, não em o serviço estar fora do ar — o segundo sintoma chega dias depois do primeiro.

Uma configuração merece uma decisão deliberada, não o padrão de fábrica. As pré-visualizações de URL fazem o seu servidor buscar qualquer link postado numa sala, o que significa que o endereço IP do seu servidor faz uma requisição de saída para terceiros no instante em que alguém cola um link — inclusive um link escolhido especificamente para ver quem morde a isca. Se o seu homeserver está atrás de um front e o endereço real dele importa, pese isso com cuidado; o nosso guia sobre como esconder um endereço de origem cobre essa mesma classe de vazamento com mais detalhes.

Registro, spam e a reputação que você herda

Registro aberto num homeserver público é um convite, e não do tipo que você quer. Cadastros automatizados transformam um servidor pequeno numa fonte de spam em questão de dias, e a consequência não fica restrita ao seu servidor: outros homeservers passam a incluir o seu domínio em listas de controle de acesso, e assim que o seu nome está em listas suficientes, os seus usuários legítimos ficam impedidos de participar de salas em outros lugares. Recuperar a reputação de um domínio queimado é muito mais difícil do que evitar chegar a esse ponto, exatamente como acontece com a entregabilidade de e-mail.

As configurações padrão defensáveis são simples. Mantenha o enable_registration desligado num servidor privado e crie as contas você mesmo. Se quiser deixar a porta aberta, controle o acesso: o registration_requires_token transforma o registro num sistema de convites sem depender de nenhum serviço de terceiros, e um captcha ajuda contra a ponta mais grosseira do problema. Para as salas que você administra, os bots de moderação da família Mjolnir e Draupnir permitem aplicar listas de banimento e ACLs de sala para uma comunidade inteira de uma vez, em vez de sala por sala.

Vale saber também o inverso: as nossas faixas de endereço não constam nas blocklists de ACL do Matrix que circulam entre homeservers, então um servidor novo começa com a reputação limpa. O que acontece com essa reputação depois é definido por como você conduz o registro, não por onde a máquina está.

Bridges, e a conta de metadados que vem junto

As bridges são o motivo honesto pelo qual muita gente continua no Matrix: um único cliente para salas que vivem em outras redes. Elas também mudam a posição de segurança do seu servidor de um jeito fácil de deixar passar despercebido. Uma bridge guarda as credenciais da conta remota e, na fronteira onde os protocolos se encontram, ela necessariamente lida com as mensagens numa forma que consegue converter — o que significa que o processo da bridge vê em texto plano um tráfego que está criptografado de ponta a ponta dos dois lados dela.

Isso não é motivo para evitar bridges. É motivo para tratar o host da bridge como infraestrutura sensível: é a máquina que, se comprometida, expõe as contas que ela representa. Cada bridge praticamente dobra o consumo de memória de um servidor pequeno, então planeje a capacidade levando isso em conta, e dedique ao lugar onde ela roda a mesma atenção que você dedicou ao próprio homeserver — o raciocínio do nosso guia de jurisdição vale com ainda mais força para uma máquina que guarda credenciais de várias redes ao mesmo tempo.

Mantendo tudo vivo: chaves, backups e atualizações

Um servidor Matrix tem um arquivo cuja perda é irrecuperável de um jeito que não tem nada a ver com volume de dados. A chave de assinatura — o signing.key no Synapse — é o que prova que os eventos que dizem vir do seu domínio realmente vêm. Se você a perder, deixa de conseguir ser de forma crível o seu próprio servidor; os pares vão rejeitar eventos assinados por um desconhecido usando o seu nome. Faça o backup dela separadamente de tudo o mais, e mantenha essa cópia fora da máquina.

Atualizações são rotina, mas não são opcionais. Os lançamentos do homeserver trazem migrações de schema, e pular muitas versões transforma uma atualização de cinco minutos numa tarde inteira. Leia as notas de lançamento antes de avançar, atualize com regularidade suficiente para que cada passo seja pequeno, e faça a higiene básica de host da nossa checklist de proteção da primeira hora — um servidor de chat é um serviço de longa duração exposto à internet com um banco de dados anexado, e merece o mesmo tratamento que qualquer um.

Onde o servidor está continua decidindo o resultado

Tudo o que foi dito até aqui é configuração. A parte que a configuração não alcança é qual sistema jurídico recebe um pedido sobre os seus usuários, e para um servidor de comunicação essa questão pesa mais do que para um site comum. Um homeserver guarda registros de participação, marcações de tempo e dados de grafo social em texto claro mesmo quando o corpo das mensagens está criptografado — então a jurisdição que hospeda o servidor é a jurisdição que rege o acesso a esse registro.

Esse é o argumento prático para escolher uma localização de propósito, e não só pela latência. Nós operamos em sete, e as vantagens e desvantagens entre elas estão no guia de jurisdição e na página de localizações. A outra metade da mesma questão é quem o provedor sabe que você é: uma conta sem identidade associada não pode produzir documentos de identidade que nunca coletou, e esse é o motivo simples pelo qual a hospedagem sem KYC e as comunicações autohospedadas continuam aparecendo na mesma conversa. Nenhuma das duas é defesa contra um tribunal que já sabe o seu nome, e o nosso guia de OpSec é direto sobre onde essa linha está.

A versão resumida

Se você for levar seis coisas desta página, leve estas:

• Escolha o server_name antes de instalar qualquer coisa — é a única decisão que você nunca poderá revisar.
• Delegue com /.well-known/matrix/server ou um registro SRV, e mantenha TLS válido nos dois nomes.
• Dimensione para as salas em que os seus usuários vão entrar, não para quantos usuários você tem.
• Defina a retenção de mídia logo no primeiro dia, e decida sobre as pré-visualizações de URL em vez de simplesmente herdar o padrão.
• Mantenha o registro fechado ou controlado por token; reverter a reputação de um domínio queimado é caro.
• Faça backup do signing.key separadamente, e nunca reverta o banco de dados para trás dos seus pares.

Faça isso e o servidor vai ser discreto, que é exatamente o que um servidor de chat deveria ser. O que você ganha em troca vale a pena encarar com clareza: não é invisibilidade, e não é um protocolo que esconde quem fala com quem, mas sim conversas cujo conteúdo é seu, uma conta que ninguém mais pode encerrar, e uma máquina sob um sistema jurídico que você escolheu deliberadamente. Coloque um homeserver onde você escolheu, e deixe a federação vir até ele.