NIPs de Nostr expliqués : les documents de spécification du protocole

L'évolution de Nostr se fait par le biais de NIPs, des documents de spécification brefs que n'importe qui peut proposer. Si vous voulez comprendre comment de nouvelles fonctionnalités comme les zaps ou les messages directs chiffrés arrivent dans le protocole, les NIPs sont la réponse.

Ce guide couvre ce que sont les NIPs, comment ils fonctionnent comme mécanisme de gouvernance, et lesquels lire si vous devenez technique.

Les NIPs sont des documents markdown courts sur GitHub qui proposent comment implémenter des fonctionnalités Nostr. Les développeurs de clients choisissent lesquels supporter. Un NIP devient « réel » lorsque suffisamment de développeurs l'adoptent. L'ensemble principal des NIPs largement utilisés est d'environ 30 ; la liste complète en compte environ 100.

Quand vous êtes prêt, prenez votre adresse @nostr.blog →

Ce qu'un NIP est réellement

Un NIP est un fichier markdown dans le référentiel github.com/nostr-protocol/nips. Chaque fichier décrit une fonctionnalité, un format ou une convention spécifique : comment signer des événements, à quoi ressemble un événement de métadonnées de profil, comment envoyer un message direct, quel format utilisent les demandes de zap Lightning.

La taille varie. Les plus courts NIPs font moins d'une page ; les plus longs en font plusieurs milliers de mots. La plupart se situent autour de 500 à 2000 mots. Ils sont écrits pour être implémentables à partir de la spécification seule, ils incluent donc les formats de message, les champs obligatoires et les événements d'exemple.

La convention de nommage est NIP-XX où XX est un numéro. Les numéros sont attribués lorsque le NIP est fusionné ; ils ne reflètent pas la priorité ou l'importance. NIP-05 concerne les identifiants vérifiés ; NIP-04 est la norme de messages directs plus ancienne ; NIP-01 est le protocole principal. Les numéros suivent l'ordre de proposition, pas la signification de la fonctionnalité.

Pourquoi « Implementation Possibilities »

Le nom est un choix délibéré. Comparez avec d'autres traditions de spécification.

• RFCs (Requests for Comments) dans les protocoles Internet deviennent souvent obligatoires pour l'interopérabilité.
• EIPs (Ethereum Improvement Proposals) deviennent souvent obligatoires via la mise à niveau du réseau.
• NIPs sont définitivement optionnels. Un client qui implémente 40 NIPs et un client qui en implémente 10 sont tous deux des clients Nostr valides ; ils font simplement des sous-ensembles différents.

Cela signifie que les NIPs ne « cassent » jamais les implémentations existantes. Un nouveau NIP pour une fonctionnalité ne force pas les clients plus anciens à changer. Le protocole grandit aux bords tandis que le cœur reste stable.

Le cycle de vie du NIP

Comment un nouveau NIP entre en existence :

1. Quelqu'un remarque un manque ou un besoin. « Nous n'avons aucun moyen standard de faire X. » Cela pourrait être un développeur de client, un opérateur de relais, ou un utilisateur frustré par un problème spécifique.
2. Ils écrivent un brouillon. Le format suit les NIPs existants : titre, objectif, spécification, exemples.
3. Ils soumettent une demande de fusion au référentiel des NIPs.
4. Examen communautaire. Les développeurs, opérateurs de relais, et utilisateurs intéressés commentent. Le brouillon est révisé en fonction des retours.
5. Fusion ou abandon. Les NIPs fusionnés reçoivent un numéro et deviennent partie du référentiel. Les brouillons abandonnés restent dans l'historique des demandes de fusion.
6. L'implémentation suit (ou non). Certains NIPs sont implémentés en quelques semaines. D'autres attendent des années. Certains ne sont jamais largement implémentés.

Le processus est léger. Pas de vote de comité, pas d'approbation formelle. Si la demande de fusion reçoit une rétroaction largement positive et répond à un besoin évident, elle est fusionnée.

Les NIPs qui comptent si vous êtes un utilisateur

La plupart des NIPs sont invisibles pour les utilisateurs. Une poignée affecte votre expérience quotidienne :

