Matrix es un estándar, no un producto. Todo lo que lo rodea es trabajo y es lo que hacemos.

00

Qué es Matrix y las tres formas de tenerlo.

Una dirección Matrix funciona como una de correo. Después se elige quién tiene la máquina.

Matrix es un estándar abierto de comunicación en tiempo real. La cuenta está en un servidor, la dirección es @you:example.com y las personas de distintos servidores se comunican como por correo. No necesitan la misma plataforma y ninguna empresa ocupa el centro de la red.

Queda la decisión importante: quién tiene el servidor. Cliente, puentes e identidad pueden cambiar después sin cambiar las direcciones.

Tres formas de tener un homeserver, distintas por quién posee la máquina y se despierta si falla, no por funciones.

Si esto es nuevo

• Qué es un homeserver y qué no
• Por qué la dirección lleva su dominio y cuánto vale
• Federación sencilla: abierta, limitada a socios identificados o cerrada
• Cifrado de extremo a extremo y lo que aún ve el servidor
• Qué pueden y no pueden transportar los puentes con otras redes
• Coste de operación en máquinas y atención
• Qué cambia para quienes lo usan diariamente
• Cómo sería un primer mes realista

Las tres formas de tenerlo y qué sigue

• Tras el pedido: acordamos dominio, paga la factura de configuración y empieza el desarrollo
• Un servidor operativo, reforzado y con copias de seguridad, en los plazos acordados en el alcance escrito del trabajo
• Después grupo piloto, todos y entrega; nada se traslada de golpe
• En nuestra infraestructura: dedicado, en la UE, actualizado y supervisado
• En su hardware o cuenta de nube: instalado, protegido y mantenido por nosotros
• Enteramente por su cuenta: diseño, desarrollo y entrega; luego lo opera usted
• Cualquiera puede convertirse en otra; dirección y datos se trasladan
• Sin alojamiento compartido, licencia por usuario ni dependencia de un cliente
• La salida se diseña al principio, no se improvisa al final

No se incluye: cuentas en un servidor público abierto al registro. Cada despliegue pertenece a una organización.

01

Despliegue, operación y escala.

Homeserver con inicio limpio, crecimiento planificado y reconstruible.

Matrix es un protocolo, no un paquete. Desplegar exige decidir servidor, base de datos, ubicación de medios y delegación del dominio.

Trabajamos con las implementaciones del ecosistema y admitimos gestión de configuración, contenedores u operador Kubernetes. La configuración sigue versionada para reconstruir, no recordar.

Crecer es distinto de instalar. Separar funciones, controlar estado de salas y probar tráfico realista se hace antes de que llegue la carga.

Instalar y configurar

• Revisión del servidor: Synapse casi siempre; implementaciones ligeras cuando la carga realmente las exija
• Requisitos claros para su hardware: máquina x86-64, Debian o Ubuntu actual, salida sin restricciones y dominio suyo o subdominio gratuito nuestro
• Instalación nueva con terminación TLS, proxy inverso y valores seguros
• Nombre y delegación mediante archivos well-known y registros de servicio
• Gestión de configuración para versionar y revisar todo el despliegue
• Despliegue en contenedores mediante charts u operador
• Aprovisionamiento, ajuste y agrupación de conexiones de base de datos
• Repositorio de medios en disco local u objetos
• Pasarela push, incluida una dedicada a una app móvil de marca
• Política de registro: invitaciones, tokens, aprobación o captcha
• Instalación aislada y sin conexión para redes sin acceso de salida
• Topologías multidominio y multiinquilino
• Pruebas que reflejan producción para ensayar actualizaciones

Escalar

• Arquitectura de procesos de trabajo con solicitudes separadas por función
• Separación de escritura de flujos y persistencia de eventos para mucha escritura
• Replicación y coordinación de caché entre procesos
• Reglas del equilibrador acordes con el enrutamiento del homeserver
• Control del crecimiento y compresión del estado de salas
• Descarga de medios a objetos y capa de distribución
• Escalado de emisores de federación y gestión de colas de salida
• Política de escalado automático en contenedores
• Pruebas con tráfico realista, no casos óptimos sintéticos
• Análisis de ubicación multirregión y en el perímetro
• Rendimiento de salas y espacios grandes
• Cambio de implementación del servidor cuando lo exija la carga

No se incluyen guardias. Los plazos de respuesta figuran en los niveles de soporte en /matrix/G. La infraestructura sigue siendo suya o de su proveedor.

02

Migración, traslado y portabilidad.

Entrar sin perder el hilo. Salir sin pagar por marcharse.

La mayoría de los proyectos de Matrix empieza en otra parte: una plataforma alojada para equipos, un servidor de chat que nadie actualiza, un homeserver público que solo era una prueba.

Se migra por etapas. Un puente mantiene activos ambos sistemas mientras se trasladan los usuarios; el cambio es gradual, no brusco.

La portabilidad funciona igual al revés. Aquí la propiedad son niveles de permisos, no una licencia; la salida se diseña al inicio.

Entrar

• Migración desde plataformas alojadas, servidores comunitarios, IRC o XMPP
• Importación del historial conservando autores, fechas y adjuntos
• Mapeo entre su directorio e identificadores Matrix
• Migración de base integrada a motor de producción
• Migración de medios a objetos o capa de distribución
• Pasar de contraseña integrada a servicio de autenticación dedicado
• Cambio gradual con ambos sistemas conectados y activos
• Reversión y contingencias planificadas para cada etapa

Trasladar, salir, repetir

• Traslado del homeserver a otro hardware, región o proveedor
• Cambio de nombre del servidor y estrategia de delegación
• Cambio de implementación según el modelo operativo
• Actualización de versiones de salas en todos los sistemas
• Exportación, archivo y retirada de la plataforma anterior
• Distribución interna para que los equipos desplieguen servidores conformes
• Arquitectura de referencia y configuración modelo para despliegues repetidos
• Altas y bajas de inquilinos al alojar para otros
• Paquetes de artefactos sin conexión y repositorios espejo privados para redes restringidas

