NIP-84 ergänzt Highlights um i-Tags und lockert r

NIP-84 definiert kind:9802, das Highlight-Event, dessen .content die Passage enthält, die jemand als aufbewahrenswert markiert hat. Die Frage, die die Spezifikation immer beantworten musste, ist, woher diese Passage stammt. Pull Request #2454 schreibt diese Antwort neu. Er wurde am 1. September 2026 eröffnet und am selben Tag gemergt, eine Datei und sechs geänderte Zeilen.

Der Referenzabschnitt wird zur Liste

Der alte Text bestand aus zwei Sätzen und deckte zwei Fälle ab:

a or e tags should be used for nostr events and r tags for URLs.

An seine Stelle tritt eine Liste mit drei Punkten:

a and/or e tags for nostr events

i tags for structured sources per NIP 73

r tags for anything else (may contain a URL or text)

Dort sind zwei Dinge gleichzeitig passiert. Ein Fall kam hinzu, und ein bestehender Fall wurde neu definiert.

Was das i-Tag bringt

NIP-73 ist die Spezifikation für externe Inhalts-IDs. Sie gibt i-Tags ein festes Vokabular für Kennungen, die außerhalb von nostr existieren: isbn: für Bücher, doi: für Fachartikel, isan: für Filme, geo: für Geohashes, iso3166: für Länder und deren Untergliederungen, podcast:guid: samt den Varianten für Episode und Herausgeber, dazu Formen für Blockchain-Transaktionen und -Adressen sowie eine normalisierte URL-Form unter dem Typ web.

Ein Highlight aus einem Buch konnte das mit der alten Formulierung nicht ausdrücken. Der einzige Platz außerhalb von nostr war r, definiert als URL, und ein gedrucktes Buch hat keine. Der Verweis von i auf NIP-73 gibt einem solchen Highlight eine Kennung, auf die andere Clients abfragen können, und genau darum geht es beim ID-Register: alle Events mit ["i", "isbn:9780123456789"] sind als Gruppe auffindbar.

Ein Detail lässt die neue Zeile aus. NIP-73 stellt jedem i-Tag ein k-Tag zur Seite, das die Art der Kennung benennt, und erst das macht die Abfrage nach Art möglich. NIP-84 spricht von i-Tags nach NIP-73, ohne die k-Anforderung zu wiederholen, dieses Paar muss man also in NIP-73 selbst nachlesen.

Was das r-Tag verliert

r ist nicht mehr das URL-Tag. Es ist jetzt der Auffangfall, und die Spezifikation sagt ausdrücklich, dass es eine URL oder Text enthalten darf. Der Pull Request beschreibt die Situation, die dazu geführt hat: Highlights, die mit einer Quelle veröffentlicht wurden, die keine URL ist, und die Clients, die eine gültige URL voraussetzten, nicht interpretieren konnten.

In der Praxis war es nie sicher, das Feld als URL zu lesen, und die Änderung gibt Implementierungen, die es weiterhin so parsen, nicht länger recht. Sie gibt auch etwas auf. Ein Client kann einen r-Wert an einem Highlight nicht mehr ungeprüft als Link behandeln.

Dieselbe Änderung entfernte eine Empfehlung, die an der alten Definition hing:

When tagging a URL, clients generating these events SHOULD do a best effort of cleaning the URL from trackers or obvious non-useful information from the query string.

Das war der einzige Hinweis zu Trackern in NIP-84, und aus der Datei ist er verschwunden. Nichts im Diff verschiebt ihn an eine andere Stelle. Clients, die Tracking-Parameter aus Highlight-Quellen entfernen, tun das nun nach eigenem Ermessen und nicht aufgrund eines SHOULD der Spezifikation, und die normalisierte URL-Form aus NIP-73, die der Weg über i jetzt abdeckt, verwirft das Fragment, sagt aber nichts über den Query-String.

Zurück bleibt außerdem ein Rest. Der Schlussabsatz von NIP-84, den dieser Pull Request nicht angefasst hat, hält weiterhin fest, dass URLs in r-Tags aus dem Kommentar ein mention-Attribut haben MUST, um sie von der URL der hervorgehobenen Quelle zu unterscheiden, und dass die Quell-URL das Attribut source haben MUST. Dieser Text setzt voraus, dass r eine URL enthält, was der Referenzabschnitt darüber nicht mehr verlangt.

Aus einem MUST wird ein SHOULD

Die zweite normative Änderung steht im Abschnitt zu zitierten Highlights. Ein comment-Tag macht aus einem Highlight ein zitiertes Highlight, und die Darstellungsregel war unbedingt:

This MUST be rendered like a quote repost with the highlight as the quoted note.

Jetzt heißt es dort SHOULD. Die im umgebenden Text genannte Begründung bleibt gleich: Die Konstruktion existiert, damit eine einzelne Highlight-Aktion nicht zwei Notizen erzeugt, ein Highlight und ein kind 1, die in Microblogging-Clients direkt hintereinander auftauchen. Ein Client, der zitierte Highlights anders darstellt, verstößt damit nicht mehr gegen die Spezifikation.

Die verbleibende Änderung ist eine Tippfehlerkorrektur, creation and multiple notes zu creation of multiple notes, im selben Absatz.

Sonst hat sich an NIP-84 nichts geändert. Es bleibt draft und optional, das Event bleibt kind:9802, und die Tags p, context und comment behalten ihre bisherige Bedeutung.