Wie Nostr wirklich funktioniert: das Protokoll, ohne Jargon

Die meisten Erklärungen von Nostr enden mit „es ist ein dezentralisiertes Sozialprotokoll" und lassen den interessanten Teil unausgesprochen. Der interessante Teil ist, dass das gesamte Protokoll in ein kurzes Dokument passt. Kein cleverer Trick, keine verborgene Komplexität. Einfach nur ein paar primitive Bausteine, die zusammenarbeiten.

Dieser Leitfaden führt dich durch diese Bausteine in der Reihenfolge, wie sie auftauchen, wenn du Nostr tatsächlich verwendest: Wie ein Event erstellt wird, wie es signiert wird, wie es Relays erreicht, wie Clients abonnieren, und wie der Ablauf aussieht, wenn du einen Post mit „Like" markierst, eine Antwort erhältst oder einen Zap empfängst. Keine Blockchain-Vergleiche, keine großartige Erzählung. Einfach nur die Mechanik.

TL;DR. Nostr ist Pub/Sub über WebSockets mit kryptografischen Signaturen. Clients veröffentlichen signierte JSON-Objekte (Events) an Relays (kleine Server), und andere Clients abonnieren Relays mit Filtern, die den Events entsprechen, die sie wollen. Signaturen verhindern Fälschungen; mehrere Relays verhindern Single Points of Failure. Das ist das gesamte Protokoll; alles andere sind Formatierungskonventionen für verschiedene Arten von Inhalten.

When you're ready, grab your @nostr.blog address →

Der Baustein: ein Event

Alles auf Nostr ist ein Event. Ein Post ist ein Event. Eine Reaktion ist ein Event. Eine Profilaktualisierung ist ein Event. Eine Direktnachricht ist ein Event. Ein Zap-Quittung ist ein Event.

Ein Event ist ein JSON-Objekt mit genau dieser Form:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Sechs Felder leisten bedeutungsvolle Arbeit. id ist ein Hash des eigenen Inhalts des Events; er identifiziert das Event eindeutig. pubkey ist der Autor (ein 64-stelliger hexadezimaler öffentlicher Schlüssel). created_at ist ein Unix-Zeitstempel. kind ist eine Ganzzahl, die beschreibt, was das Event darstellt (mehr dazu unten). tags ist eine Liste strukturierter Anmerkungen wie Hashtags (t), Erwähnungen (p für pubkey, e für event), und Dutzende andere. content ist die freie Payload, normalerweise Text.

sig ist die Schnorr-Signatur, erstellt mit dem privaten Schlüssel des Autors, über den Hash in id. Dieses Feld verhindert Fälschungen: Jeder kann den Hash berechnen, aber nur der Inhaber des privaten Schlüssels kann eine gültige Signatur darauf erzeugen.

Was ist ein „kind"

Das kind-Feld teilt Clients mit, wie sie das Event interpretieren sollen. Die Nummer ist der gesamte semantische Typ.

Eine Handvoll Kinds in aktiver Verwendung:

Neue Kinds werden vorgeschlagen und standardisiert über NIPs (Nostr Implementation Possibilities). Jeder kann einen vorschlagen. Die, die weit verbreitet werden, werden zu De-facto-Teilen des Protokolls; die, die es nicht werden, bleiben einfach Nische, ohne etwas zu unterbrechen.

Wie ein Event veröffentlicht wird

Wenn du in einem Nostr-Client auf „Post" tippst, läuft diese Sequenz ab:

1. Client stellt die JSON zusammen. Füllt pubkey, created_at, kind, tags, content.
2. Client berechnet die id. Führt SHA-256 über eine kanonische Serialisierung dieser Felder aus. Das ist der Hash, den die Signatur abdeckt.
3. Client signiert die id mit dem privaten Schlüssel. Schnorr-Signatur über secp256k1, die gleiche Kurve, die Bitcoin verwendet. Die 64-Byte-Signatur wird das sig-Feld.
4. Client öffnet WebSocket-Verbindungen zu jedem konfigurierten Relay. Oder verwendet bestehende offene, wenn sie aktiv sind.
5. Client sendet das Event als Nachricht. Das On-Wire-Format ist ein JSON-Array: ["EVENT", {...event...}].
6. Jedes Relay validiert die Signatur. Lehnt das Event ab, wenn die Signatur nicht gegen den behaupteten pubkey überprüft wird. Akzeptiert und speichert ansonsten.
7. Jedes Relay pusht das Event an Abonnenten. Jeder Client mit einer offenen Subscription, deren Filter diesem Event entspricht, erhält das Event in Echtzeit.