Diagrama

Ocho decisiones que determinan un despliegue Matrix institucional. Cada una deliberada, no heredada de un valor predeterminado.

00 El registro

• Qué abarca: despliegue, protección, acceso único, federación, moderación, llamadas y documentación solicitada a una institución. Cada ajuste es una decisión y cada decisión se escribe.
• Qué se escribe: documentación, diagramas y registros de decisiones arquitectónicas; además, documentación completa de protección de datos: evaluación de impacto, registro de tratamiento, política de supresión y procedimiento de violaciones.
• Operación: revisión de configuración, planificación de recuperación y pruebas de restauración de bases de datos en un entorno aislado.
• Temas: soberanía y privacidad, autoalojamiento, contenedores, protección y conservación de datos, acceso único, marca, bots y widgets, integración de soporte, federación selectiva, moderación y cumplimiento, operaciones y observabilidad, adopción y recomendaciones.
• Las casillas marcadas acompañan este mensaje.

01 Alojamiento

¿Dónde está realmente el homeserver?

• A. Nube gestionada
• + Activo el día del registro, sin contratar a nadie
• + Adecuado para equipos pequeños sin operador de servidor
• - Asume la conservación, los límites y la ubicación del proveedor
• - Las actualizaciones siguen su calendario, no el suyo
• B. Servidor dedicado
• + Base de datos, medios y registros en hardware identificable
• + Usted fija conservación, límites de carga y protección
• - Alguien debe actualizarlo, supervisarlo y responder por él
• - Una mala configuración es su caída, no una página de estado

Homeserver, cliente, proveedor de identidad, base de datos y proxy inverso en contenedores sobre hardware controlado por la institución.

02 Federación

¿Quién puede acceder a sus salas?

• A. Federación abierta
• + Toda la red Matrix desde el primer día
• + Adecuado para grupos de investigación con colaboradores externos
• - Debe moderar toda la red antes de tener una política
• - Lo enviado por federación no puede recuperarse
• B. Federación por lista de permitidos
• + Puerto de federación cerrado hasta que decida abrirlo
• + Servidores asociados admitidos por nombre, uno a uno
• - Lo ajeno a la lista es inaccesible, incluso lo deseado
• - Cada nuevo socio exige una decisión

Puede empezar cerrado: puerto de federación cerrado, lista explícita de servidores y moderación antes de admitir el primer servidor externo.

03 Identidad

¿Cómo accede una persona?

• A. Cuentas locales
• + El acceso funciona aunque nada más esté activo
• + Adecuado para un piloto de veinte personas sin directorio
• - Registro, restablecer contraseñas y bajas forman una cola de soporte
• - Quien se marcha conserva acceso hasta que alguien lo recuerde
• B. Acceso único
• + Una identidad institucional cuyo ciclo de vida ya se gestiona fuera
• + Filtrar por dominio de correo decide quién puede registrarse
• - El proveedor de identidad es otro sistema que operar
• - Una mala configuración bloquea el acceso de todos

Integración del proveedor de identidad, separación de ámbitos, filtrado por dominio de correo y configuración de la base de datos.

04 Cifrado

¿Qué salas tienen cifrado de extremo a extremo?

• A. Todas las salas
• + El operador no puede leer nada, tampoco nosotros
• + Adecuado cuando el alojamiento forma parte del modelo de amenazas
• - Búsqueda, bots, widgets y revisión de cumplimiento pierden acceso
• - Puentes y cifrado de extremo a extremo no se combinan fácilmente
• B. Distinto por sala
• + Cifrado donde el contenido lo exige; salas sin cifrar donde no
• + Búsqueda, bots y archivo funcionan donde se necesitan
• - Alguien debe escribir la regla y defenderla
• - Clasificar mal es un error silencioso

Acordamos el cifrado por sala y documentamos sus efectos sobre puentes, moderación, búsquedas y archivo.

05 Conservación

¿Cuánto tiempo permanece todo?

• A. Conservar todo
• + Nada se pierde y nadie debe decidir
• + Adecuado donde la ley exige conservación indefinida
• - Predeterminado en muchos despliegues, sin elección de nadie
• - Cada mensaje sin borrar sigue siendo su responsabilidad
• B. Política de conservación del servidor
• + Mensajes y medios locales caducan según un calendario declarado
• + Medios de otros servidores en caché, no archivados
• - Lo caducado caducó; no hay deshacer
• - El calendario debe acordarse antes de configurarse

Un período para mensajes y medios locales; otro menor para medios externos. Ambos se configuran y documentan.

06 Moderación

¿Qué ocurre cuando algo falla en una sala?

• A. A mano
• + Sin mecanismos adicionales: un administrador lee y actúa
• + Adecuado para una sala con quince compañeros
• - Se responde cuando alguien está despierto
• - Lo aprendido en una sala no protege otra
• B. Aplicación de políticas
• + Una sala de políticas aplica sus bloqueos a todas las salas protegidas
• + Las salas nuevas heredan protección sin configurarla
• - Una política mala se propaga tan rápido como una buena
• - Alguien debe seguir siendo responsable de la lista

Un bot de moderación aplica políticas en los sistemas, junto a un entorno de plugins para las tareas diarias.

07 Reuniones

¿Dónde ocurre la llamada?

• A. Enlace externo
• + Lo que la institución ya licenció y aprobó
• + Adecuado si el ciclo de compras cerró el año pasado
• - Otro producto, acceso y revisión de privacidad
• - Chat, llamada y notas en tres lugares distintos
• B. Dentro de la sala
• + La llamada empieza donde ya están las personas correctas
• + Los widgets mantienen reunión y conversación juntas
• - Más operación: servidores de medios, TURN y señalización
• - El soporte de llamadas en sala aún varía entre clientes

