Nostr

Anna findet auf Nostr Autoren, denen sie folgen möchte. Später gefällt ihr die App nicht mehr. Verwendet sie denselben privaten Schlüssel oder ein angeschlossenes Signiergerät sicher in einer anderen App, kann sie ihre Identität behalten. Andere erkennen sie an ihrem öffentlichen Schlüssel und prüfen damit Signaturen; mit ihrem privaten Schlüssel lässt sich in ihrem Namen signieren. Deshalb sind npub und nsec grundverschieden. Nach NIP-19 stellen sie öffentliche beziehungsweise private Schlüssel in Bech32-Kodierung dar. NIPs sind nummerierte Dokumente, die Regeln und Erweiterungen von Nostr beschreiben. Kodierung ist keine Verschlüsselung: Ein nsec ist kein unbedenklicher Profillink zum Weitergeben. Auch mit derselben Identität findet eine neue App nicht zwangsläufig alle alten Beiträge oder übernimmt sämtliche Einstellungen. [2] [7]

Die App, auch Client genannt, signiert den Beitrag und sendet ihn an ausgewählte Relays. Ein Relay ist ein Server, der Nachrichten annimmt und nach eigenen Regeln speichert oder weiterleitet. Petrs App verbindet sich mit Relays und fordert die Beiträge an, die ihn interessieren. Es gibt weder einen zentralen Server noch die Pflicht, alles auf jedem Server zu kopieren. Technisch läuft die Kommunikation über WebSocket, eine für weitere Nachrichten offen gehaltene Verbindung: EVENT transportiert eine Nachricht, REQ eröffnet ein Abonnement, und OK meldet Annahme oder Ablehnung. Selbst ein positives OK bestätigt weder die Zustellung an Petr noch dauerhafte Speicherung. EOSE markiert das Ende der gespeicherten Ergebnisse dieser Anfrage; danach kann das Abonnement neue Nachrichten liefern. [1] [7]

Erhält Petr eine Nachricht, prüft seine App, ob die Signatur zum angegebenen öffentlichen Schlüssel passt und die signierten Daten unverändert sind. Das belegt weder den Wahrheitsgehalt noch die bürgerliche Identität des Autors. Auch den Erstellungszeitpunkt setzt der Autor selbst; er ist kein unabhängiger Zeitstempel. Für technisch Interessierte: Ein Datensatz namens Event enthält pubkey, created_at, kind, tags und content, also Schlüssel, Zeit, Art, Markierungen und Inhalt. SHA-256 berechnet aus deren genau vorgeschriebener Darstellung einen kurzen Prüfwert namens id. Damit lassen sich Änderungen an den signierten Daten erkennen. Im Feld sig steht eine Schnorr Signature nach BIP340 auf der Kurve secp256k1. Sie besagt: „Der Inhaber des zugehörigen Schlüssels hat diese Daten signiert“, nicht: „Diese Behauptung ist vertrauenswürdig.“ [1]

Ein langer öffentlicher Schlüssel lässt sich schwer merken. NIP-05 erlaubt die Zuordnung zu einer Kennung, die wie eine E-Mail-Adresse aussieht. Die App fragt die betreffende Domain nach dem Schlüssel zu diesem Namen und vergleicht ihn mit dem Profilschlüssel. Bestätigt wird die konkrete Zuordnung zur Domain, nicht automatisch der echte Name, der Ruf oder die Zuverlässigkeit einer Person. Der Domainbetreiber kann die Zuordnung später ändern. Folgt Anna bereits jemandem, soll der ursprüngliche öffentliche Schlüssel maßgeblich bleiben; ein neuer Schlüssel unter demselben Namen darf nicht stillschweigend die gefolgte Person austauschen. Pseudonymität bedeutet, dauerhaft unter einer Kennung statt unter dem bürgerlichen Namen aufzutreten, nicht garantierte Anonymität. [3]

Petr muss nicht jede Nachricht herunterladen. Er sendet einen Filter, etwa für bestimmte Autoren und eine bestimmte Beitragsart. Verschiedene Bedingungen innerhalb eines Filters werden mit AND verknüpft: Alle müssen zugleich zutreffen. Mehrere erlaubte Werte derselben Bedingung sind OR-Alternativen; ebenso werden mehrere Filter in einer REQ-Anfrage verbunden. Ein passender Filter genügt. limit begrenzt die anfängliche Menge gespeicherter Ergebnisse, nicht automatisch künftige Nachrichten des Abonnements. NIP-01 verwendet in Events und Filtern hexadezimale Schlüssel, nicht das für Nutzer gedachte npub-Format. Eine erfolglose Suche kann am Filter, am gewählten Server oder dessen Bestand liegen. Sie beweist nicht, dass der Beitrag nirgends existiert. [1]

Anna ändert ihre Profilbeschreibung und möchte, dass andere die neue sehen. Nostr unterscheidet deshalb, welche Daten Relays aufbewahren sollen. Bei ersetzbaren Events wählen sie den neuesten Datensatz zur gleichen Kombination aus pubkey und kind. Bei adressierbaren Events kommt der Wert des d-Tags hinzu, der etwa verschiedene Dokumente desselben Autors unterscheidet. Haben ersetzbare Datensätze denselben Zeitstempel, soll die lexikografisch kleinere id erhalten bleiben, also die in der Sortierung ihrer Schreibweise zuerst kommende. Bei flüchtigen, sogenannten ephemeral Events wird eine Speicherung gar nicht vorausgesetzt. Das sind Konventionen; Relays können sich unterschiedlich verhalten. Nostr ist somit kein Register, in dem sich das gesamte Netzwerk auf eine unveränderliche Geschichte einigt. [1]

Anna merkt, dass sie etwas veröffentlicht hat, das privat bleiben sollte. Mit NIP-09 kann sie eine signierte Löschanfrage senden. Bevor ein Client darauf reagiert, muss er prüfen, ob Anfrage und ursprünglicher Beitrag zum selben öffentlichen Schlüssel gehören. Ein Fremder darf Annas Beitrag nicht allein durch einen Verweis darauf löschen. Mitwirkende Server und Apps können den Inhalt entfernen oder nicht mehr anzeigen. Die Anfrage beseitigt jedoch nicht jede Kopie, jeden Screenshot oder jedes unabhängige Archiv. Auch das Ausblenden in einer App sagt nichts darüber aus, ob ein anderer Server den Beitrag weiter anbietet. Entscheidend ist daher, was Sie veröffentlichen, nicht nur das Vorhandensein einer Löschen-Schaltfläche. [4]

Öffentliche Beiträge kann jeder lesen, der sie erhält; eine Signatur verbirgt ihren Inhalt nicht. Private Nachrichten benötigen zusätzliche Regeln. NIP-44 beschreibt die Verschlüsselung des Inhalts, NIP-17 das Verpacken und Zustellen mit weiteren Schutzschichten. Das schafft nicht automatisch Anonymität: Netzwerkadressen, Zeitpunkte und das Verhalten der App können weiterhin Informationen verraten. Dieser Verschlüsselung fehlt zudem forward secrecy, der Schutz früherer Gespräche, wenn der langfristige Schlüssel später in fremde Hände gerät. Wer den nötigen privaten Schlüssel und zuvor aufgezeichnete verschlüsselte Nachrichten erhält, kann auch ältere Kommunikation lesen. Prüfen Sie deshalb, welche Erweiterungen die konkrete App unterstützt; „Nostr“ allein beschreibt ihre Privatsphäre nicht. [5] [6]