3 puntos por GN⁺ 2023-08-01 | 1 comentarios | Compartir por WhatsApp
  • Conduit es un servidor ligero de código abierto que implementa la especificación de Matrix, enfocado en configurar tu propio homeserver en pocos minutos
  • El proyecto todavía está en beta, así que ya puede usarse, aunque todavía le faltan algunas funciones pequeñas
  • Matrix es una red abierta para comunicación segura y distribuida, y los usuarios de distintos homeservers pueden chatear entre sí
  • En términos operativos, usa una estructura de binario único y base de datos integrada, con RocksDB como base de datos predeterminada
  • Como busca ser una alternativa más ligera y fácil de instalar que Synapse, vale la pena considerarlo si necesitas un servidor de chat autohospedado con bajos requisitos de sistema

El papel de Conduit y Matrix

  • Conduit es un servidor ligero de código abierto que implementa la especificación de Matrix
  • Su estado actual es beta
    • Ya puede usarse
    • Algunas funciones pequeñas todavía no están disponibles
  • Matrix es una red abierta para comunicación segura y distribuida
    • Todos los usuarios de homeservers de Matrix pueden chatear con usuarios de otros servidores Matrix
    • Si usas bridges, también puedes comunicarte con usuarios fuera de Matrix, como comunidades de Discord

Instalación y características operativas

  • Su objetivo es ofrecer configuración sencilla y bajos requisitos de sistema, para que puedas crear tu propia instalación de Conduit en pocos minutos
  • El servidor usa una estructura de binario único y base de datos integrada
  • La base de datos predeterminada es RocksDB
  • En algunos casos puede ser más rápido que otras implementaciones de servidor

Enlaces relacionados y apoyo

