Bon retour sur Nostr Compass, votre guide hebdomadaire de Nostr.

Cette semaine : Shopstr garde les secrets de signataire distant et de portefeuille hors du stockage navigateur, Routstr SDK vérifie la découverte de fournisseurs venue des relays, Postr sort comme petit compositeur Android, Infans chiffre le suivi familial et la synchronisation entre parents, walls.rip transporte un chat chiffré en PGP à travers des relays Nostr publics, et pakstr rend la publication Zapstore explicite. nostr-tools lie les rumors de gift wrap à leurs seals. Les versions couvrent l’isolation des souscriptions, les statuts de profil et les marqueurs de départ par relay. Le travail de protocole atteint le déploiement des fils de commentaires, des brouillons de plafond de frais et de consultation de paiement pour wallet connect, des demandes d’affichage pour napplets, et une inscription expérimentale depuis le même compte. Le numéro se termine par Six mois d’août dans l’histoire de Nostr.

À la une

Postr sort comme petit compositeur Android

Postr est un compositeur Android délibérément petit pour les notes kind 1. La garde de la clé privée reste dans Amber, un signataire Android NIP-55 (signataire local) et NIP-46. La version 1.0.0 apporte une file de sortie durable qui survit à la perte de connectivité et à la mort du processus, des brouillons privés par compte, et des pièces jointes Blossom avec hachages vérifiés et autorisation de téléversement délimitée.

Une publication réussit après que Postr a relu l’événement signé identique et vérifié sa signature. Les nouvelles tentatives conservent le même id d’événement. La publication utilise les relays d’écriture de la liste NIP-65 (liste de relays) de l’auteur, plus des relays d’amorçage chiffrés, ou une liste personnalisée par compte. Une annonce de dépôt NIP-34 (git sur Nostr) signée et un profil de projet kind 0 correspondant sont publiés sur relay.ngit.dev. Les fils, l’analytique, la publicité et le stockage de clés restent hors de l’application.

Infans chiffre le suivi familial et la synchronisation entre parents sur Nostr

Des parents peuvent garder les données d’alimentation, de sommeil et de croissance sur leurs propres téléphones et les partager sans fournisseur de données familiales. Infans est un suivi de bébé Android qui traite une base Room locale comme source de vérité et publie des événements chiffrés kind 30078 de NIP-78 (données propres à une application) pour la sauvegarde et la synchronisation avec le partenaire. Son dépôt étiquette le chiffrement local comme NIP-44 (chiffrement de charge utile), mais l’implémentation utilise AES-256-GCM alors que NIP-44 v2 exige ChaCha20 avec HMAC-SHA256 ; les charges utiles en mode local ne devraient donc pas être présentées comme compatibles NIP-44.

La synchronisation avec le partenaire utilise le d-tag baby-tracker-sync, tandis que les sauvegardes personnelles utilisent baby-tracker-backup. Les notes asynchrones voyagent dans la charge utile du partenaire. Le chemin Amber NIP-55 documenté (signataire local) délègue signature et chiffrement au signataire, mais le dépôt ne fournit aucun test d’interopérabilité montrant que chaque chemin de sauvegarde et de synchronisation produit du texte chiffré NIP-44 v2. Le dépôt ne présente ni revendication de dispositif médical ni audit de sécurité externe.

Le Ghost Chat de walls.rip amène le chat chiffré en PGP sur des relays Nostr publics

walls.rip est une boîte à outils de communication anonyme dont le mode Ghost Chat crée ou importe une identité OpenPGP dans le navigateur. Son client open source chiffre chaque message avec la clé publique PGP du destinataire. La conversation lisible reste dans le stockage de session local de l’appareil ; l’application n’a ni compte de chat ni base de messages centrale.

Le transport est du vrai Nostr, mais il est délibérément propre à l’application. Ghost Chat publie du texte chiffré au format armored comme événements kind 1 vers cinq relays par défaut et étiquette chaque événement avec un tag de salle stable dérivé de l’empreinte PGP du destinataire. Cela donne aux développeurs un exemple concret d’usage des relays comme transport de messages résistant à la censure, tout en montrant pourquoi la livraison décentralisée seule ne protège pas les métadonnées et n’est pas interopérable avec les messages directs NIP-17.

pakstr 0.13.0 à 0.15.0 rend la publication Zapstore explicite

