Nostr ist ein offenes Protokoll für signierte Ereignisse, die Clients über unabhängige Relays austauschen. Soziale Netzwerke sind eine Anwendung; das Protokoll besitzt weder eine eigene Blockchain noch einen gemeinsamen Konsens aller Relays.
Ein Ereignis enthält pubkey, created_at, kind, tags, content, id und sig. NIP-01 leitet id per SHA-256 aus einer genau festgelegten Serialisierung ab und verwendet BIP340 auf secp256k1. Clients prüfen Integrität und Schlüsselautorisierung. created_at stammt vom Autor; es ist weder ein unabhängiger Zeitstempel noch ein Wahrheitsbeleg. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
Ein Client veröffentlicht EVENT und abonniert mit REQ über WebSocket. OK meldet Annahme oder Ablehnung durch dieses Relay. EOSE beendet die Liste gespeicherter Ereignisse, nicht unbedingt das Abonnement neuer Ereignisse. Keine dieser Nachrichten bestätigt Empfang beim Adressaten, netzweite Replikation oder dauerhafte Speicherung. [Nostr — NIP-01: Basic protocol]
Innerhalb eines Filters muss ein Ereignis alle angegebenen Bedingungen erfüllen: Autor und Art bedeuten AND. Mehrere Filter eines REQ werden mit OR verknüpft; einer genügt. limit begrenzt die anfängliche Liste, nicht die Zahl zukünftiger Ereignisse. Fehlende Ergebnisse können auf begrenzte Relay-Historie hinweisen, nicht auf die Nichtexistenz eines Ereignisses. [Nostr — NIP-01: Basic protocol]
Ersetzbare Ereignisse werden nach pubkey und kind verglichen, adressierbare zusätzlich nach dem d-Tag. Eine neuere Version kann eine ältere ersetzen; bei gleichem Zeitstempel entscheidet die lexikografisch kleinere id. Flüchtige Ereignisse sollen nicht gespeichert werden. Das beschreibt Relay-Verhalten, kein unveränderliches globales Archiv; Implementierungen können abweichen. [Nostr — NIP-01: Basic protocol]
NIP-19 nutzt Bech32 für die Darstellung: npub bezeichnet den öffentlichen, nsec den privaten Schlüssel. Kodierung ist keine Verschlüsselung. Wer nsec weitergibt, übergibt daher den geheimen Schlüssel und nicht bloß einen Profillink. Ereignisse und Filter nach NIP-01 verwenden hexadezimale öffentliche Schlüssel, nicht deren npub-Darstellung. [Nostr — NIP-19: Encoded entities]
NIP-05 verknüpft einen E-Mail-ähnlichen Namen anhand der Domainantwort mit einem öffentlichen Schlüssel. Das belegt die Zuordnung, nicht die tatsächliche Identität oder Ehrlichkeit. Clients sollen dem ursprünglichen Schlüssel folgen: Ordnet die Domain den Namen neu zu, darf der neue Schlüssel das bisher verfolgte Profil nicht automatisch ersetzen. [Nostr — NIP-05: Internet identifiers]
NIP-09 definiert die Bitte eines Autors, seine Ereignisse zu entfernen. Vor dem Ausblenden soll ein Client prüfen, ob Original und Anfrage denselben öffentlichen Schlüssel haben. Relays und Clients können die Anfrage bearbeiten, doch das Protokoll kann nicht jede heruntergeladene oder anderweitig gespeicherte Kopie entfernen. Löschen in einer Oberfläche belegt keine globale Löschung. [Nostr — NIP-09: Deletion requests]
NIP-44 definiert einen verschlüsselten Payload, kein vollständiges privates Nachrichtensystem; NIP-17 ergänzt Hüllen und Zustellregeln. NIP-44 allein bietet bei späterem Schlüsselverlust keine forward secrecy. Netzwerkadressen, Zeitpunkte und Client-Verhalten bleiben auch bei verschlüsseltem Inhalt relevant. Welche NIPs unterstützt werden, ist je Anwendung zu unterscheiden. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Nostr Wallet Connect, Schnorr-Signatur, Privater Schlüssel, Bitcoin-Privatsphäre, Pseudonymität. Auf diesen Eintrag verweisen außerdem Nostr Wallet Connect.