El caso contrario, en serio

Un argumento que solo se ha oído en su versión favorable no se ha entendido. Las cuatro lecciones anteriores han construido la defensa de la propiedad y la longevidad, y esta existe para someterla a la única prueba que importa: qué se pierde exactamente cuando se elimina la autoridad central. La respuesta no es una lista de inconvenientes menores ni un conjunto de problemas de ingeniería pendientes de resolver. Hay cuatro funciones —moderar, revocar, cumplir y recuperar— que dependen de que exista un punto donde alguien pueda decir la última palabra, y hay una clase entera de invariantes que un teorema demuestra imposibles sin coordinación. Para el software que necesita esas funciones, la centralización no es pereza arquitectónica ni captura del usuario: es el diseño correcto. Reconocerlo no debilita el argumento local-first, lo delimita, y un argumento sin delimitar es un eslogan.

Cuatro funciones que exigen un centro

Las cuatro comparten una estructura común que conviene ver antes de examinarlas por separado: todas requieren que exista un lugar donde se pueda tomar una decisión que obligue a los demás. No basta con que alguien tenga una opinión sobre qué debe ocurrir; hace falta que su decisión sea ejecutable sobre réplicas que no controla. Eso es exactamente lo que una arquitectura sin centro elimina por diseño, y por eso las pérdidas no son subsanables con más ingenio dentro del mismo modelo.

Moderar. Retirar contenido de circulación exige poder verlo y poder eliminarlo en todas partes. En una arquitectura replicada y cifrada no ocurre ninguna de las dos cosas: nadie ve el contenido y nadie puede despublicar, porque cada réplica que ya lo recibió lo conserva. Esto no es una preocupación hipotética ni un debate académico; es la disputa regulatoria central de la década, con propuestas europeas de detección de material de abuso y legislación británica de seguridad en línea presionando justamente sobre este punto. La respuesta técnica que se propone —análisis en el propio dispositivo antes de cifrar— es contestada por la comunidad criptográfica con un argumento serio: instala en cada terminal una infraestructura de inspección cuya lista de objetivos puede ampliarse después sin cambiar una línea de código. Y aunque esa objeción sea correcta, no elimina el problema que intentaba resolver.

Las respuestas que se manejan tampoco son intercambiables, y conviene conocer sus formas antes de despacharlas. Una es la moderación en el cliente antes de cifrar, que preserva el cifrado y crea la infraestructura de inspección que se acaba de mencionar. Otra es limitar la propagación en vez del contenido: no se puede borrar lo publicado, pero sí impedir que el servidor de sincronización lo redistribuya, lo que reduce el alcance sin garantizar la eliminación. Una tercera es el reenvío verificable, que permite demostrar el origen de un mensaje sin revelar su contenido a terceros, útil contra la desinformación y no contra el material ilegal. Ninguna resuelve el problema entero, y esa es exactamente la razón por la que el debate sigue abierto.

Revocar. En un sistema con servidor, quitar el acceso es una operación instantánea y efectiva: el servidor deja de servir. En un sistema local-first, revocar es rotar claves, y rotar claves impide la lectura futura sin tocar nada de lo que ya se descargó. Quien tuvo una réplica la sigue teniendo. La revocación deja de ser una capacidad y pasa a ser una petición cortés, y esa diferencia es decisiva en cualquier contexto laboral: la salida de una persona de una organización exige cortar el acceso al histórico, no solo a lo nuevo. Hay que decirlo con franqueza porque el matiz suele venderse como equivalencia y no lo es.

Cumplir. La normativa presupone un lugar donde ejercer control, y no una sino varias obligaciones distintas lo dan por supuesto:

• Supresión. Borrar de verdad y poder demostrarlo, frente a un modelo cuya historia es inmutable y cuyas lápidas de borrado nunca desaparecen del todo.
• Residencia. Saber en qué jurisdicción están los bytes, algo que no significa nada cuando están en el portátil de cada participante.
• Retención. Congelar información por orden judicial, lo que exige poder impedir que alguien la elimine de su réplica.
• Auditoría. Registrar de forma fiable quién accedió a qué, lo que exige un observador que no sea el propio interesado.
• No repudio. Que nadie pueda negar haber hecho algo, lo que exige un testigo que ninguna de las partes controle.

Vale la pena precisar qué es exactamente lo que se degrada, porque el vocabulario induce a error. Con servidor, revocar tiene tres efectos simultáneos: impide leer lo nuevo, impide leer lo viejo y permite comprobar que ambas cosas ocurrieron. Sin servidor solo se conserva el primero, y ni siquiera el segundo se puede aproximar, porque el material ya replicado está fuera de todo alcance técnico. La comprobación desaparece por completo: no hay forma de saber quién conservó una copia. Un responsable de seguridad que oiga que el sistema soporta revocación entenderá los tres efectos, y recibirá uno.

Recuperar. El usuario pierde el teléfono. Sin un tercero que custodie algo recuperable, perder la clave es perder los datos, sin apelación y para siempre. Los mecanismos de rescate existen —depósito de claves, recuperación social entre contactos de confianza, sincronización de claves en el llavero del fabricante— y todos comparten la misma estructura lógica: reintroducen a un tercero de confianza. La formulación honesta es que la recuperación es la reintroducción de una autoridad, y para la inmensa mayoría de las personas es la decisión correcta.

Lo interesante del caso de la recuperación es que enseña a discutir bien los otros tres. La pregunta útil no es si se reintroduce un tercero, porque casi siempre hay que reintroducirlo, sino cuánto poder se le da y sobre qué. Un custodio que guarda un fragmento cifrado inservible por sí solo tiene mucho menos poder que uno que guarda la clave entera; un conjunto de contactos que necesitan ponerse de acuerdo para reconstruirla tiene un perfil de riesgo distinto del de una empresa que puede hacerlo sola. La conversación productiva es sobre el reparto y la granularidad, no sobre la presencia o la ausencia de autoridad.

Convergencia no es corrección

Las cuatro funciones anteriores son argumentos empíricos y contingentes: dependen de cómo esté el mundo, de qué exija la ley y de cómo se comporten las personas, y podrían cambiar. Lo que sigue no.

Este es el límite más profundo y el único que se puede demostrar. Los tipos replicados sin conflicto garantizan que todas las réplicas terminan en el mismo estado; no garantizan que ese estado sea válido. Dos personas desconectadas reservan el mismo asiento y las réplicas convergen impecablemente hacia un estado donde el asiento está reservado dos veces. Convergieron y el sistema es incorrecto.

El ejemplo del asiento no es una curiosidad: se repite en cuanto una regla del dominio habla de límites, exclusividad o ausencia. Basta contrastar dos columnas para ver dónde cae cada cosa:

• Monótonas y por tanto convergentes sin árbitro. Añadir una anotación, acumular etiquetas, incrementar un contador de visitas, unir conjuntos de participantes, registrar que un hecho ocurrió.
• No monótonas y por tanto imposibles sin coordinación. Que un nombre sea único, que un saldo no baje de cero, que solo haya un administrador, que no se vendan más entradas que asientos, que un permiso ya no esté vigente.

La generalización tiene nombre y demostración. El principio CALM, formulado por Hellerstein en 2010 y probado formalmente por Ameloot y colegas, establece que un programa admite una implementación distribuida sin coordinación si y solo si es monótono, es decir, si añadir información nunca invalida una conclusión previa. Que sea un bicondicional importa mucho más de lo que parece: no dice solo que los programas monótonos se pueden distribuir sin coordinar, dice también que los no monótonos no se pueden, y por tanto cierra la puerta a esperar que una biblioteca futura lo consiga. Acumular hechos, unir conjuntos, incrementar contadores: todo eso es monótono y converge sin árbitro. Pero las invariantes que más importan en los sistemas de registro son negativas y por tanto no monótonas: que un identificador sea único exige afirmar la ausencia de otro igual; que un saldo no baje de cero exige conocer todos los cargos pendientes; que un inventario no se sobrevenda exige contar lo que aún no ha llegado. Afirmar una ausencia sobre información incompleta es imposible sin coordinación, y eso no es una limitación de las bibliotecas actuales: es un teorema.

