Wochenrückblick: Neun Pull Requests in nostr-protocol/nips gemergt

NIP-59: ein neuer ephemerer Gift-Wrap-Kind für Echtzeit-Nachrichten

PR #2245 fügt kind:21059 hinzu, ein ephemeres Gegenstück zum bestehenden Gift Wrap kind:1059. Es hat dieselbe Struktur wie kind:1059, folgt aber der in NIP-01 definierten Semantik ephemerer Events, was bedeutet, dass Relays es NICHT speichern dürfen. NIP-59 legt nun die vorgesehene Aufteilung fest: kind:1059 ist für persistente, asynchrone Nachrichten gedacht, etwa NIP-17-Konversationen, die eine Offline-Zustellung benötigen, während kind:21059 für Echtzeit-Kontexte gedacht ist, etwa Live-Chat oder Gaming, bei denen nur aktuell verbundene Empfänger zählen. Das ändert nichts daran, wie NIP-17-Direktnachrichten heute funktionieren; es fügt einen zweiten, nicht persistenten Gift-Wrap-Kind für Anwendungsfälle hinzu, die keinen Nachrichtenverlauf benötigen.

NIP-17: in Gift Wraps verpackte Direktnachrichten erhalten einen Abschnitt zu Löschen und Bearbeiten

PR #2260 fügt NIP-17 einen Abschnitt "Delete and Edit" hinzu. Er besagt, dass Clients zusätzlich zu dem bereits in NIP-59 festgelegten Löschverhalten, bei dem ein Gift Wrap vom im p-Tag genannten Empfänger gelöscht werden kann, Nutzern ERLAUBEN DÜRFEN, eine Nachricht zu löschen, indem sie ein kind:5-Löschevent in einen kind:1059-Gift-Wrap verpacken und als Teil der Konversation an den Empfänger senden. Clients SOLLTEN die gelöschte Nachricht dann aus der Konversation entfernen oder als gelöscht markieren. Derselbe Abschnitt erlaubt außerdem, das Bearbeiten von Nachrichten als Löschen mit anschließender Veröffentlichung eines neuen Events mit demselben Zeitstempel umzusetzen. Das ist eine neue Vorgabe, die auf das bestehende Gift-Wrap-Format aufsetzt, keine Änderung der Verschlüsselung selbst.

NIP-01: Relays müssen zusätzliche Pfadsegmente als denselben Endpunkt behandeln

PR #2307 fügt NIP-01 einen einzigen Satz hinzu: "Relays MUST only accept connections to a single endpoint when additional path segments do not influence its behavior." Die Beschreibung des PRs weist darauf hin, dass eine Relay-URL wie wss://relay.example/<random-string> bei den meisten laufenden Relays funktional identisch zu wss://relay.example/ war, eine Mehrdeutigkeit, die es Clients erschwerte, Relay-Identität und Deduplizierung nachzuvollziehen.

NIP-29: Audio- und Video-Live-Räume für Gruppen

PR #2238 fügt NIP-29 einen Abschnitt hinzu, der es einer Gruppe erlaubt, über ein livekit-Tag im Gruppenankündigungsevent einen LiveKit-basierten Sprach- und Videoraum anzukündigen, zusammen mit einem neuen supported_kinds-Tag, der auflistet, welche Event-Kinds die Gruppe akzeptiert (eine leere Liste bedeutet, dass keine Kinds unterstützt werden, nur der AV-Raum). Clients fordern ein Beitritts-Token über den /.well-known/nip29/livekit/<group-id>-Endpunkt eines Relays mithilfe eines NIP-98-Autorisierungsevents an, und Relays können über ein neues kind:39004-Teilnehmerevent veröffentlichen, wer sich aktuell im Raum befindet.

NIP-71: mehrere Audiospuren pro Video

PR #2255 erweitert die imeta-Tag-Konventionen in NIP-71, sodass ein einzelnes Video mehrere Audiospuren als separate imeta-Tags auflisten kann, jeweils mit einer l-Eigenschaft für die Sprache und einer ov-Eigenschaft, die die Spur in der Originalsprache markiert. Außerdem wird eine waveform-Eigenschaft hinzugefügt, eine kurze, durch Leerzeichen getrennte Liste von Amplitudenwerten, mit der Clients eine Wellenform für eine Audiospur darstellen können.

NIP-78: ein normaler, nicht adressierbarer Kind für anwendungsspezifische Daten