Après le travail d’empaquetage et Amber de 0.3.1 en juillet, pakstr est une CLI qui transforme un dossier de ressources web en APK Android signé et le publie sur Zapstore avec une clé Nostr. 0.13.0 ajoute le versionnage automatique des releases. Les suites 0.13.1 à 0.13.3 réparent la publication Blossom : l’autorisation utilise désormais base64url, les téléversements portent un Content-Digest, et l’événement d’application Zapstore est publié avant le téléversement Blossom.

0.14.0 valide l’éditeur Zapstore avant qu’une publication continue. 0.15.0 écrit les métadonnées de fiche dans des événements d’application kind 32267 et place les notes de version dans le content des événements de release kind 30063, de sorte que la fiche Zapstore d’une application empaquetée peut porter nom, résumé et notes sans étape manuelle séparée.

Heterodyne spécifie des personas portables et une communication sociale chiffrée

Heterodyne est une famille de protocoles orientée spécification pour des personas portables, une communication authentifiée, le contrôle de son propre appareil et l’interaction sociale. Son README actuel compose quatre couches existantes : événements Nostr signés, Radicle (git pair à pair) comme stockage durable, Marmot (messagerie de groupe MLS sur Nostr) pour les conversations chiffrées directes et de groupe, et journaux d’événements de clé KERI (Key Event Receipt Infrastructure) pour la rotation d’identité. Un persona est décrit comme un npub Nostr à racine froide plus un journal KERI accepté ; la signature courante utilise des clés d’époque rotatives, tandis que les identités de nœud Radicle sont déléguées avec double preuve.

La famille découpe ce travail en quatre brouillons 0.x versionnés indépendamment. Core détient l’identité, la vérification des journaux d’événements de clé, les octets canoniques Nostr et le substrat de dépôt Radicle ; Comms détient les enveloppes natives Nostr, les niveaux de confidentialité, la publication et les conversations Marmot ; et Social détient le suivi public, les interactions et les listes. Control, pour l’inscription et les autorisations de ses propres appareils, est incomplet et ne peut être revendiqué. Ces documents restent des brouillons susceptibles de casser avant la 1.0, et ce numéro présente la famille avant toute sortie de client Heterodyne.

Versions

Nostr Java v2.0.8 : isolation des souscriptions et NIP-44 portable

Une requête gift wrap contre un relay contenant cinq événements en renvoyait zéro, deux ou six au hasard, parce que Nostr Java, une bibliothèque Java pour dialoguer avec les relays et chiffrer les charges utiles Nostr, livrait chaque trame entrante à tous les listeners de la connexion. La version 2.0.8 route EVENT, EOSE et CLOSED vers la souscription que ces trames nomment, de sorte que le signal de fin d’événements stockés d’une requête ne peut plus fermer une autre. Les trames de portée connexion comme NOTICE, OK et AUTH atteignent toujours tous les listeners.

NIP-44 (chiffrement de charge utile) dans la même version n’a plus besoin d’un fournisseur JCE enregistré dans le processus. Le chiffrement ne fonctionnait qu’après la génération d’une clé dans cette JVM, ce qui enregistrait BouncyCastle par effet de bord, et il échouait sur Android, où ajouter un fournisseur nommé « BC » ne fait rien. Les deux chemins de chiffrement utilisent désormais le moteur ChaCha20 léger de BouncyCastle, et la génération de clés ne modifie plus l’état JCE global du processus. Les appelants qui comptaient sur la bibliothèque pour enregistrer le fournisseur doivent l’enregistrer eux-mêmes. La dépendance de NIP-44 au fournisseur JCE est le ticket que cela clôt.

NoorNote v1.3.6 : statuts de profil et annonces classées

NoorNote est un client Nostr pour bureau, web et Android. Une semaine après que 1.3.4 a ajouté les adhésions chiffrées aux communautés, la version 1.3.6 affiche NIP-38 (statuts d’utilisateur) sous le nom NIP-05 (vérifié par domaine) d’un profil : les événements adressables kind 30315, à expiration optionnelle, qui portent un statut général ou musical d’une ligne. Un clic sur cette ligne définit le statut de la personne qui regarde.

Les annonces classées de NIP-99 (offres de place de marché kind 30402) s’affichent désormais partout dans l’application, de sorte que le module de place de marché ne sert plus qu’à acheter et vendre. Les notes privées de surnom sur les profils apparaissent aussi en orange d’avertissement, avec une icône de note pleine et un anneau orange autour de l’avatar.

