Logiciel local-first : posséder ses données même à l’ère du cloud (2019)

• Les applications cloud ont considérablement amélioré la collaboration et l’accès depuis plusieurs appareils, mais comme la copie faisant autorité des données se trouve sur un serveur, la propriété et le contrôle de l’utilisateur s’en trouvent affaiblis
• Le logiciel local-first fait du stockage local des ordinateurs portables, tablettes et téléphones la copie principale des données, et limite le rôle du serveur à une fonction auxiliaire de synchronisation et de sauvegarde
• Cette approche vise simultanément une réponse rapide, le travail hors ligne, la synchronisation entre plusieurs appareils, la collaboration en temps réel, la conservation à long terme, ainsi que la sécurité et la confidentialité par défaut
• Les fichiers, l’e-mail, les applications web, la synchronisation de type Dropbox, Git, Firebase, CloudKit, Realm et CouchDB offrent chacun certains avantages, mais ne satisfont pas à la fois la collaboration et la propriété des données
• Les prototypes fondés sur les CRDT et Automerge ont montré un potentiel, mais des défis restent à relever en matière de performances, de communications réseau, de stabilité P2P et d’interface utilisateur pour les documents distribués

---

Le conflit entre collaboration cloud et propriété des données

• Les applications cloud comme Google Docs, Figma, Slack ou Trello sont accessibles via un navigateur ou une application mobile, et stockent les données sur des serveurs
• Ce modèle offre les avantages de la collaboration en temps réel et de l’accès depuis n’importe où, mais tout accès aux données doit passer par le serveur
  • Seules les opérations autorisées par le serveur sont possibles
  • Si le service s’interrompt, l’accès peut être bloqué non seulement au logiciel, mais aussi aux données créées avec ce logiciel
  • Même s’il est possible d’exporter les données, il est difficile de continuer à exécuter le même logiciel sans serveur
• À l’inverse, les anciennes applications locales lisent et écrivent des fichiers sur le disque local, ce qui permet à l’utilisateur de contrôler directement les sauvegardes, l’archivage à long terme, la manipulation par d’autres programmes et la suppression
• La tension centrale tient au fait que le cloud apporte la collaboration, tandis que les applications locales apportent la propriété ; le local-first est une orientation de conception qui cherche à obtenir les deux à la fois

Le modèle de base du logiciel local-first

• Le logiciel local-first donne la priorité au stockage local et au réseau local plutôt qu’aux serveurs de datacenters distants
• Dans les applications cloud, les données du serveur constituent la source faisant autorité, et les données du client ressemblent davantage à un cache dépendant du serveur
• Dans les applications local-first, les données locales de chaque appareil sont la copie principale, tandis que le serveur conserve une copie auxiliaire qui aide à l’accès depuis plusieurs appareils et à la sauvegarde
• Ce changement de perspective a un impact direct sur les performances, l’utilisation hors ligne, la conservation à long terme, la confidentialité et le contrôle par l’utilisateur

Les 7 idéaux du local-first

• 1. Des actions instantanées, sans spinner

  • Dans les applications cloud, la modification des données et de nombreuses consultations nécessitent un aller-retour avec le serveur, ce qui introduit de la latence
  • L’Optimistic UI masque cette latence en donnant l’impression que la requête est terminée, mais en cas d’erreur réseau, le délai réapparaît
  • Dans les applications local-first, les données principales se trouvent sur l’appareil local, ce qui réduit le besoin d’attendre une réponse du serveur aux saisies de l’utilisateur
  • La synchronisation s’effectue en arrière-plan, et l’application peut réagir presque instantanément aux saisies

• 2. Un travail qui n’est pas enfermé dans un seul appareil

  • Les utilisateurs passent d’un appareil à l’autre : capturer une idée sur smartphone, l’organiser sur tablette, la documenter sur ordinateur portable, par exemple
  • Les applications local-first doivent elles aussi conserver les données sur chaque appareil tout en assurant la synchronisation entre tous les appareils de travail
  • La plupart des services de synchronisation entre appareils stockent aussi une copie sur un serveur, qui sert de sauvegarde hors site
  • Lorsque plusieurs personnes modifient simultanément le même fichier, des conflits peuvent survenir, ce qui rend la conception de la collaboration importante

• 3. Le réseau comme option

  • Les avions, tunnels, ascenseurs, parkings, WiFi instables, frais d’itinérance, ainsi que les connexions Internet imparfaites dans les pays en développement et les zones rurales créent un besoin de travail hors ligne
  • Les applications cloud sont généralement faibles hors ligne, et il est également difficile d’ajouter après coup une prise en charge hors ligne à un modèle centré sur le serveur
  • Les applications local-first stockent les données principales dans le système de fichiers local de chaque appareil, ce qui permet de les lire et de les écrire même hors ligne
  • Lorsque le réseau redevient disponible, elles se synchronisent ensuite avec les autres appareils ; la synchronisation peut se faire non seulement via Internet, mais aussi par Bluetooth ou WiFi local
  • Pour une bonne expérience hors ligne, un exécutable installé localement convient mieux qu’un onglet de navigateur

• 4. Une collaboration fluide avec ses collègues

  • Les anciens logiciels fondés sur des fichiers locaux sont sujets aux conflits lorsque plusieurs personnes modifient simultanément le même fichier
  • Les applications cloud comme Google Docs ont popularisé une expérience où plusieurs utilisateurs modifient un document en même temps sans se soucier des conflits
  • L’idéal du local-first est de prendre en charge une collaboration en temps réel aussi bonne, voire meilleure, que celle des meilleures applications cloud actuelles
  • Les flux où un utilisateur propose une modification et où un autre la relit avant de l’intégrer sélectivement sont également importants
    • le suggesting mode de Google Docs
    • la pull request de GitHub

• 5. Long Now : l’accessibilité à long terme

  • Un aspect important de la propriété des données est de pouvoir encore y accéder longtemps dans le futur
  • Les anciennes applications locales peuvent continuer à être utilisées si l’on dispose des données et d’une copie exécutable du logiciel, et les anciens systèmes d’exploitation ou ordinateurs peuvent aussi être lancés dans des machines virtuelles ou des émulateurs
  • Même si les supports de stockage changent, les fichiers peuvent être copiés vers de nouveaux supports
  • Les applications cloud reposent sur l’hypothèse que le service continuera d’être fourni, et sont vulnérables à l’arrêt du service, à la perte de données, aux changements de prix ou de fonctionnalités, ainsi qu’aux mises à niveau forcées non souhaitées
  • Avec le logiciel local-first, les données et le logiciel qui permet de les lire et de les modifier sont stockés localement, ce qui augmente les chances de conservation à long terme
  • Le plain text, JPEG et PDF ont de bonnes chances de rester lisibles longtemps, et la Bibliothèque du Congrès des États-Unis recommande XML, JSON et SQLite comme formats de conservation de datasets

