Das Nostr-Protokoll, einfach erklärt

Ein Protokoll ist ein Regelwerk dafür, wie Programme miteinander kommunizieren. Eine Plattform ist ein Unternehmen, das diese Programme in deinem Namen betreibt. Twitter ist eine Plattform. Email ist ein Protokoll. Nostr ist ein Protokoll.

Diese Unterscheidung ist wichtig, weil Protokolle und Plattformen unterschiedliche Fehlertypen, verschiedene Kostenstrukturen und unterschiedliche Zukünfte haben. Dieser Leitfaden erklärt, was Nostr spezifisch als Protokoll ausmacht, was das in der Praxis bedeutet, und warum das Design bewusst klein gehalten wird.

TL;DR. Nostr ist ein Pub/Sub-Messaging-Protokoll mit kryptographischen Signaturen. Es definiert ein kleines Event-Format und eine einfache Möglichkeit für Clients, diese Events über Relays zu senden und zu empfangen. Keine Firma besitzt es. Jeder kann einen Client schreiben, ein Relay betreiben oder Erweiterungen vorschlagen. Die Kernspezifikation passt auf ein paar Seiten.

Wenn du bereit bist, sicher dir dein @nostr.blog →

Was ein Protokoll wirklich ist

Email ist ein guter Vergleich. Wenn du eine E-Mail von Gmail zu Outlook sendest, braucht Gmail nicht Outlooks Erlaubnis. Beide Dienste sprechen SMTP (das Email-Protokoll), und SMTP definiert alles, was notwendig ist, damit ein Mailserver eine Nachricht an einen anderen übergibt. Die Server sind verschiedene Unternehmen. Das Protokoll ist eine neutrale Vereinbarung.

Nostr funktioniert genauso. Ein Nostr-Event (ein Post, ein Like, ein Follow) ist ein JSON-Objekt mit einer spezifischen Form, die im Protokoll definiert ist. Ein Relay ist jeder Server, der sich bereit erklärt, Events mit dieser Form zu akzeptieren, zu speichern und weiterzuleiten. Zwei beliebige Clients, die Nostr sprechen, können über jedes Relay, das Nostr spricht, interagieren, egal wer welches von den drei erschaffen hat.

Das Protokoll ist eine neutrale Vereinbarung. Die Implementierungen sind frei, alles zu sein.

Die Nostr-Spezifikation in den wenigsten Sätzen

Drei Regeln decken fast alles ab.

1. Ein Event ist ein JSON-Objekt mit id, pubkey, created_at, kind, tags, content, sig. Die id ist ein Hash der anderen Felder; sig ist eine Schnorr-Signatur über die id mit dem privaten Gegenstück des pubkey.
2. Ein Relay akzeptiert gültige Events über WebSocket und bedient Abos, die Events nach Autor, Kind, Tag oder Zeit filtern.
3. Ein Client signiert Events und veröffentlicht sie auf Relays; liest Events durch Abos auf Relays mit Filtern.

Das ist das Kernprotokoll. Jedes fortgeschrittene Feature (Artikel mit langer Form, Zaps, DMs, Communities, Listen) ist eine Erweiterung, die in diesen Rahmen passt, ohne ihn zu ändern.

Warum das Protokoll klein bleibt

Die meisten Protokolle wachsen durch Ansammlung. Jeder Anwendungsfall fügt zur Spezifikation hinzu; jedes Jahrzehnt ist die Spezifikation größer als im Jahrzehnt davor. HTTP ist jetzt hunderte Seiten. Email wuchs von einer Handvoll RFCs zu einem Dickicht. Nostr hat das bewusst vermieden.

Der Mechanismus sind NIPs (Nostr Implementation Possibilities). Neue Features werden nicht zur Kernspezifikation hinzugefügt; sie werden als optionale NIPs vorgeschlagen. Clients implementieren die NIPs, die ihnen wichtig sind. Andere Clients ignorieren sie. Eine populäre NIP wird Teil des praktischen Protokolls, weil genug Implementierungen sie sprechen; eine unpopuläre NIP verschwindet ohne Aufhebens.

Das bedeutet, der Kern bleibt für immer klein (die wichtigen Invarianten: signierte Events, offene Relays, portable Identität) und die Ränder bleiben für immer flexibel (neue Features entwickeln sich, ohne bestehende Clients zu brechen). Ein Nostr-Client von 2022 funktioniert noch 2026, weil der Kern sich nicht änderte; er macht nur weniger Dinge als neuere Clients.

Protokoll vs. Plattform, konkret

Fünf praktische Unterschiede, die du als Nutzer spüren kannst.

Identität. Auf einer Plattform gehört dein Konto dem Unternehmen. Auf einem Protokoll ist dein Konto eine kryptographische Identität, die dir gehört. Niemand kann sie dir wegnehmen.

Daten. Auf einer Plattform leben deine Posts in ihrer Datenbank. Auf einem Protokoll leben deine Posts auf mehreren unabhängigen Relays. Wenn eines verschwindet, haben die anderen sie noch.

Feature-Geschwindigkeit. Auf einer Plattform werden Features ausgerollt, wenn das Unternehmen es entscheidet. Auf einem Protokoll werden Features ausgerollt, wenn irgendein Implementierer sie schreibt. Das ist in mancher Hinsicht langsamer (kein zentraler Fahrplan) und in anderen schneller (viele Experimente parallel).