nostrord v2.9.0 : état de groupe et médias par relay

Quitter un groupe NIP-29 (groupes gérés par relay) sur un hôte supprimait auparavant le même id de groupe sur tous les autres relays, parce que nostrord, un client multiplateforme pour les communautés hébergées sur relays, indexait ses marqueurs de départ et de suppression par id nu. Les marqueurs de départ et de suppression délimités par relay gardent ces suppressions sur l’hôte qui les a produites, de sorte qu’un groupe partageant un id entre deux relays n’est plus quitté ni abandonné en paire. Une adhésion que le relay refuse parce qu’on est déjà membre compte désormais comme un succès et efface le marqueur local, qui était un état absorbant : l’auto-réparation libérait un emplacement tandis que le démarrage à froid restaurait l’autre.

La version 2.9.0 rend aussi les images intégrées en markdown que d’autres clients écrivent comme ![alt](url), au lieu d’afficher la ponctuation markdown autour d’une URL déjà détectée. Les messages directs prennent en charge NIP-17 (DM privés en gift wrap) et les rumors de fichier kind 15, de sorte qu’une pièce jointe chiffrée envoyée depuis Jumble est téléchargée, déchiffrée et affichée, et que les pièces jointes sortantes sont chiffrées avant téléversement. Ce tag livre désormais le travail de clé de chiffrement NIP-4e couvert la semaine dernière. La proposition reste non fusionnée, et nostrord indique que son implémentation suit le comportement déployé de Jumble là où celui-ci diffère du brouillon.

Changements non publiés

Shopstr garde les secrets de signataire distant et de portefeuille hors du stockage navigateur

Shopstr est une place de marché web pour les annonces classées NIP-99. Après le travail d’intégrité des paiements du mois dernier, il cesse d’écrire dans localStorage les secrets sérialisés du signataire bunker. Une charge utile de bunker NIP-46 (signature distante) contenait l’URL bunker:// active et la clé privée d’application générée, de sorte que n’importe quel script dans l’origine Shopstr pouvait reprendre la session de signature distante. Les données de bunker restent désormais en mémoire pour la session courante, les charges utiles de bunker résiduelles sont supprimées quand elles sont trouvées, et les types de signataire autres que bunker conservent leur comportement de stockage antérieur.

Le changement NWC correspondant fait de même pour les identifiants NIP-47 (wallet connect). Shopstr avait stocké la chaîne nostr+walletconnect:// complète, y compris le secret utilisé pour les actions de portefeuille, comme donnée navigateur ordinaire, et la réutilisait au paiement. Les chaînes de connexion et les métadonnées de portefeuille restent désormais en mémoire, et les anciennes copies stockées sont supprimées à la lecture des données locales. Les scripts qui s’exécutent déjà dans l’origine Shopstr pendant une session active peuvent encore voir ces valeurs en mémoire.

Routstr vérifie la découverte de fournisseurs venue des relays

Un seul relay malveillant pouvait auparavant décider à quels fournisseurs d’inférence un client Routstr faisait confiance. Routstr SDK est la bibliothèque TypeScript derrière Routstr, une place de marché qui découvre des fournisseurs d’IA sur Nostr et les paie en Cashu. Le correctif de découverte de cette semaine vérifie chaque annonce de fournisseur, liste de modèles et avis livrés par relay (kinds 38421, 38423 et 38425) avant qu’un consommateur les voie, de sorte qu’un avis nommant une pubkey de confiance mais portant une signature invalide n’entre plus dans le classement.

Les horodatages très lointains sont écartés avant la sélection de l’« avis le plus récent ». Les événements en avance de plus de quinze minutes sur l’horloge locale sont retirés sur le chemin direct et à la lecture du stockage persistant, ce qui empêche un created_at falsifié de devancer des avis valablement signés d’un redémarrage à l’autre. Si aucun avis de confiance n’est disponible, la porte des avis échoue en position fermée et exclut du classement de paiement les fournisseurs sans avis jusqu’à ce que des avis arrivent. Les opérateurs peuvent toujours activer un fournisseur à la main.

nostr-tools lie les rumors de gift wrap à leurs seals