• 6. La sécurité et la confidentialité par défaut

  • Les applications cloud regroupent les données de tous les utilisateurs dans une base de données centrale, ce qui en fait une cible attrayante pour les attaquants
  • Des employés internes ou des hackers ayant accédé aux serveurs peuvent lire ou manipuler les données, et les fuites de données restent un risque courant
  • Les conditions de Google Drive indiquent que des systèmes automatisés analysent les contenus des utilisateurs afin de personnaliser les résultats de recherche et de détecter le spam et les malwares
  • Pour les professionnels de santé, les journalistes d’investigation, les responsables gouvernementaux ou diplomatiques et autres utilisateurs manipulant des données sensibles, l’usage d’applications cloud peut entrer en conflit avec des obligations réglementaires ou de confidentialité
  • Les applications local-first ne stockent sur chaque appareil local que les données propres à l’utilisateur, et peuvent ne conserver sur le serveur qu’une copie chiffrée de bout en bout
  • iMessage, WhatsApp, Signal, Keybase et Tarsnap sont cités comme exemples de chiffrement de bout en bout ou de partage et sauvegarde de fichiers chiffrés

• 7. Propriété et contrôle ultimes

  • Dans les applications cloud, le fournisseur du service peut restreindre l’accès de l’utilisateur
  • En octobre 2017, certains utilisateurs de Google Docs se sont vu bloquer l’accès à leurs documents après qu’un système automatisé les a signalés à tort comme malveillants
  • Ici, la propriété ne désigne pas les droits de propriété intellectuelle, mais l’agentivité de l’utilisateur, son autonomie et son contrôle sur les données
  • Dans un logiciel local-first, les octets qui composent les données se trouvent sur les appareils de l’utilisateur, ce qui lui donne la liberté de les traiter de manière arbitraire
  • La propriété des données s’accompagne aussi de responsabilités : maintenir des sauvegardes, éviter la perte de données, faire face aux ransomwares et gérer les archives de fichiers
  • Le local-first ne doit pas nécessairement être open source ; un logiciel commercial et propriétaire peut aussi se rapprocher de cet idéal s’il ne limite pas artificiellement l’usage des fichiers
  • Les PDF qui empêchent l’impression, les liseuses eBook qui entravent le copier-coller et les DRM sur les fichiers multimédias sont cités comme exemples de restrictions artificielles

Limites des modèles existants de stockage et de partage

