s@ : Dezentrales Social Networking auf Basis statischer Websites

 (satproto.org)
9 Punkte von GN⁺ 2026-03-13 | 1 Kommentare | Auf WhatsApp teilen
  • Ein dezentrales Social-Networking-Protokoll auf Basis statischer Websites, bei dem jeder Nutzer seine Daten direkt selbst besitzt und verwaltet
  • Alle Daten werden in einem verschlüsselten JSON-Speicher aufbewahrt, und der Browser-Client aggregiert den Feed und veröffentlicht Beiträge
  • Funktioniert ohne Server oder Relay durch direkte Kommunikation zwischen den Websites von Freunden und ihren Browsern
  • Der Domainname des Nutzers ist zugleich seine Identität und wird über HTTPS/TLS authentifiziert
  • Setzt mit einer einfachen Struktur ein selbstsouveränes soziales Netzwerk um, mit Fokus auf vertrauensbasierte Interaktion zwischen Einzelpersonen

Überblick über das sAT Protocol

  • s@ ist ein dezentrales Social-Networking-Protokoll auf Basis statischer Websites, bei dem jeder Nutzer Daten auf seiner eigenen Website speichert
    • Alle Daten werden als verschlüsselte JSON-Dateien gespeichert, die vom Browser-Client gelesen werden, der außerdem Beiträge veröffentlicht und Feeds aggregiert
    • Es funktioniert ohne zentrale Server oder Relays, und die Daten wandern direkt von der Website eines Nutzers in den Browser eines Freundes
  • Für den Austausch von Beiträgen ist eine gegenseitige Follow-Beziehung erforderlich; eine influencer-zentrierte Struktur wird ausgeschlossen
  • Das Protokoll ist nicht an bestimmte Hosting-Dienste wie GitHub Pages gebunden

Identität

  • Der Domainname des Nutzers dient als Identität
  • Über HTTPS/TLS wird bestätigt, dass der Eigentümer der Domain die Inhalte veröffentlicht hat

Discovery

  • Unter https://{domain}/satellite/profile.json werden Protokollversion und öffentlicher Schlüssel bereitgestellt 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • Wird statt des Standardpfads /satellite/ ein anderer Pfad verwendet, kann die tatsächliche Speicherposition über die Datei .well-known/satproto.json angegeben werden

Verschlüsselungsmodell

  • Alle Nutzerdaten werden in einem verschlüsselten JSON-Speicher abgelegt und können nur vom Nutzer selbst und seinen Followern entschlüsselt werden
  • Verwendet wird ein X25519-Schlüsselpaar; der öffentliche Schlüssel wird in profile.json veröffentlicht, der private Schlüssel im Browser-localStorage gespeichert
  • Beitragsdaten werden mit XChaCha20-Poly1305 verschlüsselt; der Content-Schlüssel wird pro Follower mit libsodium crypto_box_seal verschlüsselt
  • Die Datei keys/_self.json enthält den Content-Schlüssel des Nutzers und Veröffentlichungsgeheimnisse und kann nur vom Nutzer selbst entschlüsselt werden

Schlüsselrotation und Unfollow

  • Beim Unfollow wird ein neuer Content-Schlüssel erzeugt und alle Beiträge werden neu verschlüsselt
  • Für die verbleibenden Follower werden neue Schlüsselumschläge erstellt und keys/_self.json aktualisiert
  • Entfolgte Nutzer können Beiträge nicht länger entschlüsseln

Entschlüsselungsablauf

  • Wenn ein Besucher die Website eines Freundes aufruft, entschlüsselt er mit seinem privaten Schlüssel keys/{follower-domain}.json, um den Content-Schlüssel zu erhalten
  • Anschließend werden posts/index.json und einzelne Beiträge (posts/{id}.json.enc) abgerufen und entschlüsselt

Datenstruktur

  • Jeder Beitrag wird als einzeln verschlüsselte Datei gespeichert; posts/index.json listet die Beitrags-IDs in umgekehrt chronologischer Reihenfolge auf
  • Beispiel für ein Beitragsobjekt: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • Die Beitrags-ID besteht aus einem ISO8601-UTC-Zeitstempel und einem 4-stelligen Zufallshash