Déballer un événement NIP-59 (gift wrap) déchiffrait auparavant le wrap, déchiffrait le seal et renvoyait le rumor interne sans vérifier de qui venait le seal. nostr-tools est une bibliothèque JavaScript d’utilitaires du protocole Nostr. Le correctif de déballage de cette semaine exige que le wrap soit kind 1059, que le seal soit kind 13 avec une signature valide, et que le pubkey du rumor soit égal au pubkey du seal. Déchiffrer le seal prouve déjà le contrôle de seal.pubkey. Sans cette dernière vérification, n’importe qui pourrait sceller un rumor nommant quelqu’un d’autre comme auteur et amener un client à attribuer le message à cette victime.

NIP-17 (DM privés en gift wrap) utilise le même chemin de déballage, la liaison s’applique donc aux DM privés. Le déballage par lot ignore désormais un wrap qui échoue à ces vérifications au lieu de lever une exception, car les gift wraps ne sont pas sollicités et un seul événement hostile écarterait le reste d’une requête relay.

Haven ajoute une administration de relay signée et un navigateur de notes local

Haven est un relay Nostr auto-hébergé et un serveur de médias Blossom. Sa console d’administration tout juste fusionnée expose les appels de gestion NIP-86 sur chaque point d’entrée du relay, chaque requête étant authentifiée par un événement NIP-98 du propriétaire configuré. Les opérateurs peuvent gérer bannissements, listes d’autorisation, règles de kind, noms de relay et médias stockés sans donner au relay une clé de signature. Un navigateur de notes en lecture seule garde les kinds chiffrés opaques et ne charge les médias distants qu’après un clic, évitant une requête automatique qui révélerait l’adresse IP de l’opérateur à un hôte extérieur.

Le même changement Haven ajoute des graphiques de trafic persistants et corrige une défaillance LMDB par défaut où le comptage des événements stockés pouvait boucler indéfiniment, saturer un cœur de CPU et bloquer les appels de statistiques suivants. Haven utilise désormais le compteur du backend là où il termine, et un parcours d’événements borné sinon. Le projet a ajouté ses 23 premiers tests autour de la pagination d’événements, de la suppression, de la persistance des métriques, des contrôles de propriétaire et des signatures de requête liées à l’URL.

Amethyst sort l’autorisation Blossom des threads de chargement d’images

Amethyst, un client Nostr Android, n’attend plus l’autorisation de lecture Blossom sur les threads du dispatcher OkHttp. L’intercepteur démarre désormais la signature hors du thread réseau, tandis que le chargeur d’images attend une signature partagée par hôte et réessaie la requête du blob protégé. Une rafale d’images sous contrôle n’occupe donc plus tous les emplacements de connexion par hôte pendant qu’un signataire répond.

Le même correctif Amethyst aligne l’encodage du jeton sur BUD-11 : Base64url sans remplissage, portée server, et pas de tag x propre à un blob, ce qui permet à un jeton de couvrir plusieurs blobs sur le même hôte. De nouveaux tests de concurrence exercent la mise en cache, l’expiration, les réessais signés et seize appelants simultanés partageant une signature.

Mises à jour des NIP et travail de spécification du protocole

NIPs

Snort et Ditto utilisent désormais NIP-22 (fils de commentaires) pour les réponses texte ordinaires, convergeant sur kind 1111 tout en conservant des chemins de compatibilité ; cela n’établit pas un kind de réponse unique à l’échelle du protocole. Après que l’amendement de juin a levé l’interdiction d’utiliser NIP-22 sur des notes kind 1, un ajout fusionné à NIP-30 (emoji personnalisés) liste kind 1111 parmi les événements pouvant porter des tags emoji, avec un shortcode dans content résolu par ce tag. Snort, un client Nostr web, écrit désormais chaque réponse en kind 1111, charge ces commentaires via les tags de portée racine E/A en majuscules, et accepte toujours un chemin NIP-10 (tags de réponse kind 1) optionnel pour les notes plus anciennes. Ditto, à la fois serveur Mastodon et relay Nostr, publie chaque réponse comme commentaire NIP-22, kind 1111 pour le texte et kind 1244 pour la voix, tout en continuant d’afficher les réponses kind 1 existantes. Les clients qui ne comprennent que NIP-10 ne verront pas la nouvelle forme. Les publications de premier niveau restent kind 1.