1 comentarios

 
GN⁺ 2023-08-01
Opiniones de Hacker News
  • Llevo varios años operando una instancia de Conduit autoalojada; lo bueno es que es fácil de instalar y usar, y lo malo es que todavía es software beta.
    Aun así, me ha funcionado bastante bien: lo he usado para chats estables con algunos amigos y también en salas un poco más grandes en las que participo.
    El autor también trabaja en Veloren, otro proyecto interesante en Rust: https://veloren.net

    • Veloren es un juego realmente genial. Hace unos años lo compilé con amigos por diversión, y corría sorprendentemente fluido incluso en mi GTX 1050 Ti.
      Entré al lobby, jugué unos 30 minutos y luego descubrí que podía seguir alejando la cámara del personaje con la rueda de desplazamiento. Iba más allá de lo típico en un RPG de acción: pasaba a escala de minimapa, hasta por encima de las nubes, sin caídas de frames; se sentía bastante alucinógeno.
      No sé qué tan bien mantenido esté el proyecto ahora, pero parece tener una base más que suficiente para convertirse en un RPG potente.
    • Llevo bastante tiempo usando Conduit y lo valoro muy positivamente.
      Durante mucho tiempo le faltó soporte para Spaces, pero acaba de entrar en las builds de desarrollo y está excelente. Ya actualicé mi servicio y funciona como se esperaba.
    • Parece una buena alternativa a correr Dendrite, el servidor en Go. Dendrite se siente como si fuera a estar en desarrollo eternamente, y el servidor en Python ya consume demasiados recursos, así que da gusto ver alternativas además del servidor en Go.
    • Sería bueno que existiera un cliente similar que soportara completamente las funciones. El problema de Matrix es que tiene tantas funciones que parece una mezcla de Signal, Discord, Slack, Zoom y Teams.
      Me gustaría que hubiera un subprotocolo solo para chat seguro.
    • Lo llevo operando 10 meses y tanto la instalación como el uso han sido muy fluidos.
      Soy el único usuario de mi servidor y no he entrado a salas muy activas, pero hasta ahora el impacto en el rendimiento de un VPS pequeño ha sido despreciable.
  • Hola, soy Timo, quien inició el proyecto Conduit hace unos años. Si tienen preguntas, háganlas con confianza.

    • Llevo 10 meses usando Conduit y me encanta. Tengo dos preguntas.
      Me pregunto si no hay preocupaciones sobre el futuro del proyecto después de que termines la universidad. Hasta ahora Timo parece ser, por mucho, el contribuidor más activo, así que me preocupa que el proyecto todavía dependa en gran medida del tiempo que puedas dedicarle.
      También me gustaría saber por dónde debería empezar un desarrollador de Rust/Linux para hacer una primera contribución significativa a Conduit. Hay 155 issues abiertos en GitLab y, desde la perspectiva de usuario, no tengo ningún problema claramente evidente, así que no sé por dónde comenzar.
      Si Dortmund o el trabajo remoto no son requisito, siéntete libre de contactarme, y espero que consigas un buen empleo.
    • Me interesa saber qué opinas de matrix-p2p / Pinecone, que se está desarrollando para Dendrite.
      También me pregunto si Conduit tiene planes de volverse P2P en el futuro cercano.
      https://github.com/matrix-org/pinecone
      https://archive.fosdem.org/2022/schedule/event/matrix_p2p_pi...
    • Viendo Matrix como protocolo, me pregunto cuál es la parte de su diseño que te resulta más frustrante.
      Tengo mis propias impresiones tras escribir bots, pero me interesa especialmente el punto de vista de un mantenedor de una implementación de homeserver.
    • Me pregunto si existe algún documento que resuma cómo se compara Conduit, en términos de funciones, con Synapse o con la especificación de Matrix.
      No queda claro si el objetivo es ser un servidor Matrix con todas las funciones o si apunta a un subconjunto específico en escala o funcionalidad.
    • Me gustaría saber si usas Conduit directamente todos los días. Quiero saber si es lo bastante estable para uso cotidiano.
  • Lo que no me gustó de Matrix fue que operé un servidor con 3 o 4 usuarios y, en unos meses, la base de datos creció a unos 80 GB.
    Sumando el contenido subido por los usuarios y el texto, serían unos 2 o 3 GB. Me pregunto si hay alguna forma de borrar, por ejemplo, a partir de las 2 semanas, la caché de datos recibidos de servidores antiguos y volver a obtenerlos si hace falta.

    • Hay una API de administrador para borrar imágenes locales/remotas antiguas. En esta situación, probablemente esa API sea la adecuada.
      https://matrix-org.github.io/synapse/v1.85/admin_api/media_a...
      Mi servidor no está federado, pero es bastante activo y lo trato como un espacio temporal. Lo tengo configurado para que tanto texto como medios de más de 1 o 2 semanas se recuperen automáticamente.
    • Lo que ocupa espacio son los datos de estado de las salas/conversaciones, y se pueden comprimir.
      https://levans.fr/shrink-synapse-database.html
      https://github.com/matrix-org/rust-synapse-compress-state
    • Este tipo de cosas hace que valore más a XMPP. No existe la expectativa de tener que replicar todo el historial de una sala de chat.
      En muchos MUC, el valor predeterminado son los últimos 20 mensajes, lo que normalmente basta para entender el flujo de la conversación y sumarse. El costo de operar mi servidor también fue bastante bajo.
  • Me pregunto si hay alguna forma de migrar de Synapse a Conduit. Es difícil justificar perder 6 años de historial de conversaciones.

    • Todavía no. Hay planes para una herramienta de migración de Synapse a Dendrite, pero el soporte para Conduit tendría que añadirse por separado.
      En cualquier caso, no se sabe cuánto tardará.
      Lo único que encontré es el issue de seguimiento para la migración Synapse -> Dendrite.
      https://github.com/matrix-org/dendrite/issues/1705
  • Artículo relacionado: Conduit Beta – Matrix chat server - https://news.ycombinator.com/item?id=28385840 - septiembre de 2021, 69 comentarios

  • ¿Alguien puede explicar por qué usar Matrix si existe XMPP?

    • Mi primera impresión fue que la pregunta debería ser al revés. Como no sé bien por qué habría que usar XMPP, voy a decir qué me parece bueno de Matrix.
      Es una solución de chat moderna con las funciones que la gente espera de Slack y Discord, y tiene muchos bridges que evitan tener que usar varios clientes de chat para distintos protocolos.
      Hay muchas comunidades excelentes, el chat de voz también es bastante bueno, es open source y se puede autohospedar. Me da curiosidad qué tiene de bueno XMPP.
    • Matrix se parece más a chatear con Git: usa una base de datos distribuida y tiene un carácter más marcado de mensajero de equipo, como Mattermost o Zulip.
      XMPP, por su estructura, se parece más al correo electrónico, con opciones como presencia en línea, “está escribiendo” y última conexión; incluso grandes servicios de mensajería como WhatsApp suelen usar sus propias variantes.
      XMPP es el único sistema que puede usarse, y está bien usar, en cualquier lugar donde se use correo electrónico. Es tan moderno como Matrix, solo que piensa distinto sobre el almacenamiento y la distribución de datos.
      Comparación: https://www.freie-messenger.de/en/systemvergleich/xmpp-matri...
    • Este resumen sigue siendo válido: https://news.ycombinator.com/item?id=8998290
      XMPP es excelente para el propósito para el que fue diseñado, pero no encaja bien en móviles ni en conexiones con alta pérdida de paquetes o alta latencia. Es verboso y consume mucho ancho de banda, así que no es bueno en entornos con datos y batería limitados, y originalmente tampoco contemplaba la realidad de que una persona use varios dispositivos.
      La transferencia de archivos también fue mala durante mucho tiempo, y había una mezcla de métodos incompatibles según el cliente y la topología de la red.
      Que haya demasiados XEP tampoco ayuda al ecosistema. Cuando hay demasiadas extensiones opcionales, cae la interoperabilidad. Las funciones que se esperan de un chat moderno exceden el alcance para el que XMPP fue diseñado, y aunque los XEP intentaron parchearlo, los resultados fueron dispares.
      En su momento fue una elección técnica natural, pero hoy hay muchas opciones mejores. Los desarrolladores suelen elegir tecnologías que hacen más agradable el trabajo, por eso se mueve más actividad hacia plataformas nuevas. Por ejemplo, hoy mismo otro post de HN hablaba de que un parser XML común podría no ser suficiente y que se necesita un parser XML muy avanzado: https://news.ycombinator.com/item?id=36930196
    • XMPP tiene un mínimo común denominador, y buena parte de sus funciones clave están bajo XEP opcionales. Por eso la experiencia de usuario varía muchísimo según el cliente y el servidor.
      Matrix tiene un conjunto de funciones importantes más claro, así que con un cliente compatible se puede esperar una implementación uniforme y sin sorpresas.
    • Matrix se parece más a un servicio de sincronización de estado que a una forma de enviar mensajes.
      Cuando entras a una sala de otro servidor Matrix, tu servidor empieza a mantener una copia de ese servidor, y tú puedes usarla como quieras. Si apagas tu servidor por un día y luego lo vuelves a encender, se resincroniza.
      No sé si XMPP funciona así, pero siempre lo pensé más como enviar mensajes al estilo del correo electrónico, con algunos reintentos. Tampoco sé bien cómo funcionan entre servidores el estado actual, las confirmaciones de lectura o información transitoria como “está escribiendo”.
  • Conduit es un proyecto muy genial, pero parece difícil seguir su estado y progreso si no lees todos los commits e issues.
    Es prometedor que la función integrada de Sliding Sync haya avanzado recientemente, porque facilitará mucho el despliegue.

  • ¿Alguien sabe por qué en Matrix a veces el último mensaje no se descifra hasta que se envía un nuevo último mensaje, o por qué los mensajes alrededor se descifran pero un único mensaje da error de descifrado?

    • Todavía no lo entiendo a la perfección, pero no todos los mensajes se cifran con la misma clave.
      Si no todos mis clientes están conectados al mismo tiempo, y al emisor le pasa lo mismo, no pueden intercambiar claves entre sí. Entonces cada cliente solo puede descifrar la parte de los mensajes para la que tiene claves. Además, los clientes solo intercambian claves con otros clientes verificados.
      Si miras la propiedad session_id del JSON original del mensaje, puedes ver que los mensajes de una sesión específica, es decir, mientras el emisor estuvo conectado en un cliente, se descifran todos o no se descifra ninguno. Lo primero significa que tienes la clave de esa sesión; lo segundo, que todavía no la recibiste.
  • Puede que se me esté escapando algo, pero la página es demasiado simple y parece asumir que uno ya sabe qué es Matrix y cómo usar esto.
    Dedica mucho tiempo a varias formas de instalación, pero no veo cómo usar el servidor en sí, como el uso de clientes.

    • El primer enlace de la página va a matrix.org, y matrix.org tiene enlaces a clientes: https://matrix.org/ecosystem/clients/
      Probablemente baste con usar Element.
      Me parece que la página de Conduit lo está haciendo bien. Más que asumir que ya sabes qué es Matrix, asume que, si no lo sabes, tienes la comprensión suficiente para hacer clic en el enlace.
    • Si estás familiarizado con Matrix.org, la landing page es bastante buena. Parece dirigida a desarrolladores de Matrix.
      Personalmente me gustó que sea breve, que muestre de forma simple el problema que intenta resolver y que aparezca rápido el enlace al repositorio Git, que es el verdadero llamado a la acción.
      También puede ser que la landing page en sí se haya actualizado con contenido nuevo después del post original.
    • ¿Cambió el enlace?
      Matrix es una red abierta para comunicaciones seguras y descentralizadas. Los usuarios de cualquier homeserver de Matrix pueden chatear con usuarios de cualquier otro servidor Matrix. También pueden comunicarse mediante bridges con usuarios fuera de Matrix, como comunidades de Discord.
      Y no veo información de instalación.
    • Matrix es un protocolo de chat. Funciona como chatear usando Git y usa una base de datos distribuida; se parece más a mensajeros de equipo como Mattermost o Zulip.
      Conduit es software de servidor, no una app para usuarios finales.
      Más información sobre Matrix: https://www.freie-messenger.de/en/matrix
  • Me da curiosidad cuál es la relación de Conduit con Synapse.
    Dendrite se prueba con https://github.com/matrix-org/sytest y hasta hay issues del tipo “¿ya es Synapse?”, pero no encuentro discusiones relacionadas en Conduit. Ni siquiera veo una discusión sobre por qué no querrían volverse como Synapse.

    • Conduit es una implementación de terceros de la especificación de servidores Matrix escrita en Rust. Synapse y Dendrite son implementaciones oficiales, y Dendrite empezó originalmente con el objetivo de reemplazar a Synapse.
      Lo que presenta como ventajas es que es liviano y fácil de instalar, lo que implica que Synapse no lo es. Más importante aún, sirvió como caso de validación de la especificación de servidores Matrix y, durante años, contribuyó bastante a aclarar partes ambiguas.
    • SyTest está adaptado principalmente para usarse con Synapse, y parece que del lado de Dendrite están trabajando en envolverlo para integrarlo a su propia integración continua.
      Conduit podría reutilizar parte de ese trabajo, pero, si mal no recuerdo, Conduit usa GitLab y Dendrite usa GitHub Actions.
      Por separado, por ahora Conduit no parece apuntar a ser un reemplazo drop-in de Synapse. La última vez que lo vi en una sala de Matrix, todavía había varios huecos de funcionalidad notorios.