Software local-first: conservar la propiedad de tus datos incluso en la era de la nube (2019)

 (inkandswitch.com)
2 puntos por GN⁺ 2025-07-06 | 1 comentarios | Compartir por WhatsApp
  • Las apps en la nube mejoraron mucho la colaboración y el acceso desde varios dispositivos, pero como la copia autorizada de los datos está en el servidor, se debilitan la propiedad y el control del usuario
  • El software local-first mantiene el almacenamiento local de laptops, tablets y teléfonos como la copia principal de los datos, y limita los servidores a un rol auxiliar para sincronización y respaldo
  • Este enfoque busca combinar respuestas rápidas, trabajo sin conexión, sincronización entre varios dispositivos, colaboración en tiempo real, preservación a largo plazo y seguridad y privacidad por defecto
  • Los archivos, el correo electrónico, las apps web, la sincronización tipo Dropbox, Git, Firebase, CloudKit, Realm y CouchDB tienen cada uno algunas ventajas, pero no satisfacen a la vez la colaboración y la propiedad de los datos
  • Los prototipos basados en CRDT y Automerge mostraron potencial, pero aún quedan desafíos como el rendimiento, la comunicación de red, la estabilidad P2P y las interfaces de usuario para documentos distribuidos

El conflicto entre la colaboración en la nube y la propiedad de los datos

  • Las apps en la nube como Google Docs, Figma, Slack y Trello se acceden desde el navegador o una app móvil, y almacenan los datos en servidores
  • Este modelo ofrece las ventajas de la colaboración en tiempo real y el acceso desde cualquier lugar, pero todo acceso a los datos debe pasar por el servidor
    • Solo es posible realizar las acciones que el servidor permite
    • Si el servicio se interrumpe, puede bloquearse no solo el software, sino también el acceso a los datos creados con ese software
    • Aunque se puedan exportar los datos, es difícil seguir ejecutando el mismo software sin el servidor
  • En cambio, las apps locales tradicionales leen y escriben archivos en el disco local, por lo que el usuario puede controlar directamente el respaldo, la conservación a largo plazo, la manipulación con otros programas y la eliminación
  • La tensión central es que la nube ofrece colaboración, mientras que las apps locales ofrecen propiedad; local-first es una dirección de diseño que intenta obtener ambas

Modelo básico del software local-first

  • El software local-first prioriza el almacenamiento local y la red local por encima de los servidores en centros de datos remotos
  • En las apps en la nube, los datos del servidor son la fuente autorizada, y los datos del cliente se parecen más a una caché dependiente del servidor
  • En las apps local-first, los datos locales de cada dispositivo son la copia principal, y el servidor mantiene una copia auxiliar que ayuda al acceso desde varios dispositivos y al respaldo
  • Este cambio de perspectiva impacta directamente en el rendimiento, el uso sin conexión, la preservación a largo plazo, la privacidad y el control del usuario

Los 7 ideales de local-first

  • 1. Trabajo inmediato, sin spinners

    • En las apps en la nube, modificar datos y muchas consultas requieren un viaje de ida y vuelta al servidor, lo que genera latencia
    • La UI optimista oculta la latencia al hacer parecer que la solicitud ya terminó, pero si hay un error de red, la demora vuelve a quedar expuesta
    • En las apps local-first, como los datos principales están en el dispositivo local, se reduce la necesidad de que la entrada del usuario espere una respuesta del servidor
    • La sincronización ocurre en segundo plano, y la app puede responder casi de inmediato a la entrada del usuario

  • 2. Trabajo que no queda atrapado en un solo dispositivo

    • Los usuarios pasan de un dispositivo a otro: capturan ideas en el smartphone, las organizan en la tablet y las documentan en la laptop
    • Las apps local-first también necesitan sincronización entre todos los dispositivos de trabajo, aun manteniendo los datos en cada dispositivo
    • La mayoría de los servicios de sincronización entre dispositivos también guardan una copia en el servidor, que funciona como respaldo fuera del sitio
    • Si varias personas editan el mismo archivo al mismo tiempo, pueden surgir conflictos, por lo que el diseño de la colaboración se vuelve importante

  • 3. La red como algo opcional

    • Los aviones, túneles, elevadores, estacionamientos, WiFi inestable, costos de roaming y entornos con internet incompleto en países en desarrollo o zonas rurales generan la necesidad de trabajar sin conexión
    • Las apps en la nube suelen ser débiles sin conexión, y también es difícil agregar soporte offline a posteriori sobre un modelo centrado en el servidor
    • Las apps local-first almacenan los datos principales en el sistema de archivos local de cada dispositivo, por lo que pueden leerse y escribirse incluso sin conexión
    • Luego, cuando la red está disponible, se sincronizan con otros dispositivos; la sincronización puede hacerse no solo por internet, sino también por Bluetooth o WiFi local
    • Para una buena experiencia offline, un ejecutable instalado localmente es más adecuado que una pestaña del navegador

  • 4. Colaboración fluida con colegas

    • En el software tradicional basado en archivos locales, si varias personas editan al mismo tiempo el mismo archivo, es fácil que aparezcan conflictos
    • Las apps en la nube como Google Docs popularizaron una experiencia en la que varios usuarios editan un documento al mismo tiempo sin preocuparse por los conflictos
    • El ideal de local-first es admitir colaboración en tiempo real igual o mejor que la de las mejores apps en la nube actuales
    • También es importante un flujo en el que un usuario propone cambios y otro los revisa y los incorpora de forma selectiva
      • el modo de sugerencias de Google Docs
      • los pull requests de GitHub

  • 5. Long Now: accesibilidad a largo plazo

    • Un aspecto importante de la propiedad de los datos es que se pueda acceder a ellos durante mucho tiempo en el futuro
    • Las apps locales antiguas pueden seguir usándose si se cuenta con los datos y una copia ejecutable del software, y los sistemas operativos o computadoras antiguas también pueden ejecutarse mediante máquinas virtuales o emuladores
    • Aunque cambien los medios de almacenamiento, los archivos pueden copiarse a nuevos medios
    • Las apps en la nube dependen de la premisa de que el servicio seguirá prestándose, y son vulnerables al cierre del servicio, la pérdida de datos, los cambios de precio o funcionalidad y las actualizaciones forzadas no deseadas
    • El software local-first aumenta la posibilidad de preservación a largo plazo porque los datos y el software que los lee y modifica se almacenan localmente
    • plain text, JPEG y PDF tienen alta probabilidad de seguir siendo legibles durante mucho tiempo, y la Biblioteca del Congreso de Estados Unidos recomienda XML, JSON y SQLite como formatos de preservación para conjuntos de datos

  • 6. Seguridad y privacidad por defecto

    • Las apps en la nube reúnen los datos de todos los usuarios en una base de datos central, lo que las convierte en un blanco atractivo para atacantes
    • Empleados internos o hackers con acceso a los servidores pueden leer o manipular los datos, y las filtraciones de datos siguen siendo un riesgo común
    • Los términos de Google Drive indican que los sistemas automatizados analizan el contenido de los usuarios para ofrecer resultados de búsqueda personalizados y detectar spam y malware
    • Para usuarios que manejan datos sensibles, como profesionales de la salud, periodistas de investigación o funcionarios gubernamentales y diplomáticos, el uso de apps en la nube puede entrar en conflicto con obligaciones regulatorias o de confidencialidad
    • Las apps local-first pueden almacenar en cada dispositivo local solo los datos propios del usuario, y dejar en el servidor únicamente copias cifradas de extremo a extremo
    • iMessage, WhatsApp, Signal, Keybase y Tarsnap se presentan como ejemplos de cifrado de extremo a extremo o de uso compartido y respaldo de archivos cifrados

  • 7. Propiedad y control finales

    • En las apps en la nube, el proveedor del servicio puede restringir el acceso del usuario
    • En octubre de 2017, a algunos usuarios de Google Docs se les bloqueó el acceso a documentos porque un sistema automático los marcó erróneamente como maliciosos
    • Aquí, propiedad no se refiere a derechos de propiedad intelectual, sino a la agencia del usuario, su autonomía y su control sobre los datos
    • En el software local-first, los bytes que componen los datos están en los dispositivos del usuario, por lo que existe libertad para procesarlos de cualquier forma
    • La propiedad de los datos también implica la responsabilidad de mantener respaldos, evitar la pérdida de datos, responder al ransomware y administrar archivos archivados
    • Local-first no necesariamente tiene que ser open source; incluso el software comercial y cerrado puede acercarse a este ideal si no restringe artificialmente el uso de archivos
    • Como ejemplos de restricciones artificiales se mencionan los PDF que impiden imprimir, los lectores de eBook que dificultan copiar y pegar, y el DRM en archivos multimedia