OpenTalk, Jitsi con Prosody, Jicofo, JVB y coturn, y LiveKit para Matrix-RTC, como widgets dentro de salas.

08 Interfaces administrativas

¿Quién accede al plano de control?

• A. Puntos de acceso públicos
• + Acceso desde cualquier dispositivo sin distribuir túneles
• + Un sistema menos que operar para equipos pequeños
• - Cualquiera que adivine el nombre llega al acceso
• - La API administrativa es un objetivo valioso en un puerto público
• B. Restringido por red
• + Interfaces administrativas responden a dirección de origen, no nombre
• + No hay acceso que atacar porque no hay ruta
• - Necesita un túnel activo antes de reparar nada
• - Si se bloquea, recupera mediante consola

Interfaces administrativas tras WireGuard, por IP de origen, no DNS. Medios autenticados, push sin contenido, límites de carga, eliminación de dispositivos obsoletos y duración limitada de tokens de renovación se configuran explícitamente.

09 Enviar la ruta

Diga en qué columna está y qué intenta operar. Las ocho selecciones acompañan el mensaje.

• Salas, personas, plazo. Lo que ya sepa.
• Sin seguimiento ni solicitudes a terceros. Nada se transmite desde aquí: ruta y mensaje forman un borrador en su correo y no se envían hasta que usted lo haga.

No se incluye: garantizar lo que otro proveedor le entregará. La calidad de exportación la decide él.

03

Federación, puentes y descubrimiento.

Llegar a otras organizaciones y redes con condiciones explícitas.

La federación no puede copiarse en plataformas cerradas. Organizaciones distintas mantienen servidores separados y comparten salas.

Requiere política escrita. Abierta, por lista, solo socios o cerrada son opciones válidas; cada una cambia la supervisión necesaria.

Los puentes extienden la idea más allá del protocolo: conectan a quienes no migran y dan tiempo a quienes sí.

Política de federación

• Modelo: abierto, por lista de permitidos, solo socios o cerrado
• Listas de permitidos y bloqueados con revisión al añadir socios
• Listas de control de acceso de servidores por sala
• Delegación well-known, descubrimiento y estrategia de certificados
• Gestión y renovación de claves de firma y configuración de notarios
• Diagnóstico de resolución de estado, eventos ausentes, lagunas de historial y tráfico bloqueado
• Procedimientos de incorporación de socios a salas compartidas
• Diseños de transferencia entre dominios y unidireccional para redes segmentadas
• Servidores de políticas y suscripciones compartidas a listas entre socios
• Procedimiento de retirada de federación para socios eliminados

Puentes y búsqueda

• Arquitectura de puentes: redes y modelo de salas
• Puentes a WhatsApp, Telegram, Signal, Discord, Slack, Google Chat, Google Messages, Instagram, Facebook Messenger, LinkedIn, Bluesky, Steam, IRC y correo
• Usted elige cuáles tendrá: cada uno exige operación, supervisión y reparaciones ocasionales; ninguno se activa por defecto
• Mapeo de identidad para atribuir mensajes al autor correcto
• Retransmisión para participantes remotos sin cuenta Matrix
• Configuración de puentes cifrados
• Puentes a medida con la API de servicios de aplicación para sistemas internos
• Supervisión, retirada y tratamiento de datos al cerrar puentes
• Publicación del directorio de salas y alcance del descubrimiento
• Alias y enlaces permanentes con direcciones estables para salas duraderas
• Jerarquía de espacios para orientarse sin explicaciones

No se incluye: control del otro lado. El puente depende de la API y las condiciones de la otra red.

04

Acceso, cuentas e integración del directorio.

Una cuenta, un directorio y una vía de entrada.

Las contraseñas locales no bastan para una organización. Matrix usa OAuth y OpenID Connect mediante autenticación dedicada para integrar el acceso con el existente.

Lo importante es el ciclo de vida: altas, traslados y bajas deben recibir y perder las salas correctas sin solicitudes manuales.

Acceder

• Autenticación delegada mediante servicio de autenticación Matrix
• Integración del proveedor de identidad con directorios e intermediarios
• Migración de contraseñas integradas a acceso delegado
• Multifactor y acceso condicional impuestos por el proveedor de identidad
• Intercambio de tokens de identidad firmados para widgets y servicios
• Fijación de certificados y gestión de dispositivos en flotas de clientes
• Invitados e invitación por correo o teléfono cuando corresponda

Cuentas a lo largo del tiempo

• Altas y bajas desde el directorio corporativo
• Altas, traslados y bajas mapeados a cuentas, salas y espacios
• Política de identificadores: partes locales, nombres, avatares y direcciones personalizadas
• Vinculación y conciliación de identificadores externos
• Alcance del directorio para buscar solo lo permitido
• Procedimientos de desactivación, cambio de nombre y reactivación
• Gestión de sesiones, duración de tokens y cierre forzado

No se incluye: operar su proveedor de identidad. El trabajo termina en integración y mapeo.

05

Claves, dispositivos y recuperación.

Cifrado del que los usuarios pueden recuperarse.

El cifrado es la parte fácil. Lo difícil es perder el teléfono, borrar el portátil o incorporarse años después al chat.

Firma cruzada, copias de claves y almacenamiento de secretos hacen operable el cifrado. Cada uno cambia lo visible para búsqueda, exportación y archivo.

Los límites se escriben, no se disimulan.

Activarlo

• Cifrado predeterminado para salas nuevas con excepciones identificadas
• Firma cruzada y verificación de dispositivos con emoji y escaneo de códigos
• Copias de claves y secretos en servidor con gestión de clave de recuperación
• Migración de clientes y SDK al conjunto criptográfico actual
• Bots, puentes y servicios operativos en salas cifradas
• Renovación de claves de sala y sus costes en otras funciones

