Conduit: um servidor de chat simples e rápido baseado em Matrix

 (conduit.rs)
3 pontos por GN⁺ 2023-08-01 | 1 comentários | Compartilhar no WhatsApp
  • Conduit é um servidor open source leve que implementa a especificação Matrix, com foco em permitir configurar seu próprio homeserver em poucos minutos
  • O projeto ainda está em beta, então já pode ser usado, mas ainda faltam alguns recursos menores
  • Matrix é uma rede aberta para comunicação segura e distribuída, e usuários de homeservers diferentes podem conversar entre si
  • Do ponto de vista operacional, usa uma estrutura de binário único com banco de dados embutido, e utiliza RocksDB como banco de dados padrão
  • Como busca ser uma alternativa mais leve e mais fácil de instalar que o Synapse, vale considerar se você precisa de um servidor de chat próprio com baixos requisitos de sistema

O papel do Conduit e do Matrix

  • Conduit é um servidor open source leve que implementa a Matrix Specification
  • O estado atual é beta
    • Já pode ser usado
    • Alguns recursos menores ainda não estão disponíveis
  • Matrix é uma rede aberta para comunicação segura e distribuída
    • Qualquer usuário de um homeserver Matrix pode conversar com usuários de outros servidores Matrix
    • Com bridges, também é possível se comunicar com usuários fora do Matrix, como comunidades no Discord

Características de instalação e operação

  • O objetivo é facilitar a configuração e reduzir os requisitos de sistema, permitindo criar sua própria instalação do Conduit em poucos minutos
  • O servidor usa uma estrutura de binário único com banco de dados embutido
  • O banco de dados padrão é o RocksDB
  • Em alguns casos, pode ser mais rápido que outras implementações de servidor

