Qu'est-ce que NIP-05 ? L'adresse Nostr, expliquée

Votre clé publique Nostr, écrite complètement, ressemble à npub1pf8hkx3ang2jngcgpsawtmj48c90pgqasmgpva7qhvnsty5j87yqwk3vy5. Essayez de dire cela à haute voix au dîner. Essayez maintenant de l'écrire sur une carte de visite, ou de l'épeler au téléphone. Vous ne pouvez pas. La clé brute est correcte et sûre à partager, mais elle est inutile comme identifiant que les humains utilisent.

NIP-05 est la solution. Il vous permet de joindre quelque chose de court et en forme d'email, comme alice@nostr.blog ou vous@votredomaine.com, à la même clé publique. Les clients vérifient le mappage et affichent la version lisible à côté de votre nom. C'est l'idée générale.

Ce guide couvre ce que fait le NIP-05, comment fonctionne réellement la vérification sous le capot, ce qu'il ne vous donne pas (ce n'est pas une coche bleue), et les deux façons d'en obtenir un.

TL;DR. NIP-05 est un identifiant sous la forme nom@domaine.com qui mappe vers votre clé publique Nostr. Un domaine publie un petit fichier JSON à /.well-known/nostr.json ; les clients lisent ce fichier pour confirmer le mappage. Il vous donne un nom lisible et un léger signal de confiance. Il ne vérifie pas votre identité du monde réel et ne protège pas votre compte contre la perte.

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

Ce qu'est le NIP-05, en une phrase

NIP-05 est une norme pour pointer un identifiant lisible vers une clé publique Nostr, en utilisant le DNS et un fichier JSON sur un serveur web.

L'identifiant ressemble intentionnellement à une adresse email. Une adresse email est déjà la forme que la plupart des gens reconnaissent comme « un nom que vous pouvez remettre à quelqu'un d'autre ». Emprunter cette forme évite une ronde d'explications.

L'implémentation est volontairement low-tech. Pas de blockchain, pas de registre central, pas de cryptographie fantaisiste au-delà de ce que Nostr utilise déjà. Le propriétaire d'un domaine publie un fichier JSON simple, n'importe quel client peut le lire, et la cryptographie n'intervient que lorsque le client vérifie que la clé publique mappée correspond à la signature sur les messages.

Comment cela fonctionne réellement

Voici le mécanisme littéral, car il est assez court pour tenir dans un article.

Vous dites à votre client Nostr que votre identifiant est alice@nostr.blog. Le client :

1. Analyse l'identifiant en une partie locale (alice) et une partie domaine (nostr.blog).
2. Effectue une requête GET vers https://nostr.blog/.well-known/nostr.json?name=alice.
3. Le serveur répond avec un fichier JSON qui ressemble à peu près à ceci :

{
  "names": {
    "alice": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88"
  }
}

4. Le client lit la clé publique hexadécimale et la compare avec la clé publique attachée à vos messages.
5. S'ils correspondent, le client marque l'identifiant comme vérifié et le rend à la place de (ou à côté de) votre npub.

C'est toute la danse. Pas d'OAuth, pas de création de compte du côté du domaine au-delà de « héberger ce fichier ». Quand nostr.blog cesse de vous lister dans ce fichier, l'identifiant cesse de fonctionner. Quand le mappage est de retour, cela recommence à fonctionner.

La requête GET est censée retourner les en-têtes CORS (Access-Control-Allow-Origin: *) pour que les clients dans le navigateur puissent la lire. La plupart des hôtes NIP-05 y compris nostr.blog le font déjà correctement ; ceux qui ne le font pas sont à l'origine de la plupart des fils de support « mon NIP-05 est cassé ».

Ce que le NIP-05 vous donne réellement

Trois avantages concrets, par ordre décroissant d'utilité.

Un nom que vous pouvez prononcer à haute voix

C'est celui dont tout le monde parle en premier parce que c'est celui qui résout le plus de frictions courantes. alice@nostr.blog fonctionne sur les podcasts, les cartes de visite, les bios de profil sur d'autres réseaux et les panneaux manuscrits. npub1pf8hkx3ang2... ne fonctionne pas.

Portabilité entre les clients et les relais

L'enregistrement NIP-05 pointe vers votre clé publique, pas vers le domaine qui l'héberge. Si demain vous décidez de migrer de alice@nostr.blog à alice@alicedomain.com, vous le faites en mettant à jour les deux fichiers JSON pour pointer vers la même clé publique. Vos messages, suivis et réputation ne s'en soucient pas. Comparez cela à Twitter, où un changement de pseudo signifie que la plateforme redirige tout pour vous et une suppression de compte signifie que tout disparaît.

Un léger signal de confiance

Pas un fort, et la distinction compte. Un NIP-05 sur un domaine prudent est une preuve que celui qui contrôle ce domaine a décidé de lister votre nom. Si le domaine est connu pour examiner ses utilisateurs (par exemple, une entreprise exécutant un espace de noms vérifié pour les employés), cet examen se répercute sur l'identifiant. Si le domaine distribue des noms à quiconque le demande, le signal de confiance est zéro. La plupart des clients le savent et rendent la coche neutre.

