Los cinco problemas abiertos: lo que sigue sin estar resuelto

Un track que terminase celebrando lo conseguido sería propaganda. La honestidad del campo, que ha sido una constante de este recorrido, exige cerrar nombrando con precisión lo que todavía no funciona, porque esa lista es más útil que cualquier resumen de logros: predice dónde va a doler un proyecto, orienta a quien quiera investigar y desactiva la promesa comercial de que basta con adoptar una biblioteca. Los cinco problemas que siguen no son incomodidades menores pendientes de pulido. Son consecuencias directas de haber quitado el árbitro, y cada uno de ellos tiene hoy respuestas parciales, caras o que aplazan el problema en lugar de resolverlo. Conviene conocerlos por su nombre antes de prometer nada a nadie.

Revocación: quitar el acceso a lo que ya se entregó

El primer problema es también el más definitivo, porque no admite solución completa ni la admitirá nunca. En una arquitectura con servidor, revocar el acceso de alguien es cambiar una fila: la próxima petición se rechaza y la relación termina ahí. En una arquitectura donde cada participante tiene una réplica completa, revocar significa pedirle a alguien que olvide algo que ya está en su disco, y eso no es una operación que un sistema pueda ejecutar.

Lo que sí se puede hacer es acotar el daño hacia adelante, y ahí las técnicas son conocidas. Se puede rotar la clave de un espacio compartido y volver a cifrar el contenido para los miembros restantes, de modo que quien salió conserve lo que tenía pero no reciba nada nuevo. Se puede diseñar el reparto de claves por épocas, para que el coste de una salida sea proporcional al número de miembros y no al tamaño de la historia. Y se puede reducir la ventana de exposición limitando lo que cada dispositivo descarga de entrada.

Ninguna de esas medidas cambia el hecho central: la revocación en local-first es una operación hacia el futuro. Y hay una consecuencia práctica que rara vez se comunica a los usuarios ni a los responsables de cumplimiento: cuando un producto centralizado promete que un antiguo colaborador dejó de tener acceso, está haciendo una afirmación verificable sobre su servidor; cuando lo promete un producto local-first, está haciendo una afirmación mucho más débil sobre datos que ya salieron. Vender la primera garantía sobre la segunda arquitectura es, sencillamente, mentir.

Migración y compactación: el mismo problema visto desde dos ángulos del tiempo

El segundo y el tercer problema se estudian por separado y comparten raíz: en un sistema sin autoridad, no existe el momento en que todos los participantes están presentes y de acuerdo.

La migración de esquema es el problema peor documentado del campo. En un servidor, cambiar la forma de los datos es un despliegue coordinado con una ventana de mantenimiento si hace falta. Aquí el esquema vive replicado en dispositivos que no controlas, algunos apagados durante meses, y cuando vuelvan escribirán con la versión antigua contra un mundo que ya cambió. Eso obliga a compatibilidad en las dos direcciones: la versión nueva tiene que entender lo que escribe la vieja, y la vieja tiene que no destruir lo que escribe la nueva, que es la mitad difícil y la que casi nadie implementa. Las respuestas actuales son parciales: campos siempre opcionales, transformaciones idempotentes al leer, conservación de lo desconocido al reescribir, y una disciplina de versionado que ningún sistema de tipos comprueba por ti.

La compactación con dispositivos ausentes es la misma tensión con el signo cambiado. Un modelo convergente acumula historia y lápidas, y podar esa historia exige saber que nadie la va a necesitar. Sin un servidor que lleve la cuenta, esa certeza no existe: siempre puede aparecer un dispositivo con una réplica de hace un año pidiendo una base común que ya se tiró. Las estrategias reales pasan por instantáneas acordadas, por umbrales temporales explícitos y por aceptar que un dispositivo demasiado antiguo se resincroniza desde cero perdiendo su historia local, que es una degradación honesta pero degradación al fin.

flowchart TD
T[El tiempo sin arbitro] --> M[Migrar el esquema]
T --> C[Compactar el historial]
M --> M1[Version nueva lee lo viejo]
M --> M2[Version vieja no destruye lo nuevo]
C --> C1[Podar exige saber quien ya lo vio]
C --> C2[El dispositivo ausente rompe la certeza]
M2 --> R[Ningun sistema de tipos lo comprueba]
C2 --> R
style R fill:#f9e2af,color:#11111b

Control de acceso sin un servidor que lo haga cumplir

El cuarto problema es el más activo en investigación y el que más se subestima al empezar. En cliente-servidor, la autorización es trivial conceptualmente: hay un punto que ve cada petición y decide. Al quitarlo, hay que responder tres preguntas que antes ni se planteaban.

La primera es quién eres cuando no hay tabla de sesiones. La respuesta del campo pasa por identidades basadas en claves y por identificadores descentralizados, con dispositivos que se autorizan entre sí formando un conjunto por persona. La segunda es quién te autorizó, que se resuelve con cadenas de delegación verificables sin conexión: un permiso es un certificado firmado que otro dispositivo puede validar mirando solo la cadena, sin preguntar a nadie. La tercera es cómo se aplica esa decisión, y aquí está el hueco de verdad, porque un permiso que solo comprueba el cliente no es un permiso: es una convención. Sin servidor, la única forma de que un permiso sea real es que el dato esté cifrado con una clave que el no autorizado no tiene, lo cual convierte todo el control de acceso en un problema de gestión de claves de grupo.

Y ahí se abre el segundo frente: la gestión de claves entre muchos miembros con altas y bajas frecuentes es un problema con soluciones maduras en mensajería, pero la mensajería tiene un modelo de datos mucho más simple que un documento colaborativo con historia. Combinar convergencia con cifrado de grupo, de modo que el servidor de relevo no vea nada y aun así pueda relevar, sigue siendo terreno de proyectos de investigación activos más que de bibliotecas listas para producción.

El quinto problema no es técnico: el conflicto en pantalla

El último es el que menos artículos genera y el que más productos hunde. La convergencia garantiza que dos réplicas terminen idénticas; no garantiza que el resultado tenga sentido para quien lo mira, y no dice absolutamente nada sobre cómo contárselo.

El campo ha invertido veinte años en que la fusión sea automática, y esa automatización tiene un efecto secundario incómodo: cuando el sistema decide solo, el usuario no se entera de que ha habido una decisión. Si dos personas editaron el mismo párrafo y el algoritmo entrelazó las frases, o si un registro de valor único resolvió por reloj y descartó lo que alguien escribió, no hay ningún momento en la interfaz donde eso se comunique. El dato no se ha perdido en sentido técnico —la operación está en el historial— pero se ha perdido en el único sentido que le importa a una persona: no está en la pantalla y nadie avisó.

Las respuestas disponibles son todas insatisfactorias por motivos distintos. Mostrar los conflictos explícitamente devuelve al usuario a la fricción que local-first prometía eliminar. Ocultarlos por completo produce pérdidas silenciosas de confianza que se manifiestan como abandono y no como informes de error. Exponer un historial navegable ayuda, pero traslada el trabajo a quien tiene que revisarlo. Y guardar varios valores concurrentes para que el usuario elija solo funciona cuando el modelo tiene pocos puntos donde eso ocurre.

Lo importante es que esta pregunta se responde en el diseño del producto y no en la elección de la biblioteca, y que responderla tarde es carísimo, porque el modelo de datos condiciona qué se puede llegar a mostrar. Un diseño que no guardó qué operación vino de quién no podrá explicar nunca lo que pasó, por muy buena que sea su convergencia.