Software local-first (2019)

• Software local-first é uma abordagem que busca realizar ao mesmo tempo as vantagens da colaboração baseada em nuvem e da propriedade dos dados pessoais
• Os apps de nuvem existentes se destacam em colaboração em tempo real e acessibilidade, mas causam problemas como propriedade dos dados e acessibilidade de longo prazo
• O software local-first considera o armazenamento local como o local padrão de armazenamento dos dados, oferecendo adicionalmente recursos de sincronização e colaboração
• Esse tipo de software oferece vantagens em velocidade, suporte offline, privacidade e controle do usuário, mas também apresenta dificuldade de implementação em áreas como colaboração em tempo real e sincronização entre múltiplos dispositivos
• Para tornar esse software viável, vários modelos tecnológicos existentes estão sendo comparados e analisados, e explora-se a possibilidade de desenvolver modelos mais ideais no futuro

---

Limites dos apps em nuvem e da propriedade dos dados

• A maioria dos usuários utiliza vários apps em nuvem, como Google Docs, Figma e Slack, para diferentes fins, como escrever documentos, projetar e colaborar
• Esses serviços são acessados por navegador ou app móvel e, na maior parte dos casos, armazenam os dados no servidor
• O software baseado em nuvem tem a vantagem de permitir colaboração e acesso aos dados de qualquer lugar, mas quanto mais tempo se investe no app, maior fica o valor dos dados dentro dele
• Por meio de entrevistas com especialistas, confirmou-se que, por trás das vantagens funcionais dos apps em nuvem, existem desvantagens críticas como perda de propriedade e incerteza sobre o acesso de longo prazo
• Há ansiedade psicológica e riscos práticos no fato de que o direito do usuário de preservar e possuir materiais e dados criados ou produzidos por ele mesmo é limitado

O significado da posse real dos dados

• Os dados armazenados na nuvem parecem ser “seus”, mas o poder real de controle de gestão e acesso está com o provedor do serviço em nuvem
• Em caso de encerramento do serviço ou falha no servidor, surgem impossibilidade de acesso aos dados e dificuldades para sua preservação de longo prazo
• O ponto central do problema não é a propriedade intelectual em si, mas a sensação de posse e de controle sobre os dados que o usuário percebe
• Aplicativos antigos centrados em armazenamento local, como editores de texto, sistemas de controle de versão e várias ferramentas, garantem propriedade plena dos dados e autonomia

Comparação entre as vantagens e desvantagens da nuvem e do local

• “Apps em nuvem = colaboração e acessibilidade”, “apps locais = propriedade e autonomia”
• Em vez de uma escolha binária, surge a necessidade de buscar a melhor combinação em um modelo híbrido
• Propriedade dos dados e colaboração em tempo real não são necessariamente conflitantes, e é possível projetar um modelo de software que alcance ambos
• Isso é definido como software local-first, propondo como estrutura básica a combinação de armazenamento local, rede e servidores auxiliares

As 7 qualidades do software local-first

• Nos apps em nuvem, como o servidor atua como a “cópia principal” dos dados, cada solicitação exige ida e volta ao servidor, o que causa latência na experiência do usuário
• Já o software local-first trata a cópia no armazenamento local como a versão principal dos dados, deixando a sincronização (via servidor) como algo secundário
• Essa mudança de perspectiva traz vantagens reais em velocidade de resposta, suporte offline e controle sobre os dados

1. Velocidade (resposta rápida)

• Apps local-first processam todas as operações no sistema de arquivos local, podendo alcançar resposta imediata ao usuário sem atrasos de espera por requisições ao servidor
• A sincronização é tratada silenciosamente em segundo plano, de modo que a experiência do usuário não seja interrompida em nenhum momento

2. Sincronização entre múltiplos dispositivos

• Como o usuário moderno trabalha em vários dispositivos, apps local-first também precisam obrigatoriamente de sincronização de dados entre dispositivos
• A sincronização em nível de arquivo é fácil para um único usuário, mas quando várias pessoas editam ao mesmo tempo, surgem problemas de conflito (Conflict)

3. Prioridade ao offline

• O software local-first permite criar e editar dados a qualquer momento em estado offline, sincronizando automaticamente mais tarde quando a rede voltar
• É possível compartilhar e sincronizar dados entre dispositivos por vários meios, como Bluetooth e WiFi local
• Para um suporte offline de verdade, prefere-se a forma de executável instalado localmente