Limitaciones de los modelos existentes de almacenamiento y uso compartido

  • Archivos y adjuntos de correo electrónico

    • Los archivos tradicionales son fuertes en visualización y edición sin conexión, control por parte del usuario, copias de seguridad, conservación a largo plazo y acceso rápido
    • Para acceder desde varios dispositivos se necesitan métodos como correo electrónico, USB, NAS/NFS/FTP/rsync, sincronización de archivos tipo Dropbox o Git
    • Los adjuntos de correo electrónico son fáciles de entender y confiables, y aun 6 meses después el archivo adjunto sigue estando en su forma original
    • Su debilidad es la colaboración
      • Por lo general, solo una persona puede modificar un archivo a la vez
      • Si varias personas lo editan, se requiere una fusión manual
      • Aparece confusión con nombres de archivo como Budget draft 2 (Jane's version) final final 3.xls
    • Las apps que quieran aplicar la idea local-first pueden empezar ofreciendo exportación a formatos ampliamente compatibles, como plain text, PDF, PNG y JPEG

  • Apps web

    • En apps web como Google Docs, Trello, Figma y Pinterest, el navegador o la app móvil son clientes ligeros y el almacén de datos está en el servidor
    • Las apps web establecieron el estándar de la colaboración en tiempo real, y su gran ventaja en el trabajo en equipo es que la versión más reciente puede verse desde cualquier lugar
    • En cambio, la propiedad y el control se reducen considerablemente
      • Los datos del servidor son la referencia y los datos del cliente se parecen más a una caché
      • Aunque la red se corte por un momento, el acceso puede quedar bloqueado en medio del trabajo
      • El soporte sin conexión limitado, como el plugin offline de Google Docs, se parece más a algo agregado a posteriori sobre una arquitectura centrada en el servidor
    • Incluso los clientes de escritorio instalables como Milanote y Figma son, en esencia, navegadores reempaquetados, por lo que sus límites quedan expuestos ante fallas de red, caídas del servidor o cierre del servicio

  • Dropbox, Google Drive, Box, OneDrive

    • Dropbox, Google Drive, Box y OneDrive vigilan una carpeta designada en el escritorio y copian los archivos modificados a otras computadoras
    • Como usan el sistema de archivos local, son rápidos y permiten trabajar sin conexión; además, aunque el servicio de sincronización cierre, los archivos permanecen en el disco local
    • Si ocurre una falla del disco duro, se puede restaurar instalando la app y esperando la sincronización, lo que ofrece ventajas en términos de durabilidad y control
    • En iOS y Android móviles se parecen más a un modelo de cliente ligero que no sincroniza carpetas completas, sino que trae archivos uno por uno desde el servidor
    • La opción “Make available offline” debe configurarse de antemano, es engorrosa y solo funciona cuando la app está abierta
    • Su punto más débil es la colaboración en tiempo real
      • Si el mismo archivo se modifica en dos dispositivos, se produce un conflicto que requiere fusión manual
      • Poder sincronizar formatos de archivo arbitrarios es una ventaja de compatibilidad, pero también se vuelve una debilidad porque no se pueden hacer fusiones específicas por formato

  • Git y GitHub

    • Git y GitHub se usan principalmente para la colaboración en código fuente, y actualmente se consideran el paquete de software más cercano a local-first
    • Un repositorio Git es la copia principal de los datos en el sistema de archivos local y no depende de un servidor
    • Ofrece trabajo completamente sin conexión, funcionamiento rápido, control del usuario y aptitud para conservación a largo plazo
    • GitHub proporciona colaboración, acceso desde varios dispositivos y un lugar para copias de seguridad y archivo, pero no cifra los repositorios
    • Git tiene dos grandes debilidades
      • No ofrece colaboración con fusión automática y granular en tiempo real como Google Docs, Trello o Figma
      • Está optimizado para código y texto basado en líneas, y otros formatos de archivo se tratan como blobs binarios difíciles de editar y fusionar de manera significativa
    • El hecho de que muchos ingenieros de software citen “es lento”, “no confío en eso” y “quiero tener el código en mi sistema local” como razones para evitar editores y entornos de ejecución en la nube como Cloud9, Repl.it y Colaboratory conecta con las motivaciones local-first

Opciones desde la perspectiva de la infraestructura para desarrolladores

  • Apps web de cliente ligero

    • Es un modelo en el que servidores Rails, Django, PHP o Node.js almacenan datos en bases de datos SQL o NoSQL y sirven páginas web por HTTPS
    • No requiere instalación y el usuario solo tiene que visitar una URL; la responsabilidad de administrar los datos recae en el equipo de ingeniería y DevOps que hizo el despliegue
    • Meteor, ShareDB, Pusher, Ably y WebSocket facilitan agregar funciones de colaboración en tiempo real a las apps web
    • Si cada acción del usuario requiere una solicitud al servidor, la app se vuelve lenta, y aunque se oculte el ida y vuelta con JavaScript del cliente, se rompe fácilmente con una conexión a internet inestable
    • A pesar de esfuerzos como manifest, localStorage, service worker y Progressive Web Apps, la arquitectura de las apps web sigue siendo fundamentalmente centrada en el servidor
    • Si se borran las cookies del navegador, a menudo también se eliminan los datos del almacenamiento local, por lo que no es adecuada para guardar datos importantes a largo plazo
    • Si el usuario aloja por su cuenta una app web de código abierto, puede mejorar algunas características, pero como la mayoría de los usuarios no quiere convertirse en administrador de sistemas, el autoalojamiento no es una opción realista para la mayoría

  • Apps móviles que usan almacenamiento local

    • Las apps de iOS y Android descargan un binario y lo instalan localmente, pero muchas apps como Twitter, Yelp y Facebook son clientes ligeros que necesitan un servidor para funcionar
    • Las apps que primero guardan datos en el dispositivo local mediante una capa de persistencia como SQLite, Core Data o archivos comunes están más cerca del ideal local-first
    • Clue y Things son casos que comenzaron como apps de un solo usuario y luego agregaron un backend en la nube para sincronización entre dispositivos o uso compartido
    • Estas apps de cliente pesado son rápidas y funcionan sin conexión porque la sincronización con el servidor ocurre en segundo plano
    • La dificultad aumenta cuando varios dispositivos o varios usuarios colaboradores modifican datos
    • Los desarrolladores de apps móviles suelen ser especialistas en desarrollo de apps para usuarios finales, no especialistas en sistemas distribuidos
    • Los algoritmos improvisados de diff, merge y resolución de conflictos suelen ser poco confiables y frágiles

  • Firebase, CloudKit, Realm

    • Firebase es un BaaS móvil que combina una base de datos en el dispositivo local, un servicio de base de datos en la nube y sincronización entre ambos
    • Firebase admite uso compartido entre varios dispositivos y uso sin conexión, pero al ser un servicio de hosting propietario obtiene puntuaciones bajas en privacidad y durabilidad
    • Parse fue adquirido por Facebook y luego cerrado en 2017, por lo que las apps que dependían de él tuvieron que migrar a otros backends
    • La consola de Firebase ofrece a los desarrolladores una buena experiencia para ver, modificar y eliminar datos, pero los usuarios no cuentan con medios equivalentes para acceder, manipular y administrar sus datos
    • CloudKit de Apple ofrece una experiencia similar a Firebase para apps que pueden limitarse a iOS y Mac
      • Almacenamiento clave-valor y sincronización
      • Buenas funciones sin conexión
      • Menos fricción para crear cuentas e iniciar sesión gracias a la integración con la plataforma
    • Realm ganó popularidad como biblioteca de persistencia local para iOS, y Realm Object Server puede ser de código abierto y autoalojado, lo que reduce el riesgo de dependencia de un servicio

  • CouchDB

    • CouchDB llamó la atención por su enfoque de multi-master replication, en el que varias máquinas tienen una copia completa de la base de datos y cada réplica puede crear cambios de forma independiente
    • Cloudant es la versión alojada, y PouchDB y Hoodie usan el mismo protocolo de sincronización, pero están diseñados para ejecutarse en dispositivos de usuarios finales
    • Filosóficamente, CouchDB está cerca de los principios local-first, pero los datos modificados simultáneamente deben resolverse de forma explícita mediante código de la aplicación
    • En apps de colaboración granular, donde cada pulsación de tecla puede ser un cambio individual como en Google Docs, es difícil escribir código correcto de resolución de conflictos
    • Entre las razones por las que no logró una adopción amplia se mencionan la escalabilidad de bases de datos separadas por usuario, la integración de clientes JavaScript dentro de apps nativas de iOS y Android, la resolución de conflictos y lo poco familiar del modelo de consultas MapReduce

CRDT y mejores tecnologías de base

  • Las capas de datos existentes para el desarrollo de aplicaciones no satisfacen todos los ideales local-first
  • Ink & Switch empezó a investigar hace tres años para encontrar una solución, y propone como base prometedora los Conflict-free Replicated Data Types o CRDT
  • Los CRDT son estructuras de datos de propósito general surgidas en 2011 a partir de investigaciones académicas en ciencias de la computación
  • Almacenan el estado de un documento como estructuras de datos tipo hash map o lista, pero desde el inicio contemplan entornos multiusuario
  • Los editores de texto, hojas de cálculo y apps de gráficos vectoriales mantienen el estado de cada documento como una estructura de datos; en apps colaborativas multiusuario, esto puede reemplazarse por un CRDT

  • Cómo fusionan los CRDT

    • El usuario puede ver y modificar el estado de la aplicación en su dispositivo local incluso sin conexión
    • El CRDT rastrea los cambios y, cuando hay red disponible, los sincroniza en segundo plano con otros dispositivos
    • Si en distintos dispositivos se agregan nuevas tareas al mismo tiempo, el estado fusionado incluye todos los elementos agregados en un orden consistente
    • Los cambios simultáneos sobre objetos distintos pueden fusionarse fácilmente
    • El caso difícil de resolver automáticamente ocurre cuando varios usuarios actualizan al mismo tiempo la misma propiedad del mismo objeto; el CRDT rastrea los valores en conflicto y deja que la app o el usuario los resuelva
    • Un CRDT se parece a Git, pero funciona con tipos de datos más ricos que archivos de texto
    • El canal de sincronización puede ser cualquier cosa: un servidor, una conexión P2P, Bluetooth, una memoria USB, etc.
    • La unidad de cambio puede ser tan pequeña como una sola pulsación de tecla, lo que permite colaboración en tiempo real al estilo Google Docs, o puede enviarse en paquetes grandes como en un pull request de Git

  • Automerge y Hypermerge

    • Ink & Switch desarrolló Automerge, una implementación CRDT open source en JavaScript
    • Automerge se basa en investigaciones sobre JSON CRDT
    • Al combinar Automerge con el stack de red Dat, crearon Hypermerge
    • Es difícil decir que estas bibliotecas realicen por completo los ideales local-first, y todavía queda mucho trabajo por hacer
    • Los CRDT tienen el potencial de convertirse en una tecnología de base para software colaborativo en el que los usuarios conservan la propiedad de sus datos, así como el packet switching para internet o la pantalla táctil capacitiva para los smartphones

Prototipos de Ink & Switch

  • Aunque la validación de algoritmos y teoría de CRDT avanzó en el ámbito académico, su uso industrial aún es limitado y se da sobre todo en computación centrada en servidores
  • Como ejemplos de sistemas centrados en servidores que usan CRDT se mencionan Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi y Facebook OpenR
  • Ink & Switch creó prototipos de apps colaborativas local-first para trabajo creativo que usan CRDT en dispositivos de usuarios finales
  • Los experimentos abordan tres preguntas
    • Viabilidad técnica: qué tan cerca están los CRDT del software real
    • Experiencia de usuario: si es posible lograr colaboración en tiempo real como Google Docs y colaboración asíncrona amigable con el trabajo offline como Git, sin un servidor central de autoridad
    • Experiencia de desarrollador: en qué se diferencia una capa de datos CRDT de una base de datos SQL, un sistema de archivos o Core Data
  • Los tres prototipos se hicieron con Electron, JavaScript y React, y se consideró que el hecho de ser software descargable e instalable era importante para la sensación de propiedad

  • Trellis

    • Trellis es un tablero Kanban modelado a partir de Trello
    • Experimentó con WebRTC como capa de comunicación de red
    • Diseñó un historial de cambios inspirado en Git y en “See New Changes” de Google Docs
    • El usuario puede ver las tareas del tablero Kanban y volver a estados anteriores del documento

  • Pixelpusher

    • Pixelpusher es un programa de dibujo colaborativo que suma una experiencia de colaboración en tiempo real tipo Figma a Pixel Art to CSS de Javier Valencia
    • Experimentó con comunicaciones de red mediante la biblioteca P2P del proyecto Dat
    • Experimentó con URLs para compartir documentos, branch/merge visual inspirado en Git, resolución de conflictos que resalta en rojo los píxeles en conflicto e identificación básica de usuarios basada en avatares dibujados por ellos mismos

  • PushPin

    • PushPin es un espacio de trabajo con lienzo de medios mixtos, similar a Miro o Milanote
    • Fue el tercer proyecto basado en Automerge y el más completo de los tres prototipos
    • El uso real por parte del equipo y de usuarios externos de prueba impuso una carga mayor sobre la capa de datos subyacente
    • Experimentó con documentos compartidos anidados y conectados, diversos renderers para documentos CRDT, un sistema de identidad más avanzado que incluye un modelo de outbox y el intercambio de datos efímeros como el resaltado de selecciones

Resultados obtenidos de los prototipos

  • El objetivo de los tres prototipos fue evaluar la viabilidad técnica, la experiencia de usuario y la experiencia de desarrollo del software local-first y los CRDT
  • Los usaron regularmente 5 integrantes del equipo de desarrollo, y se realizaron pruebas de usabilidad individuales con unos 10 usuarios externos
    • Los usuarios externos incluían diseñadores profesionales, gerentes de producto e ingenieros de software
    • Se usó un enfoque exploratorio, no una metodología de evaluación formal

  • La tecnología CRDT funciona

    • La confiabilidad de Automerge fue mejor de lo esperado
    • Los desarrolladores de apps del equipo pudieron integrar la biblioteca con relativa facilidad, y la fusión automática de datos fue casi siempre intuitiva y fluida

  • La experiencia de usuario sin conexión fue buena

    • Funcionó bien el flujo de pasar a modo offline, trabajar todo lo que se quisiera y, al volver a conectarse, fusionar los cambios con los de los colegas
    • Incluso cuando otras apps bloqueaban el trabajo mostrando advertencias y errores de “offline”, los prototipos local-first funcionaban normalmente sin importar el estado de la red
    • A diferencia de los sistemas basados en navegador, se redujo la preocupación por si la app funcionaría o si los datos estarían disponibles, y dio una sensación de propiedad sobre las herramientas y el trabajo realizado

  • Encaja bien con el modelo FRP de React

    • El modelo de Functional Reactive Programming de React encaja bien con los CRDT
    • En una capa de datos basada en CRDT, el documento recibe al mismo tiempo entradas del usuario local y cambios de otros usuarios y dispositivos llegados por la red
    • El modelo FRP sincroniza de forma confiable el estado visible de la aplicación con el underlying state del documento compartido
    • Los desarrolladores se liberan de la tarea engorrosa de rastrear cambios provenientes de otros usuarios y conciliarlos con la pantalla actual
    • Si todos los cambios de estado pasan por una única función reducer, también se vuelve más fácil enviar a otros usuarios los cambios locales correspondientes

  • Los conflictos fueron menos graves de lo esperado

    • Los usuarios encontraron conflictos rara vez durante la colaboración, y los mecanismos generales de resolución funcionaron bien
    • Automerge rastrea los cambios a un nivel fino y tiene en cuenta el significado de los tipos de datos
    • Si dos usuarios insertan elementos simultáneamente en la misma posición de un arreglo, combina ambos elementos en un orden determinista
    • Un sistema de control de versiones de texto como Git podría considerar esto un conflicto que requiere resolución manual
    • Los usuarios tienen intuiciones sobre la colaboración, por lo que a veces dividen implícitamente las áreas de trabajo para no editar la misma sección al mismo tiempo
    • En la app Kanban, si un usuario comentaba una tarjeta y otro movía la tarjeta a otra columna, ambos cambios se reflejaban
    • Los conflictos ocurren solo cuando se modifica simultáneamente la misma propiedad del mismo objeto; por ejemplo, cuando dos usuarios cambian al mismo tiempo la posición del mismo objeto de imagen
    • En los prototipos, la semántica de fusión predeterminada de Automerge fue suficiente, y no se encontraron casos que requirieran semánticas personalizadas

  • Visualizar el historial del documento es importante

    • En un sistema de colaboración distribuido, pueden llegar muchos cambios de otros usuarios en cualquier momento
    • Como no hay un servidor central que medie los cambios, se necesitan herramientas para entender el camino por el que el documento llegó a su estado actual, las versiones existentes y el origen de las contribuciones
    • Trellis experimentó con una interfaz de “time travel” que permite al usuario navegar a estados anteriores del documento fusionado
    • También se experimentó con un método para resaltar automáticamente los elementos de cambios recién recibidos

  • Compartir mediante URL resulta natural

    • Entre varios mecanismos para compartir documentos, el modelo de URL inspirado en la web fue el más natural para usuarios y desarrolladores
    • Las URL se pueden copiar y pegar, y compartirse por canales de comunicación como correo electrónico o chat
    • Los permisos de acceso a documentos más allá de las URL secretas siguen siendo una pregunta de investigación abierta

  • Los sistemas P2P no se dividen simplemente entre online y offline

    • Los sistemas centralizados suelen definir el estado “up” o “down” según si hay una conexión estable con el servidor
    • En un sistema distribuido, cada usuario puede tener perspectivas distintas según qué datos posee, comparte y acepta
    • Las ediciones que estaban en una laptop dentro de un avión pueden distribuirse a otros usuarios cuando se conecte después de aterrizar
    • Otros usuarios pueden aceptar en su versión del documento todos esos cambios, algunos o ninguno
    • Como en un repositorio Git, el “master” de un usuario determinado se vuelve una función del momento en que se comunicó por última vez con otro usuario
    • Los documentos distribuidos dan a los usuarios control sobre los datos, pero hace falta más investigación sobre qué significa esto desde la perspectiva de la UI real

  • Los historiales largos de cambios generan problemas de rendimiento

    • Cuando PushPin se usó con documentos reales, como la planificación de sprints, el rendimiento y el uso de memoria y disco se volvieron rápidamente un problema
    • Los CRDT guardan todo el historial, incluida la edición de texto carácter por carácter
    • No se puede recortar fácilmente el historial, porque alguien podría volver a conectarse al documento seis meses después y necesitar fusionar los cambios desde ese momento
    • Las optimizaciones de Automerge continúan y siguen siendo una de las principales áreas de trabajo en curso

  • La comunicación de red aún no está resuelta

    • Los algoritmos CRDT solo se ocupan de fusionar datos; no de cómo las ediciones de otros usuarios llegan físicamente a la misma computadora
    • En los experimentos se probaron WebRTC, una implementación sneakernet que copiaba archivos mediante Dropbox y memorias USB, la posibilidad del protocolo IPFS y la biblioteca P2P Hypercore de Dat
    • Los CRDT no requieren necesariamente una capa de red P2P; también es posible comunicarse a través de servidores
    • Para hacer realidad por completo el objetivo de largo plazo de local-first, una solución descentralizada que sobreviva más que los servicios backend de un proveedor es el destino lógico final
    • La tecnología P2P no estaba suficientemente lista para producción, y en particular el NAT traversal era poco confiable según el router o la topología de red
    • La experiencia de colaborar en tiempo real directamente entre computadoras sin acceso a internet mostró un gran potencial en un mundo que depende de APIs centrales

  • Los servidores en la nube quedan como apoyo

    • Los prototipos de colaboración en tiempo real como PushPin pueden compartir documentos sin un servidor intermediario, lo cual es bueno para la privacidad y la propiedad
    • Sin embargo, si un usuario comparte un documento y luego cierra la laptop antes de que la otra persona se conecte, no pueden conectarse porque ambos usuarios no están online al mismo tiempo
    • En un mundo local-first, el servidor puede cumplir el rol de cloud peer, no de autoridad central
      • Guardar una copia del documento y entregarla cuando otro peer esté online
      • Proporcionar una ubicación de archivo y respaldo
      • Servir de puente hacia APIs de servidor tradicionales, como pronósticos del tiempo o cotizaciones bursátiles
      • Proporcionar burst computing, como renderizado de video con GPUs potentes
    • La diferencia entre los sistemas tradicionales y los sistemas local-first no es si existe o no un servidor, sino que el servidor no es la fuente de la verdad, sino que cumple un rol de apoyo

Trabajo necesario de aquí en adelante

  • Investigadores en sistemas distribuidos y lenguajes de programación

    • La investigación en CRDT y tecnologías P2P puede aportar mucho al software local-first
    • La investigación actual sobre CRDT normalmente asume un modelo en el que todos los colaboradores aplican ediciones de inmediato a una única versión del documento
    • Las apps local-first reales deben poder rechazar ediciones de otros colaboradores, o crear cambios privados en una versión del documento que no se comparte
    • Falta investigación que extienda conceptos de control de versiones distribuido como branch, fork y rebase a un modelo de colaboración donde múltiples versiones de documentos y branches coexisten en paralelo
    • Los tipos, las migraciones de esquemas y la compatibilidad también son problemas importantes
      • Cada colaborador puede usar distintas versiones y funciones de la app
      • Como no hay un servidor de DB central, no existe un esquema “actual” autoritativo para los datos
      • Varias versiones de la app deben interoperar de forma segura mientras evoluciona el formato de los datos

  • Investigadores en HCI

    • En los sistemas centralizados hay muchos casos de interfaces que muestran el estado de sincronización con el servidor, pero los sistemas descentralizados plantean nuevos problemas de UI
    • Se necesita investigar cómo comunicar los estados online/offline y disponible/no disponible en sistemas donde cada usuario puede tener una copia distinta de los datos
    • Cuando se puede colaborar directamente con otros nodos sin una Internet amplia, también cambia lo que significa estar “online”
    • Como cualquier documento puede adquirir un historial de versiones complejo con el uso cotidiano, hace falta una UI que ayude a los usuarios a entender las versiones, la aceptación de cambios y el proceso de formación del documento
    • Actualmente, la gestión de cambios está dominada por el modelo diff/patch típico del código fuente y por el modelo de sugerencias/comentarios de Google Docs
    • Cómo generalizar estas ideas a formatos de datos que no sean texto sigue siendo un problema abierto
    • En local-first no se puede impedir que un usuario que tiene los datos los modifique localmente; el concepto de permisos cambia hacia un modelo en el que otros usuarios eligen si se suscriben a esos cambios

  • Profesionales

    • Ingenieros, diseñadores, product managers y desarrolladores independientes que crean software de producción pueden dar pasos incrementales hacia un futuro local-first
    • Para lograr apps rápidas, se pueden reducir los spinners al abrir documentos mediante caching agresivo y descargas anticipadas, y confiar por defecto en la caché local
    • El soporte multidispositivo puede implementarse con relativa facilidad usando infraestructuras de sincronización como Firebase e iCloud, pero existen preocupaciones sobre longevidad y privacidad
    • Para el uso offline en la web, pueden ayudar las Progressive Web Apps, los Service Workers y el app manifest
    • Las pruebas de apps pueden hacerse apagando el WiFi o cambiando las condiciones de red con herramientas como el simulador de condiciones de red de Chrome DevTools o iOS Network Link Conditioner
    • Para la colaboración, además de CRDT, Operational Transformation, implementado en tecnologías como ShareDB, es una técnica más consolidada
    • Para la preservación a largo plazo, debe ser fácil exportar a formatos estables como JSON y PDF
      • Exportaciones masivas como Google Takeout
      • Copias de seguridad continuas en el formato de archivo estable de GoodNotes
      • Descarga de documentos JSON de Trello
    • En cuanto a privacidad, se debe informar claramente al usuario si los datos se almacenan solo en el dispositivo o si se envían al backend
    • Para dar control al usuario, debe ser fácil hacer copias de seguridad, duplicar y eliminar documentos dentro de la app; se presenta como ejemplo el caso de Google Docs, que reimplementó operaciones básicas de sistema de archivos mediante Google Drive

Oportunidades para startups y conclusión

  • Para fundadores que quieran crear infraestructura para desarrolladores, “Firebase for CRDTs” se presenta como una oportunidad de mercado interesante
  • Una startup así debería ofrecer una buena experiencia para desarrolladores y librerías de persistencia local como SQLite o Realm
  • Debería soportar iOS, Android, Windows, Mac, Linux, Electron y Progressive Web Apps
  • El control del usuario, la privacidad, el soporte multidispositivo y la colaboración deberían venir incluidos por defecto
  • La prueba de fuego para el éxito es si las apps de los clientes siguen funcionando de forma permanente aunque se apaguen todos los servidores
  • El software en la nube ofreció colaboración y apps actualizadas accesibles desde cualquier lugar, pero al alojar la propiedad de los datos en servidores convirtió a los usuarios en una especie de inquilinos de sus propios datos
  • El enfoque local-first muestra que los usuarios pueden conservar la propiedad y el control de sus datos y, aun así, obtener colaboración y accesibilidad al estilo de la nube
  • Para implementarlo en la práctica, todavía se necesita más soporte offline, mayor aprovechamiento del almacenamiento on-device, mejoras en algoritmos, modelos de programación e interfaces de usuario, y la productización de CRDT y redes P2P

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-06
Opiniones de Hacker News

  • Totalmente de acuerdo. Ya me cansé de la tendencia en la que todos los servicios se llevan mis datos a su nube y me obligan a pagar una suscripción para usarlos bien.
    La app de seguimiento de fitness que estoy creando va por el modelo de “compras una vez, recibes actualizaciones durante X años, se sincroniza con todos tus dispositivos y puedes seguir usándola para siempre después”. Si después de X años necesitas actualizaciones, compras la nueva versión; si las funciones actuales te bastan, sigues usándola.
    Ojalá la mayoría del software pudiera comprarse así a un precio razonable, que el producto en sí sea bueno y que no te ate de forma que no puedas usarlo sin la nube. Lo mejor del software local-first es que recupera un incentivo sano para cobrar por la calidad del producto, no por publicidad, rastreo o maximización del engagement.

    • Obsidian también es un buen modelo para tomar como referencia. El cliente es completamente gratis y solo venden el servicio opcional de sincronización.
      Todas las notas son archivos Markdown, así que el propio cliente también pasa a ser opcional.
    • Me da curiosidad cómo planean hacer la sincronización sin infraestructura en la nube.
    • “X años de actualizaciones + sincronización entre dispositivos + uso perpetuo” suena bien, pero con ese enfoque tendrían que cobrar de una vez el costo total de 1 o 2 años de suscripción.
      También hay que mantener los servidores de sincronización en funcionamiento, y considerar casos en los que un usuario sincroniza de golpe un año de datos en un solo día. Además, hay que seguir pagando sueldos a la gente que se encargará del desarrollo futuro, así que si se mira solo desde la perspectiva del desarrollador, hay cosas que se están dejando fuera.
    • Hace unos años, una fábrica local detuvo la producción durante dos días por una caída en los servidores de su proveedor de IT, y eso me hizo pensar en escenarios similares considerando el peor caso.
      https://rodyne.com/?p=1439
    • El backend puede ser parte de la funcionalidad, como la colaboración en tiempo real o la sincronización. Pero si es posible salir de la nube (ejectable) y cambiar en cualquier momento a self-hosting, o volver atrás, se puede garantizar la propiedad y la longevidad tanto de los datos como del servicio.
      El IDE de notas/tareas que estamos creando funciona así: https://thymer.com/local-first-ejectable

  • En Berlín hay una Local-first Software Conference anual organizada por Ink and Switch, y este noviembre en SF también se realizará un evento derivado llamado Sync Conf.
    https://www.localfirstconf.com/
    https://syncconf.dev/
    Este año estuvo bueno un panel en el que coautores del paper original hablaron sobre qué significa el software local-first en el contexto de las herramientas de desarrollo y qué aprendieron desde la publicación del paper original: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    La comunidad parece estar convergiendo hacia la idea de que la “sincronización” es un componente de local-first, pero también una tecnología aplicable de forma mucho más amplia. Local-first es una característica del software para usuarios finales, y las herramientas de desarrollo como los motores de sincronización son herramientas que lo hacen posible, no necesariamente local-first en sí mismas.
    Todas las charlas de los últimos años están aquí: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    Es un momento interesante para la comunidad de local-first/motores de sincronización. Hemos estado construyendo herramientas que permiten experiencias de colaboración en tiempo real y asincrónicas, y con la llegada de la IA este mercado está creciendo. Todas las apps de IA son, en esencia, sistemas colaborativos multiusuario donde los agentes participan como actores, por lo que necesitan las tecnologías que la comunidad de motores de sincronización ha venido trabajando.

    • También hay un excelente podcast Local First que entrevista a ingenieros que crean apps e infraestructura local-first.
      https://www.localfirst.fm/

  • Vale la pena leerlo, y ya hubo varias discusiones activas en el pasado.
    https://news.ycombinator.com/item?id=19804478 - mayo de 2019, 191 comentarios
    https://news.ycombinator.com/item?id=21581444 - noviembre de 2019, 241 comentarios
    https://news.ycombinator.com/item?id=23985816 - julio de 2020, 9 comentarios
    https://news.ycombinator.com/item?id=24027663 - agosto de 2020, 134 comentarios
    https://news.ycombinator.com/item?id=26266881 - febrero de 2021, 90 comentarios
    https://news.ycombinator.com/item?id=31594613 - junio de 2022, 30 comentarios
    https://news.ycombinator.com/item?id=37743517 - octubre de 2023, 50 comentarios

  • Todo lo que tiene dependencia en línea inevitablemente implica mantenimiento y costos continuos. Si un sistema no es local-first, o de ser posible solo local, no está diseñado para la confiabilidad a largo plazo
    Los electrodomésticos y autos conectados están cerca de ser la ingeniería más tonta desde un punto de vista práctico

    • Todo es por los ingresos por suscripción
      Las empresas que obtienen ingresos por suscripción tienen más ingresos y valuaciones más altas, lo que les facilita conseguir financiamiento adicional, y terminan venciendo a las empresas que no siguen este modelo. Por esta estructura que se refuerza a sí misma, creo que el software local-first murió
    • Si miras el almacenamiento gratuito/de pago de lugares como Dropbox o Apple, se ve el costo real. Es aproximadamente 10 dólares al mes por 2 TB
      Cloudflare ofrece hosting de archivos estáticos casi gratis, y el costo es prácticamente un error de redondeo. Aunque 1000 apps local-first se sincronicen con Dropbox, podrían funcionar con almacenamiento de 10 dólares al mes. Este almacenamiento no es una herramienta primitiva de bajo nivel como S3, sino un servicio para consumidores con autenticación, soporte y programa de sincronización incluidos. La mayoría de los costos de la nube en realidad no son necesarios
    • Si eres de los que se oponen a la iniciativa Stop Killing Games, deberías leer este comentario
      Nadie obliga a que los juegos dependan únicamente de servicios en línea. No es un requisito legal ni regulatorio. Como muchas cosas en el software, es solo una elección. Elegir depender de servicios en línea y luego decir “revertir esto cuesta dinero” es miope, lamentable y no debería aceptarse

  • Más apps deberían ser local-first. Si el usuario no quiere sincronizar sus datos con la nube, debería tener esa opción
    Desde hace un tiempo estoy creando Brisqi, una app offline-first o local-first, y la diseñé desde el inicio con una filosofía offline-first
    https://brisqi.com
    Una app local-first debería estar diseñada para funcionar completamente sin conexión de forma indefinida. La experiencia local es la base, no un sustituto; la sincronización en la nube debería ser una función auxiliar, no un requisito
    No considero offline-first a las apps que dependen de una caché temporal. Una app verdaderamente offline-first debe persistir los datos en una base de datos local. Muchas apps que se llaman “offline-first” en realidad se parecen más a offline-capable, ya que solo ofrecen funcionalidad offline limitada y al final dependen de reconectarse a internet
    Las apps offline-first son claramente más difíciles de construir que las apps web solo online, y el mecanismo de sincronización debe ser lo suficientemente confiable para que, incluso al pasar entre offline/online, los datos se sincronicen de forma consistente con la nube y no se pierdan. Escribí más sobre el enfoque en el blog: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • Me preocupa que este modelo pueda ser más difícil de sostener como negocio; me da curiosidad saber cómo les está yendo en la práctica

  • Es interesante cómo explican este principio para el ámbito de consumo, pero actualmente nosotros estamos haciendo lo mismo con activos industriales/datos industriales
    En www.sentineldevices.com, todo el aprendizaje, análisis y toma de decisiones ocurre sobre el equipo del cliente. Ni siquiera hay servidores a los que enviar datos; es un modelo en el que explícitamente todo corre dentro del dispositivo
    En SCADA/automatización industrial hay muchos casos de uso en los que no se pueden sacar los datos. Las empresas de datos/IA ignoran una enorme base de clientes y casos de uso porque es difícil prestar el servicio donde está el cliente; en cambio, quieren llevarse los datos hacia ellas y mantener el lock-in con el proveedor
    Cuando hablamos con clientes, más bien tenemos que recalcar mucho: “No, esto es local y no tiene conexión externa”. Como casi nunca han oído algo así, muchas veces hay que explicarlo paso a paso para que entiendan que todo ocurre localmente, y a los proveedores de software les cuesta aceptar este concepto. Ojalá el software local-first se afiance más en el ámbito de consumo para que también se vuelva familiar en el industrial

    • Tampoco ayuda que todos los proveedores de SCADA se hayan subido a la moda de la nube y empujen en esa dirección
      “¡Opera tu planta desde el smartphone!”. Genial, ahora basta un solo zero-day para que un script kiddie pueda jugar con mis bombas
    • Es un área interesante y me alegra que estén trabajando en esto
      Vi la página de empleos y todos los puestos eran no remotos; me pregunto si es por las limitaciones de tener que verse en persona para construir software local-first, o si es principalmente por razones de gestión

  • Personalmente, no estoy de acuerdo con este enfoque. Parece un intento de resolver el problema de negocio de “no se puede confiar en los proveedores de la nube” mediante una concesión técnica: “evitar una arquitectura centralizada”.
    La falta de control y de confiabilidad del software cerrado se resolvió con un nuevo modelo de negocio, el desarrollo open source, nuevas licencias y formas de ingresos como contratos de mantenimiento en lugar de costos de licencia.
    Del mismo modo, los problemas de los proveedores de la nube necesitan una solución a nivel de modelo de negocio. Por ejemplo, se podrían crear contratos/licencias estándar que definan derechos para que los usuarios puedan confiar en su relación con el proveedor de la nube. Con el tiempo, los usuarios podrían hacer negocios solo con proveedores que tengan esas licencias.
    Esto podría incluir cláusulas como acuerdos de fin de vida, garantías de portabilidad de datos y transparencia de privacidad de datos, que audite el acceso a los datos e informe quién/qué/cuándo los leyó. El problema es la adopción. La cuestión clave es por qué los proveedores de la nube deberían aceptarlo; si temen la tasa de abandono, podrían ofrecer estos contratos solo en suscripciones anuales o cobrar un precio más alto.

    • Si un problema de negocio o político puede resolverse con una solución técnica, por lo general es un enfoque sólido. Esos problemas los provocan actores adversarios, y una solución técnica elimina la capacidad de ese actor de traicionar la confianza.
      El cifrado al usar servicios en la nube es un buen ejemplo. Intentar proteger los datos con políticas de privacidad y reglas burocráticas es casi inútil. Los datos tienen valor, es difícil que los clientes o el gobierno sepan si una empresa los vende en secreto, y también es difícil saber si ahorró dinero en seguridad hasta que ya es demasiado tarde.
      Pero si los datos se cifran en el dispositivo del cliente y se puede demostrar matemáticamente que el servidor no puede acceder al texto plano, ya no hace falta preocuparse por eso. El problema aparece cuando el servidor no solo debe almacenar los datos, sino también procesarlos; en ese caso, la solución técnica pasa por usar servidores propios.
    • Dudo que un contrato así resuelva realmente el problema. Aunque un servicio en la nube documente que avisará con X meses de anticipación antes del cierre y permitirá exportar los datos, lo que queda en la práctica después del cierre puede ser un enorme archivo JSON prácticamente inútil.
      Es difícil aprovecharlo a menos que uno mismo cree una app o alguien amable la cree. Es mejor que nada, pero no tan bueno como una app local que pueda seguir funcionando durante años o décadas después de que la empresa cierre o deje de dar soporte.
    • Este modelo podría convertir a los proveedores de la nube en algo parecido a bancos. El proveedor de la nube guarda una especie de propiedad dentro de la cuenta del usuario, y el usuario tiene derechos claros sobre esa propiedad y capacidad legal para recuperarla de la cuenta.
      En finanzas, recuperar algo equivale a recibir dinero o bienes; en la nube, podría ser recibir un gran archivo Zip con todo el contenido de la cuenta.
      Pero recibirlo no siempre es práctico ni deseable. En finanzas, se puede transferir una cuenta a otro proveedor, y en los servicios en la nube, en muchos casos una transferencia de cuenta probablemente sea mucho más útil.
      La dificultad aquí es la portabilidad. Aunque se definan bien los derechos de propiedad y los derechos del usuario sobre una cuenta en la nube, queda ambiguo qué significa recibir tus amigos de Facebook, o qué significa transferir una cuenta de Facebook a otro lugar.
    • Creo que esa interpretación no es correcta. Los autores reconocen plenamente que el caso de negocio de local-first no está completamente resuelto y que es un problema estrechamente relacionado.
      Este problema necesita tanto soluciones de negocio como soluciones técnicas, y el paper propone qué características deberían tener esas soluciones.
      Tampoco es correcto decir que local-first defiende la descentralización. Martin Kleppmann indicó explícitamente que no considera que la tecnología descentralizada resuelva este problema de una forma que pueda llegar al mercado masivo. Él apoya un motor de sincronización estándar centralizado que haga posibles los ideales de local-first.
      Ver la charla de la Local-first conf del año pasado: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • Las garantías de portabilidad de datos no son prácticas para datos de cierto tamaño. Migrar una base de datos de producción a una nueva base de datos puede llevar de meses a años si se quiere hacer sin problemas.
      En una situación de crisis, puede hacerse en pocas semanas, pero puede quedar muy desordenado. Incluso al pasar entre bases de datos open source de la misma versión, ocurre lo mismo por las muchas diferencias entre servicios en la nube.
      La mejor solución es mantener los datos en tu propio entorno desde el principio y desconectarlos si hace falta. Esto es posible combinando la gestión BYOC con open source. Nuestra empresa también opera productos de datos BYOC, así que tenemos un interés económico en este enfoque, pero sabemos que es posible porque lo hemos visto funcionar.

  • Con mis proyectos https://github.com/ibizaman/selfhostblocks y https://github.com/ibizaman/skarabox intento hacer que justamente eso sea ampliamente posible
    El objetivo común es hacer que el self-hosting sea más accesible para el público general
    Basado en NixOS, busca ofrecer de forma predeterminada https, SSO, LDAP, backups, ZFS con snapshots, etc., de la manera más declarativa posible
    Al empaquetar Vaultwarden y Nextcloud, puede almacenar la mayor parte de los datos, así que compite con el hosting en la nube, y también ofrece servicios como Home Assistant
    También compite con YUNoHost, pero SelfHostBlocks es, o intenta ser, mejor porque permite hacer self-hosting directamente del paquete que quieras con los componentes de configuración que ofrece. Es más una biblioteca que un framework
    También compite con los NAS, pero considero que es mejor porque todo es open source. Por ahora el usuario todavía tiene que ser técnico, pero estamos eliminando esa restricción, y uno de los objetivos es que cualquiera pueda instalarlo en su propio hardware sin saber Nix ni tocar la línea de comandos

    • Muy bueno. Últimamente he estado pensando mucho en esto. Es raro que haya tantas alternativas libres y open source excelentes que, aunque para alguien técnico sean relativamente fáciles con algo como “docker compose up”, sigan siendo inaccesibles para personas no técnicas
      Muchas apps que pueden autoalojarse son aplicaciones web con base de datos, servidor y frontend, pero en muchos casos de uso se usan en una sola computadora y no hace falta una versión alojada ni sincronización con otros dispositivos. Por ejemplo, la contabilidad personal basta con hacerla en la computadora una vez al mes, así que no hace falta tener una app web corriendo 24/7 en algún lado. Abres el programa, trabajas y luego lo cierras
      Hay una gran brecha entre la cantidad de alternativas libres y open source autoalojables de alta calidad y la cantidad de personas que realmente pueden usarlas. Hacen falta más proyectos que reduzcan esa brecha. Voy a probar selfhostblocks para algunas cosas y tratar de contribuir
    • Me gusta que incluya hledger. Para quienes no están acostumbrados a la contabilidad en texto plano puede ser un poco raro, pero es un software realmente excelente

  • No hay razón para que todas las aplicaciones tengan su propia plataforma de sincronización. Este encuadre parece venir de las apps móviles, donde no hay composabilidad ni modularidad entre programas
    Si te tomas en serio lo de “local-first”, simplemente puedes usar el sistema de archivos, y el usuario puede elegir entre varias soluciones como git, Box, etc.
    Exigir una suscripción a una sincronización propia me desagrada tanto como cualquier otro SaaS, e incluso es más opaco y frágil

    • Estoy de acuerdo en que no todas las apps necesitan su propio motor de sincronización, pero no estoy de acuerdo con presentar el sistema de archivos como la forma universal de adoptar el enfoque local-first
      Primero, quiero local-first, pero también quiero concurrencia. Si fuera solo local-first, cualquier sincronización serviría, pero quiero algo más que eso. Quiero que funcione sin problemas, como Dropbox, sin tener que preocuparme, y que mi esposa y yo podamos hacer cambios por separado desde nuestros teléfonos incluso en zonas sin comunicación
      Segundo, la sincronización funciona mucho mejor cuando conoce a fondo la estructura y el significado de los datos. Tanto git como Box tienen limitaciones importantes, y esas limitaciones se vuelven mayores cuando hay requisitos de concurrencia
    • En general estoy de acuerdo, pero en la práctica no siempre es tan simple. Hice una app que funcionaba exactamente así, pero como no podía coordinar cuándo y qué cliente debía estar autorizado a editar archivos, al final los conflictos de archivos se volvieron inevitables

  • En teoría me gusta el enfoque de desarrollo local-first. Encaja bien con la filosofía de small tech, que toma la privacidad y la propiedad de los datos como valores predeterminados
    Pero en la práctica es difícil. Básicamente hay que crear un motor de sincronización, manejar la resolución de conflictos y gestionar migraciones de esquema
    Aun así, parece que en los últimos años las herramientas para desarrollar software local-first han mejorado. Estoy siguiendo jazz.tools, electric-sql y Zero de Rocicorp, y me da curiosidad si hay otras

    • CouchDB en el servidor y PouchDB en el cliente fueron intentos de crear ese tipo de entorno
      https://couchdb.apache.org/
      https://pouchdb.com/
      También se pueden ver más reflexiones sobre el desarrollo de aplicaciones local-first de hace unos 10 años aquí: https://unhosted.org/
    • Durante más o menos el último mes estuve usando instantdb bastante en serio en un proyecto paralelo de una app de presupuesto personal
      Tendría que escribir una entrada de blog, pero antes investigué PowerSync, electricSQL, LiveStore, PowerSync, y también miré un poco jazz.tools, aunque quería algo más estructurado
      Hasta ahora me ha impresionado bastante. La estoy escribiendo con Vue y una biblioteca de la comunidad; los permisos fueron un poco complicados, pero una vez que los entendí resultaron simples. También me gusta el inicio de sesión con email mágico, y las funciones de dashboard/respuesta son buenas, aunque parece que necesitaría algunos cambios importantes para que sea menos engorroso
      Me gusta que sea open source y que se pueda autoalojar si uno quiere. A jazz le faltaba estructura, y en LiveStore el almacén de eventos parecía demasiado engorroso, aunque tenía su atractivo. Me dio pena que las herramientas de desarrollo estuvieran detrás de un muro de pago, pero lo entiendo. electricSQL ofrecía la mitad de la solución, es decir, solo lectura, y le faltaba un modelo de escritura. CouchDB/PouchDB también me parecieron faltos de estructura, y quería que el soporte entre documentos estuviera integrado de forma más clara. Zero no lo investigué a fondo
    • Me pregunto si conoces este sitio: https://www.localfirst.fm
      En realidad quería apuntar al enlace “landscape” del menú superior, pero la URL es bastante incómoda
    • Hace poco vi que alguien mencionó Automerge
      https://automerge.org/
      Tiene implementaciones en Rust y JavaScript, y también ofrece varias estrategias de red. No viene con una combinación de productos gratis/de pago como jazz.tools, pero está bastante bien
    • Ditto también vale la pena verlo
      https://www.ditto.com
      Es una plataforma local-first que admite sincronización en tiempo real con CRDT como núcleo, lo que facilita mucho la gestión de resolución de conflictos. Está diseñada para manejar de forma nativa casos de uso offline-first y sincronización peer-to-peer, así que no hace falta crear un motor de sincronización desde cero
      Soporta muchas plataformas, incluidas Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java y Rust. Se puede ver más documentación aquí: https://docs.ditto.live/home/about-ditto