La ontología de Local-First

Es tentador leer local-first como una optimización —una capa de caché agresiva, una app que además aguanta el metro— y esa lectura te llevará a implementarlo mal. No es una técnica de latencia: es un cambio de quién tiene la autoridad sobre los datos. En la arquitectura cliente-servidor que heredamos, el servidor decide qué es verdad y el cliente pregunta; de ahí salen en línea recta las tres patologías que damos por normales: la rueda de carga, que aparece porque cada lectura es una pregunta remota; la aplicación que muere sin conexión, porque no queda nadie que pueda responderla; y tus datos, que dejan de existir el día que la empresa cierra, porque nunca fueron tuyos. Local-first invierte la relación: la copia que tienes en el dispositivo ES la verdad, y la red pasa a ser un detalle de propagación entre iguales. El artículo de Ink and Switch que acuñó el término en 2019 formalizó esa intuición en siete ideales —velocidad, multidispositivo, funcionar sin red, colaboración, longevidad, privacidad y propiedad—, pero el precio del cambio está entero en el problema que crea: cuando dos copias divergen no hay árbitro que dirima, de modo que la convergencia tiene que estar garantizada por las matemáticas de la estructura de datos y no por una regla de negocio escrita dentro de un if. Por eso este track dedica quince niveles a los CRDT antes que a ningún framework: la propiedad que necesitas —que dos réplicas que han visto las mismas operaciones en cualquier orden terminen idénticas— es algebraica, no arquitectónica. Y hace tiempo que dejó de ser investigación: Automerge 3.0 recortó el consumo de memoria diez veces a finales de 2025, Zero de Rocicorp alcanzó su 1.0 en junio de 2026, iroh publicó la suya el 15 de junio de 2026 y FOSDEM 2026 dedicó una sala entera a local-first, motores de sincronización y CRDT. Todo lo demás que estudies aquí se deduce de esa única inversión.