Die gesamte Umlaufzeit beträgt 50 bis 300 Millisekunden, je nach Relay-Standorten. Wenn ein Relay langsam oder offline ist, veröffentlichen die anderen Relays das Event trotzdem. Du brauchst nur ein Relay, das es akzeptiert, damit das Event im Netzwerk existiert.

Wie ein Client Posts abruft

Lesen ist das Spiegelbild des Veröffentlichens.

Dein Client öffnet WebSocket-Verbindungen zu einer Liste von Relays. Für jedes sendet er eine Subscription-Nachricht:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Dies bittet das Relay um bis zu 50 Events von den Autoren in der Liste, der Kind 1 (Kurznote) oder Kind 6 (Repost). Das Relay:

1. Fragt seine lokale Datenbank nach übereinstimmenden Events ab, sendet sie (von ältest zu neueste standardmäßig, bis zur Grenze) als EVENT-Nachrichten zurück an den Client.
2. Sendet eine EOSE-Nachricht (end of stored events), damit der Client weiß, dass der historische Dump vollständig ist.
3. Hält die Subscription offen. Jedes neue Event, das dem Filter entspricht (später von jemandem veröffentlicht), wird in Echtzeit an den Client gepusht.

Das ist, wie dein Feed Live wird. Du fragst nicht ab; das Relay streamt.

Dein Client macht dies parallel über alle konfigurierten Relays. Die Vereinigung von Antworten ist deine Timeline. Doppelte Events über Relays werden durch id dedupliziert.

Wie Signaturen Fälschungen tatsächlich verhindern

Das ist der Teil, den die meisten Erklärungen übergehen.

Wenn ein Client ein Event erhält, berechnet er den Hash über die kanonische Serialisierung neu (gleich wie der Publisher) und führt Schnorr-Verifikation aus: Gegeben der pubkey, die id und die sig, überprüft die Signatur kryptografisch?

Wenn ja, ist das Event authentisch. Der Autor dieses Events war der Inhaber dieses pubkey im Moment der Signatur. Jeder Client führt diese Prüfung auf jedem Event aus. Ein Relay, das ein gefälschtes Event mit einer ungültigen Signatur verschickt, lässt das Event einfach stillschweigend von jedem Client fallen, der es sieht.

Das ist wichtig, denn es bedeutet, dass Relays nicht vertrauenswürdig sind. Ein böswilliges Relay kann dir keine Worte in den Mund legen. Es kann sich weigern, deine Posts zu servieren, es kann jemand anderen's (legitime) Posts in deinen Feed injizieren, aber es kann keinen gültigen Post produzieren, der von dir signiert ist, ohne deinen privaten Schlüssel, und es kann einen deiner bestehenden Posts nicht ändern, ohne die Signatur zu brechen.

Die Kosten dieser Eigenschaft sind genau eine Schnorr-Verifikation pro Event, was schnell genug ist, dass selbst mobile Clients dies mit Zehntausenden von Events pro Sekunde bewältigen.

Was Relays wirklich tun

Ein Relay ist eine einfache, schnelle Leitung mit drei Aufgaben:

1. Events akzeptieren und Signaturen validieren. Lehnt alles ab, das nicht überprüft wird oder Richtlinienprüfungen fehlschlägt (Spam-Filter, Größenlimits, blockierte pubkeys).
2. Events speichern. Normalerweise in einer SQLite- oder PostgreSQL-Datenbank, die nach id, pubkey, kind und Tag-Werten indexiert ist.
3. Subscriptions servieren. Filter von eingehenden REQ-Anfragen gegen die Datenbank abgleichen (für Verlauf) und gegen Live-Events (für Echtzeit).

Das ist alles. Ein Relay ordnet nicht ein, empfiehlt nicht, kuriert nicht, monetarisiert nicht, zeigt Anzeigen, wendet einen Algorithmus an oder tut etwas, das eine Plattform tun würde. Es leitet signierte Bytes weiter.

Das Fehlen dieser anderen Aufgaben ist der Grund, warum Relays klein sein können. Ein einzelner $5-pro-Monat VPS kann ein Relay bedienen, das Hunderte von aktiven Nutzern bedient. Die gleiche Funktion im Maßstab von Twitter kostet Milliarden, denn Twitter tut all die anderen Dinge.