• NIP-01 : Protocole principal. Comment les événements sont structurés et signés. Vous ne le voyez jamais, mais tout le reste en dépend.
• NIP-05 : Identifiants vérifiés. Vous donne des noms lisibles vous@domaine.com. Notre guide NIP-05 le couvre.
• NIP-07 : Signature d'extension de navigateur. Permet aux clients web de signer sans voir votre clé privée.
• NIP-19 : Encodage Bech32. Pourquoi votre clé publique ressemble à npub1... au lieu de l'hexadécimal brut.
• NIP-23 : Articles long-form. Active les articles de style blog sur Nostr.
• NIP-44 : Messages directs chiffrés. La norme moderne de messagerie directe (meilleure que l'ancien NIP-04).
• NIP-57 : Zaps. Pourboires Lightning avec reçus publics.
• NIP-98 : Authentification HTTP. Permet aux identités Nostr de s'authentifier auprès de sites web réguliers.

En tant qu'utilisateur, vous bénéficiez de tous ces éléments sans interagir avec eux. Les clients gèrent les détails du protocole.

Les NIPs qui comptent si vous êtes un développeur

Si vous écrivez ou maintenez un client Nostr, les NIPs à lire augmentent en dizaines :

• NIP-01 à NIP-10 (mécaniques principales).
• NIP-11 (documents d'information de relais).
• NIP-13 (preuve de travail, pour la résistance aux spam).
• NIP-17 (messages directs enveloppés pour dissimuler les métadonnées).
• NIP-22 (expiration des événements).
• NIP-27 (références de notes de texte).
• NIP-30 (emoji personnalisés).
• NIP-31 (types d'événements).
• NIP-33 (événements remplaçables paramétrés).
• NIP-42 (authentification des connexions aux relais).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (capacité de recherche).
• NIP-65 (métadonnées de liste de relais).
• NIP-78 (données d'application personnalisée arbitraire).

Ce sont ceux que la plupart des clients grand public implémentent. Un client qui soutient cet ensemble plus les NIPs orientés utilisateur ci-dessus couvre 95 % de l'utilisation typique.

Lire un NIP

Si vous voulez en lire un directement, le référentiel se trouve à github.com/nostr-protocol/nips. La structure de la plupart des NIPs :

• Titre et description. Ce que le NIP propose.
• Motivation. Pourquoi la fonctionnalité est nécessaire.
• Spécification. Format exact du message, champs obligatoires, règles de validation.
• Événements d'exemple. JSON concret montrant à quoi ressemble un événement conforme.
• Comportement du client/relais. Comment les implémentations doivent gérer les événements.

Les NIPs sont écrits pour être lisibles par les développeurs les implémentant. La section de spécification est celle qui compte ; c'est là que vit le protocole réel.

NIPs avec adoption partielle

Certains NIPs existent mais sont implémentés de manière incohérente entre les clients. Cela crée des cas limites où votre expérience varie selon le client.

NIP-44 (messages directs chiffrés). Adopté par Damus, Primal, Amethyst, et la plupart des clients majeurs en 2024-2025. Certains clients plus anciens ne supportent que NIP-04. Si vous envoyez un message direct à quelqu'un dont le client ne supporte que NIP-04, vos messages NIP-44 à cette personne échouent silencieusement. La réponse pratique : utilisez un client moderne et espérez que votre correspondant le fait aussi.

NIP-17 (messages directs enveloppés). Messages directs qui cachent les métadonnées. L'adoption en 2026 s'améliore mais n'est pas universelle. La fonctionnalité est excellente lorsque les deux clients des parties la soutiennent ; sinon elle revient silencieusement à des messages directs moins privés.

NIP-46 (signataires distants). Permet à un signataire matériel ou une application de bunker de signer des événements au nom d'un client. Supporté dans Amethyst, partiellement ailleurs.

NIP-65 (liste de relais de l'utilisateur). Permet aux utilisateurs de publier leurs relais préférés afin que les clients puissent automatiquement acheminer vers les bons endroits. L'adoption s'améliore ; les clients plus anciens l'ignorent.

NIP-50 (recherche). Permet aux clients de interroger les relais pour les correspondances de texte. Certains relais la supportent ; beaucoup ne le font pas. La qualité de la recherche est incohérente en conséquence.

Vérifier quels NIPs un client donné supporte est un diagnostic utile lorsque quelque chose ne fonctionne pas comme prévu. La plupart des clients publient leur matrice de support NIP dans leur documentation.

Comment le processus des NIPs maintient la cohérence du protocole

Pas d'autorité centrale, donc la cohérence vient des dynamiques sociales. Quelques observations :

Les mauvais NIPs ne se propagent pas. Une proposition qui duplique un NIP existant ou résout le mauvais problème reçoit une adoption minimale et meurt tranquillement. La communauté n'est pas formelle mais est opinâtre.

Les bons NIPs sont implémentés indépendamment. Plusieurs développeurs de clients lisent les propositions et décident indépendamment. Les bonnes idées accumulent des adoptants ; les mauvaises idées ne le font pas.

Des NIPs concurrents émergent parfois. Deux propositions différentes pour la même fonctionnalité peuvent coexister pendant un temps. Généralement, l'une l'emporte en pratique parce que plus de clients l'implémentent ; parfois elles fusionnent.

Évolution compatible avec les fourches. Parce que les NIPs sont optionnels, un client peut implémenter NIP-X-v1 et plus tard se mettre à niveau vers NIP-X-v2 sans casser quiconque ne supporte que v1. Le protocole ne se divise pas.

C'est compliqué mais fonctionnel. Le protocole a considérablement évolué au cours de cinq ans sans un organe de gouvernance central parce que le mécanisme social d'« implémenteurs lisent, implémenteurs décident, implémenteurs codent » a assez d'alignement pour produire de la cohérence.

Proposer votre propre NIP

Si vous avez une idée pour une nouvelle fonctionnalité Nostr :

1. Consultez d'abord le référentiel des NIPs. Quelqu'un l'a peut-être déjà proposé.
2. Si non, ouvrez un problème GitHub décrivant le problème que vous résolvez.
3. En fonction des retours, rédigez un NIP complet en suivant le format existant.
4. Soumettez une demande de fusion.
5. Engagez-vous dans la discussion. Soyez disposé à réviser.
6. S'il est fusionné, tant mieux. S'il ne l'est pas, le problème peut avoir une meilleure solution ; considérez pourquoi.

Pas chaque bonne idée ne devient un NIP. Pas chaque NIP ne devient une fonctionnalité. L'écosystème a plus de propositions que n'importe quel développeur unique ne pourrait suivre, et le filtre est « suffisamment de la communauté l'implémente-t-elle ». Ce filtre est au cœur de la façon dont Nostr reste cohérent sans être de haut en bas.