Soziales Dateisystem

 (overreacted.io)
1 Punkte von GN⁺ 2026-01-19 | 1 Kommentare | Auf WhatsApp teilen
  • Das Konzept des dateizentrierten Personal Computing wird auf Social Computing ausgeweitet und beschreibt eine Struktur, in der alle von Nutzern erstellten Inhalte ihnen selbst gehören statt einer App
  • Auf Basis des AT-Protokolls wird das Konzept eines dezentralen sozialen Dateisystems vorgestellt, das Dateninteroperabilität zwischen Apps ermöglicht
  • Jeder Nutzer hat seinen eigenen „everything folder“ bzw. ein Repository, in dem Beiträge, Likes und Follows als JSON-basierte Dateien (Records) gespeichert werden
  • Durch DID (Decentralized Identifier) und das at://-URI-Schema bleiben dauerhaft identifizierbare Links auch bei Hosting-Wechsel oder Handle-Änderungen erhalten
  • Diese Struktur bildet ein datenzentriertes soziales Ökosystem statt eines appzentrierten und ermöglicht es jedem, neue Apps zu bauen, die auf vorhandenen Daten arbeiten

Das Datei-Paradigma und seine soziale Erweiterung

  • Dateien existieren ursprünglich in einem vom Nutzer kontrollierten Bereich statt innerhalb einer App, und Apps dienen nur als Werkzeuge zum Lesen und Schreiben von Dateien
    • Offene Dateiformate wie .svg ermöglichen es mehreren Apps, dieselben Daten gemeinsam zu nutzen
    • Nach dem Prinzip „Das Dateiformat ist die API“ wird Interoperabilität zwischen Apps möglich
  • Wendet man dieses Konzept auf soziale Apps an, können auch Handlungen wie Beiträge, Follows und Likes wie Dateien behandelt werden
    • Es gibt einen „everything folder“, der sämtliche Online-Aktivitäten eines Nutzers enthält
    • Apps spiegeln die Daten dieses Ordners wider, der als Single Source of Truth dient

Das AT-Protokoll und das soziale Dateisystem

  • Das AT-Protokoll ist die Technologie, die diese Struktur praktisch umsetzt; Bluesky, Leaflet, Tangled, Semble und Wisp basieren darauf
  • Apps besitzen die Nutzerdaten nicht; durch getrennte Datenspeicherung auf Dateiebene können neue Apps bestehende Daten wiederverwenden
  • Die Ordner aller Nutzer zusammen bilden ein dezentrales soziales Dateisystem

