Nostr

Anna trouve sur Nostr des auteurs qu’elle souhaite suivre. Plus tard, son application ne lui convient plus. Si elle utilise la même clé privée ou un dispositif de signature connecté de façon sûre dans une autre application, elle peut conserver son identité. La clé publique permet aux autres de la reconnaître et de vérifier ses signatures ; la clé privée permet de signer en son nom. D’où la différence essentielle entre npub et nsec. Selon NIP-19, ces formes représentent respectivement les clés publique et privée dans l’encodage Bech32. Les NIP sont des documents numérotés qui décrivent les règles et extensions de Nostr. Encoder n’est pas chiffrer : un nsec n’est pas un simple lien de profil à partager librement. Conserver l’identité ne garantit pas non plus que la nouvelle application retrouvera toutes les anciennes publications ou importera tous les réglages. [2] [7]

L’application, appelée client, signe la publication puis l’envoie aux relais choisis. Un relais est un serveur qui reçoit les messages et les conserve ou les transmet selon ses propres règles. L’application de Petr contacte des relais pour demander les publications qui l’intéressent. Aucun serveur central unique n’existe, et chaque serveur n’est pas tenu de tout copier. Les échanges passent par WebSocket, une connexion maintenue ouverte : EVENT transporte un message, REQ ouvre un abonnement et OK indique une acceptation ou un refus. Même un OK positif ne confirme ni la réception par Petr ni un archivage permanent. EOSE marque la fin des résultats déjà stockés pour cette requête ; l’abonnement peut ensuite continuer à recevoir de nouveaux messages. [1] [7]

Lorsqu’un message arrive, l’application de Petr vérifie que sa signature correspond à la clé publique annoncée et que les données signées n’ont pas changé. Cela ne prouve ni la véracité du message ni l’identité civile de son auteur. L’auteur renseigne aussi l’heure de création : ce n’est donc pas un horodatage indépendant. Pour aller plus loin : un enregistrement appelé event contient pubkey, created_at, kind, tags et content, soit la clé, l’heure, le type, les balises et le contenu. SHA-256 produit, à partir de leur représentation précisément définie, une courte valeur de contrôle appelée id. Elle permet de repérer une modification des données signées. Le champ sig contient une Schnorr Signature conforme à BIP340 sur la courbe secp256k1. Elle signifie « le détenteur de la clé correspondante a signé ces données », pas « cette affirmation mérite confiance ». [1]

Une longue clé publique est difficile à retenir. NIP-05 permet de l’associer à un identifiant ressemblant à une adresse e-mail. L’application demande au domaine concerné quelle clé correspond au nom, puis compare la réponse à la clé du profil. Elle vérifie cette association avec le domaine, pas automatiquement le vrai nom, la réputation ou la fiabilité d’une personne. Le responsable du domaine peut modifier l’association. Si Anna suit déjà quelqu’un, la clé publique d’origine doit rester la référence ; attribuer le même nom à une autre clé ne doit pas changer discrètement la personne suivie. La pseudonymité consiste à utiliser un identifiant durable plutôt que son nom civil, sans garantir l’anonymat. [3]

Petr n’a pas besoin de télécharger tous les messages. Il envoie un filtre, par exemple pour certains auteurs et un type de publication précis. Les différentes conditions d’un filtre sont liées par AND : elles doivent toutes être remplies. Plusieurs valeurs admises pour une même condition sont des alternatives OR, comme les différents filtres d’une même requête REQ. Il suffit de satisfaire l’un de ces filtres. limit borne le lot initial de résultats stockés, pas automatiquement les futurs messages de l’abonnement. NIP-01 utilise des clés hexadécimales dans les événements et les filtres, et non le format npub destiné aux utilisateurs. Une recherche vide peut venir du filtre, du serveur choisi ou de son historique ; elle ne prouve pas que la publication n’existe nulle part. [1]

Anna modifie sa description et souhaite que les autres voient la nouvelle. Nostr distingue donc ce que les relais doivent conserver. Pour les événements remplaçables, ils retiennent le plus récent pour une même paire pubkey et kind. Les événements adressables ajoutent la valeur de la balise d, qui distingue par exemple plusieurs documents d’un même auteur. Lorsque des enregistrements remplaçables ont le même horodatage, il est recommandé de garder l’id la plus petite dans l’ordre lexicographique, autrement dit celle dont l’écriture vient en premier dans cet ordre. Les événements temporaires, dits ephemeral, ne sont même pas censés être stockés. Ce sont des conventions, et les relais peuvent se comporter différemment. Nostr n’est donc pas un registre où tout le réseau s’accorde sur une histoire unique et immuable. [1]

Anna remarque qu’elle a publié quelque chose qu’elle voulait garder privé. NIP-09 lui permet d’envoyer une demande de suppression signée. Avant de l’appliquer, le client doit vérifier que la demande et la publication initiale relèvent de la même clé publique : un tiers ne doit pas pouvoir supprimer le message d’Anna simplement en le désignant. Les serveurs et applications qui coopèrent peuvent retirer le contenu ou cesser de l’afficher. Mais la demande ne peut éliminer toutes les copies, captures d’écran ou archives indépendantes. Masquer une publication dans une application ne dit pas non plus si un autre serveur la propose encore. Ce que vous publiez importe donc davantage que la présence d’un bouton Supprimer. [4]

Toute personne qui obtient une publication publique peut la lire ; la signature seule n’en cache pas le contenu. Les messages privés reposent sur des règles supplémentaires. NIP-44 décrit le chiffrement du contenu, tandis que NIP-17 traite de l’enveloppement et de la livraison des messages avec d’autres protections. Cela ne garantit pas l’anonymat : adresses réseau, horaires et comportement de l’application peuvent encore révéler des informations. Ce chiffrement ne fournit pas non plus de forward secrecy, c’est-à-dire de protection des anciennes conversations si la clé durable est compromise plus tard. Quiconque obtient la clé privée nécessaire et des messages chiffrés enregistrés auparavant peut aussi lire les échanges passés. Vérifiez donc les extensions réellement prises en charge par l’application ; le nom « Nostr » ne suffit pas à décrire sa confidentialité. [5] [6]