Follow-Liste

  • Gespeichert als Klartext-JSON unter https://{domain}/satellite/follows/index.json 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • Sie ist nicht verschlüsselt, da die Follow-Beziehung durch die Schlüsselumschläge ohnehin bereits offengelegt wird

Feed-Aggregation

  • Der Client liest die Follow-Liste und entschlüsselt die Beiträge der einzelnen Follower, um einen chronologischen Feed aufzubauen
  • Die Beiträge werden nach created_at absteigend sortiert

Antworten

  • Antworten sind Beiträge, bei denen die Felder reply_to und reply_to_author gesetzt sind
  • Verschachtelte Antworten werden nicht unterstützt; direkte Antworten sind nur auf Top-Level-Beiträge möglich
  • Wenn der ursprüngliche Beitrag nicht sichtbar ist, etwa weil keine Follow-Beziehung besteht, wird die Antwort nicht angezeigt

Veröffentlichen

  • Neuen Beitrag erstellen → mit dem Content-Schlüssel verschlüsseln → auf die statische Website hochladen → posts/index.json aktualisieren
  • Für das Hochladen kann z. B. die GitHub Contents API verwendet werden
  • Veröffentlichungsgeheimnisse werden verschlüsselt in keys/_self.json gespeichert

Beispiel für die Struktur einer statischen Website

{domain}/satellite/
  profile.json              # Öffentlicher Schlüssel und Profil
  posts/
    index.json              # Liste der Beitrags-IDs
    {id}.json.enc           # Verschlüsselter Beitrag
  follows/
    index.json              # Follow-Liste
  keys/
    _self.json              # Content-Schlüssel und Zugangsdaten
    {domain}.json           # Content-Schlüssel pro Follower

