Soziales Dateisystem

(overreacted.io)

1 Punkte von GN⁺ 2026-01-19 | Noch keine 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 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

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

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

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

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

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

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

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“