4. Colaboração e gestão de conflitos

• Métodos tradicionais, como anexos de e-mail e ferramentas de controle de versão, têm o inconveniente de conflitos e mesclagem manual quando várias pessoas trabalham ao mesmo tempo no mesmo arquivo
• Apps em nuvem, como Google Docs, minimizam a dificuldade e os conflitos da colaboração com recursos de edição simultânea em tempo real
• O software local-first também tem potencial para implementar vários fluxos colaborativos, como colaboração em tempo real, sugestão de mudanças e aprovação, sendo uma área de desafio técnico

5. Preservação de longo prazo dos dados

• Ao usar apps local-first, o acesso aos dados é garantido mesmo que a empresa de software deixe de existir
• Formatos de arquivo comuns, como texto, PDF e JPEG, podem manter compatibilidade por muito tempo, e mesmo formatos incompatíveis podem ser acessados por máquinas virtuais ou emuladores
• Sem verdadeira preservação de longo prazo dos dados, o problema da era das trevas digital — em que a humanidade futura não consegue acessar nem interpretar os dados de hoje — pode se tornar realidade

6. Privacidade e segurança

• Estruturas centralizadas na nuvem são vulneráveis a vários incidentes de segurança, como hackeamento e abuso por funcionários internos
• Profissionais que lidam com informações pessoais e dados sensíveis podem, numa estrutura local-first, garantir segurança e independência dos dados por meio de criptografia de ponta a ponta
• Grandes empresas como o Google podem utilizar internamente os dados de várias formas, enquanto o software local-first dá o controle ao titular dos dados

7. Propriedade e controle do usuário

• O acesso aos dados pode ser bloqueado ou restringido arbitrariamente por provedores de serviços em nuvem, por exemplo devido a sinalizações automáticas incorretas ou mudanças de política
• Em um ambiente local-first, o próprio usuário decide sobre uso, modificação, backup e armazenamento dos dados
• Isso não diz respeito apenas ao direito autoral legal, mas à autonomia real do usuário e ao controle sobre os dados

Comparação entre vários modelos de software

• Anexo de e-mail + arquivo local: excelente em velocidade, offline, preservação de longo prazo e controle, mas inconveniente em colaboração e sincronização entre dispositivos
• Webapps em nuvem (Google Docs, Trello etc.): excelentes em colaboração em tempo real e acessibilidade, mas fracos em velocidade, offline, propriedade e privacidade
• Serviços de sincronização de arquivos (Dropbox etc.): excelentes em velocidade, offline, preservação de longo prazo e controle, mas com limites em colaboração e no ambiente móvel
• Sistemas de controle de versão (Git etc.): excelentes em velocidade, offline, preservação de longo prazo e controle, mas fracos com arquivos não textuais e colaboração em tempo real
• Clientes móveis (Firebase, CloudKit etc.): fortes em sincronização e offline, mas com limites em privacidade de dados pessoais e continuidade do serviço no longo prazo
• Replicação multimaster (bancos de dados, ex.: CouchDB): forte em offline e sincronização, mas difícil ou insuficiente para realizar plenamente ideais como colaboração, privacidade e controle

Perspectiva dos desenvolvedores de software e direção futura

• O software local-first ideal precisa projetar e implementar desde o início offline, sincronização entre múltiplos dispositivos, colaboração em tempo real, privacidade e controle do usuário
• Porém, na prática, ainda não existe uma tecnologia aberta que satisfaça todos esses ideais ao mesmo tempo
• Novas tecnologias concebidas em pesquisas recentes em ciência da computação, como Conflict-free Replicated Data Types (CRDTs) e métodos de sincronização de dados distribuídos, podem se tornar a base central para viabilizar o software local-first no futuro

Conclusão

• O software local-first é uma direção importante capaz de equilibrar colaboração e independência, privacidade e soberania dos dados na era digital
• Ele oferece a especialistas, criadores e outros uma sensação de posse sobre os dados e proteção de longo prazo, e há expectativa de que gere mudanças positivas em toda a indústria
• Daqui para frente, será necessário continuar pesquisando e experimentando infraestruturas, ferramentas de desenvolvimento, arquiteturas e algoritmos melhores para realizar esse ideal

[GN⁺]