flowchart TD
P1[Hay invariantes no monotonas como unicidad o saldo no negativo]
P1 -->|si| S[Hace falta coordinacion y por tanto una autoridad]
P1 -->|no| P2[Hay obligacion legal con un punto de control exigible]
P2 -->|si| S
P2 -->|no| P3[La revocacion debe impedir leer y no solo pedirlo]
P3 -->|si| S
P3 -->|no| P4[Los participantes pueden custodiar sus claves con seguridad]
P4 -->|no| S
P4 -->|si| L[Local first es el valor por defecto razonable]
style S fill:#f38ba8,color:#11111b
style L fill:#a6e3a1,color:#11111b

El coste de la soberanía y quién lo paga

Más allá de las funciones perdidas hay costes que rara vez se contabilizan y que, sobre todo, recaen sobre partes distintas de las que toman la decisión:

1. Durabilidad, sobre el usuario. Pasa a ser responsable de sus copias de seguridad, y la evidencia dice que se le da mal.
2. Ceguera, sobre el soporte. Nadie puede mirar los datos del usuario para diagnosticar por qué su documento se corrompió. Lo que era una consulta de cinco minutos se convierte en una sesión de reproducción a distancia sin garantías.
3. Observabilidad, sobre la ingeniería. Depurar un sistema cuyos nodos son dispositivos ajenos, con versiones distintas, relojes distintos y particiones arbitrarias, es un orden de magnitud más difícil que depurar un servidor inspeccionable.
4. Superficie de ataque, sobre la seguridad. El dispositivo del usuario suele estar peor protegido que un centro de datos, y ahora contiene el conjunto completo de los datos en vez de la vista que estaba mirando.
5. Coste de la primera versión, sobre el equipo. Un producto centralizado equivalente se construye antes, se prueba antes y se corrige antes. Para un equipo pequeño esa diferencia decide si el producto existe.

La distribución de esos costes es lo que hace difícil la decisión, porque quien decide la arquitectura no suele ser quien paga. El equipo que elige local-first por convicción traslada la durabilidad al usuario, que no participó en la conversación y probablemente no la entiende; y traslada la depuración a su yo futuro, que tampoco estaba en la sala. Ninguna de esas dos partes puede objetar en el momento en que se decide.

Y hay un coste temporal que decide muchos proyectos: la migración de esquemas. Cuando la forma de los datos vive en dispositivos ajenos que llevan meses sin abrirse, cambiarla exige compatibilidad en las dos direcciones y durante un plazo indefinido, porque no existe la ventana de mantenimiento en la que se migra la base y se acabó. Un equipo pequeño que en una arquitectura centralizada despliega un cambio de esquema en una tarde, en una arquitectura local-first asume una obligación permanente.

Ese coste tiene además una propiedad desagradable: crece con el éxito. Cuantos más usuarios y más antiguos, más versiones distintas del esquema circulan, más larga es la ventana de compatibilidad que hay que sostener y más caro resulta cada cambio. Una arquitectura centralizada tiene el perfil inverso, porque la migración se hace una vez sobre una base que el equipo controla. Conviene saberlo al elegir, porque es el tipo de coste que no se percibe en el primer año y decide el tercero.

Un criterio por dominio, no una preferencia general

De todo lo anterior sale un criterio que se puede aplicar sin discutir de ideología. Local-first es el valor por defecto razonable cuando se cumplen a la vez cinco condiciones:

1. El dominio es monótono en lo esencial: sus reglas hablan de acumular, no de excluir ni de limitar.
2. Los participantes son pocos y con confianza mutua, de modo que la moderación es una conversación y no un procedimiento.
3. La revocación es una cortesía y no un requisito, porque nadie va a ser adversario de nadie por el contenido compartido.
4. No hay obligación normativa con punto de control exigible: ni supresión demostrable, ni residencia, ni auditoría formal.
5. La población de usuarios puede custodiar una clave sin que perderla sea una catástrofe irreparable. Ese perfil describe con bastante exactitud el trabajo creativo sobre documentos: notas, escritura, diseño, código, gestión personal, investigación. No es casualidad que ahí sea donde las herramientas local-first son mejores que sus alternativas centralizadas y no solo más nobles.

Ese perfil no es un nicho residual: cubre la mayor parte del software con el que una persona pasa el día produciendo algo. Pero conviene notar que las cinco condiciones se evalúan sobre el producto tal como es hoy, y que los productos crecen. Muchas herramientas empiezan cumpliéndolas las cinco y dejan de cumplirlas en cuanto añaden equipos, roles, facturación por asientos o un plan corporativo con requisitos de auditoría. Diseñar local-first sin prever ese crecimiento produce una reescritura, y preverlo desde el principio suele significar reservar desde el día uno el pequeño servicio autoritativo que más adelante hará falta.

El servidor autoritativo es la respuesta correcta en cuanto aparece cualquiera de las condiciones inversas, y la lista de dominios donde aparecen es tan reconocible como la anterior:

• Registro financiero y contable. Saldos, límites y conciliación son no monótonos por definición, y encima hay supervisión formal.
• Historia clínica. Auditoría de accesos, retención obligatoria y consecuencias graves de una divergencia entre réplicas.
• Comercio con inventario. No vender lo que no hay es una invariante negativa, y aceptarla con conflictos posteriores tiene coste real para alguien.
• Plataformas abiertas. Participantes que no se conocen y pueden ser adversarios, lo que hace de la moderación y la revocación requisitos y no cortesías.
• Servicios cuyo valor es el cómputo. Si lo valioso es lo que el servidor calcula y no lo que el usuario escribe, la propiedad de los datos apenas cambia nada. Aquí la centralización no es una captura: es el mecanismo por el que el sistema puede prometer algo y responder de ello.

Entre ambos extremos hay una zona amplia donde la respuesta correcta es la frontera bien trazada, y merece describirse con algo más de detalle porque es donde acabará la mayoría de los productos. La forma que suele funcionar es un servicio autoritativo reducido a lo mínimo —identidades, pertenencia a grupos, unicidad de nombres, permisos vigentes, contadores con límite— junto a un sustrato replicado que lleva todo el contenido. El servicio pequeño es fácil de auditar, barato de operar, sencillo de someter a requisitos normativos y, sobre todo, no ve el contenido; el sustrato replicado da la velocidad, el trabajo sin conexión y la propiedad. Lo que se gana con esa separación no es un punto medio tibio, es que cada parte queda gobernada por el mecanismo que su naturaleza lógica exige.

Queda una advertencia final que apunta en la otra dirección, porque el criterio se puede abusar. La existencia de razones legítimas para centralizar ha servido durante años para justificar centralizaciones que no las tenían: una aplicación de notas no tiene invariantes no monótonas, un gestor de tareas personal no necesita moderación y un editor de texto no está sujeto a residencia de datos. La pregunta que desarma el abuso es simple y hay que hacerla producto por producto: qué invariante concreta, qué obligación concreta o qué revocación concreta justifica que la fuente de verdad esté en el servidor. Cuando existe una respuesta específica, el debate está cerrado y con razón. Cuando la respuesta es que así se ha hecho siempre, o que así se cobra la suscripción, el debate ni siquiera había empezado.