Usarlo diariamente

• Ciclo de dispositivos y sesiones con revocación de perdidos o retirados
• Visibilidad de historial y compartición de claves según lo que deba revelar una incorporación
• Efecto real del cifrado sobre búsqueda, exportación y archivo
• Análisis de contenido y antivirus donde lo permita el cifrado
• Documentación de custodia y recuperación de claves
• Guía para usar verificación y recuperación como se diseñaron

Diagrama

01 - 06 · De fuera hacia dentro

01 Perímetro

WireGuard, puertos cerrados y sin ruta desde DNS

La administración no está en la web pública. Solo responde mediante túnel WireGuard a una dirección de origen permitida, nunca a un nombre de host.

• El puerto de federación sigue cerrado hasta decidir abrirlo.
• nginx termina el lado público; lo situado detrás se alcanza dentro del túnel.
• Nada del despliegue se encuentra resolviendo DNS.

wireguard · nginx · acl de dirección de origen · puerto de federación cerrado

02 Federación

Primero lista de permitidos; abrir con moderación lista

Configuramos la federación según la política de la organización: cerrada, con lista de permitidos o abierta.

• Se abre tras preparar la moderación, nunca antes.
• La lista registra con quién acordó comunicarse la organización.
• La federación selectiva se decide y escribe antes de activarla.

synapse · política de federación · lista de servidores permitidos

03 Identidad

Acceso único, ámbitos separados y filtro de dominio de correo

El acceso único usa un proveedor como Keycloak con ámbitos separados y filtro de dominio; las cuentas siguen el directorio institucional, no otro privado.

• La integración del proveedor de identidad y la configuración de la base de datos siguen los requisitos de la organización.
• Tokens de renovación con duración limitada y retirada automática de dispositivos obsoletos.
• La marca forma parte del acceso, no se añade después.

keycloak · ámbitos separados · postgresql · element web

04 Gobernanza

Aplicación de políticas y automatización diaria

La moderación se prepara antes de abrir el espacio. Un bot aplica políticas en los sistemas y los plugins llevan las tareas rutinarias.

• Espacios de estudiantes y personal tienen reglas distintas en el mismo servidor.
• Bots y widgets gestionan rutas, recordatorios y entrega al soporte existente.
• Revisamos la configuración y documentamos los procedimientos de recuperación.

bot de moderación · automatización por plugins · listas de políticas · integración de soporte

05 Datos

Conservación en servidor y su documentación

El servidor fija un período para mensajes y medios locales, y otro menor para medios de otros servidores.

• Medios solo para solicitudes autenticadas, push sin contenido y tamaño de carga limitado.
• Preparamos evaluaciones de impacto, registros de tratamiento, procedimientos de eliminación y procedimientos ante brechas de datos.
• Documentación, diagramas y decisiones arquitectónicas explican cada ajuste.

conservación synapse · postgresql · medios autenticados · push sin contenido

06 La sala

Cifrado donde se justifica

Acordamos el cifrado por sala según los requisitos de moderación, búsqueda y conservación de la organización.

• Cifrar cambia moderación, búsqueda, bots y widgets. Activarlo en todo deshabilitaría silenciosamente las cinco capas circundantes.
• Documentamos cómo afectan los puentes al cifrado antes de integrarlos.
• Llamadas dentro de la sala: OpenTalk, Jitsi y LiveKit para Matrix-RTC, autoalojados como widgets.

element web · livekit (matrix-rtc) · opentalk · jitsi: prosody / jicofo / jvb / coturn

No se incluye: leer historial cifrado sin claves. Nadie puede ofrecerlo; si lo hace, es una señal de alarma.

06

Clientes elegidos, adaptados o construidos.

El cliente se elige. El servidor no decide lo que ve la gente cada día.

Matrix separa servidor y aplicación. La interfaz se decide aparte y puede cambiar sin tocar el despliegue. Hay varios clientes maduros, distintos más por experiencia que por capacidad.

Es más fácil elegir por público: quienes vienen de chat de equipo quieren familiaridad; de plataformas comunitarias, canales e hilos; los administradores, una app de escritorio ligera que no dificulte su trabajo.

Después vienen temas, paquetes y gestión de flota: colores y nombre, distribución por sus canales y política de aplicaciones admitidas.

Elegir y desplegar

• Element Web y Desktop para quienes vienen de chat de equipo
• Element X para quienes usan el teléfono y quieren rapidez
• FluffyChat para sencillez y escuelas
• Cinny para quienes esperan canales de una plataforma comunitaria
• Nheko para administradores y quienes quieren una app nativa ligera
• Elegido por sus usuarios, no por tablas de funciones
• Cliente web en su dominio, no una dirección externa
• Paquetes de escritorio para Windows, macOS y Linux
• Distribución móvil mediante tiendas o canal interno
• Notificaciones push por una pasarela bajo su control
• Acceso único conectado al cliente
• Política de flota: versiones y apps que pueden conectarse
• Migración entre clientes sin perder historial ni claves

Hacerlo suyo

• Temas: colores, nombre, icono, textos y primer inicio
• Compilación de marca publicada desde su cuenta de desarrollador
• Retirada de funciones cuando interesa tener menos
• Widgets con sus herramientas dentro de la sala
• Trabajo a medida con los SDK cliente publicados
• Revisión de accesibilidad del cliente que entrega
• La selección, personalización e integración del cliente se acuerdan en el alcance del trabajo.

Seleccionamos y personalizamos un cliente Matrix existente para su organización.

07

Clientes, bots, widgets, llamadas y SDK.

La sala es una superficie. Ponga el trabajo en ella.

Matrix publica API de servicios de aplicación, API de widgets y SDK en la mayoría de lenguajes usados. La sala puede formar parte del proceso, no solo servir para comentarlo.

