Nous sommes heureux de vous retrouver dans Nostr Compass, votre guide hebdomadaire de Nostr.

Cette semaine : Amethyst 1.13.1 poursuit le lancement des applications Nostr de la version 1.13.0 avec l’authentification du relay hôte NIP-29 et de nouvelles tentatives authentifiées de téléchargement Blossom. Code Call permet de poursuivre depuis un téléphone les sessions de programmation à distance, GitWorkshop coordonne les mainteneurs et la synchronisation des dépôts, et Mosaico fournit aux agents de programmation une couche partagée de visibilité sur Nostr. Nostrology cartographie la répartition des fonctions de lecture et d’écriture entre les listes de relays publiées par les profils. Les versions Android de Mafrend, Hanami et Cordn ouvrent la liste des versions étiquetées, tandis que FIPS ajoute une couche d’accès OpenWrt et qu’une PR ouverte propose un portage FreeBSD. La couverture des protocoles fait le point sur les NIPs, BUDs, NAPs, Marmot, Gamma Markets, Concord et NWC, tandis que Six ans de mois de juillet sur Nostr retrace les changements apportés en juillet, des premières recherches de domaines à l’état des groupes de relay.

À la une

Après le lancement de ses applications Nostr, Amethyst 1.13.1 ajoute un accès authentifié aux groupes et à Blossom

Amethyst 1.13.0, publiée le 28 juillet pour le client Nostr Android et multiplateforme, ouvre les napplets et les nsites NIP-5A dans un processus de navigateur isolé et dépourvu de clé. Une passerelle window.nostr, activée après consentement, peut signer et utiliser certaines fonctionnalités par l’intermédiaire du compte actif, tandis que des écrans d’autorisation propres à chaque site et à chaque compte permettent aux utilisateurs d’examiner ou de révoquer ces droits. Les applications favorites peuvent rester épinglées dans la barre inférieure sans partager leurs cookies, leur état de connexion ni leurs autorisations entre les comptes.

La même version 1.13.0 ajoute les arborescences de dépôts Git, les issues et les pull requests aux côtés des communautés Concord, des groupes de relay NIP-29, des discussions de groupe Buzz, des pages wiki et des flux RSS. Ces interfaces permettent à l’utilisateur de naviguer entre le code, la vie communautaire, la publication et les vues sociales sous une même identité Nostr.

Les fonctions de paiement et d’identité se sont également étendues dans la version 1.13.0. Amethyst peut créer et payer des offres BOLT12, démarrer automatiquement des comptes avec signataire distant, ajouter des serveurs Blossom de secours et étendre les réglages du Web of Trust aux badges, aux communautés et aux groupes de relay. La mise à jour 1.13.1 du 29 juillet ajoute un sceau de dissolution CORD-02, la suppression des groupes et des canaux par le kind 9008, l’authentification du relay hôte NIP-29 et de nouvelles tentatives BUD-01 authentifiées pour les téléchargements Blossom soumis à un contrôle d’accès.

Code Call 0.2.68 ajoute un navigateur de dossiers du worker après l’introduction du rattrapage dans la version 0.2.66

Code Call 0.2.68, une télécommande Android pour les sessions de programmation exécutées sur ordinateur, remplace sa liste spéciale d’espaces de travail par un navigateur de dossiers dont la racine correspond au répertoire du worker. Un utilisateur peut parcourir les dossiers imbriqués autorisés, en sélectionner un pour une session OpenCode et revenir aux dossiers parents ; la version 0.2.67 ouvre ce navigateur lors du lancement d’une session.

La version 0.2.66, antérieure, peut demander à un worker destinataire un résumé concis à partir du dernier message envoyé depuis le téléphone. D’autres versions de la même semaine maintiennent plusieurs sessions indépendantes, n’acceptent les réponses que de l’expéditeur attendu et gardent la boîte de réception connectée à chaque relay de worker configuré pour la livraison en arrière-plan. Les demandes et les réponses transitent dans NIP-17 (Messages directs privés), tandis que les pièces jointes Blossom chiffrées localement conservent leur type de fichier d’origine après le déchiffrement.

GitWorkshop coordonne les mainteneurs et préserve l’indépendance de la synchronisation des dépôts

La version signée de GitWorkshop du 27 juillet ajoute la connexion Android via NIP-55 (Application de signature Android) à la forge web NIP-34 (git stuff). Son dépôt source coordonne désormais les mainteneurs principaux de façon récursive, préserve les indications de relay de chacun et dissocie la synchronisation des dépôts de l’acceptation des invitations. Les références d’éléments de travail entre dépôts relient les travaux apparentés, tandis que GRASP copie les données des dépôts vers certains points de terminaison Git sans lier ce transfert à la livraison des invitations. La mise à jour 3.1.1, signée par le développeur, répare la livraison des intents au signataire Android, la résolution récursive des mainteneurs et les liens de dépôt qui préservent les chemins.

Mosaico 0.1.2 permet aux agents de programmation de partager leur statut sur Nostr

Mosaico 0.1.2 permet aux sessions d’agents de programmation dans Claude Code, Codex, Goose, Hermes, OpenCode et Grok de publier de brèves mises à jour de statut via NIP-29 (Groupes fondés sur les relays). Les sessions peuvent repérer des travaux actifs apparentés sur différents hôtes sans partager leurs transcriptions ni leur contexte.