Ce que le NIP-05 N'EST PAS

Cette section existe parce que l'analogie de la coche bleue égare les nouveaux utilisateurs de trois façons spécifiques.

Ce n'est pas la preuve que vous êtes une vraie personne ou une personne spécifique. NIP-05 vérifie que la clé publique signant les messages correspond à la clé publique que le domaine a listée sous ce nom. Il ne vérifie pas que le nom correspond à une véritable personne nommée Alice. L'usurpation d'identité de célébrité est possible si l'imposteur contrôle un domaine disposé à le lister.

Ce n'est pas un mécanisme de récupération. Si vous perdez votre clé privée, votre NIP-05 ne peut pas vous sauver. L'identifiant pointera joyeusement vers une clé publique dont le propriétaire n'a aucun moyen de publier à nouveau. Personne ne peut la réinitialiser pour vous parce que personne d'autre n'a la clé.

Ce n'est pas une URL. alice@nostr.blog est un identifiant. Le coller dans un navigateur n'ouvrira rien. Pour accéder au profil d'Alice, vous alimentez l'identifiant à un client Nostr ou une passerelle web. La forme ressemble à un email, pas à un lien.

Comment obtenir une adresse NIP-05

Deux chemins, clairement différents en coût et effort.

S'inscrire sur nostr.blog

Le chemin le plus rapide. Vous choisissez un nom d'utilisateur, l'identifiant est en direct en moins d'une minute, et l'inscription comprend un portefeuille Lightning plus un client web complet sur la même page. Tarification par longueur de nom :

• 1 caractère : 999 $ par an (réservé aux vraies poignées premium à une lettre)
• 2 caractères : 499 $ par an
• 3 caractères : 199 $ par an
• 4 caractères : 99 $ par an
• 5 caractères : 29 $ par an
• 6 à 7 caractères : 9,99 $ par an
• 8 caractères ou plus : 2,99 $ par an

Les noms plus longs sont beaucoup moins chers parce qu'il y en a beaucoup plus. Les noms plus courts sont rares, mémorables et tarifés en conséquence.

Hébergez le vôtre sur un domaine que vous possédez

Si vous possédez déjà un domaine et êtes à l'aise pour éditer un fichier sur un serveur web, vous pouvez exécuter NIP-05 vous-même pour le coût du domaine (et rien de plus).

La configuration minimale viable :

1. Mettez un fichier JSON à https://votredomaine.com/.well-known/nostr.json avec la forme montrée plus tôt.
2. Assurez-vous que le serveur retourne Access-Control-Allow-Origin: * pour ce fichier, sinon les clients basés sur navigateur ne le liront pas.
3. Définissez votrenomlocationvotre@votredomaine.com comme identifiant NIP-05 dans votre client Nostr.
4. Attendez quelques minutes que tout cache côté client soit effacé.

Le chemin DIY est approprié pour les personnes qui veulent une totale indépendance de toute tierce partie. C'est mauvais pour les personnes qui veulent « juste le nom, je ne veux pas maintenir un serveur web ». La plupart des utilisateurs se situent dans le deuxième groupe.

Les pièges courants

Cinq modes de défaillance qui représentent la plupart des questions d'assistance.

• En-tête CORS manquant. Le fichier nostr.json retourne les bonnes données mais le navigateur refuse de le lire à cause de la politique de même origine. Correction : configurez le serveur pour envoyer Access-Control-Allow-Origin: * sur le chemin .well-known.
• Mauvaise clé publique dans le JSON. Quelqu'un a copié à la main la valeur hexadécimale et a supprimé un caractère. Comparez octet par octet avec ce que votre client Nostr affiche sous « paramètres du compte ».
• Mise en cache agressif côté client. Après un changement du JSON, certains clients conservent l'ancien mappage pendant jusqu'à 24 heures. Déconnectez-vous et reconnectez-vous, ou changez temporairement de client, pour forcer une relecture.
• Utilisation d'un CDN qui réécrit les en-têtes. Cloudflare et les arêtes similaires suppriment parfois l'en-tête CORS ou ajoutent des directives de cache étranges. Vérifiez la réponse brute, pas ce que le navigateur affiche.
• Mettre des lettres majuscules dans le nom. Les noms NIP-05 doivent être en minuscules. Certains clients tolèrent les casses mélangées, d'autres non. Restez avec a-z, 0-9, tiret, tiret bas.

Cela vaut-il la peine de payer pour ?

Réponse honnête : cela dépend du nom et du domaine.

Si le nom que vous voulez est long et oubliable, le chemin DIY sur un domaine que vous possédez déjà est généralement le meilleur choix. Vous faites la configuration une fois et ne payez jamais personne pour l'identifiant.

Si vous voulez un nom court sur un domaine reconnaissable, qui est en soi un signal de confiance et de mémorabilité, payer quelques dollars par an est presque toujours mieux que d'essayer de squatter des noms équivalents sur plusieurs domaines. Les noms courts sont rares partout sur Internet et Nostr ne fait pas exception.

De toute façon, avoir un NIP-05 est mieux que de conserver le npub brut pour toujours. Le coût de ne pas en avoir est une pire impression à chaque fois que vous remettez à quelqu'un votre identifiant.