• Fichiers et pièces jointes d’e-mail

  • Les fichiers traditionnels sont très efficaces pour la consultation et l’édition hors ligne, le contrôle par l’utilisateur, les sauvegardes, la conservation à long terme et l’accès rapide
  • L’accès depuis plusieurs appareils nécessite des méthodes comme l’e-mail, l’USB, NAS/NFS/FTP/rsync, la synchronisation de fichiers à la Dropbox, ou Git
  • Les pièces jointes d’e-mail sont faciles à comprendre et fiables ; même six mois plus tard, la pièce jointe reste dans sa forme d’origine
  • Leur point faible est la collaboration
    • En général, une seule personne à la fois peut modifier un fichier
    • Si plusieurs personnes l’éditent, une fusion manuelle est nécessaire
    • Cela crée une confusion dans les noms de fichiers, comme Budget draft 2 (Jane's version) final final 3.xls
  • Les apps qui veulent appliquer l’idée du local-first peuvent commencer par proposer l’export dans des formats largement pris en charge comme le plain text, PDF, PNG ou JPEG

• Apps web

  • Dans des apps web comme Google Docs, Trello, Figma ou Pinterest, le navigateur ou l’app mobile est un client léger et le stockage des données se trouve sur le serveur
  • Les apps web ont établi le standard de la collaboration en temps réel, avec le grand avantage de permettre aux équipes de consulter partout la version la plus récente
  • En contrepartie, la propriété et le contrôle sont fortement réduits
    • Les données serveur font autorité, tandis que les données côté client ressemblent davantage à un cache
    • Même une brève coupure réseau peut bloquer l’accès en plein travail
    • La prise en charge hors ligne limitée, comme le plugin Google Docs offline, ressemble plutôt à un ajout a posteriori sur une architecture centrée serveur
  • Même les clients desktop installables comme Milanote et Figma sont essentiellement des navigateurs reconditionnés, ce qui révèle leurs limites en cas de panne réseau, d’interruption serveur ou d’arrêt du service

• Dropbox, Google Drive, Box, OneDrive

  • Dropbox, Google Drive, Box et OneDrive surveillent un dossier désigné sur le bureau et copient les fichiers modifiés vers d’autres ordinateurs
  • Comme ils utilisent le système de fichiers local, ils sont rapides et permettent de travailler hors ligne ; même si le service de synchronisation s’arrête, les fichiers restent sur le disque local
  • En cas de panne de disque dur, on peut réinstaller l’app et attendre la synchronisation pour restaurer les données, ce qui constitue un avantage en matière de longévité et de contrôle
  • Sur mobile, iOS et Android, ils se rapprochent d’un modèle de client léger qui ne synchronise pas tout le dossier, mais récupère les fichiers un par un depuis le serveur
  • L’option « Make available offline » doit être configurée à l’avance, elle est fastidieuse, et ne fonctionne que lorsque l’app est ouverte
  • Le point le plus faible est la collaboration en temps réel
    • Si le même fichier est modifié sur deux appareils, un conflit apparaît et nécessite une fusion manuelle
    • La possibilité de synchroniser des formats de fichiers arbitraires est un avantage de compatibilité, mais devient aussi une faiblesse puisqu’il n’est pas possible d’effectuer une fusion propre à chaque format

• Git et GitHub

  • Git et GitHub sont surtout utilisés pour la collaboration sur du code source et sont considérés aujourd’hui comme le package logiciel le plus proche du local-first
  • Un dépôt Git constitue la copie principale des données dans le système de fichiers local et ne dépend pas d’un serveur
  • Il offre un travail entièrement hors ligne, des opérations rapides, le contrôle par l’utilisateur et une bonne adéquation à la conservation à long terme
  • GitHub fournit la collaboration, l’accès depuis plusieurs appareils, ainsi qu’un emplacement de sauvegarde et d’archivage, mais ne chiffre pas les dépôts
  • Git a deux grandes faiblesses
    • Il ne propose pas de collaboration avec fusion automatique fine et en temps réel comme Google Docs, Trello ou Figma
    • Il est optimisé pour le code et le texte basé sur des lignes ; les autres formats de fichiers sont traités comme des blobs binaires difficiles à éditer et à fusionner de façon significative
  • Le fait que de nombreux ingénieurs logiciel citent « c’est lent », « je n’ai pas confiance » et « je veux garder mon code sur mon système local » pour expliquer leur réticence envers les éditeurs et environnements d’exécution cloud comme Cloud9, Repl.it ou Colaboratory rejoint les motivations du local-first

Options du point de vue de l’infrastructure développeur

• Apps web à client léger

  • C’est le modèle où un serveur Rails, Django, PHP ou Node.js stocke les données dans une base SQL ou NoSQL et sert des pages web via HTTPS
  • Aucune installation n’est nécessaire, l’utilisateur n’a qu’à visiter une URL, et la responsabilité de la gestion des données revient à l’équipe engineering et DevOps qui a déployé le service
  • Meteor, ShareDB, Pusher, Ably et WebSocket facilitent l’ajout de fonctions de collaboration en temps réel aux apps web
  • Si chaque action utilisateur nécessite une requête serveur, l’expérience ralentit ; même si le JavaScript côté client masque les allers-retours, cela casse facilement avec un Internet instable
  • Malgré les efforts autour de manifest, localStorage, service worker et Progressive Web Apps, l’architecture des apps web reste fondamentalement centrée serveur
  • Quand on efface les cookies dans un navigateur, les données du stockage local sont souvent supprimées en même temps, ce qui n’est pas adapté au stockage à long terme de données importantes
  • L’auto-hébergement d’une app web open source par l’utilisateur peut améliorer certaines propriétés, mais comme la plupart des utilisateurs ne veulent pas devenir administrateurs système, ce n’est pas une option réaliste pour la majorité

• Apps mobiles utilisant un stockage local

  • Les apps iOS et Android téléchargent un binaire et l’installent localement, mais beaucoup d’apps comme Twitter, Yelp ou Facebook sont des clients légers qui nécessitent un serveur pour fonctionner
  • Les apps qui enregistrent d’abord les données sur l’appareil local via une couche de persistance comme SQLite, Core Data ou de simples fichiers se rapprochent davantage de l’idéal local-first
  • Clue et Things sont des exemples d’apps mono-utilisateur qui ont ensuite ajouté un backend cloud pour la synchronisation entre appareils ou le partage
  • Ces apps à client lourd sont rapides et fonctionnent hors ligne, car la synchronisation avec le serveur se fait en arrière-plan
  • La difficulté augmente lorsque plusieurs appareils ou plusieurs utilisateurs collaborateurs modifient les données
  • Les développeurs mobiles sont généralement des spécialistes du développement d’apps pour utilisateurs finaux, pas des spécialistes des systèmes distribués
  • Les algorithmes ad hoc de diff, de merge et de résolution de conflits sont souvent peu fiables et fragiles

• Firebase, CloudKit, Realm

  • Firebase est un BaaS mobile qui combine une base de données locale sur l’appareil, un service de base de données cloud et la synchronisation entre les deux
  • Firebase prend en charge le partage entre plusieurs appareils et l’usage hors ligne, mais comme c’est un service d’hébergement propriétaire, ses scores en matière de confidentialité et de longévité sont faibles
  • Parse a été acquis par Facebook puis arrêté en 2017, ce qui a obligé les apps qui en dépendaient à migrer vers un autre backend
  • La console Firebase offre aux développeurs une bonne expérience pour consulter, modifier et supprimer les données, mais les utilisateurs ne disposent pas de moyens équivalents d’accès, de manipulation et de gestion de leurs données
  • Apple CloudKit offre une expérience similaire à Firebase aux apps qui peuvent se limiter à iOS et Mac
    • Stockage clé-valeur et synchronisation
    • Bonnes fonctions hors ligne
    • Intégration à la plateforme, réduisant la friction liée à la création de compte et à la connexion
  • Realm a gagné en popularité comme bibliothèque de persistance locale pour iOS, et Realm Object Server peut être open source et auto-hébergé, ce qui réduit le risque de dépendance au service

• CouchDB

  • CouchDB s’est fait remarquer par son approche de multi-master replication, où plusieurs machines possèdent une copie complète de la base de données et où chaque réplique peut produire des changements indépendamment
  • Cloudant en est la version hébergée, tandis que PouchDB et Hoodie utilisent le même protocole de synchronisation et sont conçus pour fonctionner sur les appareils des utilisateurs finaux
  • Philosophiquement, CouchDB est proche des principes local-first, mais les données modifiées simultanément doivent être résolues explicitement par le code applicatif
  • Dans des apps collaboratives fines comme Google Docs, où chaque frappe peut devenir un changement distinct, il est difficile d’écrire un code de résolution de conflits correct
  • Parmi les raisons avancées pour expliquer son adoption limitée figurent la scalabilité de bases séparées par utilisateur, l’intégration d’un client JavaScript dans des apps natives iOS et Android, la résolution de conflits, et le caractère peu familier du modèle de requêtes MapReduce

Les CRDT et de meilleures technologies de base

• Les couches de données existantes pour le développement d’applications ne satisfont pas tous les idéaux du local-first
• Ink & Switch a commencé ses recherches il y a trois ans pour trouver une solution, et présente comme base prometteuse les Conflict-free Replicated Data Types, ou CRDT
• Les CRDT sont des structures de données génériques apparues en 2011 dans la recherche universitaire en informatique
• Elles stockent l’état d’un document comme des structures de données telles que des hash maps ou des listes, mais sont conçues dès le départ pour des environnements multi-utilisateurs
• Les éditeurs de texte, tableurs et applications de graphisme vectoriel maintiennent chacun l’état de leurs documents sous forme de structure de données ; dans les applications collaboratives multi-utilisateurs, celle-ci peut être remplacée par un CRDT

• Le mode de fusion des CRDT

  • L’utilisateur peut consulter et modifier l’état de l’application sur son appareil local, même hors ligne
  • Les CRDT suivent les modifications et, lorsque le réseau est disponible, les synchronisent en arrière-plan avec les autres appareils
  • Si de nouvelles tâches sont ajoutées simultanément depuis différents appareils, l’état fusionné contient tous les éléments ajoutés dans un ordre cohérent
  • Les modifications simultanées portant sur des objets différents peuvent être fusionnées facilement
  • Le cas difficile à résoudre automatiquement est celui où plusieurs utilisateurs mettent à jour simultanément le même attribut du même objet ; les CRDT gardent la trace des valeurs en conflit et laissent l’application ou l’utilisateur les résoudre
  • Les CRDT ressemblent à Git, mais fonctionnent sur des types de données plus riches que des fichiers texte
  • Le canal de synchronisation peut être n’importe quoi : serveur, connexion P2P, Bluetooth, clé USB, etc.
  • L’unité de modification peut être aussi petite qu’une simple frappe, ce qui permet une collaboration en temps réel à la Google Docs, ou être envoyée par gros blocs comme une pull request Git

• Automerge et Hypermerge

  • Ink & Switch a développé Automerge, une implémentation CRDT open source en JavaScript
  • Automerge s’appuie sur les recherches autour des CRDT JSON
  • En combinant Automerge avec la pile réseau Dat, ils ont créé Hypermerge
  • Il est difficile de dire que ces bibliothèques concrétisent pleinement les idéaux du local-first ; beaucoup de travail reste nécessaire
  • Les CRDT ont le potentiel de devenir une technologie de base pour les logiciels collaboratifs où les utilisateurs possèdent leurs données, au même titre que le packet switching pour Internet ou l’écran tactile capacitif pour les smartphones

Les prototypes d’Ink & Switch

• La validation des algorithmes et de la théorie des CRDT a progressé dans le monde académique, mais leur usage industriel reste limité et se fait surtout dans l’informatique centrée serveur
• Des exemples de systèmes centrés serveur utilisant des CRDT incluent Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi et Facebook OpenR
• Ink & Switch a créé des prototypes d’applications collaboratives local-first pour le travail créatif, utilisant des CRDT sur les appareils des utilisateurs finaux
• Les expérimentations portent sur trois questions
  • Faisabilité technique : à quel point les CRDT sont-ils proches d’un logiciel réel ?
  • Expérience utilisateur : peut-on obtenir une collaboration en temps réel de type Google Docs et une collaboration asynchrone adaptée au hors-ligne de type Git, sans serveur central faisant autorité ?
  • Expérience développeur : en quoi une couche de données CRDT diffère-t-elle d’une base SQL, d’un système de fichiers ou de Core Data ?
• Les trois prototypes ont été réalisés avec Electron, JavaScript et React, et le fait qu’il s’agisse de logiciels téléchargeables et installables est considéré comme important pour le sentiment de propriété

• Trellis

  • Trellis est un Kanban board inspiré de Trello
  • WebRTC a été expérimenté comme couche de communication réseau
  • Un historique des modifications inspiré de Git et de la fonction “See New Changes” de Google Docs a été conçu
  • L’utilisateur peut consulter les tâches du Kanban board et revenir à un état antérieur du document

• Pixelpusher

  • Pixelpusher est un programme de dessin collaboratif qui ajoute une expérience de collaboration en temps réel à la Figma au projet Pixel Art to CSS de Javier Valencia
  • La communication réseau a été expérimentée avec la bibliothèque P2P du projet Dat
  • Des URL de partage de document, un système visuel de branch/merge inspiré de Git, une résolution des conflits mettant en évidence les pixels conflictuels en rouge, ainsi qu’une identification utilisateur de base fondée sur des avatars dessinés par les utilisateurs ont été expérimentés

• PushPin

  • PushPin est un espace de travail sur canvas mixed media similaire à Miro ou Milanote
  • C’est le troisième projet basé sur Automerge et le plus abouti des trois prototypes
  • L’utilisation réelle par l’équipe et par des testeurs externes a davantage sollicité la couche de données sous-jacente
  • Des documents partagés imbriqués et liés, divers moteurs de rendu pour documents CRDT, un système d’identité plus avancé incluant un modèle d’outbox, ainsi que le partage de données éphémères comme la mise en évidence de sélections ont été expérimentés

Résultats obtenus avec les prototypes

• L’objectif des trois prototypes était d’évaluer la faisabilité technique des logiciels local-first et des CRDT, ainsi que l’expérience utilisateur et l’expérience développeur
• Les cinq membres de l’équipe de développement les ont utilisés régulièrement, et des tests d’utilisabilité individuels ont été menés avec une dizaine d’utilisateurs externes
  • Les utilisateurs externes comprenaient des designers professionnels, des chefs de produit et des ingénieurs logiciel
  • L’approche était exploratoire, et non fondée sur une méthodologie d’évaluation formelle

• La technologie CRDT fonctionne

  • La fiabilité d’Automerge s’est révélée meilleure que prévu
  • Les développeurs d’applications de l’équipe ont pu intégrer la bibliothèque assez facilement, et la fusion automatique des données a presque toujours été intuitive et fluide

• L’expérience utilisateur hors ligne était bonne

  • Le flux consistant à passer hors ligne, travailler aussi longtemps que souhaité, puis se reconnecter et fusionner avec les changements des collègues a bien fonctionné
  • Même lorsque d’autres applications affichaient des avertissements et des erreurs « offline » empêchant de travailler, les prototypes local-first fonctionnaient normalement, quel que soit l’état du réseau
  • Contrairement aux systèmes basés sur le navigateur, il y avait moins d’inquiétude quant au fait que l’application fonctionne ou que les données soient présentes, ce qui donnait un sentiment de propriété sur l’outil et le travail produit

• Bonne adéquation avec le modèle FRP de React

  • Le modèle Functional Reactive Programming de React s’accorde bien avec les CRDT
  • Dans une couche de données basée sur des CRDT, un document reçoit simultanément les entrées de l’utilisateur local et les modifications provenant d’autres utilisateurs et appareils via le réseau
  • Le modèle FRP synchronise de manière fiable l’état visible de l’application avec l’underlying state du document partagé
  • Les développeurs sont libérés du travail fastidieux consistant à suivre les changements venus d’autres utilisateurs et à les réconcilier avec l’écran courant
  • Faire passer tous les changements d’état par une unique fonction reducer facilite aussi l’envoi des changements locaux pertinents aux autres utilisateurs

• Les conflits ont été moins graves que prévu

  • Les utilisateurs ont rarement rencontré des conflits pendant la collaboration, et les mécanismes généraux de résolution ont bien fonctionné
  • Automerge suit les changements à un niveau fin et tient compte de la sémantique des types de données
  • Si deux utilisateurs insèrent simultanément des éléments au même emplacement d’un tableau, les deux éléments sont combinés dans un ordre déterministe
  • Un système de gestion de versions textuel comme Git pourrait considérer cela comme un conflit nécessitant une résolution manuelle
  • Les utilisateurs ont une intuition de la collaboration et répartissent parfois implicitement les zones de travail afin de ne pas modifier simultanément la même section
  • Dans l’application Kanban, si un utilisateur ajoute un commentaire à une carte et qu’un autre déplace cette carte vers une autre colonne, les deux changements sont conservés
  • Les conflits ne surviennent que lorsque la même propriété du même objet est modifiée simultanément ; l’exemple donné est celui de deux utilisateurs qui changent en même temps la position d’un même objet image
  • Dans les prototypes, la sémantique de fusion par défaut d’Automerge a suffi, et aucun cas nécessitant une sémantique personnalisée n’a été identifié

• La visualisation de l’historique des documents est importante

  • Dans un système de collaboration distribué, de nombreux changements provenant d’autres utilisateurs peuvent arriver à tout moment
  • Comme aucun serveur central ne sert d’intermédiaire pour les changements, il faut des outils pour comprendre le chemin qui a mené le document à son état actuel, les versions existantes et l’origine des contributions
  • Trellis a expérimenté une interface de « time travel » permettant aux utilisateurs de naviguer vers des états passés d’un document fusionné
  • Une approche consistant à mettre automatiquement en évidence les nouveaux éléments reçus a également été expérimentée

• Le partage par URL est naturel

  • Parmi plusieurs mécanismes de partage de documents, le modèle d’URL inspiré du Web s’est révélé le plus naturel pour les utilisateurs comme pour les développeurs
  • Une URL peut être copiée-collée et partagée via des canaux de communication comme l’e-mail ou le chat
  • Les droits d’accès aux documents au-delà des URL secrètes restent une question de recherche ouverte

• Les systèmes P2P ne se réduisent pas à une simple distinction en ligne/hors ligne

  • Les systèmes centralisés définissent généralement les états « up » ou « down » selon la stabilité de la connexion au serveur
  • Dans un système distribué, chaque utilisateur peut avoir une perspective différente selon les données qu’il possède, partage et accepte
  • Des modifications effectuées sur un ordinateur portable dans un avion peuvent être distribuées aux autres utilisateurs après l’atterrissage, une fois la connexion rétablie
  • Les autres utilisateurs peuvent accepter dans leur version du document la totalité de ces changements, seulement une partie, ou aucun
  • Comme dans un dépôt Git, le « master » d’un utilisateur donné devient fonction du dernier moment où il a communiqué avec les autres utilisateurs
  • Les documents distribués donnent aux utilisateurs le contrôle des données, mais ce que cela signifie concrètement du point de vue de l’UI nécessite davantage de recherche

• Les longs historiques de changements créent des problèmes de performance

  • Lorsque PushPin a été utilisé pour de vrais documents, comme la planification de sprint, les performances ainsi que l’utilisation de la mémoire et du disque sont rapidement devenues problématiques
  • Les CRDT stockent l’historique complet, y compris l’édition de texte caractère par caractère
  • On ne peut pas facilement tronquer l’historique, car quelqu’un peut se reconnecter au document six mois plus tard et devoir fusionner les changements depuis ce point
  • L’optimisation d’Automerge se poursuit et reste un axe de travail majeur en cours

• La communication réseau n’est pas encore résolue

  • Les algorithmes CRDT ne traitent que la fusion des données ; ils ne disent pas comment les modifications d’un autre utilisateur arrivent physiquement sur le même ordinateur
  • Les expérimentations ont porté sur WebRTC, une implémentation sneakernet copiant des fichiers via Dropbox et clé USB, les possibilités du protocole IPFS, ainsi que la bibliothèque P2P Hypercore de Dat
  • Les CRDT n’exigent pas nécessairement une couche réseau P2P ; la communication via un serveur est aussi possible
  • Pour réaliser pleinement l’objectif de longévité du local-first, une solution décentralisée survivant plus longtemps que les services backend des fournisseurs constitue l’aboutissement logique
  • Les technologies P2P n’étaient pas prêtes pour la production, et le NAT traversal en particulier s’est montré peu fiable selon les routeurs ou la topologie réseau
  • L’expérience de collaboration directe en temps réel entre ordinateurs, sans accès à Internet, montre un grand potentiel dans un monde dépendant des API centrales

• Les serveurs cloud conservent un rôle d’appoint

  • Les prototypes de collaboration en temps réel comme PushPin peuvent partager des documents sans serveur intermédiaire, ce qui est bénéfique pour la confidentialité et la propriété
  • Mais si un utilisateur ferme son ordinateur portable après avoir partagé un document, avant que l’autre personne ne se connecte, les deux utilisateurs ne sont pas en ligne en même temps et ne peuvent donc pas se connecter
  • Dans un monde local-first, un serveur peut jouer le rôle de cloud peer, plutôt que celui d’une autorité centrale
    • Stocker une copie du document puis la transmettre lorsqu’un autre pair passe en ligne
    • Fournir un emplacement d’archivage et de sauvegarde
    • Servir de passerelle vers des API serveur traditionnelles, comme les prévisions météo ou les cours de Bourse
    • Fournir du burst computing, par exemple du rendu vidéo avec de puissants GPU
  • La différence entre les systèmes traditionnels et les systèmes local-first ne tient pas à la présence ou non d’un serveur, mais au fait que celui-ci joue un rôle de support plutôt que d’être la source de vérité

Travaux à mener

• Chercheurs en systèmes distribués et en langages de programmation

  • Les recherches sur les CRDT et les technologies P2P peuvent contribuer fortement au logiciel local-first
  • Les recherches actuelles sur les CRDT supposent généralement un modèle où tous les collaborateurs appliquent immédiatement leurs modifications à une version unique d’un document
  • Dans les vraies apps local-first, il faut pouvoir refuser les modifications d’autres collaborateurs, ou créer des changements privés sur une version de document qui n’est pas partagée
  • Il manque des travaux pour étendre les concepts du contrôle de source distribué, comme les branches, forks et rebases, à un modèle de collaboration où plusieurs versions de documents et branches coexistent
  • Les types, les migrations de schéma et la compatibilité sont aussi des sujets importants
    • Chaque collaborateur peut utiliser une version et des fonctionnalités différentes de l’app
    • Comme il n’y a pas de serveur de base de données central, il n’existe pas de schéma « actuel » faisant autorité pour les données
    • Pendant que les formats de données évoluent, plusieurs versions de l’app doivent pouvoir interopérer en toute sécurité

• Chercheurs en HCI

  • Dans les systèmes centralisés, il existe de nombreux exemples d’affichage de l’état de synchronisation avec le serveur, mais les systèmes décentralisés posent de nouveaux problèmes d’interface utilisateur
  • Dans un système où chaque utilisateur peut avoir une copie différente des données, il faut étudier comment communiquer les états en ligne/hors ligne et disponible/indisponible
  • Quand il devient possible de collaborer directement avec d’autres nœuds sans passer par l’Internet au sens large, la signification même de « en ligne » change
  • Comme tous les documents peuvent acquérir un historique de versions complexe simplement par l’usage quotidien, il faut des interfaces qui aident les utilisateurs à comprendre les versions, l’acceptation des changements et le processus de formation des documents
  • Aujourd’hui, la gestion des changements repose surtout sur le modèle diff/patch issu du code source et sur le modèle suggestions/commentaires à la Google Docs
  • La manière de généraliser ces idées à des formats de données non textuels reste une question ouverte
  • Dans le local-first, on ne peut pas empêcher un utilisateur qui possède les données de les modifier localement ; la notion d’autorisation évolue donc vers un modèle où les autres utilisateurs choisissent ou non de s’abonner à ces changements

• Praticiens

  • Les ingénieurs, designers, chefs de produit et développeurs indépendants qui créent des logiciels de production peuvent avancer progressivement vers un avenir local-first
  • Pour des apps rapides, on peut réduire les spinners à l’ouverture des documents grâce à une mise en cache agressive et au préchargement, et faire confiance par défaut au cache local
  • Le multi-appareil peut être pris en charge assez facilement avec des infrastructures de synchronisation comme Firebase et iCloud, mais cela soulève des inquiétudes de longévité et de confidentialité
  • Pour le mode hors ligne sur le Web, les Progressive Web Apps, les Service Workers et les app manifests peuvent aider
  • Les tests d’app peuvent être réalisés en coupant le Wi-Fi ou en modifiant les conditions réseau avec des outils comme le simulateur de conditions réseau de Chrome DevTools ou le Network Link Conditioner d’iOS
  • Pour la collaboration, outre les CRDT, l’Operational Transformation, implémentée notamment dans ShareDB, est une technologie plus établie
  • Pour la conservation à long terme, il faut pouvoir exporter facilement vers des formats stables comme JSON ou PDF
    • Export en masse comme Google Takeout
    • Sauvegardes continues dans le format de fichier stable de GoodNotes
    • Téléchargement de documents JSON dans Trello
  • Sur le plan de la confidentialité, il faut indiquer clairement aux utilisateurs si les données sont stockées uniquement sur l’appareil ou envoyées au backend
  • Pour donner le contrôle aux utilisateurs, la sauvegarde, la duplication et la suppression de documents doivent être faciles dans l’app ; l’exemple cité est celui de Google Docs, qui a réimplémenté les opérations de base d’un système de fichiers via Google Drive

Opportunités pour les startups et conclusion

• Pour les fondateurs qui veulent créer une infrastructure développeur, « Firebase for CRDTs » est présenté comme une opportunité de marché intéressante
• Une telle startup devrait offrir une bonne expérience développeur et des bibliothèques de persistance locale comme SQLite ou Realm
• Elle devrait prendre en charge iOS, Android, Windows, Mac, Linux, Electron et les Progressive Web Apps
• Le contrôle utilisateur, la confidentialité, la prise en charge multi-appareil et la collaboration devraient être inclus par défaut
• Le test décisif de son succès serait de savoir si les apps clientes continuent de fonctionner indéfiniment même si tous les serveurs sont arrêtés
• Les logiciels cloud ont apporté la collaboration et des apps modernes accessibles partout, mais en plaçant la propriété des données sur les serveurs, ils ont transformé les utilisateurs en locataires de leurs propres données
• L’approche local-first montre qu’il est possible de conserver la propriété et le contrôle des données par les utilisateurs tout en bénéficiant de la collaboration et de l’accessibilité façon cloud
• Pour une mise en œuvre réelle, il reste à améliorer la prise en charge hors ligne, l’utilisation du stockage on-device, les algorithmes, les modèles de programmation et les interfaces utilisateur, ainsi qu’à industrialiser les CRDT et le réseau P2P

[GN⁺]

Avis sur Hacker News

• Tout à fait d’accord. J’en ai assez de cette tendance où tous les services récupèrent mes données dans leur cloud et me font payer un abonnement pour les utiliser correctement.
  L’app de suivi fitness que je développe vise un modèle du type « achat unique donnant droit à X années de mises à jour, synchronisation avec tous les appareils, puis utilisation permanente ensuite ». Si, au bout de X années, on a besoin de mises à jour, on rachète la nouvelle version ; si les fonctionnalités actuelles suffisent, on continue à l’utiliser.
  J’aimerais que la plupart des logiciels puissent être achetés ainsi à un prix raisonnable, que le produit lui-même soit bon, et qu’ils ne soient pas verrouillés de sorte à devenir inutilisables sans le cloud. Le meilleur aspect du logiciel local-first, c’est qu’il restaure des incitations saines à faire payer la qualité du produit, plutôt que la publicité, le tracking ou la maximisation de l’engagement.

  • Obsidian est aussi un bon modèle à regarder. Le client est entièrement gratuit, et seul le service de synchronisation optionnel est vendu.
    Toutes les notes sont des fichiers Markdown, ce qui rend même le client lui-même optionnel.
  • Je suis curieux de savoir comment la synchronisation est prévue sans infrastructure cloud.
  • « X années de mises à jour + synchronisation entre appareils + utilisation permanente » paraît bien, mais avec ce modèle il faut encaisser d’un coup l’équivalent de 1 à 2 ans de coût total d’abonnement.
    Il faut aussi continuer à exploiter les serveurs de synchronisation, et prévoir les cas où un utilisateur synchronise d’un coup une année de données en une journée. Comme il faut aussi continuer à payer les personnes qui assureront les futurs développements, il y a des aspects qui manquent si l’on ne regarde que du point de vue développeur.
  • Il y a quelques années, une usine locale a arrêté sa production pendant deux jours à cause d’une panne de serveur chez son fournisseur IT ; après cela, j’ai eu des réflexions similaires en envisageant le pire scénario.
    https://rodyne.com/?p=1439
  • Le backend peut faire partie des fonctionnalités, par exemple pour la collaboration en temps réel ou la synchronisation. Mais s’il est possible de s’extraire du cloud, et de passer à tout moment à de l’auto-hébergement ou de revenir en arrière, cela peut garantir à la fois la propriété et la pérennité des données et du service.
    L’IDE de notes/tâches que nous développons suit ce modèle : https://thymer.com/local-first-ejectable

• À Berlin, il existe une Local-first Software Conference annuelle organisée par Ink and Switch, et cette année un événement dérivé, Sync Conf, se tiendra aussi à SF en novembre.
  https://www.localfirstconf.com/
  https://syncconf.dev/
  Cette année, un panel intéressant réunissait des co-auteurs de l’article original autour de ce que signifie le logiciel local-first dans le contexte des outils de développement, et de ce qui a été appris depuis l’article initial : https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
  La communauté est en train de converger vers l’idée que la « synchronisation » est une composante du local-first, mais une technologie applicable beaucoup plus largement. Le local-first est une caractéristique des logiciels destinés aux utilisateurs finaux ; des outils de développement comme les moteurs de synchronisation permettent de le rendre possible, sans être nécessairement eux-mêmes local-first.
  Toutes les conférences de ces dernières années sont ici : https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
  C’est une période intéressante pour la communauté local-first / moteurs de synchronisation. Elle a construit des outils permettant des expériences de collaboration en temps réel et asynchrone, et l’arrivée de l’IA élargit ce marché. Toutes les apps d’IA sont, par nature, des systèmes collaboratifs multi-utilisateurs où des agents participent comme acteurs ; elles ont donc besoin des technologies sur lesquelles travaille depuis longtemps la communauté des moteurs de synchronisation.

  • Il existe aussi un excellent podcast Local First qui interviewe des ingénieurs créant des apps et de l’infrastructure local-first.
    https://www.localfirst.fm/

• Ça vaut la lecture, et il y a déjà eu plusieurs discussions animées par le passé.
  https://news.ycombinator.com/item?id=19804478 - mai 2019, 191 commentaires
  https://news.ycombinator.com/item?id=21581444 - novembre 2019, 241 commentaires
  https://news.ycombinator.com/item?id=23985816 - juillet 2020, 9 commentaires
  https://news.ycombinator.com/item?id=24027663 - août 2020, 134 commentaires
  https://news.ycombinator.com/item?id=26266881 - février 2021, 90 commentaires
  https://news.ycombinator.com/item?id=31594613 - juin 2022, 30 commentaires
  https://news.ycombinator.com/item?id=37743517 - octobre 2023, 50 commentaires

• Tout ce qui dépend d’une connexion en ligne implique forcément une maintenance continue et des coûts. Si un système n’est pas local-first, voire local uniquement quand c’est possible, il n’est pas conçu pour la fiabilité à long terme.
  Les appareils électroménagers et les voitures connectés sont, d’un point de vue pratique, parmi les exemples d’ingénierie les plus absurdes.

  • Tout cela à cause des revenus d’abonnement.
    Les entreprises qui tirent des revenus d’abonnement ont davantage de chiffre d’affaires et des valorisations plus élevées, ce qui facilite les levées de fonds supplémentaires, et elles battent les entreprises qui ne suivent pas ce modèle. À cause de cette dynamique auto-renforçante, je considère que le logiciel local-first est mort.
  • Quand on regarde le stockage gratuit/payant chez Dropbox ou Apple, on voit le coût réel. On est grosso modo à 10 dollars par mois pour 2 To.
    Cloudflare héberge des fichiers statiques quasiment gratuitement, et le coût relève presque de l’erreur d’arrondi. Même si 1000 applications local-first se synchronisaient avec Dropbox, elles pourraient fonctionner avec un stockage à 10 dollars par mois. Ce stockage n’est pas un outil brut de bas niveau comme S3, mais un service grand public avec authentification, support et programme de synchronisation. La plupart des coûts cloud ne sont en réalité pas nécessaires.
  • Si vous êtes opposé à l’initiative Stop Killing Games, vous devriez lire ce commentaire.
    Personne n’oblige les jeux à dépendre uniquement de services en ligne. Ce n’est ni une exigence légale, ni une exigence réglementaire. Comme beaucoup de choses dans le logiciel, c’est simplement un choix. Choisir de dépendre de services en ligne puis dire plus tard « revenir en arrière coûterait de l’argent » est à courte vue, lamentable, et ne devrait pas être accepté.

• Davantage d’apps devraient être local-first. Si l’utilisateur ne veut pas synchroniser ses données dans le cloud, il devrait avoir cette option.
  Je développe depuis un moment Brisqi, une app offline-first ou local-first, conçue dès le départ avec une philosophie offline-first.
  https://brisqi.com
  Une app local-first devrait être conçue pour fonctionner entièrement hors ligne indéfiniment. L’expérience locale doit en être la base, pas une solution de secours, et la synchronisation cloud doit être une fonctionnalité d’appoint, pas une exigence.
  Je ne considère pas les apps qui reposent sur un cache temporaire comme offline-first. Une vraie app offline-first doit persister les données dans une base de données locale. Beaucoup d’apps qui se disent « offline-first » offrent en réalité seulement des fonctionnalités hors ligne limitées et relèvent plutôt de l’offline-tolerant, en finissant par dépendre d’une reconnexion à Internet.
  Les apps offline-first sont clairement plus difficiles à construire que les apps web uniquement en ligne, et leur mécanisme de synchronisation doit être suffisamment fiable pour que, lors des transitions hors ligne/en ligne, les données restent cohérentes, se synchronisent avec le cloud et ne soient pas perdues. J’ai détaillé davantage l’approche sur le blog : https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

  • Je crains qu’il soit plus difficile de rendre ce modèle viable comme entreprise ; je suis curieux de savoir comment cela se passe concrètement.

• Il est intéressant de voir ce principe expliqué pour le grand public, mais nous faisons actuellement la même chose du côté des actifs industriels/données industrielles.
  Chez www.sentineldevices.com, l’apprentissage, l’analyse et la prise de décision se font entièrement sur les équipements du client. Il n’y a même pas de serveur auquel envoyer les données ; le modèle est explicitement que tout tourne dans l’appareil.
  Dans le SCADA/l’automatisation industrielle, il existe de nombreux cas d’usage où les données ne peuvent pas être sorties. Les entreprises de data/IA ignorent d’énormes segments de clients et cas d’usage au motif qu’il est difficile de fournir le service là où se trouvent les clients, et préfèrent plutôt rapatrier les données chez elles tout en maintenant le verrouillage fournisseur.
  Quand nous parlons aux clients, nous devons au contraire insister très fortement sur « non, c’est local et il n’y a pas de connexion externe ». Comme ils ont rarement entendu cela, il faut souvent l’expliquer étape par étape pour qu’ils comprennent que tout se passe localement, et les éditeurs logiciels ont du mal à adopter ce concept. J’aimerais que le logiciel local-first s’installe davantage dans le grand public, afin qu’il devienne aussi plus familier dans l’industrie.

  • Le fait que tous les fournisseurs SCADA aient pris le train de la mode du cloud et poussent dans cette direction n’aide pas non plus.
    « Pilotez votre usine depuis votre smartphone ! » : il suffit maintenant d’un seul zero-day pour qu’un script kiddie puisse s’amuser avec mes pompes.
  • C’est un domaine intéressant, et je suis content que vous travailliez là-dessus.
    En regardant la page de recrutement, j’ai vu que tous les postes étaient non distanciels ; je me demande si c’est parce qu’il y a une limite qui impose le présentiel pour créer du logiciel local-first, ou si c’est surtout pour des raisons de gestion.

• Personnellement, je ne suis pas d’accord avec cette approche. Elle donne l’impression de vouloir résoudre un problème business — « on ne peut pas faire confiance aux fournisseurs cloud » — par un compromis technique : « éviter les architectures centralisées ».
  Le manque de contrôle et de fiabilité des logiciels propriétaires a été résolu par un nouveau modèle économique, le développement open source, de nouvelles licences, et des modes de revenus comme les contrats de maintenance plutôt que les frais de licence.
  De la même manière, les problèmes posés par les fournisseurs cloud nécessitent une solution au niveau du modèle économique. Par exemple, on pourrait créer des contrats/licences standard définissant les droits des utilisateurs afin qu’ils puissent faire confiance à leur relation avec leur fournisseur cloud. Avec le temps, les utilisateurs pourraient ne traiter qu’avec des fournisseurs disposant de ce type de licence.
  On pourrait y inclure des clauses comme des accords de fin de vie, des garanties de portabilité des données, ou une transparence de la confidentialité des données permettant d’auditer l’accès aux données et de savoir qui/quoi les a lues, et quand. Le problème, c’est l’adoption. La question centrale est : pourquoi les fournisseurs cloud l’accepteraient-ils ? S’ils craignent le churn, ils pourraient ne proposer ces contrats que sur des abonnements annuels, ou les facturer plus cher.

  • Si l’on peut résoudre un problème business ou politique par une solution technique, c’est généralement une approche forte. Car ces problèmes sont causés par des acteurs adverses, et une solution technique retire à ces acteurs la capacité de trahir.
    Le chiffrement dans les services cloud en est un bon exemple. Essayer de protéger les données avec des politiques de confidentialité et des règles bureaucratiques est presque vain. Les données ont de la valeur, il est difficile pour les clients ou les gouvernements de savoir si une entreprise les vend discrètement, et il est aussi difficile de savoir si elle a économisé sur la sécurité avant qu’il ne soit trop tard.
    Mais si les données sont chiffrées sur l’appareil client et que l’on peut prouver mathématiquement que le serveur n’a pas accès au texte en clair, ces inquiétudes disparaissent. Le problème survient quand le serveur ne se contente pas de stocker les données, mais doit aussi les traiter ; dans ce cas, la solution technique consiste à utiliser son propre serveur.
  • Je doute que ce genre de contrat résolve vraiment le problème. Même si un service cloud documente qu’il préviendra X mois avant sa fermeture et permettra d’exporter les données, après la fermeture effective, ce qu’il vous restera en main pourrait n’être qu’un énorme fichier JSON pratiquement inutile.
    Sans construire votre propre application, ou sans qu’une personne bienveillante le fasse pour vous, il sera difficile à exploiter. C’est mieux que rien, mais ce n’est pas aussi bien qu’une application locale capable de continuer à fonctionner pendant des années, voire des décennies, après la fermeture de l’entreprise ou l’arrêt du support.
  • Ce modèle pourrait transformer les fournisseurs cloud en quelque chose de comparable aux banques. Le fournisseur cloud conserverait une sorte de propriété dans le compte de l’utilisateur, et l’utilisateur disposerait de droits clairement définis sur cette propriété, ainsi que de la capacité juridique de la récupérer depuis son compte.
    Dans la finance, la récupération correspond à se faire remettre de l’argent ou des biens ; dans le cloud, cela pourrait correspondre à recevoir un gros fichier Zip contenant tout le contenu du compte.
    Mais ce que l’on récupère n’est pas toujours pratique ni souhaitable. Dans la finance, on peut transférer un compte vers un autre prestataire ; pour les services cloud aussi, dans de nombreux cas, un transfert de compte serait probablement bien plus utile.
    La difficulté ici, c’est la portabilité. Même si l’on définit bien les droits de propriété et les droits de l’utilisateur sur un compte cloud, il reste ambigu de savoir ce que signifie « récupérer » ses amis Facebook, ou ce que voudrait dire transférer son compte Facebook ailleurs.
  • Je ne pense pas que cette interprétation soit exacte. Les auteurs reconnaissent pleinement que le cas business du local-first n’est pas entièrement résolu et qu’il s’agit d’un problème étroitement lié.
    Ce problème nécessite à la fois des solutions business et des solutions techniques, et l’article propose les caractéristiques que ces solutions devraient avoir.
    Il n’est pas exact non plus de dire que le local-first défend la décentralisation. Martin Kleppmann a explicitement indiqué qu’il ne pense pas que les technologies décentralisées résolvent ce problème d’une manière compatible avec le marché grand public. Il soutient plutôt l’idée d’un moteur de synchronisation standard centralisé permettant de réaliser l’idéal du local-first.
    Voir sa présentation à la Local-first conf de l’an dernier : https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
  • Les garanties de portabilité des données ne sont pas pratiques pour des données d’une certaine taille. Migrer une base de données de production vers une nouvelle base peut prendre de quelques mois à quelques années si l’on veut que cela se passe correctement.
    En situation de crise, on peut le faire en quelques semaines, mais cela risque d’être très sale. Même entre bases de données open source de même version, les différences entre services cloud sont nombreuses, et le problème reste le même.
    La meilleure solution est de garder les données dans son propre environnement dès le départ, et de couper la connexion si nécessaire. C’est possible en combinant gestion BYOC et open source. Notre entreprise exploite aussi un produit de données BYOC, nous avons donc un intérêt économique dans cette approche, mais je sais qu’elle est possible parce que je l’ai vue fonctionner.

• Avec mes projets https://github.com/ibizaman/selfhostblocks et https://github.com/ibizaman/skarabox, j’essaie justement de rendre cela largement possible
  L’objectif commun est de rendre le self-hosting plus accessible au grand public
  Basé sur NixOS, le but est de fournir autant que possible, de manière déclarative par défaut, HTTPS, SSO, LDAP, sauvegardes, ZFS avec snapshots, etc.
  En empaquetant Vaultwarden et Nextcloud, on peut stocker l’essentiel de ses données, ce qui en fait un concurrent de l’hébergement cloud, et cela propose aussi des services comme Home Assistant
  C’est aussi un concurrent de YUNoHost, mais SelfHostBlocks est, ou vise à devenir, meilleur, car il permet de self-hoster directement les paquets que l’on veut grâce aux composants qu’il fournit. C’est plus proche d’une bibliothèque que d’un framework
  Il concurrence aussi les NAS, mais je le considère meilleur parce que tout est open source. Pour l’instant, il faut encore être assez technique, mais nous sommes en train de lever cette contrainte, et l’un des objectifs est de permettre une installation sur son propre matériel sans connaître Nix ni toucher à la ligne de commande

  • C’est vraiment excellent. Je pense beaucoup à ce sujet ces temps-ci. Il est étrange qu’il existe autant d’excellentes alternatives libres et open source, relativement faciles pour les profils techniques — quelque chose comme « docker compose up » — mais encore hors de portée pour les non-techniciens
    Une bonne partie des applications self-hostables sont des applications web avec base de données, serveur et frontend, mais dans beaucoup de cas d’usage, on les utilise seulement sur un ordinateur, sans avoir besoin d’une version hébergée ni de synchronisation avec d’autres appareils. Par exemple, on peut faire sa comptabilité personnelle une fois par mois sur son ordinateur : pas besoin de faire tourner une application web 24 h/24 quelque part. On lance le programme, on travaille, puis on le ferme
    Il y a un grand décalage entre le nombre d’alternatives libres et open source self-hostables de qualité et le nombre de personnes qui peuvent réellement les utiliser. Il faut davantage de projets qui réduisent cet écart. Je vais essayer selfhostblocks pour quelques usages et tenter d’y contribuer
  • J’aime le fait que hledger soit inclus. Pour quelqu’un qui n’est pas habitué à la comptabilité en texte brut, cela peut sembler un peu déroutant, mais c’est vraiment un excellent logiciel

• Toutes les applications n’ont pas de raison d’avoir leur propre plateforme de synchronisation. Cette manière de voir les choses semble venir des applications mobiles, où il n’y a ni composabilité ni modularité entre programmes
  Si l’on prend vraiment au sérieux le « local-first », il suffit d’utiliser le système de fichiers, et l’utilisateur peut choisir parmi différentes solutions comme git, Box, etc.
  Exiger un abonnement à sa propre synchronisation est aussi déplaisant que n’importe quel autre SaaS, voire plus opaque et plus fragile

  • Je suis d’accord pour dire que toutes les applications n’ont pas besoin de leur propre moteur de synchronisation, mais pas avec l’idée que le système de fichiers serait la manière universelle d’adopter le local-first
    Premièrement, je veux du local-first, mais je veux aussi de la concurrence. Pour un local-first simple, n’importe quelle synchronisation convient, mais je veux aller plus loin. Je veux que cela fonctionne de manière fluide, sans avoir à y penser, comme Dropbox, et que ma femme et moi puissions chacun modifier des choses séparément sur nos téléphones, même dans une zone sans connexion
    Deuxièmement, la synchronisation fonctionne bien mieux quand elle connaît en profondeur la structure des données et leur sémantique. git et Box ont tous deux des limites importantes, et ces limites deviennent encore plus fortes avec des exigences de concurrence
  • Je suis globalement d’accord, mais en pratique ce n’est pas toujours aussi simple. J’ai créé une application qui fonctionnait exactement comme cela, mais comme il était impossible de coordonner à quel moment tel ou tel client était autorisé à modifier un fichier, les conflits de fichiers sont finalement devenus inévitables

• En théorie, j’aime l’approche de développement local-first. Elle correspond bien à la philosophie small tech, qui considère la confidentialité et la propriété des données comme des principes de base
  Mais en pratique, c’est difficile. Il faut en fait créer un moteur de synchronisation, gérer la résolution des conflits et administrer les migrations de schéma
  Malgré tout, les outils de développement de logiciels local-first semblent s’être améliorés ces dernières années. Je suis jazz.tools, electric-sql et Zero de Rocicorp, et je me demande s’il en existe d’autres

  • CouchDB côté serveur et PouchDB côté client étaient une tentative de créer ce type d’environnement
    https://couchdb.apache.org/
    https://pouchdb.com/
    On trouve aussi ici davantage de réflexions sur le développement d’applications local-first, il y a environ 10 ans : https://unhosted.org/
  • J’ai utilisé instantdb assez sérieusement pendant environ un mois sur un projet perso d’application de budget personnel
    Je devrais écrire un billet de blog, mais auparavant j’avais étudié PowerSync, electricSQL, LiveStore, PowerSync, et j’avais aussi jeté un œil à jazz.tools, mais je voulais quelque chose de plus structuré
    Jusqu’ici, c’est assez impressionnant. Je l’écris avec Vue et une bibliothèque communautaire ; les permissions étaient un peu délicates, mais simples une fois comprises. J’aime aussi la connexion par e-mail magique, et le tableau de bord/les fonctions de réponse sont bien, même s’il semble falloir quelques changements importants pour rendre tout ça moins pénible
    J’apprécie le fait que ce soit open source et auto-hébergeable si on le souhaite. jazz manquait de structure, et LiveStore avait l’air d’imposer un event store trop contraignant, même s’il avait de l’attrait. C’est dommage que les outils de développement soient derrière un paywall, mais ça se comprend. electricSQL n’apportait que la moitié de la solution, à savoir la lecture, et manquait d’un modèle d’écriture. CouchDB/PouchDB manquait aussi de structure à mes yeux, et j’aurais voulu une prise en charge inter-documents plus clairement intégrée. Je n’ai pas vraiment étudié Zero
  • Je me demande si vous connaissez ce site : https://www.localfirst.fm
    En fait, je voulais pointer vers le lien “landscape” dans le menu du haut, mais l’URL est assez peu pratique
  • J’ai vu quelqu’un mentionner Automerge il y a quelque temps
    https://automerge.org/
    Il existe des implémentations Rust et JavaScript, ainsi que plusieurs stratégies réseau. Contrairement à jazz.tools, il n’est pas accompagné d’une offre produit gratuite/payante, mais c’est plutôt correct
  • Ditto vaut aussi le coup d’œil
    https://www.ditto.com
    C’est une plateforme local-first avec synchronisation en temps réel, centrée sur les CRDT, ce qui rend la gestion de la résolution des conflits beaucoup plus simple. Elle est conçue pour gérer nativement les cas d’usage offline-first et la synchronisation pair à pair, sans avoir à construire soi-même un moteur de synchronisation à partir de zéro
    Elle prend en charge de nombreuses plateformes, dont Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java et Rust. La documentation est disponible ici : https://docs.ditto.live/home/about-ditto