Referenz der unterstützten NIPs

Jeder Relay-seitige NIP, den nostrfy implementiert — Kinds, Hinweise und Einschränkungen — und wie die supported_nips-Liste von NIP-11 dynamisch berechnet wird.

Implementierte NIPs

NIPBeschreibung
1Basisprotokoll (Events, Subscriptions)
9Löschen von Events
11Relay-Informationsdokument
13Proof of Work
17Private DMs (Kind 14 verpackt in Kind 15; Gift Wraps der Kinds 1059 und ephemeral 21059 werden bei aktivierter NIP-42-Auth nur an den Empfänger ausgeliefert)
22Kommentare (Kind 1111, Threads über den #e-Index)
26Delegiertes Signieren von Events
28Öffentlicher Chat (clientseitig: als normale Events gespeichert und ausgeliefert, nicht beworben)
29Relay-basierte Gruppen
32Labeling (Kind 1985, #l/#L indiziert)
33Parametrisierte ersetzbare Events
34git-Funktionen (Kinds 1617-1619, 1621, 1622, 1630-1633, 30617/30618 — Opt-in per relay.enabled_git, standardmäßig deaktiviert)
40Ablaufzeitstempel
42Client-Authentifizierung
43Relay-Zugriffsmetadaten (Rollen) — Kinds 33534/13534/8000/8001 plus ephemeral 28934/28935/28936; die Relay-signierten Metadaten sind AUTH-geschützt. Einladungscodes werden mit NIP-86 createclaim/deleteclaim ausgestellt; ein kind:28934 mit einem gelisteten Code lässt seinen Autor zu
45Zählen von Ergebnissen (COUNT)
46Nostr Connect
47Nostr Wallet Connect
50Suchfunktion (Volltext, relevanzsortiert)
57Lightning-Zaps (Kinds 9734/9735)
59Gift Wrap (Auslieferung nur an den Empfänger)
62Aufforderung zum Löschen
65Relay-Listen-Metadaten
66Relay-Erkennung & Liveness (Kinds 30166/10166 werden gespeichert und ausgeliefert; veröffentlicht selbst Kind 30166)
67EOSE-Vollständigkeitshinweis
70Geschützte Events
77Negentropy-Synchronisierung (eine fehlgeschlagene Ersetzung schließt die ID mit NEG-ERR gemäß NIP-77)
78Anwendungsspezifische Daten (Kind 30078, AUTH-geschützt)
84Highlights
85Vertrauenswürdige Zusicherungen (Kinds 30382/30383/30384/30385/10040, adressierbar)
86Relay-Verwaltungs-API
87Cashu- und Fedimint-Ankündigungen (Kinds 38000/38172/38173)
88Umfragen
94Dateimetadaten (Kind 1063)
98HTTP-Auth
A3Zahlungsziele (Kind 10133, ersetzbar), ein Entwurf; wird ausgeliefert, aber nicht in supported_nips beworben

Blossom (BUD-01/02) ist kein NIP und wird im NIP-11-Dokument nicht beworben — es wird als separater Dateiserver auf dem [blossom]-Hostnamen betrieben. Details siehe Blossom-Dateiserver-Seite.

Dynamische NIP-Ankündigung

Die supported_nips-Liste ist nicht statisch: Ein NIP wird daraus entfernt, wenn jeder Kind, den der NIP definiert, von der Zugriffskontrolle des Relays abgelehnt wird.

  • blocked_kinds — Das Blockieren aller Kinds eines NIP blendet ihn aus (z. B. blendet das Blockieren von Kind 5 NIP-09 aus). Das Blockieren nur einzelner Kinds behält den NIP.
  • allowed_kinds — Ein Kind wird nur akzeptiert, wenn er gelistet ist; ein NIP, dessen Kinds alle nicht gelistet sind, wird ausgeblendet.
  • reject_ephemeral — Ephemere Kinds, die nicht in der NIP-vorgeschriebenen Ausnahmeliste stehen (22242, 27235, 28934/28935/ 28936, 24133, 23194/23195, 24242, 21059), werden abgelehnt, sodass darauf angewiesene NIPs ausgeblendet werden.
  • Voraussetzungen — NIP-29, NIP-43 und NIP-66 beruhen auf Relay-signierten Events und sind ohne relay.private_key ausgeblendet; NIP-86 ist ausgeblendet, sofern nicht rpc.management_token oder rpc.admin_pubkey gesetzt ist (sonst wird jeder Verwaltungsaufruf abgelehnt).
  • NIPs ohne eigene Kinds (1, 11, 13, 26, 33, 40, 45, 50, 67, 70, 77) werden bei Aktivierung immer beworben.

Laufzeitänderungen — NIP-86 allowkind/disallowkind oder ein SIGHUP-Neuladen von reject_ephemeral — werden beim nächsten NIP-11-Abruf sichtbar. enabled_nips/disabled_nips erfordern weiterhin einen Neustart.