El trabajo cliente va del tema a una app específica: quiosco, sala única, pantalla de lectura, poco ancho de banda o mensajería integrada en su software.

Las llamadas también requieren unidad de reenvío, credenciales y reglas de cortafuegos, no solo un botón.

Clientes y código

• Evaluación de clientes web, escritorio, móvil y terminal
• Compilaciones de marca: nombre, icono, colores, tienda, firma y publicación
• Clientes a medida con SDK Rust, JavaScript, Kotlin, Swift, Dart o .NET
• Clientes específicos: quiosco, sala única, lectura, campo y poco ancho de banda
• Mensajería Matrix integrada en una aplicación suya
• Accesibilidad y localización, incluidas disposiciones de derecha a izquierda
• Servicios de aplicación, eventos y estado personalizados para datos del ámbito en la sala
• Módulos homeserver: antispam, reglas externas y autenticación personalizada
• Pruebas de conformidad e interoperabilidad entre clientes y servidores

Bots, widgets y llamadas

• Plataforma de bots con plugins para compartir un entorno de ejecución
• Bots para soporte, alertas, fuentes, aprobaciones y mantenimiento
• Pasarelas de correo a sala y de sala a correo
• Widgets: pizarras, encuestas, reuniones, paneles, formularios y aprobaciones
• Autenticación de widgets con tokens firmados, alojamiento y alcance de permisos
• Conferencias independientes o integradas
• Unidad de reenvío desplegada y escalada para evitar una malla entre participantes
• Servidores de retransmisión y travesía, cortafuegos y traducción de direcciones
• Notificaciones móviles de llamada que suenan con el dispositivo bloqueado
• Grabación, conservación y consentimiento donde lo exija la normativa

No se incluye: los widgets no pertenecen al núcleo de la especificación. Conviene saberlo antes de basar un plan en ellos.

08

Moderación, conservación y documentación de protección de datos.

Política que resiste cuando alguien pide verla.

La moderación es trabajo de protocolo: niveles de permisos, listas, control de salas e informes. Las herramientas son abiertas; suele faltar la política que las sustenta.

Un sistema federado, replicado y cifrado necesita registros de tratamiento, reglas de conservación y descripción honesta del alcance real de la supresión.

Moderación

• Herramientas de moderación con bot dotado de la autoridad necesaria
• Listas de políticas: locales, suscripciones compartidas y listas publicadas
• Protección contra avalanchas de ingresos, spam y medios no deseados
• Permisos y roles para dar a los moderadores exactamente lo necesario
• Avisos enviados a una cola de evaluación con responsable identificado
• Bloqueos de servidor, listas de acceso de sala y cuarentena
• Análisis de contenido y comparación de hashes al cargar
• Procedimientos de confianza y seguridad, escalado y registros de decisiones
• Informes de transparencia según el régimen aplicable

Registros y reglas

• Apoyo a la evaluación de impacto y registros de tratamiento
• Mapeo de datos en salas, medios, claves, dispositivos y tráfico federado
• Diseño de ubicación de datos y alojamiento
• Política de conservación y caducidad con aplicación técnica
• Acceso de interesados, exportación y ocultación con límites reales declarados
• Cifrado en reposo y documentación de custodia de claves
• Documentación de encargados y subencargados de cada componente
• Descripción de arquitectura de seguridad, modelo de amenazas y normas de configuración
• Políticas de uso aceptable, incorporación y salida

No se incluye: asesoramiento jurídico ni aprobación legal. Son documentos técnicos para su asesor, no su sustituto.

09

Observabilidad, mantenimiento y soporte.

Alguien debe supervisarlo un martes.

Nadie puede defender un homeserver sin supervisión. Métricas, registros y trazas convierten "el chat va lento" en un componente identificado.

Mantenimiento es la parte discreta: actualizaciones, limpieza, deriva y restauración realizada, no solo programada.

El soporte actúa detrás de su servicio de asistencia, no directamente ante sus usuarios.

Supervisarlo

• Métricas y paneles de homeserver, base de datos, puentes, medios y llamadas
• Registros estructurados y agregados conservados según política
• Trazas distribuidas para solicitudes lentas y retrasos de federación
• Alertas ligadas a procedimientos escritos, no solo umbrales
• Pruebas sintéticas de acceso, entrega, federación y llamadas
• Consola para gestión diaria de usuarios y salas
• Automatización de API administrativa para tareas repetitivas
• Informes de capacidad, crecimiento y coste del despliegue

Mantenerlo activo

• Mantenimiento gestionado: actualizaciones de sistema y componentes, limpieza rutinaria
• Seguimiento de avisos de seguridad y planificación de parches
• Seguimiento de versiones, calendario de actualización y soporte prolongado
• Revisión y corrección de deriva de configuración
• Copias configuradas y restauración ensayada, probada, no supuesta
• Mantenimiento de base de datos, medios, elementos huérfanos y cuotas
• Procedimientos de respuesta a incidentes y plantillas de revisión posterior
• Soporte de escalado detrás de su servicio de asistencia
• Comprobaciones periódicas con informe escrito

No se incluyen guardias ni tareas que requieran una segunda persona despierta. Los plazos de respuesta figuran en los niveles de soporte en /matrix/G. La operación sigue a cargo de usted o de su proveedor.

10

Revisión independiente, formación y asesoramiento.

Mirada externa a sus sistemas, formación para conservarlos y asesoramiento antes de comprometerse.

Muchos despliegues funcionan sin saber por qué. Revisar es trabajo delimitado con resultado escrito: exposición, obsolescencia y próximo fallo.

La formación es la otra mitad. El estándar abierto permite no mantener a nadie. La entrega es el resultado, no el riesgo.

A veces la respuesta útil llega antes: si este estándar cumple realmente el requisito.

Revisión independiente

