Willkommen bei Nostr Compass, einem wöchentlichen Newsletter, der dem Nostr-Protokoll-Ökosystem gewidmet ist. Unsere Mission ist es, Entwickler, Relay-Betreiber und Builder über wichtige Entwicklungen im gesamten Netzwerk auf dem Laufenden zu halten. Wir dokumentieren die Protokollevolution mit technischer Genauigkeit, Neutralität und Tiefe und decken alles ab, von NIP-Vorschlägen über Client-Releases bis hin zu Best Practices für die Implementierung.

Nostr Compass ist inspiriert von Bitcoin Optech, dessen jahrelange engagierte Arbeit zur Förderung des technischen Bitcoin-Wissens den Standard für protokollfokussierte Newsletter gesetzt hat. Wir sind dankbar für ihr Beispiel und hoffen, dieselbe Strenge in das Nostr-Ökosystem zu bringen.

Diese Erstausgabe etabliert unser wöchentliches Format. Jeden Mittwoch bringen wir dir NIP-Updates, Release-Notes, Entwicklungs-Highlights und technische Anleitungen. Ob du einen Client baust, einen Relay betreibst oder zum Protokoll beiträgst – Nostr Compass möchte deine zuverlässige Quelle für das Geschehen im Ökosystem sein.

Was ist Nostr?

Da dies unsere erste Ausgabe ist, beginnen wir mit einer Einführung in die Funktionsweise von Nostr. Regelmäßige Leser können vorspringen.

Nostr (Notes and Other Stuff Transmitted by Relays) ist ein dezentrales Protokoll für soziale Netzwerke und Messaging. Anders als traditionelle Plattformen hat Nostr keinen zentralen Server, kein Unternehmen kontrolliert es und es gibt keinen Single Point of Failure. Benutzer besitzen ihre Identität durch kryptografische Schlüsselpaare, und Inhalte fließen durch unabhängige Relay-Server, die jeder betreiben kann.

Wie es funktioniert: Benutzer generieren ein Schlüsselpaar (einen privaten Schlüssel namens nsec und einen öffentlichen Schlüssel namens npub). Der private Schlüssel signiert Nachrichten, die “Events” genannt werden, und der öffentliche Schlüssel dient als deine Identität. Events werden an Relays gesendet, die sie speichern und an andere Benutzer weiterleiten. Da du deine Schlüssel kontrollierst, kannst du zwischen Clients oder Relays wechseln, ohne deine Identität oder Follower zu verlieren.

Warum es wichtig ist: Nostr bietet Zensurresistenz durch Relay-Vielfalt (wenn ein Relay dich sperrt, können andere immer noch deine Inhalte bereitstellen), Portabilität (deine Identität funktioniert in jeder Nostr-App) und Interoperabilität (alle Nostr-Clients sprechen dasselbe Protokoll). Es gibt keinen Algorithmus, der entscheidet, was du siehst, keine Werbung und keine Datensammlung.

Das Ökosystem heute: Nostr unterstützt Microblogging (wie Twitter/X), Langform-Inhalte (wie Medium), Direktnachrichten, Marktplätze, Livestreaming und mehr. Clients umfassen Damus (iOS), Amethyst (Android), Primal, Coracle und Dutzende weitere. Die Lightning-Network-Integration ermöglicht sofortige Zahlungen durch “Zaps”. Das Protokoll entwickelt sich weiter durch NIPs (Nostr Implementation Possibilities), community-getriebene Spezifikationen, die die Funktionalität erweitern.

News

NIP-BE Merged: Bluetooth Low Energy Support - Eine bedeutende neue Fähigkeit ist im Protokoll gelandet. NIP-BE spezifiziert, wie Nostr-Anwendungen über Bluetooth Low Energy kommunizieren und synchronisieren können. Dies ermöglicht offline-fähigen Apps, Daten zwischen nahen Geräten ohne Internetverbindung zu synchronisieren. Die Spezifikation passt WebSocket-Relay-Muster an die BLE-Einschränkungen an, verwendet DEFLATE-Kompression und fragmentierte Nachrichten, um mit den kleinen MTU-Größen von BLE (20-256 Bytes) umzugehen. Geräte verhandeln Rollen basierend auf UUID-Vergleich, wobei die höhere UUID zum GATT-Server wird.

MIP-05: Datenschutzerhaltende Push-Benachrichtigungen - Das Marmot Protocol veröffentlichte MIP-05 (Spec), eine Spezifikation für Push-Benachrichtigungen, die die Privatsphäre wahren. Traditionelle Push-Systeme erfordern, dass Server Geräte-Token und Benutzeridentitäten kennen; MIP-05 löst dies, indem Geräte-Token mit ECDH+HKDF und ChaCha20-Poly1305 verschlüsselt werden und ephemere Schlüssel verwendet werden, um Korrelation zu verhindern. Ein Drei-Event-Gossip-Protokoll (Kinds 447-449) synchronisiert verschlüsselte Token zwischen Gruppenmitgliedern, und Benachrichtigungen verwenden NIP-59 Gift Wrapping mit Köder-Token, um Gruppengrößen zu verbergen.

