De dónde sale el término local-first

Local-first no nació como una moda de arquitectura ni como una reacción ideológica contra la nube. Nació como un diagnóstico técnico publicado en 2019 por el laboratorio Ink & Switch bajo el título “Local-first software: You own your data, in spite of the cloud”. Entender ese diagnóstico, y entender por qué sus autores hablaron de ideales y no de requisitos, es la única forma de usar el término sin convertirlo en marketing.

El diagnóstico de 2019

El artículo parte de una observación empírica sobre dos familias de software que convivían sin mezclarse.

La primera familia es la aplicación de escritorio clásica. Sus datos viven en ficheros en tu disco. La latencia de cualquier operación es la latencia de la memoria y del almacenamiento local: unos microsegundos, ninguna ida y vuelta por la red. Si la empresa que la escribió desaparece, el fichero sigue en tu disco y otros programas pueden abrirlo. A cambio, colaborar es doloroso: adjuntos por correo, sufijos como informe-v3-final-bueno, fusiones manuales, y un dispositivo que es el único que tiene la versión buena.

La segunda familia es la aplicación en la nube. Colaboración simultánea real, acceso desde cualquier dispositivo, cero instalación, cero copias de seguridad manuales. A cambio, tus datos viven en el disco de otro. La aplicación que ejecutas en tu máquina no es un programa completo: es un cliente delgado sobre un servidor que posee el estado canónico. Sin red no hay documento. Si el producto cierra, si tu cuenta se suspende o si el proveedor cambia de precio, la relación con tus propios datos se rompe.

La tesis del artículo es que la industria trató esto como un compromiso inevitable y aceptó perder las propiedades de la primera familia a cambio de las de la segunda. Y que ese compromiso no es fundamental: es un artefacto de una decisión arquitectónica concreta, la de colocar la autoridad sobre el estado en el servidor.

Merece la pena subrayar por qué esa decisión se tomó de forma casi universal sin discutirse. Centralizar la autoridad resuelve de un golpe tres problemas difíciles: da un orden total a los eventos sin necesidad de razonar sobre causalidad, da un punto único donde aplicar reglas de validación y permisos, y da un lugar obvio donde ejecutar todo lo que el cliente no puede. Es una solución excelente de ingeniería para el problema de la coordinación. Lo que el artículo señala es que su factura se paga en un presupuesto distinto —latencia, disponibilidad, privacidad, permanencia— y que esa factura llevaba una década sin contabilizarse.

Ahí está el corazón técnico. En una aplicación de nube, el servidor guarda el estado canónico y el dispositivo guarda una caché: algo derivado, desechable, que ante la duda se descarta y se vuelve a pedir. Local-first invierte la relación: el dispositivo guarda una réplica completa y autoritativa, y la red deja de ser una fuente de verdad para convertirse en un canal de sincronización entre iguales.

flowchart LR
A[Aplicacion de escritorio clasica] --> A1[Datos en disco propio]
A --> A2[Colaboracion por adjuntos]
B[Aplicacion en la nube] --> B1[Datos en servidor ajeno]
B --> B2[Colaboracion simultanea]
C[Local first] --> C1[Datos en disco propio]
C --> C2[Colaboracion simultanea]
style C fill:#a6e3a1,color:#11111b
style C1 fill:#a6e3a1,color:#11111b
style C2 fill:#a6e3a1,color:#11111b

La diferencia se ve mejor en el código de lectura más simple posible, donde ni siquiera hay escrituras de por medio.

// Cache: la verdad esta en otro sitio; ante la duda, se descarta y se vuelve a pedir.
async function leerComoCache(id: string) {
  const fresco = await servidor.leer(id);  // la autoridad es remota
  cache.guardar(id, fresco);
  return fresco;
}

// Replica: la verdad esta aqui; la red aporta lo que otros hicieron, no permiso.
function leerComoReplica(id: string) {
  return estado.obtener(id);               // la autoridad es local
}

La segunda función no tiene fallo posible por causa de la red, no tiene estado de carga, no tiene reintentos y no tiene tiempo de espera. Esa ausencia de casuística no es una simplificación del ejemplo: es la consecuencia directa de haber movido la autoridad. Toda la complejidad que desaparece del camino de lectura reaparece, eso sí, en el camino de reconciliación, que es donde local-first concentra su dificultad.

Los siete ideales, en una sola vista

El artículo condensa el diagnóstico en siete propiedades deseables. Conviene leerlas como pruebas observables sobre el comportamiento de un programa, no como adjetivos de folleto.

1. Sin ruedas de carga. Tu trabajo responde a la velocidad del dispositivo, no de la red.
2. Tu trabajo no está atrapado en un dispositivo. Varias máquinas, el mismo trabajo, sin coreografía manual.
3. La red es opcional. Sin conexión no es un estado de error, es el supuesto por defecto.
4. Colaboración fluida con otras personas. Edición concurrente sin turnos, bloqueos ni reservas.
5. El Largo Ahora. Tus datos te sobreviven al producto, a la empresa y a la versión.
6. Seguridad y privacidad por defecto. Cifrado extremo a extremo como base, no como extra.
7. Conservas la propiedad y el control últimos. Nadie puede revocar tu acceso a tu propio trabajo.