• Revisión de configuración según prácticas recomendadas actuales
• Revisión de seguridad: exposición, autenticación, límites y secretos
• Federación: qué es accesible, confiable y qué no debería ser ninguna de las dos
• Cifrado: firma cruzada, copias de claves, dispositivos y salas abiertas
• Rendimiento y capacidad con cuellos de botella reales identificados
• Validación de copias que pruebe la restauración, no el calendario
• Ruta de actualización con componentes fuera de vida útil
• Inventario de puentes y bots con responsable por elemento
• Correcciones priorizadas con esfuerzo e impacto por elemento

Formación, entrega y asesoramiento

• Formación de administradores, operadores y moderadores en su despliegue
• Sesiones de desarrollo: API cliente-servidor, servicios de aplicación y widgets
• Incorporación de usuarios, hábitos de verificación y recuperación
• Material para formar a formadores y seguir sin nosotros
• Procedimientos, manuales y entrega documentada para su configuración
• Asesoramiento neutral sobre si el estándar abierto de mensajería encaja
• Construir o comprar, autoalojar o gestionar, con compromisos explícitos
• Apoyo a compras: requisitos, criterios de evaluación y preguntas
• Salida y portabilidad revisadas para conservar su capacidad de trasladarlo

Diagrama

Homeservers, clientes y acceso único desplegados y protegidos para escuelas, universidades e instituciones públicas.

01 AUDITORÍA

Etapa 01 / 09

Preguntas antes de contenedores. Sus sistemas actuales deciden casi toda la arquitectura; lo demás es política, no software.

• Identidad existente y dominios de correo admitidos para cuentas
• Qué registrar, qué nunca conservar y durante cuánto tiempo
• Con qué instituciones debe comunicarse y con cuáles no
• Si basta realmente un servidor dedicado para la carga descrita

RESULTADO: hallazgos escritos, arquitectura objetivo y alcance aprobable.

02 DISEÑO

Etapa 02 / 09

Cada decisión cara de revertir se escribe antes de tomarla. Los registros de decisiones de arquitectura y los diagramas explican las decisiones para la organización.

• Política de federación acordada antes del lanzamiento: cerrada, con lista de permitidos o abierta
• Un período para mensajes y medios locales; otro menor para remotos
• Cifrado por sala deliberado, no un interruptor general
• Puentes evaluados por escrito, incluidos sus efectos sobre el cifrado de extremo a extremo

RESULTADO: decisiones, diagramas y políticas legibles por su delegado de protección de datos.

03 DESPLEGAR

Etapa 03 / 09

Homeserver, cliente, base y proxy inverso en contenedores sobre su hardware. Cada componente versionado permite reconstruir, no recordar.

• Un servidor dedicado sin operador externo que conserve sus mensajes
• PostgreSQL configurado para Synapse, no con valores predeterminados
• nginx al frente con delegación .well-known para el nombre de federación correcto
• Element Web con su nombre y colores, no logo del proveedor

RESULTADO: homeserver activo, definido en archivos, no montado a mano.

04 IDENTIDAD

Etapa 04 / 09

Cuenta, contraseña y lugar único para revocar. El inicio de sesión único conecta Matrix con su directorio existente.

• Proveedor de identidad al frente con ámbitos separados
• Filtro de dominio de correo para decidir quién puede tener cuenta
• Configuración de la base de datos e integración del proveedor de identidad
• Matrix confía en el proveedor: el acceso termina según el directorio

RESULTADO: acceso por su proveedor de identidad y una lista de personas, no dos.

05 PROTEGER

Etapa 05 / 09

Los valores predeterminados son para Internet abierto. Una institución necesita los ajustes que los sustentan y registro de cambios y motivos.

• Medios autenticados para que un enlace no baste para leer
• Notificaciones push sin sacar contenido del mensaje
• Cargas limitadas, dispositivos obsoletos retirados y tokens de renovación de duración limitada
• Administración solo por WireGuard y dirección de origen, nunca por nombre

RESULTADO: registro de protección con cada ajuste distinto del predeterminado y su motivo.

06 FEDERAR

Etapa 06 / 09

La federación es política, no interruptor. Abre con moderación preparada y primero a servidores identificados.

• Acceso federado configurado según la política acordada
• Bot de moderación que aplica políticas en los sistemas
• Complementos de bots para las tareas habituales de las salas y la integración de servicios
• Informes, escalado y gestión de evidencias escritos antes de abrir más

RESULTADO: modelo de federación y moderación legible por personal jurídico y de bienestar estudiantil.

07 REUNIRSE

Etapa 07 / 09

El trabajo empieza en chat y termina en llamadas y widgets. Los medios en tiempo real se alojan junto al homeserver; la llamada tampoco sale.

• OpenTalk para reuniones programadas junto al homeserver
• Jitsi con Prosody, Jicofo, JVB y coturn, todo autoalojado
• LiveKit para llamadas Matrix-RTC dentro del cliente Matrix
• Widgets en sala para trabajar sin salir del seminario

RESULTADO: chat, reuniones y llamadas en los mismos sistemas y bajo las mismas reglas.

08 OPERAR

Etapa 08 / 09

Lo interesante no es el lanzamiento, sino el martes en que algo falla y debe entenderse, no solo reiniciarse.

• Supervisión de seguridad y planificación de respuesta a incidentes
• Revisión de configuración y procedimientos de recuperación documentados
• Pruebas de restauración de bases de datos en un entorno aislado
• Conservación impuesta en servidor, no dependiente de la memoria

RESULTADO: alcance honesto declarado antes, no descubierto después.

09 ENTREGA

Etapa 09 / 09

Debe poder sustituirnos. La documentación lo demuestra y se escribe para quien herede el sistema.

• Documentación, diagramas y registros de decisiones arquitectónicas
• EIPD, registro de tratamiento, política de supresión y procedimiento de violaciones preparados
• Cada ajuste distinto del predeterminado con su motivo
• Escrito para quien lo herede, no quien lo construyó