Blossom BUD-10: Neues URI-Schema - Das Blossom-Medienprotokoll bekommt ein benutzerdefiniertes URI-Schema via BUD-10 (Spec). Das neue blossom:<sha256>.ext-Format bettet Datei-Hash, Erweiterung, Größe, mehrere Server-Hinweise und Autor-Pubkeys für BUD-03 Server-Entdeckung ein. Dies macht Blob-Links widerstandsfähiger als statische HTTP-URLs, indem automatisches Fallback zwischen Servern ermöglicht wird.

Shopstr Marketplace Updates - Der Nostr-native Marktplatz implementierte Nostr Wallet Connect (NIP-47) für Zahlungen, fügte Listing-Ablauf hinzu mit NIP-40 und führte Rabattcodes für Verkäufer ein.

NIP Updates

Aktuelle Änderungen am NIPs Repository:

Neue NIPs:

  • NIP-BE - Bluetooth Low Energy Messaging und Gerätesynchronisation (#1979)
  • NIP-63 - Paywall/Premium Content Standard für die Handhabung von geschütztem Content im Protokoll (#2156)

Bedeutende Änderungen:

  • NIP-24 - Optionales languages-Array zu Kind 0 Benutzer-Metadaten hinzugefügt, das Benutzern erlaubt, mehrere bevorzugte Sprachen mit IETF BCP 47 Tags anzugeben (#2159)
  • NIP-69 - Order-Ablauf-Support für P2P-Trading mit expires_at und expiration Tags hinzugefügt (#2118)
  • NIP-59 - Gift Wrap Events können jetzt via NIP-09/NIP-62 Anfragen gelöscht werden (#2131)
  • NIP-51 - Hashtag- und URL-Tags aus generischen Lesezeichen entfernt; Hashtags verwenden jetzt Kind 30015 (#2133)
  • NIP-18 - Generische Reposts für ersetzbare Events mit a Tag Support verbessert (#2132)
  • NIP-17 - Formulierung verfeinert und Kind 7 Reaktions-Support zu DMs hinzugefügt (#2098)
  • NIP-11 - self Feld für Relay-Public-Key-Identifikation hinzugefügt (#1764)

NIP Deep Dive: NIP-01 und NIP-19

Für diese Erstausgabe behandeln wir zwei fundamentale NIPs, die jeder Nostr-Entwickler verstehen sollte. Siehe unsere Themenseiten für NIP-01 und NIP-19.

NIP-01: Basis-Protokoll

NIP-01 definiert das Kernprotokoll. Alles in Nostr baut auf dieser Spezifikation auf.

Events sind der einzige Objekttyp. Jedes Event enthält:

  • id: SHA256-Hash des serialisierten Events (der eindeutige Bezeichner des Events)
  • pubkey: Der öffentliche Schlüssel des Erstellers (32-Byte Hex, secp256k1)
  • created_at: Unix-Zeitstempel
  • kind: Integer, der den Event-Typ kategorisiert
  • tags: Array von Arrays für Metadaten
  • content: Die Nutzlast (Interpretation hängt vom Kind ab)
  • sig: Schnorr-Signatur, die beweist, dass die Pubkey dieses Event erstellt hat

Kinds bestimmen, wie Relays Events speichern:

  • Reguläre Events (1, 2, 4-44, 1000-9999): Normal gespeichert, alle Versionen behalten
  • Ersetzbare Events (0, 3, 10000-19999): Nur das neueste pro Pubkey wird behalten
  • Ephemere Events (20000-29999): Nicht gespeichert, nur an Abonnenten weitergeleitet
  • Adressierbare Events (30000-39999): Neuestes pro Pubkey + Kind + d Tag Kombination

Kind 0 sind Benutzer-Metadaten (Profil), Kind 1 ist eine Textnotiz (der Basis-Post), Kind 3 ist die Follow-Liste.

Kind 1: Textnotizen sind das Herz des sozialen Nostr. Ein Kind 1 Event ist ein Kurzform-Post, ähnlich einem Tweet. Das content-Feld enthält den Nachrichtentext (Plaintext, obwohl Clients oft Markdown rendern). Tags ermöglichen Antworten, Erwähnungen und Referenzen.

Adressierbare Events (30000-39999) funktionieren wie ersetzbare Events, verwenden aber ein d Tag als zusätzlichen Bezeichner. Das Relay behält nur die neueste Version jeder Pubkey + Kind + d-Tag Kombination. Dies ermöglicht editierbare Artikel, Produktlistings oder jeden Fall, in dem du mehrere ersetzbare Items pro Benutzer benötigst.

Tags sind Arrays, bei denen das erste Element der Tag-Name ist. Standard-Einzelbuchstaben-Tags (e, p, a, d, t) werden von Relays für effiziente Abfragen indexiert.

Client-Relay-Kommunikation verwendet WebSocket-Verbindungen mit JSON-Arrays als Nachrichten. Das erste Element identifiziert den Nachrichtentyp.

Von Client zu Relay:

  • ["EVENT", <event>] - Veröffentlicht ein Event am Relay
  • ["REQ", <sub-id>, <filter>, ...] - Abonniert Events, die dem/den Filter(n) entsprechen
  • ["CLOSE", <sub-id>] - Beendet ein Abonnement

Von Relay zu Client:

  • ["EVENT", <sub-id>, <event>] - Liefert ein Event, das deinem Abonnement entspricht
  • ["EOSE", <sub-id>] - “Ende gespeicherter Events” - das Relay hat alle historischen Treffer gesendet
  • ["OK", <event-id>, <true|false>, <message>] - Bestätigt, ob ein Event akzeptiert oder abgelehnt wurde
  • ["NOTICE", <message>] - Menschenlesbare Nachricht vom Relay

NIP-19: Bech32-kodierte Bezeichner

NIP-19 definiert die menschenfreundlichen Formate, die du überall in Nostr siehst: npub, nsec, note und mehr. Diese werden nicht im Protokoll selbst verwendet (das Hex verwendet), aber sie sind essentiell für Teilen und Anzeige.

Warum bech32? Rohe Hex-Schlüssel sind fehleranfällig beim Kopieren und visuell schwer zu unterscheiden. Bech32-Kodierung fügt ein menschenlesbares Präfix und Prüfsumme hinzu.

Basis-Formate kodieren rohe 32-Byte-Werte:

  • npub - Öffentlicher Schlüssel (deine Identität, sicher zu teilen)
  • nsec - Privater Schlüssel (geheim halten, zum Signieren verwendet)
  • note - Event-ID (referenziert ein bestimmtes Event)

Teilbare Bezeichner enthalten Metadaten mit TLV-Kodierung (Type-Length-Value):

  • nprofile - Profil mit Relay-Hinweisen
  • nevent - Event mit Relay-Hinweisen, Autor-Pubkey und Kind
  • naddr - Adressierbare Event-Referenz (Pubkey + Kind + d-Tag + Relays)

Wichtig: Verwende niemals bech32-Formate im Protokoll selbst. Events, Relay-Nachrichten und NIP-05-Antworten müssen Hex verwenden. Bech32 ist rein für menschliche Schnittstellen.

Releases

Amber v4.0.4 - Die Android-Signer-App behebt einen NullPointerException, verbessert die Performance auf dem Aktivitätsbildschirm und fügt Übersetzungen für einige Event-Kinds hinzu. Release

Coracle 0.6.28 - Bugfix-Release für den Web-Client. Release

Flotilla v1.6.2 - Der Discord-ähnliche Communities-Client behebt Modal-Scrolling und Stil-Probleme. Release

nak v0.17.2 - Das Kommandozeilen-Nostr-Tool fügte einen neuen nip Befehl für schnelle NIP-Referenzsuche hinzu. Release

White Noise v0.2.1 - Major Release für die MLS-basierte verschlüsselte Messaging-App mit Bild-Sharing via Blossom, Hintergrund-Sync, Push-Benachrichtigungen und Lokalisierung in 8 Sprachen. Release

Amethyst v1.04.2 - Feature-Release mit Follow-Listen/Packs, neuen Timeline-Filtern, Bildergalerie und H.265-Videokompression. Release

Mostro v0.15.5 - P2P-Trading-Bot-Update mit NIP-69 Order-Ablauf-Support. Release

Entwickler Best Practices

Validiere Auth Events Defensiv - go-nostr behob einen Panic in NIP-42 Validierung wenn das Relay-Tag fehlte. Prüfe immer erforderliche Tags vor dem Zugriff.

Rate Limiting nach Authentifizierungsstatus - khatru fügte NIP-42-basiertes Rate Limiting hinzu, das Relays erlaubt, unterschiedliche Limits für authentifizierte vs. anonyme Verbindungen anzuwenden.

Verwende Cursor-Paginierung für Listen - Blossom ersetzte datumsbasierte Paginierung durch cursorbasierte Paginierung. Datumsbasierte Paginierung bricht, wenn Items Zeitstempel teilen.

Schema-Validierung für Event-Typen - Das nostrability/schemata Projekt bietet JSON-Schemas zur Validierung NIP-konformer Events.

Das war’s für diese Woche. Baust du etwas? Hast du Neuigkeiten zu teilen? Möchtest du, dass wir dein Projekt behandeln? Kontaktiere uns via NIP-17 DM oder finde uns auf Nostr.