Nostr est un protocole ouvert d’événements signés échangés par des clients via des relais indépendants. Les réseaux sociaux en sont un usage ; le protocole n’a ni blockchain propre ni consensus commun à tous les relais.
Un événement contient pubkey, created_at, kind, tags, content, id et sig. NIP-01 calcule id par SHA-256 sur une sérialisation précise et utilise BIP340 sur secp256k1. Le client vérifie intégrité et autorisation par la clé. created_at est déclaré par l’auteur : ce n’est ni un horodatage indépendant ni une preuve de véracité. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
Le client publie EVENT et s’abonne avec REQ via WebSocket. OK indique acceptation ou refus par ce relais. EOSE termine la liste des événements stockés, pas nécessairement l’abonnement aux nouveaux événements. Aucun de ces messages ne confirme réception par le destinataire, réplication générale ou stockage permanent. [Nostr — NIP-01: Basic protocol]
Dans un filtre, toutes les conditions doivent être remplies : auteur et type signifient AND. Plusieurs filtres d’un REQ sont liés par OR ; un seul suffit. limit borne la liste initiale, pas le nombre d’événements futurs. Un résultat absent peut refléter l’historique limité d’un relais, pas l’inexistence de l’événement. [Nostr — NIP-01: Basic protocol]
Les événements remplaçables se comparent par pubkey et kind, les adressables aussi par la balise d. Une version récente peut remplacer une ancienne ; à horodatage égal, l’id lexicographiquement inférieur prévaut. Les événements éphémères ne sont pas censés être stockés. Ces règles décrivent les relais, pas une archive mondiale immuable ; les implémentations peuvent différer. [Nostr — NIP-01: Basic protocol]
NIP-19 utilise Bech32 pour l’affichage : npub désigne la clé publique, nsec la clé privée. Encoder n’est pas chiffrer. Partager nsec transmet donc le secret, pas simplement un lien de profil. Les événements et filtres NIP-01 utilisent les clés publiques hexadécimales, pas leur affichage npub. [Nostr — NIP-19: Encoded entities]
NIP-05 associe un nom ressemblant à une adresse e-mail à une clé publique selon la réponse du domaine. Cela établit l’association, pas l’identité réelle ni l’honnêteté. Le client doit suivre la clé originale : si le domaine réattribue le nom, il ne doit pas remplacer automatiquement le profil suivi par cette nouvelle clé. [Nostr — NIP-05: Internet identifiers]
NIP-09 définit la demande d’un auteur de retirer ses événements. Avant de les masquer, le client doit vérifier que l’original et la demande portent la même clé publique. Relais et clients peuvent la traiter, mais le protocole ne peut supprimer toutes les copies téléchargées ou conservées. Un effacement dans une interface ne prouve pas un effacement global. [Nostr — NIP-09: Deletion requests]
NIP-44 définit un payload chiffré, pas un système complet de messagerie privée ; NIP-17 ajoute enveloppes et règles de livraison. NIP-44 seul ne fournit pas de forward secrecy si la clé est compromise plus tard. Adresses réseau, horaires et comportement du client restent pertinents. La prise en charge des NIP dépend de chaque application. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Pour une vision complète, lisez aussi Nostr Wallet Connect, Schnorr signature, Clé privée, Confidentialité de Bitcoin, Pseudonymat. Cette entrée est également citée par Nostr Wallet Connect, Network Effect.