RESULTADO: sistema, documentos y cuentas, sin nada solo en nuestra cabeza.

10 CONTACTO

Objetivo

Empiece en la etapa 01. La auditoría es un trabajo pequeño y fijo que indica si el resto merece la pena.

• Definir un despliegue
• Preguntar por la migración
• Solicitar presupuesto
• Solo una pregunta

Sin scripts de terceros, seguimiento ni captcha. O escriba a hello@ave17.com

No se incluye: un certificado de aprobado o suspenso. La revisión informa de hallazgos. La certificación tiene su propio régimen y auditores.

Inicio

Empiece por el problema, no el producto.

• Diga qué opera, en qué debe convertirse y sus límites: normativa, personas, aislamiento, directorio o contrato con una plataforma hasta el año próximo.
• Recibirá preguntas, una idea del trabajo y una explicación clara de lo que no asumiríamos.

Escriba a

hello@ave17.com

Acerca de

Matrix

No se incluye: presupuesto fijo desde el primer mensaje. Siempre alcance antes del precio.

A

El camino habitual y el del estándar abierto.

Dos formas de poseer una conversación. Ninguna columna nombra marcas: la diferencia es estructural, no competitiva.

No se incluye: afirmar que la columna derecha siempre sea correcta. Algunos requisitos encajan mejor con un producto comprado.

B

Seis capas entre Internet y una frase.

Cada capa se decide por separado y puede fallar sola. Seleccione un anillo para leer qué decide.

Perímetro

DNS, delegación y TLS deciden el acceso antes de existir mensajes.

Federación

Listas de permitidos, control de servidores y claves de firma deciden quién puede comunicarse.

Servidor

Homeserver, base y medios contienen los sistemas. Protección y límites los mantienen activos.

Identidad

Proveedor de identidad y autenticación deciden quién tiene cuenta y cuánto dura.

Sala

Miembros, permisos, reglas de ingreso e historial deciden quién ve qué y desde cuándo.

Mensaje

Cifrado de extremo a extremo, claves de dispositivos y firma cruzada deciden quién lee. Los servidores retransmiten, no leen.

No se incluye: prometer las seis ya configuradas. Muchos despliegues hacen bien tres y heredan el resto.

C

Cómo se desarrolla un proyecto.

Seis etapas con resultado escrito al final. Seleccione una para leer trabajo y resultado.

No se incluye: duración fija. Las etapas son consecutivas y duran según sistemas y aprobaciones.

D

Tres formas de federarse y cómo elegir.

Federación asusta a compras porque se entiende como "abierto a todo Internet". Es un ajuste con tres posiciones.

Cerrada

Su servidor no habla con otros. Cuentas propias, salas internas y ningún mensaje fuera. La federación está desactivada, no solo filtrada.

Para sistemas donde "¿puede salir?" debe responderse no, por escrito.

Socios identificados

Se federa con servidores de una lista y rechaza el resto. Proveedores, entidad matriz u otra agencia se añaden y retiran deliberadamente.

El caso habitual: acceso donde quiera y puerta cerrada en lo demás.

Abrir

Se federa con la red pública. Cualquier dirección Matrix llega a sus usuarios según reglas de ingreso, salas y moderación.

Para trabajo público: comunidades, soporte y cualquier caso donde importe ser accesible.

No se incluye: afirmar que la federación abierta sea segura por defecto. Necesita moderación, políticas y atención.

E

Las preguntas que realmente se hacen.

No es introducción al protocolo. Son ocho preguntas de quienes lo consideran seriamente, respondidas como en una llamada.

¿En qué se diferencia de un servidor público gratuito?

Un servidor público se comparte: dominio ajeno, datos junto a los de todos y límites y políticas heredados. Aquí el despliegue es solo suyo, la dirección lleva su dominio y usted fija los límites.

¿Cumple realmente la normativa o solo está en Europa?

La ubicación sola no demuestra nada. Importa quién accede, mediante qué proceso y si puede comprobarlo. La sección de acceso en /matrix/H explica exactamente qué acceso tenemos y cómo verificarlo desde fuera.

¿Podemos ejecutarlo en nuestro hardware?

Sí, es la opción más barata. Su máquina, cuenta de nube o centro de datos; nosotros instalamos, protegemos y mantenemos. Los requisitos figuran en Desplegar.

¿Qué ocurre si queremos salir?

Se lleva el servidor. Dirección, salas e historial pertenecen al despliegue, no al contrato. La salida se diseña y escribe al principio; vea Salida.

¿Cobran por persona?

No. Cien o mil personas cuestan igual. El precio sigue infraestructura y trabajo, no plantilla.

¿Quién puede leer nuestros mensajes?

En salas cifradas de extremo a extremo, solo dispositivos participantes, ni servidor ni nosotros. Fuera de ellas, el servidor conserva contenido accesible a administradores, incluidos nosotros durante el mantenimiento. La sección de acceso en /matrix/H explica los límites y cómo auditarlos.

¿Cuánto tardan en responder a un fallo?

Estándar responde en dos días laborables; prioritario, ocho horas laborables. Una caída siempre cuenta, pero nunca se cobra, en cualquier plan. Vea Soporte.

¿Podemos verlo funcionar antes?

Hablamos de sus requisitos y acordamos cómo evaluar el despliegue propuesto.

No se incluye: prometer respuestas intactas tras conocer su entorno. Algunas cambiarán.

F

Cuánto cuesta.

Cambie las cifras y vea el total. No se envía nada: funciona en su navegador y estima, no presupuesta.

Configuración, una vez

590 EUR

Ingeniería fuera del alcance

110 EUR por hora

Una evaluación

desde 3 días a 110 EUR por hora

Más de 1000 usuarios

termina la escala y hacemos un presupuesto

No se añade IVA: no estamos registrados y la cifra mostrada es el total.