Une requête pay_invoice de NIP-47 (Nostr Wallet Connect) n’offre actuellement aucun moyen standard au client de spécifier un plafond de frais de routage. Une proposition ouverte de plafond de frais ajoute un paramètre optionnel max_fee, en millisatoshis, à pay_invoice. Les portefeuilles qui respectent le budget NE DOIVENT PAS envoyer un paiement dont le coût de routage dépasse amount + max_fee et DOIVENT renvoyer FEE_LIMIT_EXCEEDED, défini comme aucun débit et aucun paiement tenté. Les implémentations qui le prennent en charge DOIVENT inclure fees_paid dans la réponse pour que le client puisse réconcilier. Les implémentations sans prise en charge du plafond ignorent le paramètre inconnu, et les clients devraient traiter l’absence du champ fees_paid comme le signe que le plafond n’a peut-être pas été appliqué. Le changement n’ajoute aucun kind d’événement et reste une proposition jusqu’à sa fusion.

Une proposition ouverte d’étiquettes de langue dans NIP-32 standardiserait ["l", "<BCP-47>", "lang"] pour la langue du texte déclarée par l’auteur. Comme le tag l d’une seule lettre est déjà indexable par les relays, les clients pourraient demander un fil en japonais avec {"#l":["ja"]} sans mise à jour de relay ni détection de langue peu fiable après téléchargement. Le brouillon migre aussi les exemples de langue des rapports de relay NIP-66, des métadonnées d’image NIP-68 et des pistes audio NIP-71 vers le même espace de noms. Les étiquettes restent des affirmations d’auteur non vérifiées, et le changement n’est pas fusionné.

Nostr Wallet Connect

Après un délai dépassé, une reconnexion ou une notification manquée, un client wallet connect a besoin d’un moyen de demander un seul enregistrement de paiement sans savoir quel protocole de paiement Bitcoin l’a créé. Un brouillon ouvert de consultation de paiement dans le dépôt d’extensions NWC définit le NWC-09 optionnel lookup_payment à côté du cœur NIP-47. La requête utilise exactement un sélecteur : un transaction_id stable propre au portefeuille, les champs payment_hash et/ou invoice compatibles BOLT11 déjà utilisés par lookup_invoice, ou un payment_type plus un objet lookup typé défini par une autre extension. Un résultat réussi renvoie une enveloppe commune (transaction_id, type, state, payment_type, amount en msats, horodatages, fees_paid et metadata optionnels, et un objet details discriminé) et DOIT se résoudre en exactement un enregistrement visible pour cette connexion. Le portefeuille NE DOIT PAS révéler si un enregistrement inaccessible existe, et un sélecteur qui correspond à plusieurs enregistrements visibles renvoie MULTIPLE_MATCHES. Les états sont pending, accepted, settled, failed, expired et canceled. La même proposition ajoute les détails d’offre et de paiement BOLT12 en NWC-12 qui réutilisent cette enveloppe. Les deux documents sont encore des brouillons.

NAPs

Un brouillon NAP-DISPLAY ouvert permettrait à un napplet de demander à son hôte les afficheurs de pixels qu’il a le droit d’utiliser. Il s’appuie sur la proposition d’applets web NIP-5D, non fusionnée et traitée séparément, que la Newsletter #17 a présentée et qui reste hors de l’ensemble des NIP fusionnés. Le brouillon définit display.list, qui renverrait des identifiants stables opaques avec largeur et hauteur logiques et un type choisi à l’exécution (lcd, eink, led-matrix ou other), et display.push, qui soumettrait un lot non vide de pixels sRGB de trois octets adressés par coordonnées. La découverte à l’exécution ferait correspondre le RGB logique à la profondeur de couleur native, à l’orientation et au rafraîchissement, et PEUT faire tourner, réordonner, quantifier, tramer ou fusionner les mises à jour. La politique du shell contrôlerait quels afficheurs un napplet peut lister ou écrire et PEUT rejeter, limiter le débit ou plafonner les lots. Avant d’appliquer un pixel, le runtime validerait tout le lot, de sorte qu’un push échoué ne changerait rien sur l’appareil. Un succès signifierait que le lot a été accepté, non que le rafraîchissement matériel est terminé.

Marmot