Links relacionados e apoio

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-01
Opiniões do Hacker News

  • Venho rodando uma instância auto-hospedada do Conduit há alguns anos; o ponto positivo é que é fácil de instalar e usar, e o negativo é que ainda é um software beta
    Mesmo assim, tem sido muito bom para mim; tenho usado bem para conversas estáveis com alguns amigos e também em algumas salas um pouco maiores das quais participo
    O autor também trabalha em outro projeto interessante em Rust, o Veloren: https://veloren.net

    • Veloren é um jogo realmente incrível. Há alguns anos compilei de brincadeira com amigos, e ele rodou surpreendentemente fluido até na minha GTX 1050 Ti
      Entrei no lobby e joguei por uns 30 minutos, até perceber que dava para continuar dando zoom out com a roda do mouse a partir do personagem. Ia além do nível de um RPG de ação comum, passando para uma escala de minimapa e subindo acima das nuvens sem queda de frames; foi uma sensação bem alucinógena
      Não sei quão bem o projeto é mantido hoje, mas parece ter uma estrutura mais que suficiente para se tornar um RPG robusto
    • Uso o Conduit há bastante tempo e tenho uma ótima impressão dele
      Por muito tempo faltou suporte a Spaces, mas ele acabou de entrar nos builds de desenvolvimento e está excelente. Já atualizei meu serviço e está funcionando como esperado
    • Parece uma boa alternativa a rodar o Dendrite, que é um servidor em Go. O Dendrite parece estar eternamente em desenvolvimento, e o servidor em Python hoje consome recursos demais, então é bom ver uma alternativa além do servidor em Go
    • Seria bom se houvesse um cliente parecido que desse suporte completo aos recursos. O problema do Matrix é que ele tem recursos demais, parecendo uma mistura de Signal, Discord, Slack, Zoom e Teams
      Seria bom ter um subprotocolo voltado apenas a chat seguro
    • Estou rodando há 10 meses, e tanto a instalação quanto o uso foram muito tranquilos
      Sou o único usuário do meu servidor e não entrei em salas muito ativas, mas até agora o impacto no desempenho de um VPS pequeno é desprezível

  • Olá, sou o Timo, comecei o projeto Conduit há alguns anos. Fiquem à vontade para fazer perguntas

    • Uso o Conduit há 10 meses e gosto muito dele. Tenho duas perguntas
      Tenho curiosidade se há alguma preocupação com o futuro do projeto depois que você terminar a universidade. Até agora, o Timo parece ser de longe o contribuidor mais ativo, então fico receoso de que o projeto ainda dependa muito do tempo que você consegue dedicar
      Também queria saber por onde um desenvolvedor Rust/Linux deveria começar para fazer uma primeira contribuição significativa ao Conduit. Há 155 issues abertas no GitLab e, do ponto de vista de usuário, não tenho nenhum problema óbvio que salte aos olhos, então não sei por onde começar
      Se Dortmund ou trabalho remoto não forem requisitos obrigatórios, pode entrar em contato; espero que consiga um bom emprego
    • Tenho curiosidade sobre o que você acha do matrix-p2p / Pinecone, que está sendo desenvolvido para o Dendrite
      Também queria saber se há planos de tornar o Conduit P2P no futuro próximo
      https://github.com/matrix-org/pinecone
      https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...
    • Considerando o Matrix como protocolo, qual é a parte do design que você acha mais frustrante?
      Tenho minhas próprias impressões depois de escrever bots, mas tenho especial curiosidade pela perspectiva de um mantenedor de implementação de homeserver
    • Existe algum documento resumindo como o Conduit se compara ao Synapse ou à especificação Matrix em termos de recursos?
      Não está claro se o objetivo é ser um servidor Matrix com todos os recursos ou mirar um subconjunto específico em escala ou funcionalidades
    • Você usa o Conduit diretamente no dia a dia? Quero saber se ele é estável para uso cotidiano

  • O que não gostei no Matrix foi que eu administrava um servidor com 3 ou 4 usuários e, em alguns meses, o banco de dados cresceu para cerca de 80 GB
    Mesmo somando o conteúdo enviado pelos usuários e o texto, dava algo em torno de 2 a 3 GB. Gostaria de saber se há uma forma de apagar o cache de dados recebidos de servidores antigos, por exemplo a partir de 2 semanas de idade, e buscá-los novamente se necessário

    • Existe uma API de administrador para apagar imagens locais/remotas antigas. Nesse caso, provavelmente é a API certa
      https://matrix-org.github.io/synapse/v1.85/admin_api/media_a...
      Meu servidor não é federado, mas é bem ativo, e eu o trato como um espaço temporário. Configurei para que tanto texto quanto mídia com mais de 1 ou 2 semanas sejam coletados automaticamente
    • O que ocupa espaço são os dados de estado das salas/conversas, e eles podem ser comprimidos
      https://levans.fr/shrink-synapse-database.html
      https://github.com/matrix-org/rust-synapse-compress-state
    • É por coisas assim que passei a valorizar mais o XMPP. Não há a expectativa de replicar todo o histórico de uma sala de chat
      Muitos MUCs usam como padrão as 20 mensagens mais recentes, o que normalmente basta para entender o fluxo da conversa e entrar nela. O custo para operar meu servidor também era bem baixo

  • Gostaria de saber se há uma forma de fazer migração do Synapse para o Conduit. É difícil justificar jogar fora 6 anos de histórico de conversas

    • Ainda não há. Existe um plano para uma ferramenta de migração do Synapse para o Dendrite, mas o suporte ao Conduit também teria que ser incluído separadamente
      De qualquer forma, não dá para saber quanto tempo isso levaria
      O que encontrei foi apenas a issue de acompanhamento da migração Synapse -> Dendrite
      https://github.com/matrix-org/dendrite/issues/1705

  • Post relacionado: Conduit Beta – Matrix chat server - https://news.ycombinator.com/item?id=28385840 - setembro de 2021, 69 comentários

  • Alguém consegue explicar por que usar Matrix se já existe XMPP?

    • Minha primeira reação foi pensar que a pergunta deveria ser o contrário. Como não sei por que eu deveria usar XMPP, vou dizer o que acho bom no Matrix
      É uma solução moderna de chat com os recursos que as pessoas esperam do Slack e do Discord, e tem muitas bridges que evitam a necessidade de usar vários clientes de chat para vários protocolos
      Há muitas comunidades excelentes, o chat de voz também é bem bom, é open source e pode ser auto-hospedado. Fico curioso para saber o que há de bom no XMPP
    • Matrix é mais parecido com conversar usando Git, usa um banco de dados distribuído e tem um caráter mais forte de mensageiro de equipe, como Mattermost ou Zulip
      XMPP, estruturalmente, é mais parecido com e-mail, com opções como status online, digitando e último acesso, e grandes serviços de mensageria como o WhatsApp também costumam usar variantes próprias dele
      XMPP é o único sistema que pode ser usado, e que faz sentido usar, em qualquer lugar onde se use e-mail. Ele é tão moderno quanto o Matrix; apenas pensa de forma diferente sobre armazenamento e distribuição de dados
      Comparação: https://www.freie-messenger.de/en/systemvergleich/xmpp-matri...
    • Este resumo ainda continua correto: https://news.ycombinator.com/item?id=8998290
      XMPP é excelente para o objetivo para o qual foi projetado, mas não se encaixa bem em mobile, alta perda de pacotes e conexões de alta latência. É verboso e consome muita largura de banda, então não é bom para ambientes com dados e bateria limitados, e originalmente também não levou em conta a realidade de uma pessoa usar vários dispositivos
      A transferência de arquivos também foi ruim por muito tempo, e havia uma mistura de métodos incompatíveis dependendo dos clientes e da topologia da rede
      O excesso de XEPs também não ajuda o ecossistema. Quando há extensões opcionais demais, a interoperabilidade cai. Os recursos esperados em um chat moderno ultrapassaram o escopo para o qual o XMPP foi projetado, e as XEPs tentaram remendar isso, mas o resultado foi desigual
      Na época do projeto, era uma escolha tecnológica natural, mas hoje há muitas opções melhores. Desenvolvedores tendem a escolher tecnologias que tornam o trabalho mais agradável, então há mais movimento nas plataformas novas. Por exemplo, outro post no HN hoje também tratou do fato de que um parser XML comum pode não ser suficiente, sendo necessário um parser XML bem avançado: https://news.ycombinator.com/item?id=36930196
    • O XMPP tem um mínimo denominador comum, e boa parte das funcionalidades centrais fica sob XEPs opcionais. Por isso, a experiência do usuário varia muito dependendo do cliente e do servidor
      No Matrix, o conjunto de funcionalidades importantes é mais claro, então dá para esperar que um cliente compatível as implemente de forma uniforme, sem surpresas
    • Matrix é mais próximo de um serviço de sincronização de estado do que de uma forma de enviar mensagens
      Quando você entra em uma sala de outro servidor Matrix, seu servidor começa a manter uma cópia daquele servidor, e você pode usá-la do jeito que quiser. Mesmo que você desligue seu servidor por um dia e depois ligue de novo, ele sincroniza novamente
      Não sei se o XMPP funciona assim, mas sempre pensei nele como algo que envia mensagens como e-mail e faz algumas tentativas de reenvio. Também não sei bem como informações transitórias, como estado atual, confirmação de leitura e indicação de digitação, funcionam entre servidores

  • O Conduit é um projeto muito legal, mas parece difícil acompanhar seu estado e andamento sem ler todos os commits e issues
    O progresso recente no recurso embutido de Sliding Sync é promissor, porque facilita muito a implantação

  • Alguém sabe o que faz com que, no Matrix, às vezes a última mensagem não seja descriptografada até que uma nova última mensagem seja enviada, ou que as mensagens ao redor funcionem, mas uma única mensagem tenha falha de descriptografia?

    • Meu entendimento ainda não é perfeito, mas nem todas as mensagens são criptografadas com a mesma chave
      Se todos os meus clientes não estiverem conectados ao mesmo tempo, e o remetente também não estiver, eles não conseguem trocar chaves entre si. Então cada cliente só consegue descriptografar parte das mensagens para as quais possui a chave. Além disso, os clientes só trocam chaves com outros clientes verificados
      Observando a propriedade session_id no JSON original da mensagem, dá para ver que todas as mensagens de uma sessão específica — ou seja, enquanto o remetente estava logado em um cliente — são todas descriptografadas ou nenhuma é descriptografada. O primeiro caso significa que você tem a chave daquela sessão; o segundo, que ainda não a recebeu

  • Posso ter deixado passar alguma coisa, mas a página é simples demais e parece presumir que você já sabe o que é Matrix e como usar isso
    Ela dedica bastante tempo a várias formas de instalação, mas não vejo instruções de uso do servidor em si, como usar clientes

    • O primeiro link da página vai para matrix.org, e em matrix.org há um link para clientes: https://matrix.org/ecosystem/clients/
      Provavelmente é só usar o Element
      Acho que a página do Conduit está fazendo o certo. Não é tanto presumir que você sabe o que é Matrix, mas sim presumir que, se não souber, tem discernimento suficiente para clicar no link
    • Se você já conhece o Matrix.org, a landing page é bem boa. Parece voltada a desenvolvedores Matrix
      Pessoalmente, gostei por ser curta, deixar claro de forma simples o problema que tenta resolver e mostrar rapidamente o link do repositório Git, que é a chamada real para ação
      Talvez a própria landing page tenha sido atualizada com conteúdo novo depois do post original
    • O link mudou?
      Matrix é uma rede aberta para comunicação segura e descentralizada. Usuários de qualquer homeserver Matrix podem conversar com usuários de qualquer outro servidor Matrix. Também podem se comunicar, por meio de bridges, com usuários fora do Matrix, como comunidades do Discord
      E não vejo informações de instalação
    • Matrix é um protocolo de chat. Ele funciona como conversar via Git, usa um banco de dados distribuído e é mais parecido com mensageiros de equipe como Mattermost ou Zulip
      Conduit é um software de servidor, não um app para usuário final
      Mais informações sobre Matrix: https://www.freie-messenger.de/en/matrix

  • Fiquei curioso sobre qual é a relação do Conduit com o Synapse
    O Dendrite é testado com https://github.com/matrix-org/sytest e há até issues do tipo “já é Synapse?”, mas não encontrei discussões relacionadas no Conduit. Nem mesmo vejo discussões sobre por que ele não quer se tornar como o Synapse

    • Conduit é uma implementação de terceiros da especificação de servidor Matrix, escrita em Rust. Synapse e Dendrite são ambas implementações oficiais, e o Dendrite começou originalmente com o objetivo de substituir o Synapse
      Os pontos fortes que ele destaca são ser leve e fácil de instalar, o que implica que o Synapse não é assim. Mais importante, ele serviu como caso de validação da especificação de servidores Matrix e, ao longo dos anos, contribuiu bastante para esclarecer partes ambíguas
    • O SyTest é ajustado principalmente para ser usado com o Synapse, e parece que, no lado do Dendrite, estão fazendo um wrapper para integrá-lo à própria integração contínua
      O Conduit talvez pudesse reutilizar parte desse trabalho, mas, se me lembro bem, o Conduit usa GitLab e o Dendrite usa GitHub Actions
      Separadamente, por enquanto o Conduit não parece mirar ser um substituto drop-in do Synapse. Da última vez que vi nas salas Matrix, ainda havia várias lacunas de recursos perceptíveis