Un événement Nostr a trois parties mobiles : son kind (le type de chose qu’il est), son content (la charge utile) et ses tags (des métadonnées structurées qui relient les événements entre eux et disent aux clients comment les traiter). Nous publions déjà une référence des NIP pour les documents de spécification et un registre des event kinds pour l’espace de noms des numéros de kind. Cette page comble le troisième pilier : les tags standardisés — les petites étiquettes réutilisables qui apparaissent dans presque chaque événement.
Chaque tag est un tableau JSON dont le premier élément est le nom du tag. Les tags d’une seule lettre (e, p, a, t…) sont spéciaux : les relais les indexent, ce sont donc ceux sur lesquels on peut filtrer et interroger efficacement. Chaque définition ci-dessous est citée de la NIP qui la définit dans le dépôt canonique nostr-protocol/nips; là où le sens d’un tag est raffiné par plusieurs NIP, la plus pertinente est citée.
Tags de référence de base (NIP-01)
Ces trois-là sont définis dans le protocole de base et signifient la même chose pour chaque kind d’événement. Le tag d les rejoint comme identifiant des événements adressables.
| Tag | Rôle | Structure | NIP |
|---|---|---|---|
e |
Référer un autre événement | ["e", <id d'événement hex>, <URL de relais, optionnel>, <pubkey de l'auteur, optionnel>] |
NIP-01 |
p |
Référer un autre utilisateur | ["p", <pubkey hex>, <URL de relais, optionnel>] |
NIP-01 |
a |
Référer un événement adressable/remplaçable par coordonnée | ["a", "<kind>:<pubkey>:<valeur du tag d>", <URL de relais, optionnel>] |
NIP-01 |
d |
Identifiant qui rend un événement adressable unique par auteur+kind | ["d", <chaîne d'identifiant>] |
NIP-01 |
Fils de discussion, citations et réactions
| Tag | Rôle | Structure | NIP |
|---|---|---|---|
e (marqué) |
Structure de fil : un marqueur distingue la racine d’une réponse directe | ["e", <id>, <url-relais>, <marqueur>, <pubkey>] où le marqueur est "root" ou "reply" |
NIP-10 |
q |
Citer un autre événement (l’intègre au lieu d’y répondre) | ["q", "<id ou adresse>", "<url-relais>", "<pubkey>"] |
NIP-18 |
k |
Le numéro de kind (en chaîne) d’un événement référé/réagi | ["k", "<kind en chaîne>"] |
NIP-25, NIP-72 |
Pour les réactions (kind 7), la NIP-25 exige un tag e (l’événement réagi) et recommande un tag p (son auteur); l’événement de réaction PEUT ajouter un tag k portant le kind de l’événement réagi.
Découverte et références
| Tag | Rôle | Structure | NIP |
|---|---|---|---|
t |
Mot-clic — la valeur DOIT être une chaîne en minuscules | ["t", <mot-clic en minuscules>] |
NIP-24 |
r |
Une URL web à laquelle l’événement fait référence d’une manière ou d’une autre | ["r", <url>] |
NIP-24 |
Traitement et affichage du contenu
| Tag | Rôle | Structure | NIP |
|---|---|---|---|
subject |
Ligne d’objet d’un événement texte (kind 1), comme l’objet d’un courriel | ["subject", <chaîne>] |
NIP-14 |
content-warning |
Marque un contenu que le lecteur doit approuver avant qu’il soit affiché | ["content-warning", <raison, optionnel>] |
NIP-36 |
alt |
Court résumé lisible pour qu’un client générique rende un kind inconnu | ["alt", <description en texte>] |
NIP-31 |
emoji |
Émoji personnalisé : shortcode → URL d’image (kinds 0, 1, 7, 30315) | ["emoji", <shortcode>, <url-image>] |
NIP-30 |
imeta |
Métadonnées en ligne décrivant une URL de média dans le contenu | ["imeta", "url ...", "m ...", "dim ...", …] |
NIP-92 |
Métadonnées d’article long (NIP-23)
| Tag | Rôle | NIP |
|---|---|---|
title |
Le titre de l’article | NIP-23 |
image |
URL d’une image affichée avec le titre | NIP-23 |
summary |
Le résumé de l’article | NIP-23 |
published_at |
Horodatage Unix (en chaîne) de la première publication | NIP-23 |
Protocole et cycle de vie
| Tag | Rôle | Structure | NIP |
|---|---|---|---|
expiration |
Horodatage Unix après lequel l’événement DEVRAIT être considéré expiré et supprimé par les relais | ["expiration", <horodatage unix>] |
NIP-40 |
nonce |
Preuve de travail : une valeur mutable ajustée pour que l’id de l’événement ait les bits de tête nuls visés | ["nonce", <nonce>, <difficulté cible>] |
NIP-13 |
Pourquoi l’espace de noms des tags compte
Deux points de conception méritent d’être intégrés. D’abord, les tags d’une seule lettre sont indexables — les relais laissent les clients filtrer dessus (une recherche de mot-clic #t, un fil de mentions #p, une recherche de fil #e), c’est pourquoi une grande partie du graphe social de Nostr s’exprime par e et p. Les tags multi-caractères comme content-warning ou imeta portent un sens local, propre à l’événement, et ne sont généralement pas interrogés. Ensuite, les tags sont la façon dont le protocole reste extensible sans fork : une nouvelle NIP peut définir un nouveau tag, et les clients qui ne le comprennent pas l’ignorent simplement — le tag alt existe précisément pour qu’un client ne reconnaissant pas un nouveau kind puisse quand même montrer quelque chose de sensé.
Ce registre s’accompagne de notre référence des event kinds (l’espace de noms des kind) et de notre référence des NIP (les spécifications) pour couvrir tout le modèle de données de la NIP-01. Elle se trouve dans le pôle des spécifications de protocole aux côtés de nos références Bitcoin, Lightning et mesh. Nouveau sur le protocole? Commencez par Nostr pour les Bitcoiners, et générez ou inspectez des clés avec le convertisseur de clés Nostr. Pour la liste complète des paramètres d’un tag, la NIP qui le définit dans nostr-protocol/nips fait autorité.