Une expérience Marmot ouverte remplacerait le brouillon External Commit retiré pour l’inscription depuis le même compte par une forme de Commit bornée. Marmot, le protocole de messagerie de groupe MLS sur Nostr, assigne dans ce brouillon le composant sans données 0x800d (marmot.same-account-membership.v1) comme marqueur de comportement négocié. Tant qu’il est requis, une feuille courante peut rédiger soit exactement un Add inline du même compte, soit un à quatre Removes inline de frères, chacun avec un UpdatePath normal et une priorité de convergence ordinaire, et chaque Commit DOIT laisser au plus cinq feuilles courantes par compte. L’appariement utilise un QR éphémère affiché par le parrain (marmot-pairing-v1:) dont le secret alimente HKDF-SHA256 et ChaCha20-Poly1305 sur un canal indépendant du porteur. Des preuves kind 453 purement locales lient la session à la clé de compte partagée et ne sont jamais relayées. Après un Welcome correspondant, la première charge utile applicative de la personne qui rejoint est un accusé kind 452 non affiché lié aux empreintes de Welcome et de GroupInfo, de sorte qu’un Welcome identique octet pour octet peut être récupéré sans consommer à nouveau le KeyPackage. Le parrain apparié est la racine de confiance de la personne qui rejoint pour cette branche et ne prouve pas de finalité globale. Un document compagnon de synchronisation de compte reste exploratoire et non interopérable. L’expérience ne fait pas partie du profil de base adopté.

Six mois d’août dans l’histoire de Nostr

Les mois d’août suivent un seul problème d’interopérabilité : comment un client nomme une cible et y attache un retour. Le dépôt de protocole original n’a enregistré aucun commit en août 2021, le noyau d’événements signés est donc resté immobile. NIP-25 (réactions) a ensuite quitté la case réservée au kind 1 en 2022. Les enregistrements remplaçables réguliers ont gagné des coordonnées naddr et a à identifiant vide en 2023 ; en 2024, la classe remplaçable paramétrée distincte a été renommée événements adressables sans changement du format de transmission. Les réactions ont migré vers les médias externes en 2025. Le kind 1111 de NIP-22 (fils de commentaires) a atteint des clients en production en 2026. La progression va d’un document de protocole immobile à un vocabulaire partagé de réponses et de réactions qui fonctionne sur les notes, les enregistrements remplaçables et les objets hors réseau.

Août 2021

La fenêtre de commits d’août 2021 du dépôt de protocole original est vide. Le dernier changement avant ce mois inactif fut le brouillon NIP-05 du 18 juin, qui a ajouté les identifiants de domaine DNS comme pointeur lisible par un humain vers une clé publique. NIP-05 (identifiants de domaine) est passé plus tard à un fichier JSON well-known, mais au milieu de 2021 il s’agissait encore d’une recherche TXT DNS. Août n’a pas étendu ce travail d’identifiants et n’a ajouté ni nouveau kind d’événement ni message de relay.

La même fenêtre vide apparaît dans les outils qui existaient déjà à côté de la spécification. noscl, un client en ligne de commande créé en janvier 2021, n’a enregistré aucun commit en août ; ni go-nostr ni nostr-tools non plus. L’activité de protocole n’a repris qu’à la fin de l’année, quand le dépôt a assigné NIP-09 (demandes de suppression d’événement) et remplacé le schéma DNS par un fichier JSON well-known d’identifiants. Août 2021 est l’étape inactive entre le brouillon d’identifiants de juin et le travail de suppression et de JSON well-known de décembre, tandis que le modèle d’événements signés et de relays tenait tel qu’écrit.

Août 2022

Le 19 août, une modification de NIP-25 a étendu les cibles des réactions kind 7 des notes texte kind 1 à d’autres notes. L’événement kind 7 et la convention +/- figuraient déjà dans le brouillon. Ce changement d’interopérabilité a permis à un like, un dislike ou un emoji de s’attacher à un profil, à une liste de suivis ou à tout kind d’événement ultérieur réutilisant les mêmes tags e et p.

La spécification NIP-25 actuelle conserve cette généralisation : une réaction indique les réactions d’utilisateur à d’autres événements, et une cible adressable reçoit en plus un tag a avec des coordonnées kind:pubkey:d-tag. Amethyst, un client Android, implémente ce contrat dans son constructeur de réactions. Ce constructeur accepte n’importe quel événement, écrit des tags e, p et k, et ajoute un tag a quand la cible est un événement adressable. Cela a généralisé les cibles de réaction au-delà du kind 1 ; des changements d’août ultérieurs ont ajouté des coordonnées stables et des tags de contexte de commentaire.

Le logiciel de relay traduisait aussi les règles de tags en comportement de stockage. Le 17 août, nostr-rs-relay a cessé de traiter toute valeur de tag d’apparence hexadécimale comme clé d’index binaire. Il a limité cette optimisation aux tags d’une seule lettre et aux valeurs hexadécimales en minuscules, préservant les tags texte ordinaires au lieu de les décoder vers une forme que les filtres ne pouvaient pas apparier. Ce mois-là a donc réuni deux faces de l’interopérabilité : les spécifications ont élargi ce qu’une interaction pouvait cibler, tandis qu’un relay corrigeait la manière dont ces tags de cible étaient indexés et récupérés.