FAQ

  • „Ist das RSS + Verschlüsselung?“ → Ja
  • „Ist das eine Version des AT Protocol ohne Firehose?“ → Ja
  • „Ist es skalierbar?“ → Nein („Freundschaft skaliert auch nicht“)
  • „Steht das s für slow/shitty?“ → Ja
  • „Ist Self-Hosting möglich?“ → Ja, aber CORS muss aktiviert sein

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-13
Hacker-News-Kommentare

  • Ich habe das Gefühl, dass dieses Projekt unter denselben Problemen leidet wie viele alternative soziale Netzwerke und Self-Hosting-Netzwerke
    Das auf Verschlüsselung ausgerichtete Design ist zwar cool, aber wenn man auf ein neues Gerät wechselt, ist es schwer, den Follow-Graphen der Freunde wiederherzustellen, und Konzepte wie ein X25519-Schlüsselpaar sind für normale Nutzer schwer zu verstehen
    Ich denke, eine Struktur auf Benutzername-und-Passwort-Basis, bei der der Server die Verschlüsselung stellvertretend übernimmt, ist realistischer
    Genau so ein Ansatz könnte meiner Meinung nach auch von nichttechnischen Nutzern verwendet werden und eine echte Alternative zu Big Tech sein

    • Ich denke ähnlich. Aber wenn man eine Welt ohne Mittelsmänner will, braucht es am Ende wohl auch bei nichttechnischen Nutzern einen kulturellen Wandel hin zu etwas mehr Eigenverantwortung
    • Nach der Ersteinrichtung kann man den privaten Schlüssel exportieren und in einem Passwortmanager oder Ähnlichem speichern. Solange man das Protokoll nicht selbst implementiert, ist es nicht so kompliziert
      Allerdings müsste ich es für Familie oder Freunde vielleicht trotzdem einrichten. Trotzdem würden sie es vermutlich ziemlich mögen, wenn sie ihre eigene Website hätten
    • Laut FAQ am Ende des Artikels ist das eher ein konzeptionelles Experiment, bei dem einige Elemente des AT Protocol (BlueSky) weggelassen wurden
      In der Praxis kann man es als die Idee sehen, einen statischen Blog in BlueSky zu integrieren.
      Man könnte es verbessern, indem man die BlueSky-Identität nutzt oder Authentifizierungsinformationen automatisch über ein Plugin für einen Static-Site-Generator übernimmt
    • Ich hatte früher einmal versucht, E-Mail als Transport-Layer für ein soziales Netzwerk zu verwenden, aber das ist gescheitert
      Siehe diesen Beitrag
    • Ich weiß nicht, ob das Ziel wirklich ist, Big Tech zu ersetzen. Wenn es für kleine Communities nützlich ist, wäre das allein für mich schon ein Erfolg

  • Ich war überrascht von dem Teil, in dem steht, dass der private Schlüssel im localStorage des Browsers gespeichert wird
    Wenn man die Browser-Einstellungen zurücksetzt oder den Browser neu installiert, sind die Daten weg, Backups sind schwierig, und Malware kommt leicht daran
    Wenn der Schlüssel verloren geht, verschwindet am Ende auch der Feed für immer, was leicht dazu führen könnte, dass Nutzer abspringen

    • Stimme zu. Schon daran, dass Begriffe wie „X25519-Schlüsselpaar“ ganz selbstverständlich verwendet werden, merkt man, dass dieses Projekt eher ein Konzept-Experiment als etwas für die breite Masse ist
    • Ich denke, das ließe sich mit einem einzigen Button „Schlüssel an sicherem Ort exportieren“ lösen. Mit einfachem Code wie URL.createObjectURL(localStorage.getItem(...)) könnte man das Speichern als Datei anstoßen
    • Man sollte nicht im Streben nach Perfektion eine „gut genug“-Lösung verpassen. Schon eine Download-/Upload-Funktion für Schlüssel würde die meisten Probleme lösen
      Natürlich verliert man bei Schlüsselverlust den Zugriff, aber auch Nutzer von 2FA oder Krypto-Wallets tragen eine ähnliche Verantwortung, also ist das nicht völlig unrealistisch

  • Es wurde vorgeschlagen, statt des Pfads /satellite/ lieber /.well-known/ zu verwenden
    Dabei wurde auf den Standard Well-known URI verwiesen

    • Jemand antwortete scherzhaft mit „.poorly-known“
    • Ein anderer dachte an die Sicherheitslücke, die es in der frühen Phase von AT Proto gab, als der Root-Pfad verwendet wurde, und äußerte deshalb Bedenken
    • Es wurde argumentiert, dass .well-known für den gesamten Host gedacht sei und daher für Streams ungeeignet sei. Besser sei es, mehrere Verzeichnisse getrennt zu halten

  • Ich denke, der Vorschlag mit .well-known/ ist ernsthaft erwägenswert
    Es ist bereits ein weit verbreiteter IANA-registrierter Standard, und Dateien für Sicherheit und Discovery liegen oft dort
    Wenn man statt /satellite/satproto.json /.well-known/satproto.json verwendet, vermeidet man Konflikte und macht klar, dass es sich um einen Protokoll-Endpunkt handelt

    • Dagegen wurde eingewandt, dass .well-known hostbezogen ist und deshalb nicht gut passt, wenn man mehrere Verzeichnisse pro Account haben möchte

  • Ein Social-Network-Protokoll sollte nicht um der Technik willen existieren, sondern den Nutzern direkten Nutzen bringen
    Wie bei BitTorrent müssen Menschen einfach deshalb teilnehmen, weil sie es brauchen, erst dann entstehen Netzwerkeffekte
    Ein Ansatz, der bei Datenverwaltung und bequemem Teilen ansetzt, erscheint mir realistischer

    • Ich habe mehrere dezentrale soziale Netzwerke ausprobiert, und am Ende kommen die Leute nicht wieder, wenn der Dopamin-Kick fehlt
      Lemmy und Pixelfed hatten so wenig Inhalt, dass sie sich wie Orte anfühlten, an denen „nichts passiert“
      Bei Signal ist es ähnlich: Es ist nur fürs Messaging da, also gibt es keinen Grund zum Scrollen
      Am Ende braucht es Inhalte und FOMO (Angst, etwas zu verpassen), damit Menschen dauerhaft wiederkommen
    • Trotzdem ist gutes Protokoll-Design wichtig. Wenn es zu kompliziert ist oder zu wenig zukunftssicher, verschwindet selbst eine gute Idee schnell wieder

  • Wenn man einen wirklich dezentralen sozialen Dienst bzw. E2EE-Messenger bauen will, braucht man eher eine Struktur wie bei Discord, in der jeder Server tatsächlich unabhängig gehostet wird
    Accounts sollten über ein Protokoll wie Nostr verwaltet werden, und das Ganze sollte auf dem Yggdrasil Network laufen, um die Abhängigkeit von IPv4/6 und DNS zu verringern
    Wenn man den Traffic in HTTPS verpackt und NAT-Traversal automatisiert, könnte jeder einen Server betreiben
    Nur mit so einer Struktur könnte man sich der Kontrolle von Big Tech und Regierungen entziehen

    • Aber nur mit Technik allein geht es nicht. Die Masse wird am Ende zu Plattformen mit dem größeren Marketingbudget strömen
    • Ich halte einen cachebasierten verteilten Netzwerkansatz wie bei BitTorrent oder IPFS für besser
      Selbst wenn ein Server verschwindet, bleiben die Daten an den Edges erhalten, und der Browser des Nutzers könnte selbst als Host fungieren
      Siehe ephemeral-p2p-project
    • So eine Struktur wird bereits auf geogram.radio erprobt
      Dort arbeitet jedes Gerät als Server, und vollständiges P2P-Messaging wird mit WebRTC umgesetzt
      Selbst ohne Internet ist Datenaustausch über Funkverbindungen möglich
    • Ich baue bei Mikoto Platforms an etwas Ähnlichem. „Spaces“ können auf beliebigen physischen Nodes existieren, und DMs werden über mehrere Nodes hinweg mit E2EE-Routing übertragen

  • Früher gab es bereits vollständig dezentrale soziale Ansätze wie FOAF oder Pingback

    • Die moderne Version davon ist Webmention
      Das IndieWeb-Wiki ist eine gute Ressource, wenn man solche auf persönlichen Websites basierenden Social-Technologien erforschen will
    • Als weiteres Beispiel sollte man auch XFN nicht vergessen

  • Als ich die Beschreibung „sAT Protocol ist ein dezentrales soziales Netzwerk auf Basis statischer Websites“ las, wollte ich eine Kurve zeichnen, bei der die hochgezogenen Augenbrauen immer weiter steigen

    • Trotzdem wirkt es angesichts des eng gesteckten Ziels wie ein vernünftiges System
      Allerdings könnten öffentlich auflistbare Chiffretexte im Zeitalter von Quantencomputern riskant sein
    • Das ähnelt einer Kombination aus PGP + RSS. Jeder Feed wird verschlüsselt, sodass nur bestimmte Personen ihn entschlüsseln können
      Für kleine Netzwerke ist das geeignet, aber eine Skalierung wird wegen Problemen bei Schlüsselverteilung und -rotation schwierig
    • Ich verstehe es als ein Konzept, bei dem man „eine Datenbank ausliefert und der Client daraus eine statische Website baut“
    • Der Abschnitt „Key Rotation (Unfollow)“ war als Witz in ASCII-Art formuliert

  • Aus Nutzersicht müsste zuerst erklärt werden, was für ein Dienst das eigentlich ist und was er tut
    Es ist voller technischer Begriffe wie Fork, Pfade, JSON und Verschlüsselung, aber ein tatsächliches Nutzungsszenario ist nicht erkennbar

    • Trotzdem habe ich einige Freunde, die sich für Technik interessieren, und ich denke darüber nach, das mit Leuten auszuprobieren, die eine „paranoide Sicherheitsvorliebe“ haben
      Mastodon oder Signal decken diesen Bereich nicht ab, deshalb lohnt sich ein Experiment damit

  • Solche Experimente mit dezentralen Netzwerken finde ich wirklich spannend
    Auch wenn die Struktur viele grundsätzliche Probleme hat, macht es Spaß, neue Kombinationen kennenzulernen
    Allerdings ist es viel zu umständlich, bei jedem Follow oder Unfollow die gesamte Website neu zu verschlüsseln und neu zu bauen
    Außerdem schränkt eine Struktur, bei der man Kommentare nicht sehen kann, wenn man niemandem folgt, die Skalierbarkeit stark ein
    Trotzdem ist die Mischung aus RSS, ActivityPub und statischen Websites reizvoll
    Der Versuch, mit einer statischen Website eine dynamische Zugriffskontrolle für Freundeslisten umzusetzen, ist widersprüchlich, aber interessant
    Am Ende ist es eine Struktur, die gleichzeitig Liebe und Hass hervorruft. Trotzdem freue ich mich über solche Versuche und bin dankbar dafür