Référence des NIP pris en charge
Tous les NIP côté relais implémentés par nostrfy — kinds, notes et réserves — et comment la liste supported_nips de NIP-11 est calculée dynamiquement.
NIP implémentés
| NIP | Description |
|---|---|
| 1 | Protocole de base (événements, abonnements) |
| 9 | Suppression d’événements |
| 11 | Document d’information du relais |
| 13 | Preuve de travail |
| 17 | DM privés (kind 14 enveloppé dans kind 15 ; les gift wraps kind 1059 et éphémère kind 21059 sont servis uniquement au destinataire quand l’auth NIP-42 est activée) |
| 22 | Commentaires (kind 1111, fils via l’index #e) |
| 26 | Signature d’événements déléguée |
| 28 | Chat public (côté client : stocké et servi comme événements ordinaires, non annoncé) |
| 29 | Groupes hébergés sur le relais |
| 32 | Étiquetage (kind 1985, indexé #l/#L) |
| 33 | Événements remplaçables paramétrés |
| 34 | Fonctions Git (kinds 1617-1619, 1621, 1622, 1630-1633, 30617/30618 — sur option via relay.enabled_git, désactivé par défaut) |
| 40 | Horodatage d’expiration |
| 42 | Authentification client |
| 43 | Métadonnées d’accès au relais (rôles) — kinds 33534/13534/8000/8001 plus éphémères 28934/28935/28936 ;
les métadonnées signées par le relais sont protégées par AUTH. Les codes d’invitation sont émis avec NIP-86 createclaim/deleteclaim ; un kind:28934 portant un code listé admet
son auteur |
| 45 | Comptage des résultats (COUNT) |
| 46 | Nostr Connect |
| 47 | Nostr Wallet Connect |
| 50 | Capacité de recherche (plein texte, triée par pertinence) |
| 57 | Zaps Lightning (kinds 9734/9735) |
| 59 | Gift wrap (servi uniquement au destinataire) |
| 62 | Demande de disparition |
| 65 | Métadonnées de liste de relais |
| 66 | Découverte de relais & vivacité (kinds 30166/10166 stockés et servis ; auto-publie kind 30166) |
| 67 | Indice de complétude EOSE |
| 70 | Événements protégés |
| 77 | Synchronisation Negentropy (un remplacement échoué ferme l’id avec NEG-ERR selon NIP-77) |
| 78 | Données spécifiques aux applications (kind 30078, protégé par AUTH) |
| 84 | Points forts |
| 85 | Assertions de confiance (kinds 30382/30383/30384/30385/10040, adressables) |
| 86 | API de gestion du relais |
| 87 | Annonces Cashu et Fedimint (kinds 38000/38172/38173) |
| 88 | Sondages |
| 94 | Métadonnées de fichiers (kind 1063) |
| 98 | Auth HTTP |
| A3 | Cibles de paiement (kind 10133, remplaçable), un brouillon ; servi mais non annoncé
dans supported_nips |
Blossom (BUD-01/02) n’est pas un NIP et n’est pas annoncé dans le document NIP-11 — il est servi comme
serveur de fichiers séparé sur le nom d’hôte [blossom]. Voir la page du serveur de fichiers Blossom pour plus de détails.
Annonce dynamique des NIP
La liste supported_nips n’est pas statique : un NIP en est retiré lorsque chaque kind défini par le
NIP est rejeté par le contrôle d’accès du relais.
blocked_kinds— bloquer tous les kinds d’un NIP le masque (p. ex. bloquer le kind 5 masque NIP-09). N’en bloquer que certains conserve le NIP.allowed_kinds— un kind n’est accepté que s’il est listé ; un NIP dont les kinds sont tous non listés est masqué.reject_ephemeral— les kinds éphémères qui ne figurent pas dans la liste d’exemption imposée par le NIP (22242,27235,28934/28935/28936,24133,23194/23195,24242,21059) sont rejetés, donc les NIP qui en dépendent sont masqués.- Prérequis — NIP-29, NIP-43 et NIP-66 reposent sur des événements signés par le relais et sont
masqués sans
relay.private_key; NIP-86 est masqué sauf sirpc.management_tokenourpc.admin_pubkeyest défini (sinon chaque appel de gestion est refusé). - Les NIP sans kinds dédiés (
1,11,13,26,33,40,45,50,67,70,77) sont toujours annoncés lorsqu’ils sont activés.
Les modifications effectuées à l’exécution — NIP-86 allowkind/disallowkind, ou un rechargement SIGHUP de reject_ephemeral — sont reflétées lors de la prochaine récupération NIP-11. enabled_nips/disabled_nips exigent toujours un redémarrage.