Struktur von Records und Collections

  • Jeder Beitrag wird als JSON-Datei (Record) dargestellt und enthält weder Autoreninformationen noch abgeleitete Daten wie die Anzahl der Likes
    • Beispiel: { text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
  • Dateinamen werden als zeitstempelbasierte Schlüssel (Record Keys) erzeugt, um Kollisionen zu vermeiden
  • Die Dateistruktur wird durch ein Schema definiert, das Lexicon genannt wird; jede App kann ihr eigenes Lexicon entwerfen
    • Beispiel: com.twitter.post, fm.last.scrobble, io.letterboxd.review
  • Selbst für dasselbe Konzept können Apps unterschiedliche Lexicons haben; domainbasierte Namespaces vermeiden Kollisionen

Validierung und Vertrauen

  • Es gibt keine Lexicon Police — keine App kann die Daten anderer Apps erzwingen
    • Apps validieren eingegebene Daten beim Lesen (validate on read) und ignorieren sie, wenn sie ungültig sind
  • Bei Änderungen an einem Lexicon ist Abwärtskompatibilität zwingend; Breaking Changes werden in ein neues Lexicon ausgelagert
  • Lexicons können öffentlich verteilt werden, und über DNS kann ein Nachweis des Domain-Besitzes erfolgen

Links und Identität

  • Von Nutzern erstellte Likes oder Replies müssen auf andere Records verweisen, daher ist ein permanentes Link-Schema erforderlich
  • Nach mehreren Versuchen wurde die Identität mit DID (Decentralized Identifier) etabliert
    • Ein Bezeichner wie did:plc:6wpkkitfdkgthatfvspcfmjo ist unveränderlich
    • Jede DID wird zu einem Dokument aufgelöst, das aktuelle Informationen zu Hosting, Handle und Public Key enthält
  • Eine at://-URI kombiniert DID, Collection und Record Key und liefert Links, die auch bei Hosting-Wechseln nicht brechen
    • Beispiel: at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5

JSON-Hyperlinks und Darstellung von Beziehungen

  • Jeder Like, Repost und Reply hat eine hyperlinkartige JSON-Struktur, die auf andere Records verweist
    • Beispiel: Das Feld parent verweist auf die at://-URI eines anderen Beitrags
  • Alle Informationen in der UI (Autor, Text, Anzahl der Likes usw.) lassen sich aus diesen Verknüpfungen zwischen Dateien berechnen

Repository und Datenfluss

  • Der „everything folder“ eines Nutzers wird als Repository bezeichnet und durch eine DID identifiziert
    • Darin befinden sich mehrere Collections und Records
  • Ein Repository kann überall gehostet werden, und die Links bleiben auch nach einem Umzug erhalten
  • Apps können ein Repository wie ein Dateisystem lesen oder per Stream (WebSocket) abonnieren, um in Echtzeit zu synchronisieren
    • Jeder Commit wird über einen signierten Hash-Baum (Merkle Tree) verifiziert, um Datenfälschung zu verhindern
    • Relay-Server leiten Ereignisse lediglich weiter und schaffen Vertrauen durch eine überprüfbare Struktur

Erkundung der Atmosphere und reale Beispiele

  • pdsls.dev funktioniert durch Eingabe einer DID oder eines Handles wie ein Explorer für soziale Dateisysteme
    • Jede Collection und jeder Record kann direkt eingesehen werden
  • Die Beispiel-App Sidetrail übernimmt Änderungen an den Records eines Nutzers in Echtzeit und zeigt, dass die Daten im Repository statt in der App liegen
  • Die Demo teal.fm Relay visualisiert Musik-Abspielhistorien (Scrobbles), indem sie fm.teal.alpha.feed.play-Records indexiert, ganz ohne echte API
    • Mit dem Tool lex-gql lassen sich GraphQL-Abfragen auf Lexicon-Basis ausführen
  • In Bluesky können Nutzer selbst erstellte Custom-Feed-Algorithmen veröffentlichen
    • Beispiel: Der „For You“-Feed von @spacecowboy17.bsky.social arbeitet unabhängig und zeigt, wie Dritte Funktionen auf gemeinsam genutzten Daten verbessern können

Fazit

  • Das soziale Dateisystem präsentiert eine datenzentrierte Internetstruktur statt einer appzentrierten
  • Nutzer besitzen ihr eigenes Daten-Repository, und Apps reagieren darauf aufbauend
  • Ziel ist der Übergang weg von einer „App, die alles macht“, hin zu einem „Ökosystem, in dem alles möglich ist“

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-19
Hacker-News-Kommentare

  • Apps können verschwinden, aber Dateien bleiben
    Im Beitrag von swyx wird betont, dass langlebige Arbeit letztlich als Dateien/Daten existiert
    Daten lassen sich auch ohne Berechtigungen parsen und bleiben selbst bei teilweiser Beschädigung noch nützlich, aber die ökonomischen Anreize drehen sich weiterhin um Code
    Wenn Standards entstehen, durch die Code Daten annehmen und ausgeben kann, schafft das enormen Wert für die gesamte Zivilisation
    Ich denke, eines der stärksten Hebel, die wir haben, ist, das Entwickler-Ökosystem dazu zu bringen, dass Unternehmen wie Google, Microsoft, OpenAI und Anthropic sich freiwillig an der Datenstandardisierung beteiligen

    • Ich stimme der Aussage zu, dass „Dateien die Quelle der Wahrheit sind“
      Aber heutige Apps sind Websites, die von Werbeeinnahmen abhängen, daher gibt es überhaupt keinen Anreiz, in so einer Struktur zu arbeiten
    • Nur weil man Google, MS, OpenAI oder Anthropic gibt, was sie wollen, heißt das nicht, dass man dafür auch belohnt wird
      Schon Apple zeigt, dass Standards die Welt oft nicht verändern
    • Schön zu sehen :) Vom „Gesetz der Indirektion“ hatte ich noch nie gehört, aber das ist ein ziemlich interessantes Konzept

  • Wenn das Feld createdAt ein beliebiger Wert sein kann, könnte ich dann nicht nachträglich Einträge zurückdatieren?
    Ich frage mich, ob es eine Möglichkeit gibt, per Signatur nachzuweisen, wann etwas erstellt wurde und ob es danach verändert wurde

  • POSSE und das AT Protocol kann man als interoperablen Marktplatz verstehen
    Wie bei Reddit oder Instagram ist User-Content die Ware, Aufmerksamkeit die Währung und die Plattform verdient an Werbung oder Verhaltensdaten
    Aber diese Struktur ist nicht zwangsläufig.
    Wenn Nutzer Eigentum an ihren sozialen Daten haben, werden Apps zu Interfaces, die diese Daten lesen
    Ich wende ein ähnliches Modell auch im Commerce an — Verkäufer hosten ihre Bestell- und Zahlungslogik selbst, und der Marktplatz integriert direkt mit den APIs der Verkäufer
    So lassen sich Plattformgebühren senken und Eigentum an die eigentlichen Wertschöpfer zurückgeben

    • Ich habe openship im Profil gesehen und war neugierig, ich werde es mir direkt ansehen

  • Der Beitrag war so detailliert, dass es für die Vermittlung des Kerns fast etwas zu viel wirkte
    Trotzdem sind die Metaphern hervorragend. Mit einem Dateibrowser für PDS könnte man das direkt selbst erleben
    Das PDS von Bluesky ist im Grunde ein öffentliches Dateisystem, und Replikation gehört wie bei Git zum Design
    Replikation ist nicht kontrollierbar, hat aber auch den Vorteil automatischer Backups
    Letztlich bleibt alles, was man auf ein PDS hochlädt, wie ein permanenter Eintrag bestehen, also sollte man vorsichtig sein

    • Mein Ziel beim Schreiben ist es, die Struktur in meinem Kopf so direkt wie möglich zu übertragen
      Wenn es nützlich, aber lang ist, können andere sich einfach die Teile herausnehmen, die sie brauchen
      Im Demo-Abschnitt am Ende des Beitrags sieht man ein echtes Beispiel für einen Dateimanager
      Der Ausdruck „eine Welt, in der jeder zum Scraper wird“ trifft den Kern
    • Mit pdsfs kann man ein PDS per FUSE lokal schreibgeschützt mounten
    • pdsls.dev erfüllt diese Rolle sehr gut. Es ist eine vollständig clientseitige App und Open Source
    • Ich frage mich, wie der Stand bei der atproto-Verschlüsselung ist. Reicht es, einfach mit sha256 verschlüsselte Daten zu veröffentlichen?
    • ATProto ist noch kein fertiges Protokoll, und Unterstützung für private Daten soll bald dazukommen

  • Ich halte das Konzept „Datei“ bereits für veraltet
    Wenn man alles als hashbasierte Blob-Daten behandelt, verschwinden viele Probleme
    Was Nutzer wollen, ist nicht eine App, sondern eine Fähigkeit (Capability)
    Zum Beispiel die Fähigkeit, Yogavideos anzuschauen, oder die Fähigkeit, Bekannten Updates aus dem eigenen Leben mitzuteilen — nicht YouTube oder Bluesky an sich
    Apps sind nur Bündelungen solcher Fähigkeiten
    Was wir brauchen, sind maßgeschneiderte Workflows, etwa in einer Messaging-App ein Wort zu suchen und das Ergebnis direkt im Chatfenster zu teilen
    Inspiriert wurde ich von PerKeep

    • Das Dateisystem ist eine Metapher
      Ich habe es als Metapher verwendet, um die n:m-Beziehung zwischen Apps und Dateiformaten zu erklären
      Die Erklärung der Repository-Struktur von ATProto zeigt eine inhaltsadressierte Struktur auf Basis eines Merkle-Baums
      Lexicon steht nicht in einer 1:1-Beziehung zu Apps, daher bewegt sich AT bereits in Richtung einer Post-App-Ära

  • Ich denke, dass geschlossene Plattformen (Walled Gardens) ein Ergebnis von Verbraucherpräferenzen sind
    Als das Internet alles geöffnet hat, wollten Menschen eher kleine Räume rund um bestimmte Kulturen oder Ideen
    IG oder Snap sind in gewisser Weise solche fein segmentierten Gruppenchats
    Ich finde es sogar gut, dass meine IG-Posts nicht automatisch auf HN oder Truth Social geteilt werden
    Ich kann den Wert von Datenportabilität nicht so richtig nachvollziehen. Übergänge zwischen Plattformen mit unterschiedlichem Kontext wirken für mich wenig sinnvoll

    • ATProto-Apps teilen standardmäßig nicht automatisch alle „Dateien“
      Mein Anisota wurde so entworfen, dass es sowohl Dateien von Bluesky als auch von Leaflet unterstützt
      Man kann denselben Post zum Beispiel sowohl auf Bluesky als auch auf Anisota sehen
      Außerdem bietet das Projekt Aturi universelle Links für Inhalte auf Basis von ATProto
    • Als Twitter übernommen wurde, hätte ich es gut gefunden, meine Identität, meine Posts, Likes und meinen sozialen Graphen unverändert mitnehmen zu können
      In ATProto ist bei Apps, die dasselbe Lexicon verwenden, eine vollständige Übertragbarkeit von Identität und Daten möglich
    • Ich verstehe auch nicht so recht, warum man Datenportabilität braucht
      Die Originalbilder liegen lokal bei mir, und jede Plattform ist nur eine andere Darstellung
      Ich will keine sinnlose Integration zwischen Plattformen
    • Wenn Truth Social den Federation-Code nicht entfernt hätte, wären dort auch Posts erschienen, die auf Mastodon usw. geschrieben wurden
    • Es ist gut, wenn verschiedene Apps ihre eigene „Atmosphäre“ behalten
      AT macht lediglich Interoperabilität möglich, ohne alles zu vereinheitlichen
      Leaflet zeigt zum Beispiel Bluesky-Posts zur Nachverfolgung von Zitaten an
      Durch diese Struktur kann man ein Produkt forken und trotzdem vollständig netzwerkkompatibel bleiben, was den Wettbewerb belebt
      Tatsächlich ist Blacksky ein Fall, in dem Bluesky geforkt und eine andere Moderationspolitik angewendet wurde

  • Beiträge von Dan sind immer interessant. Beim Lesen merkt man irgendwann, dass er der Autor ist

    • Danke :)

  • Ich bin skeptisch gegenüber selbstbeschreibenden Datenmodellen (self-describing data model)
    Die Behauptung von ATProto, „wenn man nur Lexicon hinzufügt, entsteht ein Client“, wirkt übertrieben
    In Wirklichkeit muss man die Bedeutung der Daten verstehen, um eine UI zu bauen, und Lexicon allein reicht dafür nicht aus
    Letztlich unterscheidet sich das kaum davon, die Dokumentation zu lesen und es selbst zu implementieren
    Standardisierung ist gut, aber das ist nicht unbedingt ein Problem auf dem Niveau einer weltweit replizierten DB
    Trotzdem schätze ich den Versuch, Lock-in zu verringern
    Allerdings waren die eigentlichen Probleme bei Twitter soziale Faktoren wie politische Inhalte oder Spam

    • Dein Beispiel beschreibt einfach einen Fall, in dem es keinen Client gibt, weil sich niemand dafür interessiert
      Aber wenn ein beliebter Dienst wie Bento verschwindet, wird jemand versuchen, diese Daten wiederherzustellen
      Blento ist zum Beispiel ein Bento-Ersatz auf Basis von ATProto und Open Source, sodass ihn jeder wieder aufsetzen kann
      Eine solche Struktur ist ein bedeutender Fortschritt, wenn es um die Beständigkeit von Nutzerinhalten geht

  • Beim Lesen von „The Unix Programming Environment“ wurde mir klar, wie viel man allein mit einfachen Tools und Textdateien machen kann
    Ich stelle mir vor, wie Slack aussähe, wenn es in einem dateizentrierten UNIX-Stil gebaut worden wäre
    Ich möchte zurück zu einfachen, kombinierbaren Systemen

    • Unix lieferte großartige Architekturideen, aber alles als Klartext zu behandeln, war auch eine Grenze
      Für Menschen gut lesbare Serialisierung ist schön, aber ständiges Parsen und Neuformatieren ist mühsam

  • Das Konzept neuer sozialer Plattformen, die in einer dezentralen/föderierten Umgebung gemeinsame Protokolle und Datenformate teilen, ist interessant
    Aber es dürfte schwer sein, bestehende kommerzielle Plattformen davon zu überzeugen
    Wenn sich solche Standards durchsetzen, könnten Social-Marketing-Tools mehrere Netzwerke deutlich einfacher integriert verwalten
    In der Realität dominieren aber weiterhin geschlossene Ökosysteme wie Facebook, Instagram und TikTok