Comentários no Hacker News

• Me identifiquei demais com isso. Também estou desenvolvendo para resolver esse tipo de problema e já cansei desse modelo de jogar meus dados na nuvem e ainda pagar assinatura. No momento estou criando um app de acompanhamento fitness e pretendo aplicar o modelo do Sublime: compra única no início, atualizações por alguns anos, sincronização entre todos os dispositivos e uso vitalício. Depois, se quiser mais atualizações, basta comprar a nova versão. Se a qualidade for boa o suficiente, a meta é que a pessoa possa continuar usando daquele jeito para sempre. Eu gostaria desse modelo para 90% de todo o software. Tem que dar para comprar por um preço justo, o produto em si precisa ser bom, e é importante que funcione direito mesmo sem integração com a nuvem. Não é só questão de privacidade de dados; esse modelo tem muitas vantagens. Ainda há desafios, como tooling, mas a base técnica já existe. A maior vantagem do software local-first é a estrutura saudável de incentivos. Em vez de anúncios, rastreamento de usuários e maximização de “engajamento”, é um modelo em que a recompensa vem do próprio produto. Passa uma sensação de software realmente centrado no usuário.

  • O modelo do app de notas Obsidian também é um ótimo exemplo. O cliente é gratuito e o serviço de sincronização é vendido como opcional. E o fato de as notas serem arquivos Markdown é um grande ponto forte, já que você nem precisa do cliente.

  • Fiquei curioso sobre como você pretende lidar com a sincronização sem usar infraestrutura de nuvem.

  • Concordo totalmente. Se não se importar, também queria saber mais sobre a stack do app de fitness. Principalmente como você está lidando com a sincronização entre dispositivos.

  • Também existem muitos apps puramente locais monetizados com anúncios, então “sem anúncios” nem sempre vale.

