Nostr NIPs erklärt: die Spezifikationsdokumente des Protokolls

Nostrs Weiterentwicklung erfolgt durch NIPs, kurze Spezifikationsdokumente, die jeder vorschlagen kann. Wenn du verstehen möchtest, wie neue Funktionen wie Zaps oder verschlüsselte DMs in das Protokoll gelangen, sind NIPs die Antwort.

Dieser Leitfaden behandelt, was NIPs sind, wie sie als Governance-Mechanismus funktionieren, und welche du lesen solltest, wenn du technischer wirst.

NIPs sind kurze Markdown-Dokumente auf GitHub, die vorschlagen, wie man Nostr-Funktionen implementiert. Client-Entwickler entscheiden, welche sie unterstützen. Ein NIP wird „real", wenn genug Implementierer es übernehmen. Der Kernsatz von weit verbreiteten NIPs umfasst etwa 30; die vollständige Liste ist näher an 100.

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

Was ein NIP wirklich ist

Ein NIP ist eine Markdown-Datei im Repository github.com/nostr-protocol/nips. Jede Datei beschreibt eine spezifische Funktion, ein Format oder eine Konvention: wie man Events signiert, wie ein Profil-Metadaten-Event aussieht, wie man eine direkte Nachricht sendet, welches Format Lightning-Zap-Anfragen verwenden.

Die Größe variiert. Die kürzesten NIPs sind unter einer Seite; die längsten sind mehrere tausend Wörter. Die meisten liegen zwischen 500 und 2000 Wörtern. Sie sind geschrieben, um aus der Spezifikation allein implementierbar zu sein, daher enthalten sie Nachrichtenformate, erforderliche Felder und Beispiel-Events.

Die Benennungskonvention ist NIP-XX, wobei XX eine Nummer ist. Nummern werden zugewiesen, wenn der NIP zusammengeführt wird; sie spiegeln weder Priorität noch Wichtigkeit wider. NIP-05 handelt von verifizierten Identifikatoren; NIP-04 ist der ältere DM-Standard; NIP-01 ist das Kernprotokoll. Die Nummern verfolgen die Abfolge der Vorschläge, nicht die Bedeutung der Funktion.

Warum „Implementation Possibilities"

Der Name ist eine bewusste Wahl. Vergleiche mit anderen Spezifikationstraditionen.

• RFCs (Requests for Comments) in Internet-Protokollen werden oft zwingend für die Interoperabilität.
• EIPs (Ethereum Improvement Proposals) werden oft zwingend durch Netzwerk-Upgrades.
• NIPs sind dauerhaft optional. Ein Client, der 40 NIPs implementiert, und ein Client, der 10 implementiert, sind beide valide Nostr-Clients; sie machen einfach unterschiedliche Teilmengen von Dingen.

Das bedeutet, dass NIPs nie existierende Implementierungen „brechen". Ein neuer NIP für eine Funktion zwingt ältere Clients nicht zum Ändern. Das Protokoll wächst an den Rändern, während der Kern stabil bleibt.

Der NIP-Lebenszyklus

Wie ein neuer NIP entsteht:

1. Jemand bemerkt eine Lücke oder einen Bedarf. „Wir haben keine standardisierte Möglichkeit, X zu tun." Könnte ein Client-Entwickler, ein Relay-Operator oder ein Benutzer sein, der über ein spezifisches Problem frustriert ist.
2. Sie schreiben einen Entwurf. Das Format folgt den bestehenden NIPs: Titel, Zweck, Spezifikation, Beispiele.
3. Sie reichen einen Pull Request beim NIPs-Repository ein.
4. Community-Überprüfung. Entwickler, Relay-Operatoren und interessierte Benutzer kommentieren. Der Entwurf wird basierend auf Feedback überarbeitet.
5. Zusammenführung oder Verwerfen. Zusammengeführte NIPs erhalten eine Nummer und werden Teil des Repositorys. Verworfene Entwürfe bleiben in der Pull-Request-Historie.
6. Implementierung erfolgt (oder nicht). Einige NIPs werden innerhalb von Wochen implementiert. Einige warten Jahre. Einige werden nie weit verbreitet implementiert.