Monetarisierung. Auf einer Plattform erfasst das Unternehmen alle Monetarisierung. Auf einem Protokoll ist Monetarisierung das, auf das sich Nutzer und Implementierer einigen. Nostr hat Zaps (Peer-to-Peer-Tipps über Lightning), weil das zur Kultur passte; eine andere Protokoll-Community könnte zu verschiedenen Normen kommen.

Fehlerfall. Eine Plattform kann komplett verschwinden. Ein Protokoll kann nicht; solange ein Implementierer aktiv bleibt, lebt das Protokoll. Nostr ist so entworfen, dass selbst wenn fiatjaf (der ursprüngliche Autor) morgen verschwinden würde, das Netzwerk ohne Änderung weiterläuft.

Was das Protokoll bewusst nicht tut

Fünf Dinge, die absichtlich aus der Spezifikation gelassen wurden.

Moderation. Das Protokoll entscheidet nicht, welche Inhalte akzeptabel sind. Jedes Relay hat seine eigenen Regeln; jeder Client hat seine eigenen Filter; jeder Nutzer hat seine eigene Stumm-Liste. Moderation passiert an den Rändern, nicht im Kern.

Suche. Es gibt keine protokoll-definierte Suche. Einige Relays indexieren Text; andere nicht. Clients, die Suche wollen, verlassen sich entweder auf suchfähige Relays oder führen ihr eigenes Indexieren durch. Die Abwesenheit ist bewusst; sie hält das Protokoll neutral darin, was gefunden wird.

Ranking. Kein „Für dich"-Feed. Keine Engagement-Gewichtung. Clients zeigen Events standardmäßig nach Zeitstempel an; jede andere Ordnung ist eine Client-Entscheidung, keine Protokoll-Entscheidung.

Discovery. Keine Empfehlung-Engine. Neue Accounts zum Folgen zu finden ist eine Client-Funktion, keine Protokoll-Funktion. Einige Clients investieren stark darin (Primal); andere überlassen es Nutzern (Damus).

Wiederherstellung. Kein Account-Reset. Verliere den privaten Schlüssel, verliere das Konto. Das Protokoll könnte Schlüsselrotation einschließen, tut es aber nicht, weil die Tradeoffs real sind und die Community noch nicht auf einen spezifischen Mechanismus geeinigt hat. Das ist ein laufender Bereich (NIP-26, NIP-41 Entwürfe).

Jede Auslassung ist eine Entscheidung. Protokolle bleiben klein, indem sie sich weigern, jedes Problem auf der Protokoll-Ebene zu lösen.

Wer entscheidet, was Nostr wird

Niemand und jeder.

Es gibt keine Nostr-Stiftung. Keine Arbeitsgruppe von Konzernen. Kein Steuerungsausschuss. Die konzentrierteste Autorität irgendwo im Ökosystem ist fiatjafs GitHub-Repo, wo NIPs vorgeschlagen werden, und selbst das ist nur ein Koordinationspunkt, kein Gatekeeper.

Vorgeschlagene NIPs werden von Client-Entwicklern gelesen. Populäre werden implementiert. Eine NIP, die drei wichtige Clients implementieren, ist effektiv Teil des Protokolls; eine NIP, die ein Entwickler schrieb, aber niemandem anderen interessiert, ist nur ein Dokument auf GitHub.

Dieser Prozess ist chaotisch. Es gibt Koordinationsprobleme, doppelte Vorschläge und gelegentliche Politik. Er ist auch auf spezifische Weise widerstandsfähig: keine einzelne Partei kann ihn ruinieren, indem sie eine schlechte Entscheidung trifft, weil schlechte Entscheidungen einfach nicht angenommen werden. Das Protokoll entwickelt sich in grober Richtung durch das Gewicht von Entwickler-Entscheidungen, nicht durch Dekret.

Wenn das Protokoll-Modell gewinnt

Protokolle schlagen Plattformen unter spezifischen Bedingungen:

• Wenn Eigentum wichtiger ist als Polieren. Protokolle sind normalerweise weniger poliert als Plattformen. Sie gewinnen, wenn dir wichtig ist, was das Polieren nicht geben kann (permanente Identität, Zensurresistenz, offene Interoperabilität).
• Wenn der Netzwerkeffekt die Funktion ist. Der Wert eines Protokolls wächst mit Adoption durch Implementierer, nicht nur Nutzer. Mehr Clients und Relays machen das Netzwerk auf Wege stärker, die eine Plattform nicht kopieren kann.
• Wenn der Langzeit-Horizont wichtig ist. Plattformen werden gekauft, verkauft, abgeschaltet oder pivotiert. Protokolle überleben jeden einzelnen Implementierer. Email ist älter als die meisten Unternehmen; Nostr setzt auf dieselbe Dynamik.

Wenn dein Anwendungsfall mit keinem dieser Punkte übereinstimmt, ist eine Plattform normalerweise schneller und einfacher. Das ist ehrlich. Nostr ist nicht in jedem möglichen Fall universell besser als Twitter. Es ist besser in den spezifischen Wegen, in denen ein Protokoll eine Plattform schlägt.

Die eigentliche Spezifikation lesen

Wenn dieser Leitfaden dich dazu brachte, das Protokoll direkt zu lesen, hat das NIPs-Repository die vollständige Liste. NIP-01 ist der Kern; die nummerierten NIPs danach sind Erweiterungen. Du brauchst nichts davon zu verstehen, um Nostr zu nutzen, aber NIP-01 zu lesen dauert etwa zehn Minuten und klärt viel.