Août 2023

Le 24 août, NIP-19 (identifiants bech32) a défini comment encoder un événement remplaçable non paramétré en naddr. Le champ d’identifiant, le tag d, est devenu une chaîne vide pour les kinds qui remplacent par pubkey et kind seuls, comme les métadonnées et les listes de contacts. Cinq jours plus tard, NIP-01 (le protocole d’événements et de relays de base) a ajouté le format de a-tag correspondant : kind:pubkey: avec deux-points final et sans identifiant. Les clients pouvaient désormais pointer vers un enregistrement remplaçable sans attendre un id d’événement précis que le remplacement suivant invaliderait.

Le texte NIP-19 actuel demande toujours aux implémenteurs d’utiliser une chaîne vide pour ces événements remplaçables. nostr-tools, la bibliothèque JavaScript d’identifiants, encode ce champ via naddrEncode, de sorte qu’un appelant peut passer un identifiant vide et produire une coordonnée partageable. Le travail d’août 2023 a fait de l’état remplaçable quelque chose qu’un commentaire, une réaction ou un lien de partage pouvait nommer après le remplacement de l’événement sous-jacent. L’août suivant a standardisé la terminologie de la classe remplaçable paramétrée voisine, tandis que des tags de commentaire ultérieurs ont réutilisé la grammaire de coordonnées comme A et a.

Les charges utiles privées devenaient portables au même moment. Le 24 août, rust-nostr a ajouté les fonctions de chiffrement et de déchiffrement NIP-44 à ses bindings JavaScript, exposant le schéma versionné de clé de conversation aux applications web à côté des appelants Rust natifs. Le 22 août, Amethyst a séparé le chiffrement NIP-44 du format d’événement de messagerie, reflétant la séparation de protocole entre la façon dont le contenu est chiffré et la façon dont une application le transporte. Les coordonnées stables ont rendu les objets publics plus faciles à référencer ; les API de chiffrement réutilisables ont rendu le contenu privé plus facile à déplacer entre implémentations sans le coupler à un kind de message.

Le même mois a aussi apporté des financements pour des travaux voisins d’isolation de clés, d’interface et d’éducation. Une série de subventions OpenSats du 17 août a attribué ses subventions du Nostr Fund à Amber, au design d’interface Nostr partagé et à l’éducation sur les cas d’usage de Nostr. La subvention d’Amber portait sur le maintien des clés de signature dans une application Android dédiée via NIP-46, tandis que les subventions de design et d’éducation traitaient de l’accueil des nouveaux utilisateurs et de motifs applicatifs réutilisables. Le système Nostr au sens large progressait par des commits de spécification, l’isolation des clés, le travail d’interface et l’éducation des développeurs financée comme infrastructure partagée.

Août 2024

Le 20 août, les spécifications ont renommé « événement remplaçable paramétré » en « événement adressable » dans NIP-01 et seize autres documents, dont les articles longs, les activités en direct, les listes, les calendriers et les annonces classées. Le format de transmission n’a pas changé. kind:pubkey:d-tag est resté la coordonnée. Ce qui a changé, c’est que chaque spécification utilisant déjà ces coordonnées employait désormais le même mot pour les désigner.

Ce vocabulaire est celui que livrent les implémentations actuelles. NIP-01 stocke les événements adressables comme l’enregistrement le plus récent par kind, pubkey et tag d. NIP-19 appelle un naddr « a nostr addressable event coordinate ». Le chemin de réaction d’Amethyst, cité plus haut, type la cible comme AddressableEvent avant d’écrire le tag a. L’extension de coordonnées de 2023 et le changement de terminologie de 2024 utilisent tous deux la grammaire de coordonnées kind:pubkey:d-tag, tandis que NIP-01 continue de distinguer les événements remplaçables réguliers des événements adressables. Un commentaire ultérieur peut donc récupérer une discussion adressable via un A majuscule sans se soucier de l’id d’événement qui occupe cette adresse à l’instant présent.