La découverte des profils Codex nommés et la vue Top Of Mind de Goose affichent ce statut partagé dans les deux environnements (PR #618, PR #619). La version rétablit la capacité des agents hébergés à rejoindre la couche publique de visibilité, et la configuration exige désormais le choix explicite d’un relay (PR #626, PR #629). Mosaico reste une couche de visibilité, et non un hébergeur ou un orchestrateur d’agents ni un outil de fusion de transcriptions.

Nostrology cartographie la concentration des listes de relays à partir des events NIP-65 publiés

L’observatoire des relays de Nostrology tire son jeu de données du dernier event de kind 10002 publié par chaque profil au titre de NIP-65 (Métadonnées de liste de relays), conformément à la spécification publiée. Il distingue les rôles de lecture, d’écriture et mixtes des relays, représente le nombre de relays répertoriés par chaque profil et présente les décomptes sous-jacents dans un tableau triable. Lors de la vérification de publication du 29 juillet, la page contenait 34 430 valeurs distinctes d’URL de relay et regroupait 520 468 profils ayant exactement un relay répertorié, contre 150 657 avec trois et 60 710 avec quatre.

Le même instantané de Nostrology fait apparaître des concentrations qui se chevauchent autour de relay.momostr.pink pour 298 859 profils, relay.damus.io pour 287 181, nos.lol pour 279 468 et relay.primal.net pour 225 336. Ces nombres mesurent les entrées publiées dans les listes de relays, et non leur disponibilité : le tableau brut peut contenir des URL mal formées et des adresses locales, tandis que la spécification NIP-65 définit des métadonnées de routage sans tester l’état des relays. L’observatoire rend visibles les problèmes d’adoption et de qualité des données sans considérer qu’un relay répertorié est nécessairement actif.

Versions publiées avec un tag

Kairos 0.1.1 ajoute des rappels et une instruction Astraea locale

Kairos 0.1.1 ajoute des rappels d’échéance, une instruction locale explicite pour Astraea et une gestion plus stricte des relays et des URL. La version signée 0.1.0 a introduit le gestionnaire de tâches privilégiant le fonctionnement hors ligne, dont la couche facultative de synchronisation écrit sur les relays choisis par l’utilisateur des enregistrements chiffrés avec NIP-44 (Charges utiles chiffrées). Kairos utilise des coordonnées de tâches déterministes et des marqueurs de suppression chiffrés avec des demandes de suppression NIP-09 (Demande de suppression d’event), tandis que les tâches uniquement locales ne quittent jamais l’appareil.

Bray 2.3.0 dote son CLI d’un emballage cadeau générique et d’un environnement local de test Blossom

Bray 2.3.0, un SDK Nostr et une boîte à outils en ligne de commande, peut emballer et déballer n’importe quel event au moyen de NIP-59 (Emballage cadeau), la signature passant par NIP-46 (Nostr Connect) lorsqu’un bunker détient la clé. La PR #75 dote également le relay de test intégré des défis NIP-42 (Authentification des clients auprès des relays) et expose les commandes restantes du client Blossom. La PR #77 ajoute un serveur BUD-01/02 en mémoire dont l’autorisation signée lie chaque téléversement ou suppression à un blob, tandis que la PR #76 ajoute des event kinds nommés, des tags abrégés et des options de réconciliation des identifiants NIP-77 qui évitent de télécharger les events déjà détenus par l’appelant.

Buzz Desktop 0.5.0 renforce les invitations, la recherche et les mises à jour d’identité sur les relays

Après la couverture des espaces de travail Armada et Buzz la semaine dernière, Buzz Desktop 0.5.0 ajoute des liens d’invitation assortis d’un nombre limité d’utilisations (PR #3141) et des filtres de recherche par auteur, canal et plage temporelle (PR #2871). La PR #2862 récupère les politiques d’adhésion par l’intermédiaire de la couche réseau native de l’application de bureau, et la PR #2607 republie l’enregistrement d’identité d’un agent sur le relay après le changement de nom d’une persona. La version met aussi à jour sa dépendance Nostr en réponse à un avis sur un déni de service à distance dans NIP-44 et répare la récupération du stockage local, le positionnement dans les fils, la reconnexion aux relays ainsi que les chemins d’exécution sous Linux et Windows.

Shosho 1.0.0 étend sa place de marché de diffusion en direct

Shosho 1.0.0 réorganise la place de marché de diffusion en direct autour des créateurs, des sessions en direct, des extraits et des produits que les utilisateurs peuvent trouver grâce à une recherche configurable sur les relays. Un flux de notifications unifié rassemble désormais les mentions, les réactions, les republications et les zaps, et permet d’y répondre sans quitter le flux. Les spectateurs peuvent publier des extraits issus de diffusions en direct ou de rediffusions, tandis que cette version améliore aussi les discussions en fils, les réponses aux extraits, le chargement des profils et l’utilisation du réseau.

Mafrend v1.0 présente un aperçu des discussions Nostr géolocalisées sur Android

Mafrend v1.0 est la première version alpha publique pour Android d’un projet d’application Nostr de discussion liée à des lieux. Sa page de projet indique que les fonctionnalités sont encore en cours de développement et décrit chaque emplacement de la carte comme un salon de discussion consacré aux échanges autour d’un lieu. Un dépôt public de versions contient le paquet installable via Zapstore, tandis que l’application principale reste privée.

Hanami 0.1.0 offre aux serveurs Blossom un parcours Android passant par un signataire

Hanami 0.1.0, un compagnon Android pour les serveurs Blossom, permet de se connecter, de téléverser et de télécharger depuis un téléphone. L’application utilise NIP-55 (Application de signature Android) pour une signature soumise à approbation et un échange d’authentification natif NIP-98 (Authentification HTTP) pour la session du serveur. Hanami limite son interface web et sa passerelle de signature à l’origine du serveur choisi, de sorte que les identifiants restent auprès du signataire tandis que l’interface web existante du serveur fournit l’expérience applicative. La première version publique nécessite Android 8 ou une version ultérieure, un serveur Hanami accessible et une application de signature compatible.

Cordn lance sa discussion de groupe avec identité Nostr sur Android

Cordn, un client privé de messagerie de groupe, propose désormais aux utilisateurs Android un parcours d’inscription avec une identité Nostr, des liens de profil au moyen de NIP-05 (Association des clés Nostr à des identifiants Internet fondés sur le DNS) et des liens vérifiés qui ouvrent les destinations Cordn dans l’application. La version 0.2.1 publiée le 24 juillet introduit cette déclinaison native aux côtés du client web existant. Les messages utilisent MLS, un protocole de chiffrement de groupe, avec une livraison assistée par un coordinateur, ce qui permet aux groupes de conserver des conversations chiffrées ordonnées sans exiger d’adresse électronique ni de numéro de téléphone.

Nostur 1.30.1 corrige les fils et les publications en double après l’élargissement du partage dans la version 1.30.0

Nostur 1.30.1, un client Nostr pour iPhone, iPad et Mac, permet de parcourir des fils de réponses imbriqués sans les problèmes d’ouverture et de repli qui perturbaient la nouvelle mise en page. Il empêche également la publication en double d’un même brouillon, notamment lorsque les fonctions de rappel du téléversement des médias se déclenchent plusieurs fois. Cette version fait suite à la 1.30.0, qui ajoutait des messages directs éphémères et un parcours depuis la feuille de partage pour envoyer des médias vers Nostr ; l’application associe ainsi ses nouveaux parcours de messagerie et de publication à des corrections de leur utilisation quotidienne dans les fils et les publications.

Formstr Drive 0.0.2 associe les métadonnées de fichiers Nostr aux blobs Blossom

Formstr Drive 0.0.2, un gestionnaire de fichiers natif de Nostr, offre aux utilisateurs des aperçus dans l’application ainsi que la possibilité d’ouvrir les documents bureautiques dans Nostr Docs. En arrière-plan, il stocke les fichiers volumineux sous forme de blobs Blossom découpés en fragments et supprime le blob distant lorsqu’un utilisateur retire un fichier. Un relay local garde à proximité les métadonnées Nostr de l’application, tandis que Blossom héberge les données du fichier, ce qui sépare l’organisation des fichiers des volumineuses données binaires elles-mêmes.

NoorNote 1.3.1

NoorNote 1.3.1, un client Nostr pour le web, les ordinateurs et Android, ajoute des minuteries pour les messages éphémères et configure des relays de DM fonctionnels par défaut pour les nouveaux comptes. Il filtre les articles du flux global dépourvus d’image de couverture et achemine les notifications de republication vers le lecteur d’articles. La version 1.3.0, précédente, ajoutait des cartes NIP-53 (activités en direct), des tags de personnes NIP-68 (Flux axés sur les images), une mise en sourdine légère NIP-78 (données d’application) et le statut de visibilité des notes sur les relays.

algia 0.0.133

algia 0.0.133, un client Nostr en ligne de commande écrit en Go, fait suite à la version 0.0.132, qui ajoutait le répertoriage des groupes, les fils chronologiques, la publication, les réactions, les suppressions ainsi que les entrées dans les groupes et les sorties pour NIP-29 (Groupes fondés sur les relays). La même version ajoutait une préauthentification NIP-42 (Authentification des clients auprès des relays) pour les relays configurés afin de l’exiger. La version 0.0.133 a ensuite ajouté le téléversement d’images locales aux commandes de publication ordinaires, de canal et de groupe, en joignant à chaque event les URL obtenues et les tags NIP-92 (Pièces jointes multimédias). Les publications constituées uniquement d’images fonctionnent également, et les publications de groupe ciblent par défaut le stockage multimédia du relay du groupe, tandis que les autres utilisent les serveurs de fichiers configurés.

swift-nostr 0.7.0

Pour les applications Swift, swift-nostr 0.7.0, une bibliothèque Nostr destinée aux plateformes Apple, permet à un seul signataire distant NIP-46 de piloter toutes les fonctionnalités du client grâce à son abstraction de signature. La version prend en charge NIP-98 (Authentification HTTP) et NIP-29 (Groupes fondés sur les relays), y compris les parcours d’adhésion, de publication et de modération des groupes. Elle valide aussi le remplissage NIP-44 (Charges utiles chiffrées versionnées) à l’aide des vecteurs officiels et rejette les charges utiles dont le MAC est valide mais dont le remplissage n’est pas canonique.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, un portefeuille connecté à Nostr et un service NIP-47 (Nostr Wallet Connect), ajoute une connexion par passkey qui dérive la clé de signature Nostr dans le navigateur à l’aide de l’extension PRF de WebAuthn. Le serveur ne reçoit jamais ce secret, et la même passkey peut retrouver la même clé sur un autre appareil synchronisé. Les comptes peuvent désormais associer et fusionner plusieurs pubkeys Nostr, tandis que le service d’écoute facultatif transmet les events de connexion au portefeuille et retente la livraison par webhook lorsqu’un point de terminaison est inaccessible.

MDK 0.9.10

MDK 0.9.10, l’implémentation en Rust du protocole Marmot, conserve les envois en attente lorsqu’un transport est inactif et supervise la transmission des notifications de relay, afin que la réception reprenne après un retard, une panique ou une fermeture. La PR #1159 ajoute un historique durable et paginé des conversations ainsi que le contexte complet des réponses pour les agents locaux, et la PR #1167 republie l’event KeyPackage signé actuel au lieu d’en générer un autre. La version préserve aussi l’ordre manuel des discussions, prend en charge la dissolution définitive des groupes et étend la recherche classée par Web of Trust, les API de politique des relays et les liaisons de langage.

pakstr 0.3.1

pakstr 0.3.1 permet aux équipes web qui empaquettent un client Nostr pour Android de fournir une configuration d’exécution et un proxy API sans reconstruire l’enveloppe de l’application. Sa série de versions parues le même jour a ajouté une passerelle vers le signataire Amber, le chiffrement et le déchiffrement NIP-44 (charges utiles chiffrées), puis corrigé l’injection des autorisations Android avant les travaux de configuration à l’exécution de la série 0.3.x. Le squelette conserve les ressources web intégrées en local, tandis que les paramètres propres au déploiement arrivent à l’exécution, et le proxy fournit à l’application encapsulée un parcours contrôlé pour les requêtes API aux côtés de ses connexions ordinaires aux relays.

Ditto 2.34.2

Ditto 2.34.2, un client social Nostr personnalisable, affiche les statuts des utilisateurs sous forme de cartes dans les flux, les pages de détail et les citations intégrées, avec notamment des emoji personnalisés, une expiration et des aperçus de liens facultatifs. Les zaps accompagnés de commentaires apparaissent désormais comme des réponses sous la publication référencée. La version conserve aussi le bouton facultatif en forme de globe sur le profil, issu de la version 2.34.1, pour les propriétaires qui publient un site racine NIP-5A (manifeste de site web), et corrige la navigation sur la page d’accueil, la recherche de diffusions en direct, la gestion des liens externes et les emoji personnalisés défectueux.

Earthly 0.0.9

Earthly 0.0.9, un éditeur cartographique collaboratif construit sur Nostr, conserve désormais les mentions « J’aime » visibles lorsqu’un panneau d’entité cartographique se ferme, se rouvre ou s’actualise. Son parcours NIP-57 (zaps Lightning) envoie un JSON de demande de zap valide, de sorte que les fournisseurs Lightning puissent publier des reçus vérifiés sur des relays accessibles au public, y compris pendant le développement local. Les factures générées restent visibles lorsque l’interface de l’entité change, et l’application affiche une confirmation après la réception d’un reçu vérifié.

En cours de développement

Keep ajoute la signature NIP-44 v3 limitée par kind et renforce sa politique d’approbation

Keep a fusionné cinq modifications du signataire Android qui acheminent les demandes de chiffrement et de déchiffrement NIP-44 (Charges utiles chiffrées) v3 par les deux transports NIP-55 (Application de signature Android) et son bunker NIP-46 (Nostr Connect). Les PRs #451, #452 et #453 séparent les autorisations v3 des autorisations v2, les limitent par event kind, rejettent les kinds absents ou non valides et préservent les demandes d’approbation ouvertes depuis les notifications. Les PRs #454 et #455 cessent de traiter la politique de signature Basic comme Auto et déplacent la sélection globale dans le stockage chiffré géré par le cœur. Les mainteneurs de Keep ont fusionné ces cinq changements après la dernière version Android étiquetée.

Routstrd modifie son adresse réseau d’écoute par défaut après une exposition sans authentification

La PR #56 de Routstrd remplace l’adresse d’écoute par défaut du routeur d’inférence Nostr local, qui utilisait toutes les interfaces réseau, par 127.0.0.1. L’ancienne valeur par défaut exposait sans authentification le solde et l’historique du portefeuille, ainsi que les points de terminaison d’accès, d’envoi, de remboursement, de clé API, de fournisseur, de client, d’utilisation et d’arrêt du démon à tout hôte capable d’atteindre le port. Les opérateurs peuvent toujours configurer explicitement une adresse non locale, mais la modification fusionnée limite désormais un nouveau déploiement à l’hôte local par défaut et n’est pas encore parue dans une version publiée avec un tag.

Imwald Android clarifie le statut des publications hors ligne

Imwald Android, un client Nostr pour Android, ne considère désormais l’accusé de réception d’un relay local comme une publication terminée que si toutes les cibles configurées sont locales. Son correctif de publication hors ligne et de boîte d’envoi maintient la livraison distante en attente lorsqu’un relay local a accepté l’event mais que les relays distants configurés ne l’ont pas fait, de sorte que le rapport de publication distingue le stockage local sur l’appareil de la livraison aux relays.

FIPS ajoute une couche d’accès OpenWrt ; un portage FreeBSD reste à l’étude

Le Free Internetworking Peering System, natif de Nostr, permet désormais à un routeur OpenWrt d’exposer un réseau d’accès ouvert !FIPS grâce à la PR #126 fusionnée. La PR FreeBSD #129, menée en parallèle et toujours ouverte, propose de porter le démon, le chemin de données TUN, la résolution de noms .fips, la gestion des services et la construction native du paquet. La fusion pour OpenWrt élargit l’accès dès maintenant, tandis que les travaux FreeBSD l’étendraient à un autre système d’exploitation généraliste.

Une mise à jour du projet FIPS datée du 26 juillet faisait état de plus de 300 nœuds sur sa surcouche UDP publique et d’un maillage plus large approchant les 2 000 nœuds. Au cours de la même semaine, le dépôt FIPS a renforcé les tests réseau concurrents, la continuité du renouvellement de clé, le comportement de la limite de sauts, les vérifications du pare-feu et l’isolation du laboratoire NAT. Ces travaux dans le dépôt fournissent aux opérateurs des contrôles reproductibles de ces comportements à mesure que le réseau grandit.

Zap Cooking planifie les publications et lie les demandes du scanner

Zap Cooking, une application Nostr de partage de recettes et de planification des repas, peut désormais conserver une publication programmée dans un stockage chiffré et la publier à l’échéance au moyen d’un balayage périodique des relays (PR #566, PR #569). Les utilisateurs disposent ainsi d’un parcours de publication programmée sans laisser le contenu non signé de la publication exposé dans la base de données du planificateur.

Son scanner de réfrigérateur authentifie désormais le corps exact de la requête au moyen de l’authentification HTTP NIP-98, afin que les contrôles d’adhésion reposent sur la clé qui a signé la demande d’analyse, et non sur une pubkey fournie dans son corps (PR #599).

Citrine transforme un appareil Android en relay administrable

Citrine, un relay Nostr hébergé sur Android, peut désormais envoyer les events qu’il a stockés vers des relays externes, ce qui permet à un opérateur de rediffuser l’historique local (PR #179). Il ajoute également des commandes NIP-86 (API de gestion des relays) afin que les clients compatibles puissent administrer le relay (PR #150).

Les opérateurs de groupes peuvent administrer les groupes fondés sur les relays NIP-29 en signant avec Amber dans la PR #178, tandis que la PR #174 maintient la configuration des relays utilisant Tor et leur état de cycle de vie cohérents au fil des redémarrages.

Wired récupère des conversations complètes dans le navigateur

Wired, un client Nostr exécuté dans le navigateur, suit désormais les racines des flux, les réponses et les events référencés jusqu’au bout, sans s’arrêter à des limites fixes d’étendue ou de nombre de résultats (PR #148, PR #147, PR #146). Les utilisateurs peuvent ainsi récupérer des fils plus profonds et le contexte des flux lorsque les events correspondants sont disponibles sur leurs relays.

Le navigateur préserve également les indications de relay des events référencés et ne les utilise que pour le contexte encore manquant, ce qui rétablit les conversations absentes des relays configurés (PR #145, PR #144). Une récupération incomplète reste distincte d’un instantané achevé, afin qu’une réponse partielle n’écrase pas la vue antérieure mise en cache.

Travaux sur les protocoles et les spécifications

NIPs : limites de l’hébergement NIP-34, migration des groupes et trois brouillons actifs

Deux modifications de spécifications ont été fusionnées cette semaine. Le commit NIP-34 6d2979b retire les instructions d’hébergement GRASP de la description de l’event de pull request kind:1618, plaçant l’hébergement et le comportement de secours hors du contrat de l’event. Le commit NIP-29 db5fe3d définit la migration des métadonnées d’un groupe de relay vers un autre relay et la manière dont les clients distinguent un déplacement valide d’un fork qui poursuit son activité indépendamment.

La PR #2424 propose des déclarations réciproques d’ensembles de clés de kind:10045. Cette exigence de réciprocité empêcherait le détenteur d’une identité d’y associer unilatéralement une autre clé. La PR #2421 propose des intentions de zap BOLT12 et des preuves du payeur que les clients pourraient valider à partir de la cible, du montant, de l’offre et du paiement réglé, sans dépendre d’un serveur de reçus exploité par le destinataire.

La PR #2425 permettrait aux signets NIP-B0 de conserver les schémas autres que HTTP, comme nostr:, aux côtés des URL web. Les identifiants Nostr natifs, les demandes de paiement et d’autres schémas d’application resteraient ainsi intacts dans les mêmes listes de signets, privées ou publiques, qui contiennent déjà des adresses web.

Mill implémente un brouillon de sauvegarde de clé par compte cloud

Mill a annoncé l’implémentation d’un brouillon de sauvegarde de clé par compte cloud, qui associe l’identifiant d’un compte Google OIDC à une phrase secrète à forte entropie afin de dériver une clé de sauvegarde jetable. Son implémentation de référence chiffre la véritable clé de l’utilisateur sous forme de ncryptsec NIP-49 (Chiffrement de clé privée), puis la stocke dans un event provisoire de kind 30049, remplaçable et paramétré, sur les relays configurés. Le projet a fusionné le parcours de sauvegarde dans la branche main, mais aucune version ultérieure à v1.0.0 ne l’inclut, et le parcours de sauvegarde reste désactivé tant qu’un opérateur ne fournit pas de backupRelays dédiés. Une liste versionnée de relays reste provisoire, et le brouillon avertit que le texte chiffré publié demeure disponible pour tenter de deviner la phrase secrète hors ligne. Les lecteurs doivent considérer cette conception comme une expérimentation implémentée qui dépend d’une phrase secrète à forte entropie.

BUDs : les serveurs Blossom peuvent identifier les téléversements inconnus à partir de leurs octets

La PR BUD-02 #110 propose de recommander la détection du type MIME côté serveur lorsque le client omet Content-Type pendant le téléversement ou envoie application/octet-stream. Un serveur Blossom examinerait les premiers octets avec une bibliothèque maintenue de détection des types de fichiers, préserverait un type précis fourni par le client et reviendrait au type binaire générique en cas d’échec de la détection. Les images, le son, la vidéo et les fichiers produits par des agents resteraient ainsi affichables sans rendre l’inspection des octets obligatoire pour chaque téléversement.

NAPs : les conventions remplacent les séries numérotées pendant le développement des contrats de capture et de système de fichiers

La PR #87 retire la série numérotée de protocoles entre napplets et conserve les fonctionnalités d’exécution sous des contrats nommés, tandis que les messages d’application convergent vers des URI de convention napplet:<archetype>/<intent>. La modification fusionnée de l’identité des sujets sépare un chemin de convention stable et sans requête des données de charge utile propres à chaque message, et la PR #90 applique cette règle de transposition aux métadonnées de découverte et de gestionnaire.

Deux brouillons NAP étendent le périmètre de confiance de l’environnement hôte. La PR NAP-CAPTURE #94 maintient dans l’environnement d’exécution le consentement au microphone, l’autorisation de la plateforme, les limites, la conservation et la libération des ressources, tout en renvoyant à une napplet isolée un artefact multimédia soumis à des limites. La PR NAP-FS #88 constitue la proposition parallèle de système de fichiers virtuel, avec des handles soumis à une politique au lieu de chemins hôtes sans restriction.

Marmot : la spécification définit un état terminal pour les groupes

La PR Marmot #409 ajoute un état Disbanded authentifié et irréversible, car MLS ne possède aucune opération de suppression de groupe. Un commit d’administration autorisé fait sortir un groupe de l’état Active, empêche d’anciennes branches, des messages et des Welcomes de le réactiver, et fournit aux groupes existants un parcours explicite de compatibilité avant leur dissolution. Le passage en revue des issues de la spécification, qui précède cette PR, harmonise également l’autorité sur l’état des groupes, la convergence, les paquets de clés, les accusés de réception, les règles relatives aux médias, le vocabulaire du registre et 200 issues de spécification suivies.

Gamma Markets : aucune modification publique de la spécification n’a été intégrée

Le dépôt de spécification de Gamma Markets n’a enregistré aucun commit public ni aucune activité de pull request du 21 au 28 juillet. Ses documents publiés sur les ordres, le règlement et les données de marché restent la référence actuelle ; cette entrée sans changement maintient Gamma dans le suivi hebdomadaire des spécifications.

Concord : les capacités de lecture et d’écriture pourraient être séparées dans un même plan

La PR Concord #12 reste un brouillon ouvert pour les plans dans lesquels certains lecteurs ne devraient pas avoir le droit d’écrire. Elle oriente le Control Plane vers des capacités distinctes de flux en lecture et en écriture, et esquisse des canaux à écriture restreinte, des invitations et des périmètres de renouvellement de clé. La clé d’écriture constitue une barrière contre le spam dans le brouillon, tandis que les acteurs internes signés et les contrôles de la liste des membres continuent de porter l’autorité.

NWC : une méthode de portefeuille peut choisir entre BOLT11 et BOLT12

La PR NWC #2 propose des méthodes facultatives pay et receive pour les URI de paiement BIP-321. Un service de portefeuille peut annoncer leur prise en charge, choisir dans un URI une facture BOLT11 ou une offre BOLT12 compatible, refuser avant le paiement un réseau Bitcoin incompatible et indiquer le type d’instruction utilisé. La proposition reste en dehors du cœur de NWC, afin que les portefeuilles qui ne prennent pas en charge BIP-321 ou BOLT12 n’aient pas à l’implémenter.

Six mois de juillet dans l’histoire de Nostr

Ce parcours historique des mois de juillet suit des problèmes récurrents de Nostr : des identifiants lisibles, le filtrage par les relays, des données d’application portables, la confidentialité et l’interopérabilité. Sur six ans, chaque couche transforme une correction ponctuelle en infrastructure partagée : les noms deviennent des profils, les filtres des contrats d’application et l’état acheminé par les relays s’étend des notes aux salons en direct et aux groupes. Il commence par la première implémentation de NIP-05 et s’achève avec la fusion de la découverte adressable de ce mois, puis examine les changements de juillet qui ont fait évoluer ces problématiques.

Juillet 2021

Le 19 juillet 2021, le commit nostr-tools 1ce00bd a ajouté un module nip05.js et fait passer le paquet à la version 0.5.0. Sa fonction keyFromDomain construisait une requête DNS TXT pour _nostrkey.<domain>, envoyait la requête binaire à l’un des huit fournisseurs DNS-over-HTTPS choisis par rotation et renvoyait la première clé de la réponse. Un client dans le navigateur pouvait ainsi convertir un domaine contrôlé par une personne en clé publique sans exploiter de résolveur DNS ni dépendre d’un unique fournisseur codé en dur.

Cette première approche permettait de trouver une clé à partir d’un domaine, mais pas de rechercher différents noms au sein d’un même domaine, et sa limite de confiance se situait dans le DNS et le résolveur sélectionné. La spécification NIP-05 moderne a déplacé la découverte vers /.well-known/nostr.json, où un domaine associe des noms locaux à des pubkeys et peut joindre des indications de relay. Le code de 2021 consigne la contrainte de conception antérieure : les clés publiques étaient portables, mais il fallait encore des identifiants que les personnes puissent lire, vérifier et transférer entre les clients.

Juillet 2022

Le 10 juillet, le commit NIP-12 3771186 a limité les requêtes génériques adressées aux relays aux tags composés d’une seule lettre. Cette décision a rendu les filtres tels que #r, #g et #t utiles pour les références d’URL, les geohashes et les hashtags sans demander aux relays d’indexer chaque clé arbitraire de métadonnées. Dix jours plus tard, le premier brouillon de commentaires web NIP-20 a directement utilisé ce modèle de requête : un commentaire de kind 34 contenait l’URL normalisée d’une page web dans un tag r, ce qui permettait à un site et à des clients indépendants de récupérer la même discussion depuis les relays.

La politique des relays et les retours sociaux ont suivi. Le commit NIP-22 d’origine permettait aux relays de rejeter les events dont l’horodatage created_at était invraisemblablement ancien, et le commit 8bef0e9 a ajouté les horodatages futurs à la même politique. Le 30 juillet, le commit NIP-25 dcbd504 a défini les réactions de kind 7 avec des tags cibles e et p ; le commit suivant a attribué - à une réaction négative, et le commit 6903ff5 a fait de + la mention « J’aime » générique explicite. Ensemble, ces commits ont spécifié le rejet des horodatages par les relays, la récupération fondée sur les tags, les commentaires web et les tags de réaction pour les clients qui ont adopté ces brouillons.

Juillet 2023

En juillet 2023, la coordination a dépassé le cadre des notes courtes. Le brouillon NIP-37 sur les clés perdues explorait le retrait irréversible des clés, les seuils de récupération sociale et les clés de remplacement faisant l’objet d’un engagement préalable, tout en refusant explicitement de qualifier le résultat de rotation universelle des clés. Cinq jours plus tard, NIP-53 a introduit les activités en direct adressables de kind 30311 et les messages de discussion de kind 1311, en fournissant aux flux, aux scènes et aux salons en direct un modèle d’event partagé pour les hôtes, les participants, le statut et la conversation.

Les applications ont également commencé à annoncer des travaux et des échanges commerciaux. Le premier brouillon Data Vending Machine décrivait des demandes de travaux de kind 68001, des résultats de kind 68002, des offres, des expirations, un chaînage et des fournisseurs concurrents pour des tâches telles que la transcription, le résumé et la traduction. Le 13 juillet, le brouillon de petites annonces a ajouté des offres adressables de kind 30402 accompagnées de métadonnées de titre, de résumé, de prix, de lieu et de statut. Ces brouillons sont ensuite devenus NIP-90 et NIP-99, mais leurs formes de juillet séparaient déjà une demande ou une annonce du serveur qui l’affichait.

Le routage des paiements est aussi devenu composable. La fusion NIP-57 du partage des zaps du 31 juillet a transformé une destination unique de zap en une liste pondérée de pubkeys de destinataires et d’indications de relay. Un client pouvait répartir un zap entre des collaborateurs, omettre les destinataires sans pondération lorsque certains poids étaient présents et afficher la répartition avant le paiement. Cette modification a normalisé une représentation par event signé des destinataires pondérés d’un zap et des indications de relay, ce qui permettait aux clients compatibles de présenter la répartition avant le paiement.

Juillet 2024

Le 4 juillet, le commit NIP-29 c60ca88 a ajouté l’action de modération de relay kind:9007 pour créer un groupe. Six jours plus tard, NIP-70 a défini les events protégés : un tag - indique à un relay de n’accepter la publication que de l’auteur authentifié de l’event. Une modification a donné aux relays une transition explicite de l’état des groupes ; l’autre a permis aux auteurs d’empêcher des tiers de rejouer sur des relays des events signés par ailleurs valides.

Le 16 juillet, un commit de la spécification Cashu a introduit à la fois les portefeuilles NIP-60 et les nutzaps NIP-61. NIP-60 plaçait les métadonnées du portefeuille dans le kind 37375, les preuves non dépensées dans des events chiffrés de kind 7375 et l’historique facultatif des transactions dans le kind 7376. NIP-61 associait les préférences de mint et de relay du destinataire, publiées dans le kind 10019, à des nutzaps de kind 7337 verrouillés par P2PK. L’état du portefeuille et les jetons au porteur pouvaient désormais transiter par les relays, tandis que l’encaissement dépendait encore des preuves de mint Cashu et d’une prévention soigneuse des doubles encaissements.

Deux modifications de fin juillet ont renforcé le caractère déterministe de l’état. Le commit NIP-01 9c54549 imposait les identifiants d’event pour départager les horodatages created_at identiques, afin que les clients puissent trier de la même manière des ensembles de résultats identiques. La fusion NIP-09 sur la suppression précisait que les demandes de kind 5 pouvaient cibler des identifiants d’event ou des coordonnées adressables et devraient inclure des tags k identifiant les kinds à supprimer par les relays. Les deux changements ont réduit les cas où deux implémentations correctes pouvaient ne pas s’accorder.

Juillet 2025

La découverte d’ecash a obtenu son propre répertoire social le 16 juillet. Le commit NIP-87 1afb6da a défini les enregistrements de mints Cashu de kind 38172, les enregistrements Fedimint de kind 38173 et les recommandations de kind 38000, qui peuvent pointer vers ces enregistrements avec des indications de relay. Les portefeuilles pouvaient interroger les recommandations d’auteurs de confiance avant de se connecter à un mint, tandis que la spécification avertissait qu’une découverte globale sans filtrage pouvait orienter les utilisateurs vers des opérateurs malveillants.

Une semaine plus tard, un brouillon a spécifié des enregistrements portables d’events Nostr pour les messages vocaux. Le premier commit NIP-A0 a attribué le kind 1222 à la racine d’un message vocal et le kind 1244 à une réponse, avec une URL audio et des métadonnées multimédias. Le suivi du format du 27 juillet recommandait Opus dans un conteneur Ogg et normalisait une forme d’onde compressée. Les clients pouvaient échanger de courts enregistrements audio sans s’accorder sur un enregistreur, un hébergeur ni une représentation de la forme d’onde.

La messagerie privée et les connexions aux portefeuilles ont ensuite ajouté un état de protocole pour le suivi de lecture, le choix du chiffrement et la progression des paiements. Le commit NIP-17 3d76da3 a défini un enregistrement remplaçable de kind 30016 dont les tags seen ordonnés permettent à un client de distinguer les messages lus des lacunes correspondant à des messages qu’il a pu manquer. Le 31 juillet, la négociation du chiffrement NIP-47 a permis aux services de portefeuille d’annoncer NIP-44 v2 ou l’ancien NIP-04, tandis que le commit sur l’état des transactions a ajouté les états pending, settled, accepted, expired et failed. La livraison, le chiffrement et la progression des paiements sont devenus des données explicites du protocole au lieu d’être déduits localement.

Juillet 2026

Ce mois de juillet a commencé par relier les adresses web ordinaires aux requêtes destinées aux relays. Le commit de découverte adressable 2f4b093 définit une recherche /.well-known/nostr.json?ad=<path> dont la réponse contient un filtre Nostr et une liste de relays. Un navigateur classique peut toujours ouvrir l’URL d’origine sous forme de HTML, tandis qu’un client Nostr peut interroger le point de terminaison /.well-known/nostr.json?ad=<path> correspondant pour obtenir un filtre et une liste de relays qui associent l’adresse à un groupe, un nsite, un flux, un event ou un autre objet natif. Ce modèle reprend à un niveau plus large le problème de l’association d’un domaine à une clé apparu en 2021 : une URL lisible par une personne peut désormais nommer à la fois une identité et une requête.

NIP-29 a ensuite fait évoluer les groupes de relay sans hiérarchie vers des espaces structurés. Le commit sur les sous-groupes du 16 juillet a ajouté des relations de parent et d’enfants ordonnés ; les commits adjacents ont ajouté des suffixes de codes d’invitation, des bannières, des instantanés ordonnés d’éléments épinglés et l’épinglage d’events adressables. Le 22 juillet, la précision sur les migrations et les forks a défini les conditions dans lesquelles les métadonnées déplacent légitimement un groupe vers un autre relay et celles dans lesquelles une branche toujours active constitue un fork indépendant. L’identifiant du groupe est resté simple, tandis que la hiérarchie, la présentation et les changements de relay sont devenus un état explicite.

Deux modifications plus modestes ont précisé les limites de l’implémentation. Le commit NIP-46 f0af204 exige qu’un signataire distant renvoie une erreur pour les méthodes inconnues ou non prises en charge, au lieu de laisser silencieusement le client atteindre son délai d’expiration. Le commit NIP-34 6d2979b retire de la description de l’event de pull request les instructions d’hébergement propres à GRASP. L’un fournit une réponse définitive aux appelants ; l’autre empêche un event git portable d’hériter tacitement d’un protocole de serveur particulier.

Envoyez un DM NIP-17 au projet Nostr Compass pour nous signaler un projet ou une actualité.