Earthstar – Datenbank für persönliche dezentrale Offline-First-Apps

 (earthstar-project.org)
2 Punkte von GN⁺ 2025-02-02 | 1 Kommentare | Auf WhatsApp teilen
  • Earthstar ist eine Datenspezifikation und JavaScript-Bibliothek zum Erstellen von privaten dezentralen Apps, die Nutzer selbst besitzen und betreiben
  • Die neue Earthstar-Spezifikation wurde auf Willow-Basis umgestellt, und Earthstar v11 ist derzeit als Beta verfügbar
  • Apps funktionieren standardmäßig offline, unterstützen dabei Live-Synchronisierung, temporäre Dokumente, echtes Löschen sowie das Speichern von Musik, Fotos und Videos
  • Server sind optional, die Betriebsweise ist jedoch immer Self-Hosting, und es besteht keine Abhängigkeit von Blockchain oder Tokens
  • Läuft im Browser, in Deno und Node und bietet ed25519-Verifizierung, schreibgeschützten Zugriff, Streaming-Synchronisierung sowie mehrere Autoren und Storage-Treiber

Rolle und aktueller Status von Earthstar

  • Earthstar ist eine spezifikations- und datenbankähnliche JavaScript-Bibliothek zum Erstellen von nutzereigenen Anwendungen
  • Die neue Earthstar specification basiert auf Willow
  • Earthstar v11 wird derzeit als Beta bereitgestellt
  • Als wichtigste Einstiege stehen Dokumentation, JavaScript-API, Spezifikation und ein Tutorial für eine Chat-App zur Verfügung