• Neste momento está acontecendo em Berlim, com bastante força, a conferência Local-first Software (https://www.localfirstconf.com/), organizada pela Ink and Switch, e neste ano surgiu até a Sync Conf (https://syncconf.dev/) em novembro, em San Francisco. Em uma conferência recente, os coautores do artigo participaram de um painel e foi muito útil ouvir o que aprenderam no contexto de ferramentas de desenvolvimento para software local-first. Recomendo muito o vídeo do painel. Na comunidade, “Sync” está se consolidando como elemento central do local-first, e a tendência é ver ferramentas de desenvolvimento, como motores de sincronização, apenas como ferramentas de suporte para implementar características local-first, e não como o próprio local-first. A coletânea completa das palestras dos últimos anos também foi enviada aqui. O desenvolvimento de ferramentas para colaboração em tempo real e assíncrona está a todo vapor, e com a chegada recente da IA o mercado está cada vez mais demandando esse tipo de motor de sincronização. Aplicativos de IA são, em essência, ambientes multiusuário de colaboração, então estamos entrando numa era em que a base técnica da comunidade de motores de sincronização se torna necessária.

• Já houve discussões muito ativas sobre esse tema antes, então vale a leitura se você tiver curiosidade: 2019-05, 191 comentários
  2019-11, 241 comentários
  2020-07, 9 comentários
  2020-08, 134 comentários
  2021-02, 90 comentários
  2022-06, 30 comentários
  2023-10, 50 comentários

• Afirmam que não é necessário que todo app tenha sua própria plataforma de sync. Parece ser uma consequência da dificuldade, típica de apps móveis, de combinar e modularizar programas entre si. Se você quer local-first de verdade, basta usar o sistema de arquivos. Do ponto de vista do usuário, ele mesmo pode escolher entre várias soluções já existentes, como git, box etc. O próprio processo de cadastro no sync de cada app é tão opaco e sujeito a falhas quanto SaaS, então acaba sendo um peso.

  • Concordo que nem todo app precisa de um motor de sync, mas não acho que o sistema de arquivos seja uma solução universal para local-first. Há dois motivos. O primeiro é concorrência. Se a meta fosse só local-first puro, qualquer sync serviria, mas eu quero mais do que isso. Por exemplo, quero uma experiência em que eu e minha esposa possamos editar de forma independente nos nossos celulares, mesmo sem comunicação, e que depois tudo seja combinado automaticamente sem dor de cabeça. Quero uma sincronização tão natural quanto a do DropBox. O segundo motivo é que, para oferecer uma experiência de sync melhor, o motor precisa entender profundamente a estrutura e o significado dos dados. git ou box têm várias limitações diante desse desejo de edição semântica concorrente.

  • Na prática eu já implementei um modelo baseado apenas no sistema de arquivos, mas foi difícil coordenar entre clientes quando permitir edição do arquivo, então os conflitos de arquivo acabaram sendo inevitáveis.

• Sistemas que dependem do online inevitavelmente trazem custos de manutenção e operação. Sem um design local-first ou local-only, não dá para ter um sistema confiável por muito tempo. Eletrodomésticos conectados e carros do tipo conectado são exemplos de engenharia realmente idiota do ponto de vista prático.

  • No fim, tudo isso é por causa da receita de assinatura. Empresas com modelo de assinatura faturam mais, recebem mais investimento e vencem no mercado em relação às que não têm. É por isso que o software local-first desapareceu.

• Eu, por outro lado, sou crítico da visão de tentar resolver tecnicamente o problema de confiabilidade da nuvem evitando estruturas centralizadas. Antes, os problemas de software fechado — falta de controle e de confiança — eram resolvidos por modelos de negócio, como desenvolvimento open source e contratos de manutenção. Defendo que os problemas da nuvem também precisam de soluções de modelo de negócio. Por exemplo, poderíamos criar contratos ou licenças padrão que explicitem os direitos do usuário, e fazer o mercado escolher apenas fornecedores que adotem esse tipo de licença certificada. Seria possível incluir muitas cláusulas: garantia de portabilidade dos dados do usuário, divulgação transparente do uso dos dados, procedimentos definidos para encerramento do serviço etc. Claro, o maior obstáculo é por que os fornecedores aceitariam isso. Como eles têm medo de perder clientes, podem acabar oferecendo essa licença só em planos anuais ou cobrando extra.

  • Quando é possível abordar um problema de negócios/político com uma solução técnica, eu acho que isso costuma ser mais robusto. Porque permite bloquear tecnicamente interesses adversariais. Criptografia no cliente (client-side encryption) é o exemplo clássico. Há tentação demais para depender de política de privacidade ou de regras burocráticas, e fiscalizar ou detectar violações é difícil. Se os dados estiverem matematicamente criptografados de modo que o servidor não consiga lê-los, a preocupação desaparece. Só que, se você quiser que o servidor realmente processe esses dados, acaba entrando numa situação em que precisa usar o seu próprio servidor.

  • Por exemplo, mesmo que você resolva isso com contratos sobre encerramento, se o provedor de nuvem falir e apenas avisar os usuários e permitir exportar os dados, no fim o que sobra é só um arquivo JSON gigantesco. Sem você mesmo criar um app ou alguém criar um para você, isso na prática tem pouca utilidade. A intenção é boa, mas ainda fica aquém de um app local que permita usar de forma duradoura os dados de um app já extinto.

  • Mesmo cláusulas garantindo portabilidade de dados esbarram no fato de que, na prática, grandes migrações de dados são difíceis e demoradas. Fazer isso às pressas em uma situação de crise costuma piorar tudo. Mesmo entre bancos de dados open source da mesma versão, cada serviço tem tantas variáveis que não é simples. No fim, uma alternativa mais realista é manter os dados desde o início no seu próprio ambiente e ter a possibilidade de “desconectar da tomada” quando necessário. Há potencial na combinação de BYOC (bring your own cloud) com open source. Nossa empresa já opera um produto de dados em BYOC, então sei por experiência que essa estrutura é viável.

  • Mesmo que o contrato defina responsabilidades no encerramento de um serviço em nuvem, quando a empresa decide fechar as portas não é nada claro como isso seria de fato executado e administrado.

  • Não é só uma questão de negócios; a própria segurança dos dados também é um problema. Um dos principais motivos para evitar assinatura ou nuvem é a vontade de proteger meus dados. Dados transmitidos sem criptografia local estão sempre sujeitos a vazamento.

• Ler este texto me deu uma sensação de frescor. Acho que mais apps deveriam ser local-first. Se o usuário não quiser sincronização em nuvem, essa opção precisa ser garantida. O Brisqi (https://brisqi.com), que estou criando, também é um app baseado nessa filosofia offline-first. Um app local-first significa, basicamente, uma estrutura que funciona perfeitamente offline por tempo indeterminado. A experiência offline é o padrão, e o sync em nuvem é um aprimoramento adicional. Apps baseados em cache temporário não podem ser considerados offline-first. Os dados ficam salvos em um banco local; em um offline-first real, eles são preservados independentemente da internet. A maioria dos apps que se dizem “offline-first” na verdade é apenas offline-tolerant (suporte offline limitado). Criar um app offline-first é muito mais difícil do que fazer um webapp online-only. É essencial ter um mecanismo que sincronize de forma confiável, sem perda de dados, mesmo nas transições entre offline e online. O meu método de implementação está descrito no blog (https://blog.brisqi.com/posts/how-i-designed-an-offline-firs...).

• Esses princípios também fazem sentido mesmo quando o foco é o mercado consumidor. Hoje, na Sentinel Devices (www.sentineldevices.com), estamos desenvolvendo uma estrutura para ambientes industriais como SCADA e automação industrial, em que os dados não podem sair para fora de jeito nenhum, e tudo — execução, análise e tomada de decisão — acontece totalmente no equipamento do próprio cliente. Nem oferecemos servidor externo. Essa estrutura, focada no princípio on-device, dá uma espécie de choque de realidade tanto para clientes quanto para fornecedores. Muitas empresas de dados/IA ignoram esse mercado porque consideram difícil demais prestar serviços no ambiente do cliente. No nosso caso, acontece com frequência de o cliente só entender quando enfatizamos que é sem conectividade e com processamento totalmente local. Se esse hábito de local-first se tornar mais comum no mercado consumidor, a transformação no setor industrial também pode acelerar.

  • Até o setor de SCADA recentemente está empurrando tudo para a nuvem. O slogan é algo como “gerencie sua fábrica pelo smartphone”. Mas isso aumenta o risco de que até um hacker amador passe a ter acesso a controles de fábrica.

  • Acho essa área muito interessante e torço pelo trabalho de vocês. Uma dúvida: vi na página de carreiras que vocês só contratam presencial (onsite). Isso é porque desenvolvimento local-first realmente exige trabalho offline/presencial, ou é mais uma questão de gestão?

• Os projetos em que estou trabalhando (selfhostblocks, skarabox) também têm como objetivo facilitar o self-hosting para qualquer pessoa com base em NixOS. Fornecem de forma declarativa quase tudo: https, SSO, LDAP, backups, snapshots do ZFS etc. Dá para armazenar a maior parte dos dados em coisas como Vaultwarden e Nextcloud, e também inclui serviços como Home assistant. A proposta é competir com o YUNoHost, mas com objetivos melhores. O SelfHostBlocks funciona como um conjunto de blocos de construção de pacotes, que qualquer um pode estender livremente e self-hospedar. É mais uma abordagem de biblioteca do que de framework. Também serve como alternativa a NAS, e é totalmente open source. Pode até ser fácil para quem tem conhecimento técnico, mas o objetivo é reduzir a barreira de entrada para que pessoas comuns também consigam instalar isso no hardware, sem depender de nix ou CLI.

  • Torço muito por projetos assim. Existem muitas alternativas FOSS impressionantes, mas na prática só são fáceis de instalar para pessoas técnicas (algo no nível de “docker compose up”), então ainda há uma barreira para o público geral. Muitos apps self-hostable são estruturados como webapp + DB + servidor + frontend, mas no meu caso eu basicamente uso tudo em um único dispositivo. Um programa desktop totalmente local já bastaria, mas para quem não é desenvolvedor até isso pode ser inacessível. Existe claramente um desencontro entre FOSS self-hostável de alta qualidade e usuários reais. Precisamos de mais projetos que fechem essa lacuna. Também pretendo experimentar o selfhostblocks e torço pela evolução.

  • Gostei muito de ver o hledger incluído. Para iniciantes em contabilidade em texto puro isso pode soar um pouco incomum, mas é um software excelente.

  • A sensação é de muita gratidão por você ter feito isso de forma tão limpa e bem construída.

• Dando uma passada pelo texto, achei que a maioria dos pontos centrais foi bem coberta, mas a motivação do primeiro parágrafo parece fraca. Soa como dizer algo do tipo: “torta de maçã é gostosa e nutritiva, mas um dia pode pegar fogo de repente e até o babador que eu adorava vai desaparecer junto”.