La puesta en marcha se cobra una vez; lo demás es mensual. Las restricciones inusuales se delimitan antes de fijar el precio.

No se incluye: presupuesto fijo desde el primer mensaje. Siempre alcance antes del precio.

G

Qué cubre el soporte y qué no.

Dos niveles con coberturas y exclusiones escritas.

Horario laboral, de lunes a viernes, excepto festivos: una solicitud enviada el viernes por la noche se responde el siguiente día laborable. Tres preguntas distintas en un mensaje cuentan como tres solicitudes.

Cubierto

• Servidor detenido, inaccesible o que devuelve errores
• Fallo de un componente instalado con el despliegue
• Problemas del sistema: disco, memoria, certificados y copias
• Reconfiguración solicitada: añadir componente, cambiar política o límite
• Actualizaciones y fallos durante ellas

No cubierto

• Preguntas generales sobre el software abierto subyacente
• Escribir sus bots o servicios de aplicación
• Por qué un componente externo actúa así: sus autores responden mejor
• Fallo de un componente externo tras cambios de su proyecto de origen
• Actualizaciones de distribución de su sistema operativo en su máquina
• Asesoramiento para crear un negocio sobre el software

No se incluye: guardias de 24 horas. Los plazos de respuesta son laborables y explícitos.

H

A qué podemos acceder y a qué no.

Primero lo incómodo: afirmar que no hay acceso alguno no sería cierto.

A qué podemos acceder

• Cualquier archivo de un servidor mantenido: usamos SSH con root
• Todo lo no cifrado, incluidos datos de otras redes cuyo diseño impide cifrado de extremo a extremo
• Base de datos, registros y copias del despliegue
• Metadatos de cuentas: quién existe, cuándo se conectó y sus dispositivos

A qué no podemos acceder

• Contenido cifrado de extremo a extremo: claves en dispositivos, no servidor
• Nada de una máquina a la que nunca recibimos acceso
• Copias cifradas con su clave. Administrando accedemos a los propios datos; revocado el acceso, no podemos leer las copias
• Despliegues tras entregar y retirar acceso

Qué escribimos nosotros

• Gestión de configuración que construye y mantiene los despliegues
• Supervisión y alertas posteriores
• Selección, personalización e integración del cliente Matrix
• Herramientas de copias y restauración, incluida su prueba
• Todo lo demás es código abierto externo identificado en las páginas de servicios

Cómo comprobar en lugar de creer

• Accesos e inicios de programas registrados en la auditoría de su máquina
• Pida retirar acceso entre trabajos; es una petición normal
• Ejecute el sistema de auditoría y observe las llamadas al sistema
• Compruebe las afirmaciones sobre la infraestructura. Las pruebas públicas y sus instrucciones están en la sección "Dónde funciona y cómo comprobarlo sin preguntarnos." en /matrix/I.

Poder acceder y hacerlo son cosas distintas. El acceso solo se usa para mantener y reparar el servidor. El registro, no nuestra palabra, permite exigirlo.

No se incluye: afirmar acceso cero. Mantener un servidor exige acceder; fingir lo contrario sería una mentira detectable.

I

Dónde funciona y cómo comprobarlo sin preguntarnos.

Muchos operadores terminan en "servidores en la UE". Todo lo siguiente puede probarse desde fuera sin consultarnos.

Ejecute las pruebas usted

• internet.nl: pruebas independientes de sitio y correo de cualquier dominio
• DNSViz: recorre DNSSEC y muestra cada firma
• Hardenize o equivalente: una página de configuración DNS, correo y web
• Informe SSL del host: certificado, cadena y protocolos
• Dirija cualquiera a ave17.com. No le pedimos confianza ciega.

Nada de esto protege por sí solo un servidor de chat. Muestra cómo trabaja la empresa, algo que puede verificar antes de firmar nada.

Los controles operativos se documentan y usted puede verificarlos.

J

Cómo salir.

La salida se diseña al inicio. Quien la dificulta revela algo sobre el resto del acuerdo.

La identidad es suya

El nombre es su dominio. Sea quien sea el operador, las direcciones de sus usuarios no cambian de manos.

Recibe la máquina, no una exportación

Base de datos, archivos y configuración se entregan tal como están, sin convertirse en archivo de despedida.

La configuración es legible

Despliegues versionados y revisables. El siguiente ingeniero lee cómo se construyó, sin adivinar.

La entrega es servicio, no penalización

Procedimientos, explicación y responsable por componente. Se cobra como trabajo a tarifa normal.

Acceso retirado a petición

Claves retiradas, sesiones terminadas y retirada visible en sus registros.

Nunca tarifa de salida

Sin cobro por salir ni preaviso que lo disimule.

Es la respuesta honesta a la dependencia: el protocolo abierto permite que otro operador retome su despliegue y existen varios. Ese es el propósito de no poseer el protocolo.

No se incluye: trabajo gratuito. La entrega se cobra como trabajo; marcharse no se cobra.

K

Con quién trata.

Con quién trata y la documentación correspondiente.

Las condiciones completas, el aviso de privacidad y el acuerdo de tratamiento del artículo 28 están publicados antes de pedir a nadie que firme.

Escriba a

hello@ave17.com

Acerca de

Matrix

No se incluye: asesoramiento jurídico. Declaramos nuestra situación; debe asesorarse sobre sus propias obligaciones.

Cómo funciona

• A · El camino habitual y el del estándar abierto
• B · Seis capas entre Internet y una frase
• C · Cómo se desarrolla un proyecto
• D · Tres formas de federarse y cómo elegir

Antes de comprar

• F · Cuánto cuesta
• G · Qué cubre el soporte y qué no
• E · Las preguntas que realmente se hacen

Antes de confiar

• H · A qué podemos acceder y a qué no
• I · Dónde funciona y cómo comprobarlo sin preguntarnos
• J · Cómo salir
• K · Con quién trata