Der Prozess ist leichtgewichtig. Keine Abstimmungen in Komitees, keine formale Genehmigung. Wenn der Pull Request breite positive Rückmeldungen erhält und einen offensichtlichen Bedarf adressiert, wird er zusammengeführt.

NIPs, die für Benutzer wichtig sind

Die meisten NIPs sind für Benutzer unsichtbar. Eine Handvoll beeinflusst dein tägliches Erlebnis:

• NIP-01: Kernprotokoll. Wie Events strukturiert und signiert werden. Du siehst ihn nie, aber alles andere hängt davon ab.
• NIP-05: Verifizierte Identifikatoren. Gibt dir lesbare Namen wie du@domain.com. Unser NIP-05-Leitfaden behandelt es.
• NIP-07: Browser-Extension-Signierung. Lässt Web-Clients signieren, ohne deinen privaten Schlüssel zu sehen.
• NIP-19: Bech32-Codierung. Warum dein öffentlicher Schlüssel wie npub1... aussieht statt reines Hex.
• NIP-23: Längerfristige Artikel. Ermöglicht Blog-ähnliche Posts auf Nostr.
• NIP-44: Verschlüsselte DMs. Der moderne Direct-Messaging-Standard (besser als der ältere NIP-04).
• NIP-57: Zaps. Lightning-Trinkgelder mit öffentlichen Quittungen.
• NIP-98: HTTP-Auth. Lässt Nostr-Identitäten sich bei regulären Websites authentifizieren.

Als Benutzer profitierst du von all diesen, ohne mit ihnen zu interagieren. Clients handhaben die Protokolldetails.

NIPs, die für Entwickler wichtig sind

Wenn du einen Nostr-Client schreibst oder wartest, wachsen die lesenswerten NIPs zu dutzenden:

• NIP-01 bis NIP-10 (Kernmechaniken).
• NIP-11 (Relay-Informationsdokumente).
• NIP-13 (Proof of Work, zur Spam-Resistenz).
• NIP-17 (geschenkverpackte DMs zum Verbergen von Metadaten).
• NIP-22 (Event-Ablauf).
• NIP-27 (Textnotiz-Referenzen).
• NIP-30 (benutzerdefinierte Emoji).
• NIP-31 (Event-Arten).
• NIP-33 (parametrisierte ersetzbare Events).
• NIP-42 (Authentifizierung von Verbindungen zu Relays).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (Suchfunktion).
• NIP-65 (Relay-Listen-Metadaten).
• NIP-78 (beliebige benutzerdefinierte App-Daten).

Dies sind die, die die meisten Mainstream-Clients implementieren. Ein Client, der diesen Satz plus die oben genannten Benutzer-NIPs unterstützt, deckt 95% der typischen Verwendung ab.

Ein NIP lesen

Wenn du einen direkt lesen möchtest, ist das Repository unter github.com/nostr-protocol/nips. Die Struktur der meisten NIPs:

• Titel und Beschreibung. Was der NIP vorschlägt.
• Motivation. Warum die Funktion benötigt wird.
• Spezifikation. Exaktes Nachrichtenformat, erforderliche Felder, Validierungsregeln.
• Beispiel-Events. Konkretes JSON, das zeigt, wie ein konformes Event aussieht.
• Client-/Relay-Verhalten. Wie Implementierungen die Events behandeln sollten.

NIPs sind geschrieben, um von Entwicklern, die sie implementieren, lesbar zu sein. Der Spezifikations-Abschnitt ist der wichtige; dort lebt das eigentliche Protokoll.

NIPs mit teilweiser Adoption

Einige NIPs existieren, werden aber inkonsistent über Clients implementiert. Dies schafft Randfälle, bei denen dein Erlebnis je nach Client variiert.

NIP-44 (verschlüsselte DMs). Übernommen von Damus, Primal, Amethyst und den meisten großen Clients in 2024-2025. Einige ältere Clients unterstützen nur NIP-04. Wenn du jemandem eine Nachricht sendest, dessen Client nur NIP-04 unterstützt, schlagen deine NIP-44-Nachrichten an ihn stillschweigend fehl. Die praktische Antwort: Verwende einen modernen Client und hoffe, dass dein Gesprächspartner das auch tut.