PR #2292 fügt NIP-78 kind:78 als normales Event hinzu, neben dem bestehenden adressierbaren kind:30078. Der Unterschied ist wichtig für Apps, die mehrere Events desselben Typs speichern und abfragen müssen: Ein adressierbarer Kind behält nur das jeweils neueste Event pro d-Tag, während ein normaler Kind alle behält. Der PR ergänzt außerdem die Tabelle der Event-Kinds in der README des NIPs-Repositorys um den neuen Kind.

NIP-85: umformulierte Beschreibung von kind:10040

PR #2304 formuliert einen einzelnen Absatz von NIP-85 um. Der Text, der kind:10040 als Liste "vertrauenswürdiger Dienstanbieter" beschrieb, wird stattdessen so beschrieben, dass er die vom Nutzer bevorzugte Quelle für jedes Ergebnis angibt, und stellt klar, dass ein Dienstanbieter mehrere Schlüssel und Relays verwenden kann, einschließlich eines je Nutzer ausgestellten Schlüssels, wenn Ergebnisse für diesen Nutzer personalisiert sind.

C7: Chat-Ansichten auf kind 9 beschränkt

PR #2310 fügt der C7-Konvention eine Zeile hinzu: Clients, die eine "Chat-Ansicht" als geordneten Event-Strom darstellen, DÜRFEN nur kind:9-Events abrufen, um zu vermeiden, dass zwischen unterschiedlichen Implementierungen Kontext verloren geht. Andere Inhaltstypen können weiterhin innerhalb einer kind:9-Nachricht durch Zitieren referenziert werden, gemäß NIP-18.

NIP-F4: ein neuer Entwurfs-NIP für Podcasts

PR #1093 ist mit großem Abstand die größte Änderung des Tages: Sie fügt eine vollständige Entwurfsspezifikation von über hundert neuen Zeilen hinzu. Sie führt NIP-F4 ein, einen Entwurfs- und optionalen NIP, der festlegt, wie Podcast-Shows und -Episoden als Nostr-Events an Relays veröffentlicht und von dort gelesen werden, so gestaltet, dass er in bestehende Podcast-Player-Workflows passt. Unter NIP-F4 hat jeder Podcast sein eigenes Nostr-Schlüsselpaar, wodurch sich die Podcast-Präsenz mit einem gewöhnlichen kind:0/kind:1-Profil verbinden lässt. Informationen auf Show-Ebene wie Titel, Coverbild, Beschreibung und Website werden als ersetzbares kind:10154-Event veröffentlicht, das auch Hosts, Co-Hosts und Editoren per Pubkey nennen kann. Einzelne Episoden sind separate kind:54-Events, die direkt mit dem eigenen Schlüssel des Podcasts veröffentlicht werden und jeweils Titel, Beschreibung sowie ein oder mehrere audio-Tags mit Verweis auf die Mediendatei der Episode tragen. Da sonst jeder fälschlich behaupten könnte, Urheber eines Podcasts zu sein, fügt NIP-F4 ein kind:10064-Event hinzu, über das die tatsächlichen Urheber eines Podcasts ihre eigene Liste der von ihnen verantworteten Podcasts veröffentlichen, sodass eine behauptete Urheberschaft gegen diesen Gegenbeleg geprüft werden kann, statt ungeprüft übernommen zu werden. Der PR aktualisiert außerdem NIP-51 um eine "Favorite podcasts"-Liste vom Typ kind:10054, mit der jeder Nutzer öffentlich festhalten kann, welchen Podcasts er folgt, unter Verwendung von p-Tags für Podcast-Pubkeys und url-Tags für RSS/XML-Feed-URLs, und ergänzt die neuen Event-Kinds in der Kind-Tabelle der NIPs-README.

Ein Bündel, kein koordiniertes Release

Abgesehen von den beiden Änderungen zu Direktnachrichten gibt es keinen gemeinsamen roten Faden, der diese neun Pull Requests verbindet. Sie betreffen nicht zusammenhängende Teile des Protokolls, von der Handhabung von Relay-Verbindungen über Gruppenvideo und Anwendungsspeicherung bis zur Podcast-Verbreitung, und kamen einfach innerhalb desselben etwa neunzigminütigen Zeitfensters am 28. Mai durch den Review. Es war ein Bündel, kein thematisches Release, auch wenn die mit Abstand größte Änderung des Tages, der neue Podcast-NIP, im selben Zeitfenster landete wie acht weitaus kleinere.