Local-First-Software: Auch im Cloud-Zeitalter Eigentümer meiner Daten bleiben (2019)
(inkandswitch.com)- Cloud-Apps haben Zusammenarbeit und den geräteübergreifenden Zugriff deutlich verbessert, aber da sich die maßgebliche Kopie der Daten auf dem Server befindet, werden Eigentum und Kontrolle der Nutzer geschwächt
- Local-First-Software legt die primäre Datenkopie im lokalen Speicher von Laptop, Tablet und Smartphone ab und beschränkt Server auf eine unterstützende Rolle für Synchronisierung und Backups
- Dieser Ansatz strebt zugleich schnelle Reaktionszeiten, Offline-Arbeit, Synchronisierung über mehrere Geräte, Echtzeit-Zusammenarbeit, langfristige Aufbewahrung sowie Sicherheit und Privatsphäre als Standard an
- Dateien, E-Mail, Web-Apps, Synchronisierung à la Dropbox, Git, Firebase, CloudKit, Realm und CouchDB haben jeweils einige Vorteile, erfüllen aber nicht zugleich Zusammenarbeit und Dateneigentum
- Auf CRDT und Automerge basierende Prototypen haben Potenzial gezeigt, aber Herausforderungen bei Performance, Netzwerkkommunikation, P2P-Stabilität und verteilten Dokument-UIs bleiben bestehen
Der Konflikt zwischen Cloud-Zusammenarbeit und Dateneigentum
- Cloud-Apps wie Google Docs, Figma, Slack und Trello werden über den Browser oder mobile Apps genutzt und speichern Daten auf Servern
- Dieses Modell bietet Vorteile wie Echtzeit-Zusammenarbeit und von überall möglichen Zugriff, aber jeder Datenzugriff muss über den Server laufen
- Es ist nur das möglich, was der Server erlaubt
- Wenn der Dienst ausfällt, kann nicht nur die Software, sondern auch der Zugriff auf die mit ihr erzeugten Daten blockiert sein
- Selbst wenn sich Daten exportieren lassen, ist es schwer, dieselbe Software ohne Server weiter zu betreiben
- Ältere lokale Apps hingegen lesen und schreiben Dateien auf der lokalen Festplatte, sodass Nutzer Backups, langfristige Aufbewahrung, Bearbeitung mit anderen Programmen und Löschen direkt kontrollieren können
- Die zentrale Spannung besteht darin, dass die Cloud Zusammenarbeit liefert, lokale Apps aber Eigentum; Local First ist eine Designrichtung, die beides zugleich erreichen will
Das Grundmodell von Local-First-Software
- Local-First-Software priorisiert lokalen Speicher und lokale Netzwerke gegenüber Servern in entfernten Rechenzentren
- Bei Cloud-Apps sind die Serverdaten die maßgebliche Originalquelle, während die Daten auf dem Client eher einem vom Server abhängigen Cache ähneln
- Bei Local-First-Apps sind die lokalen Daten auf jedem Gerät die primäre Kopie; Server halten nur Hilfskopien für den Zugriff über mehrere Geräte und für Backups
- Dieser Perspektivwechsel wirkt sich direkt auf Performance, Offline-Nutzung, langfristige Aufbewahrung, Privatsphäre und Nutzerkontrolle aus
Die 7 Ideale von Local First
-
1. Sofortige Interaktion ohne Spinner
- Cloud-Apps benötigen für Datenänderungen und viele Abfragen Roundtrips zum Server, wodurch Latenz entsteht
- Eine Optimistic UI verbirgt diese Verzögerung, indem sie so tut, als sei die Anfrage bereits abgeschlossen, aber bei Netzwerkfehlern wird die Verzögerung wieder sichtbar
- Local-First-Apps haben die primären Daten auf dem lokalen Gerät, sodass Nutzereingaben seltener auf Serverantworten warten müssen
- Die Synchronisierung läuft im Hintergrund, und die App kann auf Eingaben nahezu sofort reagieren
-
2. Arbeiten ohne an ein Gerät gebunden zu sein
- Nutzer wechseln zwischen mehreren Geräten, etwa indem sie Ideen auf dem Smartphone festhalten, sie auf dem Tablet ordnen und auf dem Laptop dokumentieren
- Auch Local-First-Apps speichern Daten auf jedem Gerät und benötigen Synchronisierung zwischen allen Arbeitsgeräten
- Die meisten geräteübergreifenden Synchronisierungsdienste speichern auch eine Kopie auf dem Server und fungieren so als Offsite-Backup
- Wenn mehrere Personen dieselbe Datei gleichzeitig bearbeiten, können Konflikte entstehen, weshalb das Kollaborationsdesign wichtig wird
-
3. Netzwerk als Option
- Flugzeuge, Tunnel, Aufzüge, Parkhäuser, instabiles Wi‑Fi, Roaming-Kosten sowie unvollständige Internetversorgung in Entwicklungs- und ländlichen Regionen machen Offline-Arbeit notwendig
- Cloud-Apps sind in der Regel offline schwach, und es ist auch schwierig, Offline-Unterstützung nachträglich an ein serverzentriertes Modell anzubauen
- Local-First-Apps speichern die primären Daten im lokalen Dateisystem jedes Geräts und können daher auch offline lesen und schreiben
- Wenn später wieder Netzwerk verfügbar ist, synchronisieren sie mit anderen Geräten; die Synchronisierung kann nicht nur über das Internet, sondern auch per Bluetooth oder lokalem Wi‑Fi erfolgen
- Für ein gutes Offline-Erlebnis eignet sich eine lokal installierte ausführbare Anwendung besser als ein Browser-Tab
-
4. Reibungslose Zusammenarbeit mit Kolleginnen und Kollegen
- Ältere lokale dateibasierte Software erzeugt leicht Konflikte, wenn mehrere Personen dieselbe Datei gleichzeitig bearbeiten
- Cloud-Apps wie Google Docs haben die Erfahrung popularisiert, dass mehrere Nutzer ein Dokument gleichzeitig bearbeiten können, ohne sich um Konflikte zu kümmern
- Das Ideal von Local First ist, Echtzeit-Zusammenarbeit zu unterstützen, die so gut ist wie die besten heutigen Cloud-Apps oder besser
- Wichtig ist auch ein Ablauf, bei dem ein Nutzer Änderungen vorschlägt und ein anderer sie prüft und selektiv übernimmt
- der Suggesting-Modus von Google Docs
- der Pull Request von GitHub
-
5. Long Now: langfristige Zugänglichkeit
- Ein wichtiger Aspekt von Dateneigentum ist, dass der Zugriff auch in ferner Zukunft noch möglich sein muss
- Alte lokale Apps lassen sich weiter nutzen, wenn man die Daten und eine lauffähige Kopie der Software besitzt; auch alte Betriebssysteme oder Computer können per virtueller Maschine oder Emulator weiterlaufen
- Auch wenn sich Speichermedien ändern, lassen sich Dateien auf neue Medien kopieren
- Cloud-Apps hängen von der Annahme ab, dass der Dienst weiter angeboten wird, und sind anfällig für Diensteinstellung, Datenverlust, Preis- oder Funktionsänderungen und unerwünschte Zwangsupgrades
- Bei Local-First-Software werden die Daten und die Software zum Lesen und Bearbeiten lokal gespeichert, was die Chancen auf langfristige Bewahrung erhöht
- plain text, JPEG und PDF werden voraussichtlich lange lesbar bleiben, und die Library of Congress der USA empfiehlt XML, JSON und SQLite als Formate für die Aufbewahrung von Datensätzen
-
6. Sicherheit und Privatsphäre als Voreinstellung
- Cloud-Apps sammeln die Daten aller Nutzer in einer zentralen Datenbank und werden dadurch zu einem attraktiven Ziel für Angreifer
- Interne Mitarbeitende oder Hacker mit Serverzugang können Daten lesen oder manipulieren, und Datenpannen bleiben ein häufiges Risiko
- In den Nutzungsbedingungen von Google Drive steht, dass automatisierte Systeme Nutzerinhalte analysieren, um personalisierte Suchergebnisse sowie Spam- und Malware-Erkennung bereitzustellen
- Für Nutzer, die mit sensiblen Daten arbeiten, etwa medizinisches Personal, investigativ arbeitende Journalistinnen und Journalisten oder Personen mit Regierungs- und Diplomatiebezug, kann die Nutzung von Cloud-Apps mit regulatorischen oder Vertraulichkeitspflichten kollidieren
- Local-First-Apps speichern auf jedem lokalen Gerät nur die eigenen Daten des Nutzers; auf Servern können ausschließlich Ende-zu-Ende-verschlüsselte Kopien liegen
- iMessage, WhatsApp, Signal, Keybase und Tarsnap werden als Beispiele für Ende-zu-Ende-Verschlüsselung oder verschlüsselte Dateifreigabe und Backups genannt
-
7. Letztliches Eigentum und Kontrolle
- Bei Cloud-Apps kann der Dienstanbieter den Nutzerzugang einschränken
- Im Oktober 2017 wurde einigen Google-Docs-Nutzern der Dokumentzugriff blockiert, weil ein automatisiertes System ihre Dokumente fälschlich als schädlich markiert hatte
- Eigentum bedeutet hier nicht geistige Eigentumsrechte, sondern Handlungsfähigkeit, Autonomie und Datenkontrolle der Nutzer
- In Local-First-Software befinden sich die Bytes, aus denen die Daten bestehen, auf dem Gerät des Nutzers, sodass er sie auf beliebige Weise verarbeiten kann
- Zum Dateneigentum gehört auch die Verantwortung, Backups zu pflegen, Datenverlust zu verhindern, auf Ransomware zu reagieren und Dateiarchive zu verwalten
- Local First muss nicht zwingend Open Source sein; auch kommerzielle oder proprietäre Software kann dem Ideal nahekommen, wenn sie die Dateinutzung nicht künstlich einschränkt
- Beispiele für künstliche Einschränkungen sind PDFs, die das Drucken verhindern, eBook-Reader, die Kopieren und Einfügen behindern, sowie DRM bei Mediendateien
Grenzen bestehender Speicher- und Freigabemodelle
-
Dateien und E-Mail-Anhänge
- Traditionelle Dateien sind stark bei Offline-Anzeige und -Bearbeitung, Nutzerkontrolle, Backups, langfristiger Aufbewahrung und schnellem Zugriff
- Für den Zugriff über mehrere Geräte hinweg braucht man Methoden wie E-Mail, USB, NAS/NFS/FTP/rsync, Dropbox-artige Dateisynchronisierung oder Git
- E-Mail-Anhänge sind leicht zu verstehen und zuverlässig; auch sechs Monate später liegt der Anhang noch in seiner ursprünglichen Form vor
- Die Schwäche ist die Zusammenarbeit
- In der Regel kann immer nur eine Person gleichzeitig eine Datei ändern
- Wenn mehrere Personen bearbeiten, ist ein manuelles Zusammenführen nötig
- Es entsteht Verwirrung durch Dateinamen wie
Budget draft 2 (Jane's version) final final 3.xls
- Apps, die die Local-First-Idee umsetzen wollen, können zunächst Export in breit unterstützte Formate wie Plain Text, PDF, PNG und JPEG anbieten
-
Web-Apps
- Web-Apps wie Google Docs, Trello, Figma und Pinterest bestehen aus einem dünnen Client im Browser oder als mobile App, während sich der Datenspeicher auf dem Server befindet
- Web-Apps haben den Standard für Echtzeit-Kollaboration gesetzt und bieten im Team den großen Vorteil, dass die aktuelle Version von überall aus sichtbar ist
- Umgekehrt nehmen Eigentum und Kontrolle deutlich ab
- Serverdaten sind die maßgebliche Quelle, Client-Daten ähneln eher einem Cache
- Schon ein kurzer Netzwerkausfall kann den Zugriff mitten in der Arbeit blockieren
- Begrenzte Offline-Unterstützung wie das Google Docs offline plugin wirkt eher wie nachträglich an eine serverzentrierte Architektur angeflanscht
- Auch installierte Desktop-Clients wie Milanote und Figma sind im Kern neu verpackte Browser, sodass ihre Grenzen bei Netzwerkausfällen, Serverstillstand oder eingestellten Diensten sichtbar werden
-
Dropbox, Google Drive, Box, OneDrive
- Dropbox, Google Drive, Box und OneDrive überwachen auf dem Desktop einen bestimmten Ordner und kopieren geänderte Dateien auf andere Computer
- Da sie das lokale Dateisystem nutzen, sind sie schnell und offline nutzbar; selbst wenn der Synchronisierungsdienst eingestellt wird, bleiben die Dateien auf der lokalen Festplatte erhalten
- Bei einem Festplattenausfall kann man die App installieren und nach abgeschlossener Synchronisierung wiederherstellen, was in Bezug auf Langfristigkeit und Kontrolle Vorteile hat
- Unter mobilem iOS und Android ähneln sie eher einem Thin-Client-Modell, das nicht ganze Ordner synchronisiert, sondern Dateien einzeln vom Server holt
- Die Option „Make available offline“ muss vorab gesetzt werden, ist umständlich und funktioniert nur, solange die App geöffnet ist
- Der schwächste Punkt ist die Echtzeit-Kollaboration
- Wird dieselbe Datei auf zwei Geräten bearbeitet, entstehen Konflikte, die manuell zusammengeführt werden müssen
- Dass sich beliebige Dateiformate synchronisieren lassen, ist ein Vorteil für die Kompatibilität, aber auch eine Schwäche, weil kein formatspezifisches Merging möglich ist
-
Git und GitHub
- Git und GitHub werden vor allem für die Zusammenarbeit an Quellcode genutzt und gelten derzeit als das Softwarepaket, das Local-First am nächsten kommt
- Ein Git-Repository ist die primäre lokale Datenkopie im lokalen Dateisystem und nicht vom Server abhängig
- Es bietet vollständiges Offline-Arbeiten, hohe Geschwindigkeit, Nutzerkontrolle und Eignung für langfristige Aufbewahrung
- GitHub bietet Zusammenarbeit, Zugriff über mehrere Geräte hinweg sowie einen Ort für Backups und Archivierung, verschlüsselt das Repository jedoch nicht
- Git hat zwei große Schwächen
- Es gibt keine feingranulare Echtzeit-Kollaboration mit automatischem Merging wie bei Google Docs, Trello oder Figma
- Es ist für Code und zeilenbasierten Text optimiert; andere Dateiformate werden als binäre Blobs behandelt, die sich nur schwer sinnvoll bearbeiten oder zusammenführen lassen
- Dass viele Softwareingenieure Cloud-basierte Editoren und Laufzeitumgebungen wie Cloud9, Repl.it und Colaboratory ablehnen, weil sie „langsam sind“, „nicht vertrauenswürdig sind“ oder man „den Code auf dem lokalen System haben möchte“, berührt sich mit der Motivation hinter Local First
Optionen aus Sicht der Entwickler-Infrastruktur
-
Dünne Client-Web-Apps
- Es handelt sich um ein Modell, bei dem Rails-, Django-, PHP- oder Node.js-Server Daten in einer SQL- oder NoSQL-Datenbank speichern und Web-Seiten per HTTPS ausliefern
- Eine Installation ist nicht nötig, Nutzer müssen nur eine URL aufrufen, und die Verantwortung für das Datenmanagement liegt beim Engineering- oder DevOps-Team, das die Anwendung bereitstellt
- Meteor, ShareDB, Pusher, Ably und WebSocket erleichtern es, Echtzeit-Kollaboration in Web-Apps einzubauen
- Wenn für jede Nutzeraktion eine Serveranfrage nötig ist, wird es langsam; selbst wenn Client-JavaScript die Round-Trip-Zeit kaschiert, bricht das bei instabilem Internet leicht zusammen
- Trotz Bemühungen wie manifest, localStorage, service worker und Progressive Web Apps bleibt die Architektur von Web-Apps grundsätzlich serverzentriert
- Löscht man im Browser die Cookies, werden oft auch die Daten im lokalen Speicher gelöscht, weshalb sich das nicht gut zur langfristigen Speicherung wichtiger Daten eignet
- Wenn Nutzer eine Open-Source-Web-App selbst hosten, lassen sich einige Eigenschaften verbessern, aber weil die meisten Nutzer keine Systemadministratoren werden wollen, ist Self-Hosting für die Mehrheit keine realistische Option
-
Mobile Apps mit lokalem Speicher
- iOS- und Android-Apps werden als Binärdateien heruntergeladen und lokal installiert, aber viele Apps wie Twitter, Yelp und Facebook sind Thin Clients, die nur mit einem Server funktionieren
- Apps, die Daten zuerst auf dem lokalen Gerät in einer Persistenzschicht wie SQLite, Core Data oder normalen Dateien speichern, kommen dem Local-First-Ideal näher
- Clue und Things sind Beispiele für Apps, die als Single-User-Anwendungen begonnen und später ein Cloud-Backend für geräteübergreifende Synchronisierung oder Teilen ergänzt haben
- Solche Thick-Client-Apps sind schnell und funktionieren offline, weil die Serversynchronisierung im Hintergrund erfolgt
- Wenn mehrere Geräte oder mehrere gemeinsam arbeitende Nutzer Daten ändern, steigt der Schwierigkeitsgrad
- Mobile-App-Entwickler sind in der Regel Experten für Endnutzer-Apps und nicht für verteilte Systeme
- Ad-hoc-Algorithmen für Diff, Merge und Konfliktauflösung sind oft unzuverlässig und fragil
-
Firebase, CloudKit, Realm
- Firebase ist ein mobiles BaaS, das eine lokale Gerätedatenbank, einen Cloud-Datenbankdienst und die Synchronisierung zwischen beiden kombiniert
- Firebase unterstützt die gemeinsame Nutzung über mehrere Geräte und Offline-Nutzung, ist aber ein proprietärer Hosting-Dienst, weshalb es bei Privatsphäre und Langfristigkeit schlecht abschneidet
- Parse wurde nach der Übernahme durch Facebook 2017 eingestellt, sodass darauf aufbauende Apps auf andere Backends migrieren mussten
- Die Firebase-Konsole bietet Entwicklern eine gute Erfahrung zum Anzeigen, Ändern und Löschen von Daten, aber Nutzer haben kein entsprechendes Mittel, um auf ihre Daten zuzugreifen, sie zu bearbeiten oder zu verwalten
- Apple CloudKit bietet eine ähnliche Erfahrung wie Firebase für Apps, die auf iOS und Mac beschränkt sein können
- Key-Value-Speicher und Synchronisierung
- Gute Offline-Funktionen
- Weniger Aufwand bei Kontoerstellung und Login durch Plattform-Integration
- Realm gewann als lokale Persistenzbibliothek für iOS an Beliebtheit, und Realm Object Server ist Open Source und selbst hostbar, was das Risiko einer Abhängigkeit von einem Dienst verringert
-
CouchDB
- CouchDB fand Beachtung wegen seines Multi-Master-Replication-Ansatzes, bei dem mehrere Maschinen vollständige Datenbankkopien besitzen und jedes Replikat unabhängig Änderungen erzeugen kann
- Cloudant ist die gehostete Version, und PouchDB sowie Hoodie verwenden dasselbe Synchronisierungsprotokoll, sind aber für die Ausführung auf Endnutzergeräten ausgelegt
- Philosophisch steht CouchDB den Local-First-Prinzipien nahe, aber bei gleichzeitig geänderten Daten muss der Anwendungscode Konflikte explizit auflösen
- In feingranularen Kollaborations-Apps wie Google Docs, bei denen jeder Tastenanschlag eine eigene Änderung sein kann, ist es schwer, korrekten Code zur Konfliktauflösung zu schreiben
- Als Gründe für die ausbleibende breite Verbreitung werden die Skalierbarkeit getrennter Datenbanken pro Nutzer, das Einbetten eines JavaScript-Clients in native iOS- und Android-Apps, die Konfliktauflösung und die Ungewohntheit des MapReduce-Abfragemodells genannt
CRDTs und bessere Basistechnologien
- Bestehende Datenebenen für die Anwendungsentwicklung erfüllen nicht alle Anforderungen von Local-First
- Ink & Switch forscht seit drei Jahren nach einer Lösung und stellt Conflict-free Replicated Data Types oder CRDTs als vielversprechende Grundlage vor
- CRDTs sind universelle Datenstrukturen, die 2011 in der akademischen Informatikforschung aufkamen
- Wie Datenstrukturen etwa Hashmaps oder Listen speichern sie den Zustand eines Dokuments, sind aber von Anfang an für Multiuser-Umgebungen ausgelegt
- Texteditoren, Tabellenkalkulationen und Vektorgrafik-Apps halten ihren jeweiligen Dokumentzustand in Datenstrukturen; in kollaborativen Multiuser-Apps lässt sich dieser durch CRDTs ersetzen
-
Wie CRDTs zusammenführen
- Nutzer können den Anwendungszustand auch offline auf ihrem lokalen Gerät ansehen und bearbeiten
- CRDTs verfolgen Änderungen und synchronisieren im Hintergrund mit anderen Geräten, sobald das Netzwerk verfügbar ist
- Wenn auf verschiedenen Geräten gleichzeitig neue To-dos hinzugefügt werden, enthält der zusammengeführte Zustand alle hinzugefügten Elemente in konsistenter Reihenfolge
- Gleichzeitige Änderungen an verschiedenen Objekten lassen sich leicht zusammenführen
- Schwer automatisch aufzulösende Fälle entstehen, wenn mehrere Nutzer gleichzeitig dieselbe Eigenschaft desselben Objekts aktualisieren; CRDTs verfolgen die Konfliktwerte und überlassen die Auflösung der App oder den Nutzern
- CRDTs ähneln Git, arbeiten aber mit reichhaltigeren Datentypen als Textdateien
- Der Synchronisationskanal kann alles Mögliche sein: Server, P2P-Verbindungen, Bluetooth, USB-Sticks usw.
- Die Änderungseinheit kann so klein wie ein einzelner Tastendruck sein, wodurch Google-Docs-artige Echtzeit-Kollaboration möglich wird, oder sie kann in großen Paketen wie bei einem Git pull request gesendet werden
-
Automerge und Hypermerge
- Ink & Switch entwickelte die Open-Source-JavaScript-CRDT-Implementierung Automerge
- Automerge basiert auf Forschung zu JSON-CRDTs
- Durch die Kombination von Automerge mit dem Dat networking stack entstand Hypermerge
- Es ist schwer zu sagen, dass diese Bibliotheken das Local-First-Ideal bereits vollständig verwirklichen; es bleibt noch viel zu tun
- CRDTs haben das Potenzial, eine Basistechnologie für kollaborative Software zu werden, bei der Nutzer Eigentümer ihrer Daten sind – so wie Packet Switching für das Internet oder der capacitive touchscreen für Smartphones
Prototypen von Ink & Switch
- Die Überprüfung von CRDT-Algorithmen und -Theorie hat in der Wissenschaft Fortschritte gemacht, doch der industrielle Einsatz ist noch begrenzt und findet überwiegend im serverzentrierten Computing statt
- Als Beispiele für serverzentrierte Systeme mit CRDTs werden Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi und Facebook OpenR genannt
- Ink & Switch baute Prototypen von Local-First-Kollaborations-Apps für kreative Arbeit, die CRDTs auf Endgeräten der Nutzer verwenden
- Die Experimente behandelten drei Fragen
- Technische Machbarkeit: Wie nahe sind CRDTs an realer Software
- User Experience: Ist ohne zentralen autoritativen Server sowohl Google-Docs-artige Echtzeit-Kollaboration als auch Git-artige offlinefreundliche asynchrone Kollaboration möglich
- Developer Experience: Worin unterscheidet sich eine CRDT-Datenebene von SQL-Datenbanken, Dateisystemen und Core Data
- Alle drei Prototypen wurden mit Electron, JavaScript und React erstellt; dass es sich um herunterladbare und installierbare Software handelt, wurde als wichtig für das Gefühl von Eigentümerschaft angesehen
-
Trellis
- Trellis ist ein an Trello angelehntes Kanban-Board
- Für die Netzwerkkommunikation wurde mit WebRTC experimentiert
- Es wurde ein Änderungsverlauf entworfen, inspiriert von Git und „See New Changes“ in Google Docs
- Nutzer können Aufgaben auf dem Kanban-Board betrachten und zu früheren Zuständen des Dokuments zurückkehren
-
Pixelpusher
- Pixelpusher ist ein kollaboratives Zeichenprogramm, das Javier Valencias Pixel Art to CSS um eine Figma-artige Echtzeit-Kollaboration erweitert
- Für die Netzwerkkommunikation wurde mit den P2P-Bibliotheken des Dat-Projekts experimentiert
- Erprobt wurden eine URL zum Teilen von Dokumenten, von Git inspirierte visuelle Branches/Merges, Konfliktauflösung mit rot hervorgehobenen Konfliktpixeln sowie eine grundlegende Nutzeridentifikation über vom Nutzer gezeichnete Avatare
-
PushPin
- PushPin ist ein Mixed-Media-Canvas-Workspace ähnlich wie Miro oder Milanote
- Es war das dritte auf Automerge basierende Projekt und unter den drei Prototypen am weitesten ausgereift
- Die tatsächliche Nutzung durch das Team und externe Testnutzer belastete die zugrunde liegende Datenebene stärker
- Erprobt wurden verschachtelte und verknüpfte geteilte Dokumente, verschiedene Renderer für CRDT-Dokumente, ein weiterentwickeltes Identitätssystem einschließlich Outbox-Modell sowie das Teilen flüchtiger Daten wie Auswahlhervorhebungen
Erkenntnisse aus den Prototypen
- Ziel der drei Prototypen war es, die technische Machbarkeit, User Experience und Developer Experience von Local-First-Software und CRDTs zu bewerten
- Ein Entwicklungsteam aus fünf Personen nutzte sie regelmäßig, zudem wurden individuelle Usability-Tests mit etwa zehn externen Nutzern durchgeführt
- Zu den externen Nutzern gehörten professionelle Designer, Produktmanager und Softwareingenieure
- Es wurde kein formales Evaluationsverfahren verwendet, sondern ein explorativer Ansatz
-
CRDT-Technologie funktioniert
- Die Zuverlässigkeit von Automerge war besser als erwartet
- Die App-Entwickler des Teams konnten die Bibliothek relativ leicht integrieren, und das automatische Zusammenführen von Daten war fast immer intuitiv und reibungslos
-
Die Offline-User-Experience war gut
- Der Ablauf funktionierte gut: offline gehen, beliebig lange arbeiten, sich wieder verbinden und anschließend die Änderungen von Kollegen zusammenführen
- Während andere Apps mit „offline“-Warnungen und Fehlern die Arbeit blockierten, funktionierten die Local-First-Prototypen unabhängig vom Netzwerkstatus normal weiter
- Anders als bei browserbasierten Systemen musste man sich weniger Sorgen machen, ob die App funktioniert oder ob die Daten vorhanden sind, und das vermittelte ein Gefühl von Eigentum an Werkzeugen und Arbeitsergebnissen
-
Passt gut zum FRP-Modell von React
- Das Functional-Reactive-Programming-Modell von React passt gut zu CRDTs
- In einer CRDT-basierten Datenschicht erhält ein Dokument gleichzeitig Änderungen durch lokale Nutzereingaben sowie von anderen Nutzern und Geräten aus dem Netzwerk
- Das FRP-Modell synchronisiert den sichtbaren Anwendungszustand zuverlässig mit dem zugrunde liegenden Zustand des gemeinsam genutzten Dokuments
- Entwickler werden von der mühsamen Arbeit entlastet, Änderungen anderer Nutzer nachzuverfolgen und mit der aktuellen Ansicht abzugleichen
- Wenn alle Zustandsänderungen durch eine einzelne
reducer-Funktion laufen, lassen sich auch die betreffenden lokalen Änderungen leicht an andere Nutzer senden
-
Konflikte waren weniger gravierend als erwartet
- Nutzer stießen bei der Zusammenarbeit nur selten auf Konflikte, und allgemeine Auflösungsmechanismen funktionierten gut
- Automerge verfolgt Änderungen auf feingranularer Ebene und berücksichtigt die Semantik von Datentypen
- Wenn zwei Nutzer gleichzeitig Elemente an derselben Position eines Arrays einfügen, werden beide Elemente in einer deterministischen Reihenfolge zusammengeführt
- Ein textbasiertes Versionsverwaltungssystem wie Git könnte dies als Konflikt ansehen, der manuell gelöst werden muss
- Nutzer haben eine Intuition für Zusammenarbeit und teilen Arbeitsbereiche mitunter implizit auf, um nicht gleichzeitig denselben Abschnitt zu bearbeiten
- In einer Kanban-App werden beide Änderungen übernommen, wenn ein Nutzer einen Kommentar zu einer Karte hinzufügt und ein anderer die Karte in eine andere Spalte verschiebt
- Konflikte treten nur auf, wenn gleichzeitig dieselbe Eigenschaft desselben Objekts geändert wird; als Beispiel wird genannt, dass zwei Nutzer gleichzeitig die Position desselben Bildobjekts verändern
- In den Prototypen reichte die Standard-Merge-Semantik von Automerge aus, und es wurden keine Fälle gefunden, die eine benutzerdefinierte Semantik erforderten
-
Visualisierung der Dokumenthistorie ist wichtig
- In verteilten Kollaborationssystemen können jederzeit viele Änderungen anderer Nutzer eintreffen
- Da kein zentraler Server die Änderungen vermittelt, werden Werkzeuge benötigt, um zu verstehen, auf welchem Weg ein Dokument seinen aktuellen Zustand erreicht hat, welche Versionen existieren und woher die Beiträge stammen
- Trellis experimentierte mit einer „Time-Travel“-Oberfläche, mit der Nutzer zu vergangenen Zuständen eines zusammengeführten Dokuments wechseln können
- Es wurde auch damit experimentiert, neu empfangene Änderungselemente automatisch hervorzuheben
-
URL-Sharing ist natürlich
- Unter verschiedenen Mechanismen zum Teilen von Dokumenten war ein vom Web inspiriertes URL-Modell für Nutzer und Entwickler am natürlichsten
- URLs lassen sich kopieren und einfügen und über Kommunikationskanäle wie E-Mail oder Chat teilen
- Zugriffsrechte auf Dokumente über geheime URLs hinaus bleiben vorerst eine offene Forschungsfrage
-
P2P-Systeme lassen sich nicht einfach in online und offline einteilen
- Zentralisierte Systeme definieren den Zustand „up“ oder „down“ normalerweise danach, ob eine stabile Verbindung zum Server besteht
- In verteilten Systemen kann jeder Nutzer eine andere Perspektive haben, je nachdem, welche Daten er besitzt, teilt und akzeptiert
- Bearbeitungen, die auf einem Laptop im Flugzeug vorgenommen wurden, können nach der Landung und Wiederverbindung an andere Nutzer verteilt werden
- Andere Nutzer können alle, einige oder keine dieser Änderungen in ihre eigene Dokumentversion übernehmen
- Wie in einem Git-Repository ist der „master“ eines bestimmten Nutzers eine Funktion des Zeitpunkts, zu dem zuletzt mit anderen Nutzern kommuniziert wurde
- Verteilte Dokumente geben den Nutzern Kontrolle über die Daten, aber was das aus Sicht der tatsächlichen UI bedeutet, muss weiter erforscht werden
-
Lange Änderungshistorien verursachen Performance-Probleme
- Als PushPin für reale Dokumente wie Sprint-Planungen verwendet wurde, wurden Performance sowie Speicher- und Festplattennutzung schnell zum Problem
- CRDTs speichern die gesamte Historie, einschließlich zeichenweiser Textbearbeitung
- Da sich jemand auch nach sechs Monaten wieder mit einem Dokument verbinden und ab diesem Zeitpunkt Änderungen zusammenführen muss, lässt sich die Historie nicht einfach abschneiden
- Die Optimierung von Automerge läuft weiter und bleibt ein zentrales laufendes Arbeitsfeld
-
Netzwerkkommunikation ist noch nicht gelöst
- CRDT-Algorithmen kümmern sich nur um das Zusammenführen von Daten, nicht darum, wie die Bearbeitungen anderer Nutzer physisch auf demselben Computer ankommen
- In den Experimenten wurden WebRTC, eine Sneakernet-Implementierung mit dem Kopieren von Dateien über Dropbox und USB-Sticks, die Möglichkeit des IPFS-Protokolls und Dats Hypercore-P2P-Bibliothek ausprobiert
- CRDTs erfordern nicht zwingend eine P2P-Netzwerkschicht; Kommunikation über Server ist ebenfalls möglich
- Um das langfristige Ziel von Local-First vollständig zu verwirklichen, ist eine dezentrale Lösung, die länger überlebt als Backend-Services von Anbietern, das logische Endziel
- P2P-Technologien waren nicht ausreichend produktionsreif; insbesondere war NAT traversal je nach Router oder Netzwerktopologie wenig zuverlässig
- Die Erfahrung direkter Echtzeit-Zusammenarbeit zwischen Computern ohne Internetzugang zeigte großes Potenzial in einer Welt, die von zentralen APIs abhängt
-
Cloud-Server bleiben in einer Nebenrolle
- Echtzeit-Kollaborationsprototypen wie PushPin können Dokumente ohne Vermittlungsserver teilen, was gut für Privatsphäre und Eigentum ist
- Wenn ein Nutzer jedoch nach dem Teilen eines Dokuments seinen Laptop schließt, bevor die andere Person eine Verbindung herstellt, können sich beide nicht verbinden, weil sie nicht gleichzeitig online sind
- Ein Server kann in einer Local-First-Welt nicht als zentrale Autorität, sondern als cloud peer fungieren
- Speichert eine Kopie des Dokuments und liefert sie aus, sobald ein anderer Peer online ist
- Bietet einen Ort für Archivierung und Backups
- Dient als Brücke zu traditionellen Server-APIs wie Wettervorhersagen oder Aktienkursen
- Bietet Burst Computing wie Video-Rendering auf leistungsstarken GPUs
- Der Unterschied zwischen traditionellen Systemen und Local-First-Systemen liegt nicht in der Existenz eines Servers, sondern darin, dass der Server nicht die Quelle der Wahrheit ist, sondern eine unterstützende Rolle übernimmt
Zukünftig notwendige Arbeiten
-
Forschende für verteilte Systeme und Programmiersprachen
- Forschung zu CRDTs und P2P-Technologien kann wesentlich zu Local-First-Software beitragen
- Die aktuelle CRDT-Forschung geht meist von einem Modell aus, in dem alle Beteiligten an der Zusammenarbeit ihre Bearbeitungen sofort auf eine einzige Dokumentversion anwenden
- Reale Local-First-Apps müssen Bearbeitungen anderer Beteiligter ablehnen oder private Änderungen an Dokumentversionen erstellen können, die nicht geteilt werden
- Es gibt zu wenig Forschung dazu, Konzepte verteilter Versionsverwaltung wie branch, fork und rebase auf Kollaborationsmodelle auszuweiten, in denen mehrere Dokumentversionen und branchs parallel existieren
- Typen, Schema-Migrationen und Kompatibilität sind ebenfalls wichtige Themen
- Beteiligte an der Zusammenarbeit können unterschiedliche App-Versionen und Funktionen verwenden
- Da es keinen zentralen DB-Server gibt, existiert kein maßgebliches „aktuelles“ Schema der Daten
- Mehrere App-Versionen müssen sicher interoperabel sein, während sich Datenformate weiterentwickeln
-
HCI-Forschende
- In zentralisierten Systemen gibt es viele Beispiele dafür, den Synchronisationsstatus mit dem Server anzuzeigen, dezentrale Systeme bringen jedoch neue UI-Probleme mit sich
- Es braucht Forschung dazu, wie in Systemen vermittelt werden kann, was online/offline sowie verfügbar/nicht verfügbar bedeutet, wenn alle Nutzenden unterschiedliche Kopien der Daten haben können
- Auch die Bedeutung von „online“ verändert sich, wenn direkte Zusammenarbeit mit anderen Knoten ohne das breite Internet möglich ist
- Da alle Dokumente schon durch alltägliche Nutzung eine komplexe Versionshistorie haben können, braucht es UIs, mit denen Nutzende Versionen, die Annahme von Änderungen und den Entstehungsprozess von Dokumenten verstehen können
- Aktuell dominieren beim Änderungsmanagement das diff/patch-Modell aus der Welt des Source Codes und das suggestion/comment-Modell von Google Docs
- Wie sich diese Ideen auf nicht textuelle Datenformate verallgemeinern lassen, ist eine offene Frage
- Bei Local First kann man Nutzende, die die Daten besitzen, nicht daran hindern, sie lokal zu verändern; stattdessen verschiebt sich das Berechtigungskonzept dahin, dass andere Nutzende wählen, ob sie diese Änderungen abonnieren
-
Praktiker
- Ingenieurinnen und Ingenieure, Designer, Produktmanager und unabhängige Entwickler, die Produktionssoftware bauen, können schrittweise Schritte in Richtung einer Local-First-Zukunft gehen
- Für schnelle Apps lassen sich durch aggressives Caching und Vorab-Downloads Spinner beim Öffnen von Dokumenten reduzieren, und grundsätzlich kann man dem lokalen Cache vertrauen
- Mehrere Geräte lassen sich mit Synchronisationsinfrastruktur wie Firebase und iCloud relativ leicht unterstützen, allerdings gibt es Bedenken hinsichtlich Langfristigkeit und Privatsphäre
- Für Offline-Unterstützung im Web können Progressive Web Apps, Service Workers und das app manifest helfen
- App-Tests lassen sich durchführen, indem man WiFi ausschaltet oder Netzwerkbedingungen mit Werkzeugen wie dem Chrome DevTools network condition simulator oder dem iOS network link conditioner verändert
- Für Zusammenarbeit ist neben CRDT auch Operational Transformation, wie es etwa in ShareDB implementiert ist, eine stärker etablierte Technologie
- Für die langfristige Aufbewahrung sollte ein einfacher Export in stabile Formate wie JSON oder PDF möglich sein
- Massenexport wie bei Google Takeout
- Fortlaufende Backups im stabilen Dateiformat von GoodNotes
- Download von JSON-Dokumenten bei Trello
- Unter Datenschutzaspekten sollte Nutzenden klar mitgeteilt werden, ob Daten nur auf dem Gerät gespeichert oder an ein Backend übertragen werden
- Für Nutzerkontrolle sollte das Sichern, Duplizieren und Löschen von Dokumenten in der App einfach sein; als Beispiel wird angeführt, wie Google Docs grundlegende Dateisystemfunktionen über Google Drive neu implementiert hat
Startup-Chancen und Fazit
- Für Gründerinnen und Gründer, die Entwickler-Infrastruktur schaffen wollen, wird „Firebase for CRDTs“ als interessante Marktchance genannt
- Solche Startups müssen eine gute Developer Experience und lokale Persistenzbibliotheken wie SQLite oder Realm bereitstellen
- Unterstützt werden müssen iOS, Android, Windows, Mac, Linux, Electron und Progressive Web Apps
- Nutzerkontrolle, Privatsphäre, Unterstützung mehrerer Geräte und Zusammenarbeit müssen standardmäßig enthalten sein
- Der Lackmustest für den Erfolg ist, ob die Kunden-App dauerhaft weiter funktioniert, selbst wenn alle Server abgeschaltet werden
- Cloud-Software hat Zusammenarbeit und moderne Apps ermöglicht, auf die man von überall zugreifen kann, hat aber die Datenhoheit auf den Servern belassen und Nutzende damit zu Mietern ihrer eigenen Daten gemacht
- Der Local-First-Ansatz zeigt, dass Nutzende Datenhoheit und Kontrolle behalten und zugleich cloudartige Zusammenarbeit und Zugänglichkeit erhalten können
- Für die praktische Umsetzung braucht es mehr Offline-Unterstützung, Nutzung von On-Device-Speicher, Verbesserungen bei Algorithmen, Programmiermodellen und Benutzeroberflächen sowie die Produktisierung von CRDTs und P2P-Networking
1 Kommentare
Hacker-News-Kommentare
Stimme vollkommen zu. Ich habe es satt, dass jeder Dienst meine Daten in seine Cloud zieht und mich mit Abogebühren zahlen lässt, wenn ich ihn vernünftig nutzen will.
Die Fitness-Tracking-App, an der ich gerade arbeite, soll ein Modell bekommen nach dem Motto: „Einmal kaufen, X Jahre lang Updates erhalten, mit allen Geräten synchronisieren und danach dauerhaft weiter nutzen.“ Wenn man nach X Jahren Updates braucht, kauft man die neue Version erneut; wenn die aktuellen Funktionen ausreichen, nutzt man sie einfach weiter.
Ich wünschte, der Großteil der Software wäre zu einem angemessenen Preis kaufbar, das Produkt selbst wäre gut, und man wäre nicht daran gebunden, es ohne Cloud nicht nutzen zu können. Das Beste an Local-first-Software ist, dass sie gesunde Anreize zurückbringt, bei denen man für Produktqualität bezahlt wird, statt für Werbung, Tracking und die Maximierung von Engagement.
Die Notizen sind alle Markdown-Dateien, wodurch selbst der Client optional wird.
Die Sync-Server müssen weiterhin betrieben werden, und ihr müsst auch Fälle berücksichtigen, in denen Nutzer ein Jahr an Daten auf einmal an einem Tag synchronisieren. Die Leute, die künftige Entwicklung übernehmen, müssen ebenfalls weiter bezahlt werden; aus reiner Entwicklerperspektive fehlt da also etwas.
https://rodyne.com/?p=1439
Unsere Notiz-/Aufgaben-IDE funktioniert ebenfalls auf diese Weise: https://thymer.com/local-first-ejectable
In Berlin gibt es die jährliche Local-first Software Conference, veranstaltet von Ink and Switch, und im November findet dieses Jahr in SF mit der Sync Conf auch ein Ableger statt.
https://www.localfirstconf.com/
https://syncconf.dev/
Dieses Jahr gab es ein gutes Panel, in dem Mitautoren des ursprünglichen Papers darüber sprachen, was Local-first-Software im Kontext von Entwicklungswerkzeugen bedeutet und was sie seit dem ursprünglichen Paper gelernt haben: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
In der Community kristallisiert sich gerade die Sicht heraus, dass „Synchronisierung“ zwar ein Bestandteil von Local-first ist, aber als Technologie viel breiter einsetzbar ist. Local-first ist eine Eigenschaft von Endnutzer-Software; Entwicklerwerkzeuge wie Sync-Engines ermöglichen das, sind aber nicht unbedingt selbst Local-first.
Alle Vorträge der vergangenen Jahre gibt es hier: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
Für die Local-first-/Sync-Engine-Community ist es eine spannende Zeit. Wir haben Werkzeuge gebaut, die Echtzeit-Kollaboration und asynchrone Zusammenarbeit ermöglichen, und mit dem Aufkommen von KI wächst dieser Markt. Jede KI-App ist im Grunde ein Mehrbenutzer-Kollaborationssystem, in dem Agenten als Akteure teilnehmen, und braucht daher die Technologien, mit denen sich die Sync-Engine-Community seit Langem beschäftigt.
https://www.localfirst.fm/
Lesenswert, und es gab auch früher schon mehrfach lebhafte Diskussionen dazu.
https://news.ycombinator.com/item?id=19804478 - Mai 2019, 191 Kommentare
https://news.ycombinator.com/item?id=21581444 - November 2019, 241 Kommentare
https://news.ycombinator.com/item?id=23985816 - Juli 2020, 9 Kommentare
https://news.ycombinator.com/item?id=24027663 - August 2020, 134 Kommentare
https://news.ycombinator.com/item?id=26266881 - Februar 2021, 90 Kommentare
https://news.ycombinator.com/item?id=31594613 - Juni 2022, 30 Kommentare
https://news.ycombinator.com/item?id=37743517 - Oktober 2023, 50 Kommentare
Alles, was von Online-Anbindung abhängt, verursacht zwangsläufig laufende Wartung und Kosten. Wenn ein System nicht Local-first ist, möglichst sogar rein lokal, ist es nicht auf langfristige Zuverlässigkeit ausgelegt.
Vernetzte Haushaltsgeräte und Autos sind aus praktischer Sicht ziemlich nahe an der dümmsten Art von Engineering.
Unternehmen, die Abo-Umsätze erzielen, haben mehr Umsatz und höhere Bewertungen, können leichter zusätzliches Kapital aufnehmen und schlagen Unternehmen, die diesem Modell nicht folgen. Wegen dieser sich selbst verstärkenden Struktur halte ich Local-first-Software für tot.
Cloudflare hostet statische Dateien praktisch kostenlos, die Kosten sind fast nur ein Rundungsfehler. Selbst wenn 1000 Local-first-Apps mit Dropbox synchronisieren, lässt sich das mit einem Speicherplan für 10 Dollar im Monat betreiben. Dieser Speicher ist kein Low-Level-Rohwerkzeug wie S3, sondern ein Consumer-Dienst mit Authentifizierung, Support und Synchronisationsprogramm. Die meisten Cloud-Kosten sind eigentlich nicht nötig.
Niemand zwingt Spiele dazu, ausschließlich von Online-Diensten abhängig zu sein. Es ist weder eine gesetzliche noch eine regulatorische Anforderung. Wie so vieles in Software ist es einfach eine Entscheidung. Sich dafür zu entscheiden, von Online-Diensten abhängig zu sein, und später zu sagen: „Das rückgängig zu machen kostet Geld“, ist kurzsichtig und armselig und sollte nicht akzeptiert werden.
Mehr Apps sollten Local-first sein. Wenn Nutzer ihre Daten nicht in die Cloud synchronisieren wollen, sollte es diese Option geben.
Ich entwickle seit einiger Zeit Brisqi, eine Offline-first- bzw. Local-first-App, und habe sie von Anfang an nach einer Offline-first-Philosophie entworfen.
https://brisqi.com
Local-first-Apps sollten so konzipiert sein, dass sie unbegrenzt vollständig offline funktionieren. Die lokale Erfahrung ist die Grundlage, kein Ausweichmodus, und Cloud-Synchronisierung sollte kein Muss, sondern eine Zusatzfunktion sein.
Apps, die auf temporäre Caches angewiesen sind, sehe ich nicht als Offline-first. Eine echte Offline-first-App muss Daten in einer lokalen Datenbank persistent speichern. Viele Apps, die sich „Offline-first“ nennen, bieten in Wirklichkeit nur eingeschränkte Offline-Funktionen und sind eher offline-tolerant, weil sie letztlich auf eine erneute Internetverbindung angewiesen sind.
Offline-first-Apps sind definitiv schwieriger zu bauen als reine Online-Web-Apps, und der Synchronisationsmechanismus muss zuverlässig genug sein, damit Daten auch beim Wechsel zwischen offline und online konsistent in die Cloud synchronisiert werden und nicht verloren gehen. Mehr zu meinem Ansatz habe ich im Blog beschrieben: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline
Es ist interessant, dass dieses Prinzip für den Consumer-Bereich erklärt wird, aber wir machen derzeit dasselbe im Bereich Industrieanlagen/Industriedaten.
Bei www.sentineldevices.com finden Lernen, Analyse und Entscheidungsfindung vollständig auf den Geräten der Kunden statt. Es gibt nicht einmal einen Server, an den Daten geschickt werden könnten; das Modell sieht ausdrücklich vor, dass alles innerhalb des Geräts läuft.
In SCADA/Industrieautomatisierung gibt es viele Anwendungsfälle, in denen Daten nicht nach außen gebracht werden dürfen. Daten-/KI-Unternehmen ignorieren eine riesige Kundengruppe und zahlreiche Use Cases, nur weil es schwierig ist, Dienste dort bereitzustellen, wo die Kunden sind, und versuchen stattdessen, die Daten zu sich zu holen und Vendor-Lock-in aufrechtzuerhalten.
In Gesprächen mit Kunden müssen wir eher sehr deutlich betonen: „Nein, das ist lokal und hat keine externe Verbindung.“ Viele haben so etwas kaum je gehört, sodass man es Schritt für Schritt erklären muss, bis sie verstehen, dass alles lokal passiert; Softwareanbieter tun sich mit diesem Konzept oft schwer. Es wäre gut, wenn sich Local-first-Software im Consumer-Bereich stärker durchsetzt, damit sie auch im industriellen Umfeld vertrauter wird.
„Betreiben Sie Ihre Fabrik vom Smartphone aus!“ — jetzt reicht ein Zero-Day, und irgendein Script-Kiddie kann mit meinen Pumpen herumspielen.
Auf der Karriereseite sehe ich, dass alle Positionen nicht remote sind. Liegt das an der Grenze, dass man sich persönlich treffen muss, um Local-first-Software zu bauen, oder eher an organisatorischen Gründen?
Ich stimme diesem Ansatz persönlich nicht zu. Er wirkt wie der Versuch, das Geschäftsproblem „Man kann Cloud-Anbietern nicht vertrauen“ durch den technischen Kompromiss „zentrale Architekturen vermeiden“ zu lösen.
Der Mangel an Kontrolle und Vertrauen bei proprietärer Software wurde durch neue Geschäftsmodelle wie Open-Source-Entwicklung, neue Lizenzen und Erlösmodelle wie Wartungsverträge statt Lizenzgebühren gelöst.
Entsprechend braucht es auch für die Probleme mit Cloud-Anbietern Lösungen auf Ebene des Geschäftsmodells. Zum Beispiel könnte man Standardverträge/-lizenzen schaffen, die Rechte definieren, damit Nutzer der Beziehung zu einem Cloud-Anbieter vertrauen können. Mit der Zeit könnten Nutzer dann nur noch mit Anbietern Geschäfte machen, die solche Lizenzen haben.
Darin könnten Klauseln zu End-of-Life-Vereinbarungen, garantierter Datenportabilität und Transparenz beim Datenschutz enthalten sein, also zur Prüfung des Datenzugriffs und zur Information darüber, wer/was/wann Daten gelesen hat. Das Problem ist die Adoption. Die zentrale Frage ist, warum Cloud-Anbieter das akzeptieren sollten; wenn sie Abwanderung fürchten, könnten sie solche Verträge nur bei Jahresabos anbieten oder höhere Preise verlangen.
Verschlüsselung bei der Nutzung von Cloud-Diensten ist ein gutes Beispiel. Daten mit Datenschutzrichtlinien und bürokratischen Regeln schützen zu wollen, ist nahezu vergeblich. Daten haben Wert, Kunden oder Regierungen können schwer erkennen, ob ein Unternehmen sie heimlich verkauft, und ob beim Thema Sicherheit gespart wurde, merkt man oft erst, wenn es zu spät ist.
Wenn Daten aber auf dem Client-Gerät verschlüsselt werden und mathematisch bewiesen werden kann, dass der Server keinen Zugriff auf Klartext hat, muss man sich darüber keine Sorgen machen. Problematisch wird es, wenn der Server die Daten nicht nur speichern, sondern auch verarbeiten muss; dann besteht die technische Lösung darin, den eigenen Server zu nutzen.
Ohne selbst eine App zu bauen oder jemanden Freundlichen zu finden, der das tut, lässt sich damit schwer etwas anfangen. Das ist besser als nichts, aber nicht so gut wie eine lokale App, die auch noch Jahre oder Jahrzehnte weiterlaufen kann, nachdem ein Unternehmen dichtgemacht oder den Support eingestellt hat.
Im Finanzbereich entspricht die Rückholung der Übergabe von Geld oder Vermögenswerten; in der Cloud könnte es bedeuten, eine große Zip-Datei mit dem gesamten Kontoinhalt zu erhalten.
Aber das, was übergeben wird, ist nicht immer praktisch oder wünschenswert. Im Finanzbereich kann man ein Konto zu einem anderen Anbieter übertragen, und auch bei Cloud-Diensten dürfte eine Kontoübertragung in vielen Fällen deutlich nützlicher sein.
Die Schwierigkeit liegt hier in der Portabilität. Selbst wenn Eigentums- und Nutzungsrechte an einem Cloud-Konto sauber definiert sind, bleibt unklar, was es bedeutet, die Facebook-Freunde „übergeben“ zu bekommen, oder was es heißt, ein Facebook-Konto an einen anderen Ort zu übertragen.
Für dieses Problem braucht es sowohl geschäftliche als auch technische Lösungen, und das Paper schlägt vor, welche Eigenschaften eine Lösung haben sollte.
Es stimmt auch nicht, dass Local-first für Dezentralisierung plädiert. Martin Kleppmann hat ausdrücklich gesagt, dass er nicht glaubt, dass dezentrale Technologie dieses Problem auf eine Weise löst, die den Massenmarkt erreicht. Er befürwortet eine zentralisierte Standard-Sync-Engine, die die Ideale von Local-first ermöglicht.
Siehe den Vortrag auf der Local-first conf im letzten Jahr: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
In einer Krisensituation geht es auch in wenigen Wochen, kann dann aber sehr unsauber werden. Selbst beim Umzug zwischen Open-Source-Datenbanken derselben Version gibt es je nach Cloud-Service viele Unterschiede; dort ist es ähnlich.
Die beste Lösung ist, die Daten von Anfang an in der eigenen Umgebung zu halten und die Verbindung bei Bedarf zu kappen. Das ist möglich, wenn man BYOC-Management mit Open Source kombiniert. Unser Unternehmen betreibt ebenfalls ein BYOC-Datenprodukt, daher haben wir ein wirtschaftliches Interesse an diesem Ansatz, aber ich weiß, dass es möglich ist, weil ich gesehen habe, dass es funktioniert.
Mit meinen Projekten https://github.com/ibizaman/selfhostblocks und https://github.com/ibizaman/skarabox versuche ich, genau das allgemein möglich zu machen
Das gemeinsame Ziel ist, Self-Hosting für die breite Masse zugänglicher zu machen
Auf Basis von NixOS sollen https, SSO, LDAP, Backups, Snapshots mit ZFS usw. möglichst deklarativ standardmäßig bereitgestellt werden
Da Vaultwarden und Nextcloud paketiert werden, lässt sich der Großteil der eigenen Daten speichern; damit ist es ein Konkurrent zu Cloud-Hosting, und es bietet auch Dienste wie Home Assistant an
Es ist auch ein Konkurrent zu YUNoHost, aber SelfHostBlocks ist besser bzw. soll es werden, weil man mit den bereitgestellten Bausteinen beliebige gewünschte Pakete selbst hosten kann. Es ist eher eine Bibliothek als ein Framework
Es konkurriert auch mit NAS, ist meiner Ansicht nach aber besser, weil alles Open Source ist. Noch müssen Nutzer technisch versiert sein, aber diese Einschränkung wird gerade abgebaut; eines der Ziele ist, die Installation auf eigener Hardware zu ermöglichen, ohne Nix zu kennen oder die Kommandozeile anfassen zu müssen
Viele selbst hostbare Apps sind Webanwendungen mit Datenbank, Server und Frontend, aber in vielen Anwendungsfällen nutzt man sie nur auf einem Computer und braucht weder eine gehostete Version noch Synchronisierung mit anderen Geräten. Private Buchhaltung erledigt man zum Beispiel einmal im Monat am Computer; dafür muss nicht irgendwo rund um die Uhr eine Web-App laufen. Man startet das Programm, arbeitet damit und beendet es wieder
Es gibt eine große Diskrepanz zwischen der Zahl hochwertiger, selbst hostbarer freier Open-Source-Alternativen und der Zahl der Menschen, die sie tatsächlich nutzen können. Es braucht mehr Projekte, die diese Lücke verkleinern. Ich möchte selfhostblocks für ein paar Dinge ausprobieren und versuchen, etwas beizutragen
Es gibt keinen Grund, warum jede Anwendung ihre eigene Synchronisierungsplattform haben sollte. Dieses Framing scheint aus Mobile-Apps zu stammen, denen Kombinierbarkeit oder Modularität zwischen Programmen fehlt
Wenn man „local-first“ ernst nimmt, kann man einfach das Dateisystem verwenden, und Nutzer können zwischen verschiedenen Lösungen wie git, Box usw. wählen
Eine eigene Sync-Mitgliedschaft zu verlangen, ist mir genauso zuwider wie andere SaaS-Angebote, nur noch undurchsichtiger und fragiler
Erstens will ich Local-first, aber ich will auch Gleichzeitigkeit. Wenn es nur einfaches Local-first wäre, wäre jede Synchronisierung in Ordnung, aber ich will mehr. Ich möchte, dass es so nahtlos läuft wie Dropbox, ohne dass ich mich darum kümmern muss, und dass meine Frau und ich auch in Gegenden ohne Verbindung jeweils auf unseren Handys getrennt Änderungen vornehmen können
Zweitens funktioniert Synchronisierung deutlich besser, wenn sie die Datenstrukturen und ihre Bedeutung gut kennt. git und Box haben beide erhebliche Grenzen, und wenn Anforderungen an Gleichzeitigkeit hinzukommen, werden diese Grenzen noch größer
Theoretisch gefällt mir der Local-first-Ansatz bei der Entwicklung. Er passt gut zur Small-Tech-Philosophie, die Privatsphäre und Dateneigentum als Standard betrachtet.
In der Praxis ist es aber schwierig. Man muss im Grunde eine Sync-Engine bauen, Konfliktlösung behandeln und Schema-Migrationen verwalten.
Trotzdem scheinen die Tools für die Entwicklung von Local-first-Software in den letzten Jahren besser geworden zu sein. Ich beobachte jazz.tools, electric-sql und Zero von Rocicorp und frage mich, ob es noch andere gibt.
https://couchdb.apache.org/
https://pouchdb.com/
Mehr Überlegungen zur Entwicklung von Local-first-Anwendungen von vor etwa 10 Jahren gibt es auch hier: https://unhosted.org/
Ich sollte dazu einen Blogbeitrag schreiben, aber vorher hatte ich PowerSync, electricSQL, LiveStore und PowerSync untersucht und mir auch jazz.tools kurz angesehen, wollte aber etwas Strukturierteres.
Bislang bin ich ziemlich beeindruckt. Ich schreibe es mit Vue und einer Community-Library; die Berechtigungen waren etwas knifflig, aber sobald man sie verstanden hat, einfach. Mir gefällt auch das Magic-E-Mail-Login, und die Dashboard-/Response-Funktionen sind gut, aber um es weniger umständlich zu machen, bräuchte es wohl ein paar größere Änderungen.
Mir gefällt, dass es Open Source ist und man es bei Bedarf selbst hosten kann. jazz fehlte es an Struktur, und bei LiveStore wirkte der Event Store zu umständlich, hatte aber seinen Reiz. Dass die Entwicklungstools hinter einer Paywall liegen, fand ich schade, verstehe es aber. electricSQL bot nur die halbe Lösung, nämlich nur Lesen, und es fehlte ein Schreibmodell. CouchDB/PouchDB hatten für mich ebenfalls zu wenig Struktur, und ich hätte mir gewünscht, dass Unterstützung über Dokumentgrenzen hinweg klarer eingebaut ist. Zero habe ich mir nicht gründlich angesehen.
Eigentlich wollte ich auf den „landscape“-Link im oberen Menü verweisen, aber die URL ist ziemlich unhandlich.
https://automerge.org/
Es gibt Implementierungen in Rust und JavaScript, außerdem bietet es einige Netzwerkstrategien. Es kommt nicht mit einem kostenlosen/kostenpflichtigen Produktpaket wie jazz.tools daher, ist aber ziemlich gut.
https://www.ditto.com
Es ist eine Local-first-Plattform mit CRDTs im Kern und Echtzeit-Synchronisierung, wodurch das Management der Konfliktlösung deutlich einfacher wird. Sie ist dafür konzipiert, Offline-first-Use-Cases und Peer-to-Peer-Synchronisierung standardmäßig zu handhaben, sodass man nicht selbst von Grund auf eine Sync-Engine bauen muss.
Unterstützt werden viele Plattformen, darunter Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java und Rust. Mehr Dokumentation gibt es hier: https://docs.ditto.live/home/about-ditto