NIP-17 (geschenkverpackte DMs). Metadaten-versteckende DMs. Die Adoption im Jahr 2026 wächst, ist aber nicht universell. Die Funktion ist großartig, wenn beide Parteien' Clients sie unterstützen; ansonsten fällt sie stillschweigend auf weniger private DMs zurück.

NIP-46 (Remote-Signatur). Lässt ein Hardware-Signer oder Bunker-App Events im Namen eines Clients signieren. Unterstützt in Amethyst, teilweise anderswo.

NIP-65 (Relay-Liste des Benutzers). Lässt Benutzer ihre bevorzugten Relays veröffentlichen, damit Clients automatisch an die richtigen Orte routen können. Die Adoption verbessert sich; ältere Clients ignorieren es.

NIP-50 (Suche). Ermöglicht Clients, Relays nach Textübereinstimmungen abzufragen. Einige Relays unterstützen es; viele nicht. Die Suchqualität ist daher inkonsistent.

Zu überprüfen, welche NIPs ein bestimmter Client unterstützt, ist eine nützliche Diagnose, wenn etwas nicht wie erwartet funktioniert. Die meisten Clients veröffentlichen ihre NIP-Unterstützungsmatrix in ihrer Dokumentation.

Wie der NIP-Prozess das Protokoll kohärent hält

Keine zentrale Autorität, daher kommt Kohärenz von sozialen Dynamiken. Einige Beobachtungen:

Schlechte NIPs verbreiten sich nicht. Ein Vorschlag, der einen bestehenden NIP dupliziert oder das falsche Problem löst, erhält minimale Adoption und stirbt stillschweigend aus. Die Community ist nicht formal, aber sie hat eine Meinung.

Gute NIPs werden unabhängig implementiert. Mehrere Client-Entwickler lesen Vorschläge und entscheiden unabhängig. Gute Ideen sammeln Adopter; schlechte Ideen nicht.

Konkurrierende NIPs entstehen manchmal. Zwei unterschiedliche Vorschläge für die gleiche Funktion können eine Weile nebeneinander existieren. Üblicherweise gewinnt einer in der Praxis, weil mehr Clients ihn implementieren; manchmal fusionieren sie.

Fork-kompatible Entwicklung. Weil NIPs optional sind, kann ein Client NIP-X-v1 implementieren und später zu NIP-X-v2 upgraden, ohne jemanden zu brechen, der nur v1 unterstützt. Das Protokoll spaltet sich nicht auf.

Das ist unordentlich, aber funktionierend. Das Protokoll hat sich in fünf Jahren erheblich entwickelt, ohne dass ein zentrales Governance-Organ existiert, weil der soziale Mechanismus von „Implementierer lesen, Implementierer entscheiden, Implementierer programmieren" genug Ausrichtung hat, um Kohärenz zu schaffen.

Deinen eigenen NIP vorschlagen

Wenn du eine Idee für eine neue Nostr-Funktion hast:

1. Überprüfe zuerst das NIPs-Repository. Jemand könnte es bereits vorgeschlagen haben.
2. Falls nicht, öffne ein GitHub-Issue, das das Problem beschreibt, das du löst.
3. Basierend auf Feedback entwirfst du einen vollständigen NIP, der dem bestehenden Format folgt.
4. Reiche einen Pull Request ein.
5. Beteilige dich an der Diskussion. Sei bereit, zu überarbeiten.
6. Wenn es zusammengeführt wird, prima. Falls nicht, könnte das Problem eine bessere Lösung haben; überlege, warum.

Nicht jede gute Idee wird zu einem NIP. Nicht jeder NIP wird zu einer Funktion. Das Ökosystem hat mehr Vorschläge, als ein einzelner Entwickler verfolgen könnte, und der Filter ist „implementiert genug von der Community es." Dieser Filter ist der Kern davon, wie Nostr ohne Top-Down-Ansatz kohärent bleibt.