Funktionen für Offline-First-Apps

  • Anwendungsfunktionen

    • Unterstützt Offline-Betrieb
    • Unterstützt Live-Synchronisierung und Sneakernet
    • Kann Musik, Fotos und Videos speichern
    • Unterstützt temporäre Dokumente und das tatsächliche Löschen von Daten
    • Es kann eine oder mehrere Identitäten (identity) verwendet werden

  • Betriebsmodell

    • Server sind optional
    • Die Betriebsweise ist immer Self-Hosting
    • Verwendet weder Blockchain noch Tokens
    • Wirbt mit „für immer kostenlos in jeder Bedeutung des Wortes“

  • Technische Funktionen

    • Unterstützt ed25519-Verifizierung
    • Läuft im Browser, in Deno und Node
    • Es kann schreibgeschützter Zugriff gewährt werden
    • Unterstützt effiziente Synchronisierung und Streaming-Synchronisierung
    • Eine Identität kann auf mehreren Geräten verwendet werden
    • Unterstützt mehrere Autoren, Storage-Treiber und Schreibberechtigungen für Dokumente

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-02-02
Hacker-News-Kommentare

  • Ein bisschen ähnlich wie nostr, aber mit Unterschieden. Die Daten sind nicht content-adressiert, sondern namensbasiert, sodass Überschreiben und Löschen unterstützt werden; auch der primitive Datentyp ist keine Menge von Nachrichten, sondern ein assoziatives Array von Namen zu Dokumenten.
    Dokumente werden in „shares“ gebündelt, und damit ein Server anerkennt, dass er die Dokumente dieses Shares besitzt, muss er zuerst die „share address“ kennen. Interessant ist der Zugriff, bei dem manches privat und manches öffentlich ist; Projekte, die auf dieser Achse ein Extrem wählen, haben es meist schwer – ich denke, das gilt für die meisten.
    Gegen Spammer und Betrüger dürfte das wohl funktionieren, aber bei großen Gruppen mit motivierten Angreifern wäre ich vorsichtig. Wenn ein einzelner Nutzer eine share address offenlegt, die in der Grauzone zwischen öffentlich und privat liegt, scheinen alle Nutzer dieses Shares offengelegt zu werden.
    Ein Web of Trust, bei dem ein Angreifer jeden Hop im Vertrauensgraphen durchbrechen muss, bevor er ein Ziel findet, wäre besser; die Komplexität für die Nutzer wäre aber höher, daher verstehe ich, warum man zugunsten von Einfachheit fehlende Granularität in Kauf nimmt. Ich hoffe, dass so etwas Erfolg hat; es fühlt sich an, als hätten wir das Web verloren, und ohne etwas Web-Ähnliches ist es in wichtigen Momenten für viele Menschen schwierig, sich in großem Maßstab zu koordinieren.

    • Bei einem ordentlichen Capability-basierten Design sollte jeder Nutzer eine eigene share address bekommen, die sich jederzeit deaktivieren lässt.
      Eine share address sollte wie ein SSH-Schlüssel behandelt werden.

  • Ich bin mir nicht ganz sicher, was genau das ist.
    Ist es irgendeine Dokumenten- und Mediendatenbank mit viel JavaScript? Ein wenig auf Self-Hosting ausgerichtet, mit Replikation über Peer-Nodes ähnlich wie Mastodon? Es scheint eine große Vision zu geben, aber sie ist nicht klar erkennbar.

    • Der Vorteil von Earthstar scheint die Dezentralität zu sein. Ansonsten ist es in der Breite der Datenbankfunktionen nicht so stark wie PGlite oder SQLite, die offline funktionieren, lokal speichern und im Browser laufen können.
      Ich weiß nicht, was man durch die Dezentralität von Earthstar gewinnt. Wenn es um Backups geht, ist das auch mit SQLite und PGlite ziemlich einfach. Ob das für die meisten Datenbanknutzer ein großer Vorteil ist, sehe ich nicht wirklich.
      Für Leute, die Daten auf ihren eigenen Geräten speichern und diese Daten mit anderen Privatpersonen teilen wollen, die ebenfalls lokale Kopien haben sollen, scheint es nützlich zu sein. Vielleicht auch für illegales Content-Sharing.
    • Im gleichen Sinn gibt es den Begriff local-first, und diese Richtung wirkt aktiver.
    • Genau das wollte ich auch schreiben. Ich weiß nicht, was der Use Case ist, wie man es benutzt oder warum man es benutzen sollte.
      Es gibt eindeutig interessante Funktionen, aber die Vision wirkt in der Feature-Aufzählung verwässert.

  • Ich sehe das als durch das früher hier gepostete Willow-Protokoll [0] ersetzt.
    Ich habe versucht, Willow zu lesen, aber ich konnte einfach kein Gefühl dafür bekommen [1]. Es sieht aus wie ein hierarchischer Key-Value-Store mit haufenweise zusätzlichen Feldern für Timestamps und Krypto-Token, aber es gibt viel zu wenige funktionierende Beispiele.
    Selbst die aktuelle Rust-Library [2] ist praktisch nur ein Bündel abstrakter Klassen, deren Implementierungen lediglich Fehler werfen. Man könnte Witze über den Stand europäischer technischer Raffinesse machen, aber ich belasse es bei einem höflichen Lächeln.
    [0] https://willowprotocol.org/earthstar/spec/
    [1] https://willowprotocol.org/specs/data-model/index.html#data_...
    [2] https://github.com/earthstar-project/willow-rs/tree/main

    • Das Projekt wird von NLnet gefördert. Die Liste der von NLnet geförderten Projekte findet sich unter [1], und jedes freie bzw. Open-Source-Projekt kann sich bewerben [2].
      [1] https://nlnet.nl/project/current.html
      [2] https://nlnet.nl/funding.html
    • Ich wollte dasselbe sagen wie der Geschwisterkommentar. Kein Grund für Sarkasmus; NLnet unterstützt wirklich sehr viele großartige Projekte.
      Wenn man die Qualität von Software aus dem Silicon Valley anhand gescheiterter VC-finanzierter Projekte beurteilen würde, käme man auch zu keinem brauchbaren Ergebnis.

    • Die Leute hinter Willow scheinen ebenfalls dasselbe Team zu sein: https://earthstar-project.org/docs/future#willow-protocol
      „Die oben genannten Funktionen werden alle durch das neue Willow General Purpose Sync Protocol möglich, an dem wir gearbeitet haben. Es ist ein neues, von Earthstar inspiriertes Protokoll, das dessen Konzepte verfeinert und erweitert. Wir werden eine neue Website mit der vollständigen Spezifikation dieses Protokolls veröffentlichen.“

      https://willowprotocol.org/more/compare/index.html#compare_e...
      „Wenn sich Earthstar sehr ähnlich wie Willow anfühlt, ist das kein Zufall. Willow begann als Neuinterpretation von Earthstar; künftige Versionen von Earthstar werden auf Willow aufbauen, und der zentrale Maintainer von Earthstar ist einer der beiden Autoren von Willow.“
    • Im Banner ganz oben auf der Website steht wörtlich: „Earthstar has a new specification powered by Willow.“
    • Ein einzelnes Ein-Personen-Open-Source-Projekt sagt nicht alles über den Stand europäischer technischer Raffinesse aus.

  • Gibt es einen Python-Client? Das Einzige in der Doku, das nach Python aussieht, ist das hier:
    # Earthstar timestamps in python
    timestamp = int(time.time() * 1000 * 1000)

  • Ich würde eher jellyfin, immich und für den Rest einfach sftp empfehlen. Synchronisierung, nein, Dezentralisierung, kann man mit git, syncthing und rsync machen.
    Einen brauchbaren selbst gehosteten Identity Manager oder SSO habe ich noch nicht gesehen. Ich glaube, bluesky baut so etwas, weiß aber nicht, ob es selbst gehostet werden kann. Die Autovervollständigung hat das freudianisch zu „self hostage“ geändert.
    Ein weiteres im Homelab/Private-Cloud-Umfeld noch ungelöstes Problem ist, selbst CA zu sein und den Zugriff auf meine Maschinen zu verwalten, ohne anderen ssh beibringen zu müssen.
    Ich möchte etwas wie meshnet von NordVPN, bei dem Leute, die im Familientarif angemeldet sind, die Maschinen der anderen wie in einem lokalen Netzwerk sehen können. Geht das mit wireguard? yggdrasil scheint auch so etwas zu sein, aber ich habe es mir noch nicht genauer angesehen.

    • Ist das nicht eine Library, um eigene Anwendungen zu bauen? Ich verstehe nicht, warum etwas wie jellyfin hier relevant sein sollte.
      Meinst du mit „gutem“ Identity Management etwas anderes als OpenLDAP oder 389? Wenn Windows berücksichtigt werden muss, weiß ich nicht, wie gut das passt.
      Selbst CA zu sein ist einfach, aber der Teil, diese CA auf allen gewünschten Maschinen zu installieren, ist unschön. Mit Let’s Encrypt läuft alles problemlos.
      Wireguard kann zwei LANs über das Internet verbinden, aber idealerweise hat man an beiden Enden je einen Router mit wireguard-Unterstützung wie pfsense. Andernfalls muss man auf jeder Client-Maschine spezielle Routing-Konfigurationen einrichten. Wie man avahi für Auto-Discovery über die Verbindung weiterreicht, habe ich noch nicht herausgefunden.
    • Wenn du mit deiner Familie ein VLAN teilen willst, ist tailscale vielleicht das, wonach du suchst.

  • Ich finde es immer noch schade, dass ich erst zur SQLite-Party dazugestoßen bin, nachdem die Browser die SQLite-Unterstützung eingestellt hatten.

  • Ein Blogbeitrag dazu wäre wirklich hilfreich. Zum Beispiel darüber, warum es so entworfen wurde und welche Alternativen es gab.
    Der erste Eindruck ist interessant. Mir gefällt auch, dass Identität ein Schlüsselpaar ist und man auf Dateien und Inhalte über Namen zugreifen kann.

  • Besteht die Möglichkeit, dass es Implementierungen in anderen Sprachen wie Python geben wird? Mir gefällt alles daran, nur dass es JavaScript ist, stört mich; JavaScript für solche Zwecke einzusetzen, sehe ich noch vorsichtig.

    • Wegen solcher Anwendungen mag ich Sprachen wie nim oder gleam, die sowohl nach JavaScript als auch auf andere Targets kompilieren. Dann kann die App überall laufen: auf einem Raspberry Pi, einem ESP32 oder in einem Browser-Tab.
      Leider sind beide nicht so verbreitet, sodass man am Ende doch Implementierungen in mehreren Sprachen anfragt, was für die Maintainer solcher Projekte eine Belastung sein dürfte. Wie auch immer, so ist die Realität, und wenn es keine solche Sprache ist, hätte ich ebenfalls Interesse an einer Python-Client-Library.

  • „Immer selbst gehostet. Server optional. Keine Blockchain. Keine Tokens. In jeder Hinsicht für immer kostenlos.“
    Das ist die beste Zusammenfassung der Kernthese.