Relay-Richtlinien unterscheiden sich. Einige sind erlaubnisfrei und bedienen alle signierten Events. Einige erfordern Zahlung (das „Paid Relay"-Modell), andere beschränken sich auf eine bestimmte Community (Mitarbeiter eines Unternehmens, Mitglieder eines Discord-Servers), und wieder andere sind aggressiv bei der Spam-Filterung. Du wählst, welche Relays du verwendest; deine Wahl beeinflusst, welche Posts du siehst und welche deine Follower erreichen.

Ein vollständiges Beispiel: Alice liked Bobs Post

Alles zusammenbindend, hier ist, was passiert von Ende zu Ende, wenn Alice einen Post liked, den Bob geschrieben hat.

1. Bob veröffentlicht. Bobs Client erstellt ein Kind:1-Event mit Inhalt „hello world", signiert es, sendet es an Bobs fünf konfigurierte Relays. Jedes Relay akzeptiert und speichert.
2. Alice abonniert. Alices Client hat eine offene Subscription auf zwei dieser Relays mit einem Filter, der Bobs pubkey in authors enthält. Die Relays pushen Bobs Event in die Subscription. Alices Client zeigt den Post in ihrer Timeline.
3. Alice tippt auf Like. Alices Client erstellt ein Kind:7-Event mit Inhalt „+" (die Nostr-„Like"-Konvention), taggt den Post, auf den es reagiert (["e", "bob_post_id"]) und den Autor (["p", "bob_pubkey"]). Signiert und veröffentlicht an Alices fünf konfigurierte Relays.
4. Die Reaktion breitet sich aus. Jedes Relay, das eine aktive Subscription mit dem Filter { "#e": ["bob_post_id"], "kinds": [7] } hat (was Bob's Client verwendet, um auf Reaktionen auf seine eigenen Posts zu achten), pusht die Reaktion an Bob. Bobs Client aggregiert die Likes und zeigt den Zähler unter dem Post.

Bemerke, was nicht passiert ist. Kein zentralisierter „Like-Button"-Service wurde angesprochen. Kein Backend entschied, ob der Like zählt. Der Like ist einfach ein signiertes Event, angekündigt auf den gleichen Kanälen wie der Post selbst.

Was Nostr bewusst nicht tut

Fünf Dinge sind absichtlich aus dem Kernprotokoll gelassen, weil sie in den Client oder das Relay gehören, nicht in das gemeinsame Wire-Format.

• Identitätsverifikation. Nostr beweist nur „dieser pubkey hat diesen Post signiert". Ob der pubkey zu einem bestimmten Menschen gehört, ist eine separate Frage, beantwortet durch NIP-05 und Off-Chain-Kontext.
• Content-Moderation. Das Protokoll entscheidet nicht, was sichtbar ist. Clients filtern, Relays filtern, Nutzer filtern. Jede Schicht unabhängig.
• Suche. Es gibt keinen globalen Search-Endpunkt. Einige Relays unterstützen Textsuche über ihren lokalen Event-Pool; es gibt keine Protokollgarantie, dass Relays Posts finden können.
• Algorithmische Rangordnung. Kein „For You"-Feed im Protokoll. Rangordnung geschieht im Client, wenn überhaupt.
• Account-Wiederherstellung. Kein Email-Reset, kein Telefon-Reset, kein zentrales Streitbeilegungssystem. Verliere den privaten Schlüssel, verliere die Identität. Das ist ein Tradeoff, kein Bug.

Diese Abwesenheiten sind, was das Protokoll klein macht. Sie sind auch, was es schwerer macht, eine aufpolierte Benutzererfahrung darauf zu bauen, als es auf einer zentralisierten Plattform zu tun, was die ehrliche Kosten ist.

Warum das Design überhaupt funktioniert

Das Design stützt sich auf eine einfache Eigenschaft: Signaturen sind billig zu verifizieren, Fälschung ist ohne den privaten Schlüssel unmöglich, und Relays sind kostenlos zu ersetzen.

Diese drei Fakten verstärken sich. Billige Verifikation bedeutet, dass jeder Client jedes Event überprüfen kann. Unmögliche Fälschung bedeutet, dass Relays nicht vertraut werden müssen. Kostenlose Ersetzung bedeutet, dass kein einzelnes Relay Macht über jemanden hat.

Zusammen bekommen du ein Soziales Netzwerk, wo die Plattformschicht austauschbar ist und die Identitätsschicht vom Nutzer besessen ist. Was „dezentralisiert" tatsächlich in der Praxis bedeutet, im Gegensatz zu wie Marketing das Wort normalerweise verwendet.

Wenn du den gesamten Ablauf von der Benutzerseite sehen möchtest (ein Schlüsselpaar, eine NIP-05-Identität, eine Relay-Liste, eine Brieftasche, bereit zu posten), bricht Nostr.blogs Signup diese Schritte auf einer Seite zusammen. Die hier beschriebene Mechanik ist das, was tatsächlich unter diesem Ablauf läuft.