Chatto ahora es de código abierto

Artículo original ↗ Discusión en Hacker News ↗

Una plataforma de chat grupal de código abierto llamada Chatto está llamando la atención como alternativa autoalojable a Slack, Teams, Discord y herramientas similares, con elogios por su interfaz PWA rápida y pulida, su despliegue sencillo (un único binario en Go más NATS) y su autoalojamiento sin restricciones bajo licencias AGPL/Apache. Los comentaristas la comparan con Matrix, Mattermost, Zulip, Fluxer y otras, sopesando compromisos como la ausencia de clientes móviles/nativos, la falta de cifrado de extremo a extremo para texto, las necesidades de SSO y retención en entornos empresariales, y el problema persistente de los efectos de red y la interoperabilidad. Un hilo destacado cuestiona la ética y la sostenibilidad de usar “agentic coding” asistido por IA para construir estos proyectos, reflejando una inquietud más amplia sobre el impacto de la IA incluso cuando algunos la ven como una vía para habilitar un desarrollo en solitario de alta calidad.

Posicionamiento y objetivos

  • Se presenta como una alternativa a Slack/Teams/Mattermost, con una sensación similar a Discord.
  • Aspira a ser agradable de usar, autoalojable y no “open-core” recortado; todas las funciones están disponibles al autoalojarlo.
  • Se centra en servidores de un solo tenant, por comunidad, en lugar de grandes mega-instances federadas.

UX, rendimiento y diseño

  • Varios evaluadores elogian que es muy rápido y ágil en comparación con Slack, clientes de Matrix y otros.
  • El diseño y la UX se perciben como inusualmente pulidos para una app de chat de código abierto.
  • Algunos lo critican por parecerse visualmente a Slack/Discord y cuestionan si resuelve los problemas de ruido/complejidad.

Arquitectura y despliegue

  • Backend en Go, frontend en Svelte; se distribuye como un binario compacto y autocontenido.
  • Usa NATS con JetStream para mensajería y persistencia; algunos desarrolladores comparten experiencias positivas con NATS a gran escala.
  • Usa LiveKit para voz/vídeo.
  • Se informa que el autoalojamiento es sencillo; se proporcionan ejemplos para almacenamiento compatible con S3 y otros componentes.
  • Uso de recursos: decenas de MB para una instancia nueva; se reportan ~10MB de RAM por cada usuario adicional conectado, con margen para optimización.

Licencia y modelo de negocio

  • El backend es AGPL; el frontend es Apache 2.0.
  • La justificación: AGPL desincentiva clones alojados propietarios y, al mismo tiempo, mantiene la UI personalizable y apta para empresas.
  • Está previsto un alojamiento comercial “Chatto Cloud”, pero el autoalojamiento no tiene restricciones.

Clientes: PWA, escritorio, móvil

  • La experiencia PWA de primera clase es el foco actual, incluidas las notificaciones push y la voz/vídeo en móvil.
  • Aún no hay apps nativas oficiales; existe un wrapper comunitario con Tauri, considerado listo para escritorio pero no para móvil.
  • Push en iOS por ahora mediante PWA/Web Push; se planean apps nativas con APNS/FCM, pero no a corto plazo.

Seguridad, privacidad y cifrado

  • Los chats están cifrados en reposo; la mensajería central no está cifrada de extremo a extremo.
  • Algunos consideran aceptable la falta de E2EE para entornos autoalojados y controlados; otros quieren E2EE para chat grupal.
  • Las claves por usuario y la semántica de eliminación de cuentas plantean dudas sobre retención legal y borrado suave para uso empresarial.

Interoperabilidad y efectos de red

  • No hay federación ni compatibilidad con Matrix/XMPP; es una decisión deliberada para mantener el sistema simple y apto para empresas.
  • Algunos sostienen que esto perjudica la adopción debido a los fuertes efectos de red de Slack/Discord; otros dicen que las comunidades privadas no necesitan federación.
  • Se está explorando una federación ligera de identidad entre servidores Chatto.

Debate sobre desarrollo asistido por IA

  • Según informes, el proyecto utilizó “agentic coding”/asistencia de IA.
  • Algunos quedan impresionados por la productividad de un desarrollador en solitario; otros se oponen firmemente por motivos éticos y medioambientales y dicen que evitarán el proyecto.
  • Los contraargumentos señalan modelos de pesos abiertos, reutilización histórica de IP y mejoras personales de productividad; el desacuerdo sigue sin resolverse.

Comparaciones y alternativas

  • Se compara con frecuencia con Mattermost, Matrix, Zulip, Rocket.Chat, Fluxer y Discord.
  • Ventajas mencionadas: configuración más simple que Mattermost, más pulido y rápido que muchos clientes de Matrix, licencia clara, SSO incluido sin sobreprecio empresarial.
  • Desventajas/no está claro: no hay E2EE para los chats; no hay migración/interoperabilidad más allá de una herramienta de importación de Slack; falta de clientes móviles nativos; no hay tablas claras de comparación de funciones.

Preocupaciones de adopción y deseos

  • Se pide: apps nativas móviles/escritorio, migración desde Slack y sincronización continua, salas públicas de solo lectura, importación/exportación, salas de voz integrables, autoactualizaciones, guía de dimensionamiento de recursos y mejor onboarding para nuevos servidores.
  • Algunos usuarios están listos para dejar Slack/Mattermost en cuanto haya clientes nativos y un onboarding más fluido.