Les protocoles de stockage appliquaient la même préférence pour les identifiants explicites. Le 27 août, le BUD-04 de Blossom a permis à un événement d’autorisation de porter plusieurs tags x de hachage de blob, de sorte qu’un client pouvait autoriser un lot borné de téléversements, de miroirs ou de suppressions sans prétendre que les hachages décrivaient un seul objet. Quatre jours plus tard, le projet a clarifié son descripteur de blob et ajouté un exemple. Les événements Nostr coordonnaient des opérations sur des médias adressés par contenu tandis que les octets restaient sur des serveurs de médias, séparant l’autorisation signée du transport de stockage.

Le 29 août, la signature distante est devenue plus tolérante aux ensembles de relays imparfaits. go-nostr a modifié son client NIP-46 pour qu’un relay défaillant ne puisse pas bloquer une requête envoyée via d’autres relays configurés : les connexions aux relays et les tentatives de publication s’exécutent indépendamment, et l’appel avance dès qu’une connexion aboutit. Le 19 août, OpenSats a aussi annoncé un soutien de long terme au créateur d’Amethyst, Vitor Pamplona, incluant un travail sur les messages privés NIP-17, les bibliothèques multiplateformes et le modèle outbox. Le vocabulaire du protocole, le transport résilient, le travail de confidentialité et le financement soutenu de la maintenance convergeaient vers le même but : des clients capables de continuer à fonctionner d’un appareil à l’autre et dans des conditions de relay inégales.

Août 2025

Le 22 août, NIP-25 a gagné les réactions au contenu externe. Une réaction à quelque chose qui n’est pas un événement Nostr natif doit être kind 17 et doit porter les tags k et i de NIP-73 (identifiants de contenu externe), remplaçant l’ancien tag r de site web. Les exemples du texte fusionné sont une URL web (k=web) et un épisode de podcast identifié par GUID d’émission et GUID d’élément, avec des URL Fountain en indices. Les réactions avaient quitté le kind 1 en 2022. Elles quittaient maintenant l’ensemble des événements Nostr.

Fountain 1.3, publié le 15 août 2025, a livré ces likes avant la fusion de la spécification et a indiqué qu’ils reposent sur Nostr afin que d’autres applications de podcast puissent les lire. Le document NIP-25 d’aujourd’hui utilise toujours l’exemple de GUID de podcast de Fountain. En août 2025, une coordonnée de réaction pouvait nommer un épisode de podcast ou une page web avec la même grammaire d’identifiants qu’un commentaire utilise ensuite pour une racine externe.

Août 2026

Cet août a fait entrer les fils de commentaires dans les clients qui écrivent des réponses ordinaires. L’amendement de juin, fusionné plus tard, a supprimé la ligne qui disait aux clients de ne pas utiliser les commentaires NIP-22 sur les notes courtes. NIP-30 (emoji personnalisés) a ensuite ajouté kind 1111 à côté des notes, des réactions et des statuts d’utilisateur, de sorte qu’un commentaire peut porter les mêmes tags d’emoji que ces autres kinds utilisaient déjà. Le travail de spécification est la permission. Le travail de client est le déploiement.

Snort, un client web, publie désormais par défaut des commentaires NIP-22 pour les cibles kind 1, s’abonne aux fils via les tags racine E/A en majuscules, et accepte kind 1111 dans les notifications. Ditto, un client web communautaire, publie chaque réponse comme commentaire NIP-22, kind 1111 pour le texte et 1244 pour la voix, y compris les réponses aux notes kind 1, tout en lisant encore les réponses NIP-10 (chaînage de notes). Le basculement de six ans se voit dans ces valeurs par défaut : 2022 a généralisé la réaction, 2023 et 2024 ont nommé la coordonnée, 2025 a pointé les réactions hors réseau, et 2026 a fait du commentaire l’événement de réponse partagé pour ces mêmes cibles.

L’infrastructure de groupes privés définissait la reprise comme exigence d’interopérabilité. Le contrat de durabilité et de redémarrage du 13 août de Marmot spécifie quel état local MLS et de publication doit survivre à un redémarrage, et exige des clients qu’ils réconcilient l’état persisté avant de poursuivre les opérations de groupe. Cela étend la progression d’août au-delà du fait de nommer une cible : un client mature doit aussi préserver assez d’état cryptographique et de livraison pour reprendre sans risque après une interruption. Les formes d’événement partagées ne servent que si les implémentations peuvent récupérer l’état nécessaire pour les utiliser.

Envoyez un DM NIP-17 pour partager un projet ou une information via le projet Nostr Compass.