Los tres primeros son ideales de rendimiento y red; los dos siguientes, de colaboración y longevidad; los dos últimos, de soberanía. Esa agrupación no es cosmética: cada bloque impone exigencias distintas y, como veremos en las lecciones siguientes, entra en tensión con los otros.

Conviene además notar qué tipo de afirmación es cada ideal. Los tres primeros son propiedades operacionales: se miden con un cronómetro y un interruptor de red. El cuarto y el quinto son propiedades del modelo de datos y del formato: se comprueban leyendo una especificación e intentando reimplementarla. El sexto y el séptimo son propiedades del modelo de amenaza y de la relación contractual: no se observan en el uso normal, solo en los modos de fallo. Esta heterogeneidad explica por qué no existe una única métrica que resuma “cuán local-first” es un sistema, y por qué la lección 5 propone una rúbrica por ejes en lugar de una nota global.

Por qué ideales y no requisitos

Esta es la decisión retórica más importante del artículo, y la más ignorada por quienes usan la etiqueta.

Un requisito es binario y define pertenencia: o lo cumples o no eres eso. Genera una frontera, y con ella una disputa sobre quién está dentro. Un ideal define una dirección y un gradiente: puedes estar más cerca o más lejos, y la pregunta útil deja de ser “¿es esto local-first?” para pasar a ser “¿en cuáles de los siete ejes cede este sistema, y qué está comprando a cambio?”.

Hay al menos tres razones técnicas para preferir el gradiente.

Primera: en 2019 los autores ya sabían que ningún sistema existente cumplía los siete. Ellos mismos evaluaron las categorías disponibles de la época, desde ficheros sincronizados por una carpeta compartida hasta editores colaborativos en la web, y ninguna las satisfacía todas. Un marco de requisitos con cero instancias es un marco inútil.

Segunda: varios ideales están en tensión real, no aparente. El cifrado extremo a extremo elimina del servidor la capacidad de indexar, buscar o previsualizar. Los metadatos que hacen posible la fusión automática hacen el formato más opaco y más frágil a largo plazo. Un marco de requisitos obligaría a declarar imposible lo que en realidad es negociable.

Tercera: los siete ideales no pesan igual en todos los dominios. Una aplicación de diario personal puede ignorar por completo la colaboración sin traicionar nada. Un requisito uniforme sería una carga arbitraria.

Hay además una razón de método, más profunda que las tres anteriores. Un requisito se comprueba una vez y se archiva; un ideal se revisa en cada versión. Los siete ejes no describen un estado alcanzable sino una presión que hay que mantener, porque la deriva hacia la arquitectura de nube no ocurre por una decisión, sino por acumulación de decisiones pequeñas y razonables tomadas por separado: una comprobación de sesión que simplifica el arranque, un identificador asignado por el servidor que evita un dolor de cabeza, una búsqueda remota que ahorra semanas de trabajo. Cada una es defendible; la suma no lo es. Un marco de ideales sobrevive a esa dinámica porque obliga a volver a preguntar; una lista de requisitos aprobada en su día no protege de nada.

Del artículo a la comunidad

El texto de 2019 hacía además una apuesta técnica concreta: que las estructuras de datos replicadas sin conflicto, investigadas en el mundo académico durante la década anterior, eran el sustrato práctico para lograr el ideal 4 sin sacrificar los tres primeros. Esa apuesta orientó buena parte del trabajo posterior del laboratorio.

Ink & Switch mantiene también un proyecto centrado en el control de acceso local-first, llamado Keyhive, que ataca precisamente el punto más duro del bloque de soberanía: cómo se autoriza, se comparte y se revoca el acceso cuando no hay un servidor de confianza que decida quién puede leer qué. Es una señal de dónde está hoy la frontera de la investigación.

Y hay una señal social igual de nítida: en 2026, FOSDEM dedicó una sala de desarrolladores entera al tema. Lo que en 2019 era el manifiesto de un laboratorio se ha convertido en un área con implementaciones, protocolos rivales y una comunidad que discute compromisos concretos.

Ese desplazamiento importa para leer el artículo con la distancia adecuada. En 2019 el texto tenía que argumentar que el problema existía; hoy esa parte está aceptada y la discusión se ha movido a los detalles duros: cuánto pesan los metadatos de convergencia, cómo se poda el historial, cómo se autoriza a un colaborador nuevo sin un servidor que lo bendiga, y qué significa exactamente revocar el acceso a alguien que ya descargó los datos. El marco ha sobrevivido a ese desplazamiento precisamente porque no se definió como una lista de requisitos que la práctica hubiera invalidado, sino como un conjunto de direcciones que sigue siendo útil para situar cada nueva propuesta.