Nostr Compass #32 | Nostr Compass

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

Cette semaine : IndieSats abandonne la garde des clés, sa liste blanche et sa commission obligatoire sur les revenus, et se relance comme un relay ouvert, un lecteur et une couche de découverte où les artistes publient sous leurs propres clés. Nostrord v2.3.0 livre la modération de groupe, les listes de sourdine et les relays onion la même semaine où cinq PR de spécification NIP-29 sont fusionnées. Zapstore 1.1.0 introduit une clé d’appareil portable chiffrée avec sauvegarde Amber et des mises à jour automatiques en arrière-plan optionnelles. Le kind de liste des ensembles de suivi favoris est fusionné puis fait l’objet d’une PR de renumérotation en quelques jours. Et les projets Iris livrent nostr-pubsub, le runtime navigateur fips-ts et nostr-social-graph 2.0.0 en une seule semaine.

Les versions taguées apportent Amber v6.3.0 avec des approbations groupées de signature bunker, Armada v0.37.0 avec un second client pour les espaces de travail Buzz, Divine Mobile 1.0.17 avec une livraison NIP-17 durable et une validation TLS stricte, et nak v0.20.2 avec des commandes pour les pull requests NIP-34.

Du côté des changements non publiés, Snort enregistre la couverture du cache prouvée par EOSE, Shopstr comble deux failles d’intégrité des paiements, Mostr relie les conversations privées ActivityPub aux DM Nostr, nostream fusionne la pile de contrôle d’accès couverte par l’analyse approfondie de cette semaine, et Amethyst atteint 88 PR fusionnées avec des sondages NIP-88 complets sur Desktop.

Le dépôt NIPs fusionne cinq PRs cette semaine, dont le bloc NIP-29 et les ensembles de suivi favoris kind:10011, et ouvre des débats sur la simplification de NIP-47 et les affirmations de confiance des relays. L’analyse approfondie couvre NIP-42 et NIP-43, la paire de contrôle d’accès des relays.

Articles principaux

IndieSats abandonne son rôle d’éditeur et se relance comme infrastructure musicale Nostr ouverte

IndieSats est une plateforme musicale basée sur Nostr qui agissait jusqu’à cette semaine comme éditeur : elle détenait les clés des artistes, gérait une liste blanche et prélevait une commission obligatoire de 2 % sur les revenus. Dans une annonce de pivot publiée le 20 juillet, le projet a abandonné ces trois rôles d’un coup. La plateforme relancée se compose de trois éléments d’infrastructure ouverte : un relay ouvert, un lecteur et une couche de découverte. Les artistes publient désormais leur musique sous leurs propres profils Nostr. La part de 2 % prélevée par la plateforme sur chaque piste est facultative, mais sélectionnée par défaut lors de la publication ; les artistes peuvent la désactiver pour conserver l’intégralité du paiement. La plateforme respecte aussi les demandes de suppression kind:5 de NIP-09 afin que les artistes puissent retirer leurs œuvres. Une mise à jour v1.1.5 publiée le 21 juillet a adapté la publication des pistes au format d’event attendu par Amethyst et d’autres clients musicaux Nostr, et a rendu explicite la livraison aux relays. Pour un secteur qui parle habituellement de protocoles remplaçant les plateformes, c’est un cas réel d’une plateforme qui se démantèle volontairement en éléments de protocole.

Nostrord v2.3.0 livre la modération de groupe, les listes de sourdine et les relays onion

Nostrord, le client de chat de groupe pour Android, iOS, web et bureau, a livré v2.3.0 avec des actions de modération de groupe branchées sur toutes les interfaces (PR #192), des invitations de groupe soumises à consentement avec détection inter-relays (PR #195), des listes de sourdine NIP-51 multiplateformes (PR #188), et le support des relays .onion via Tor. La version arrive la même semaine où la spécification NIP-29 sous-jacente a fusionné cinq PRs couvrant les sous-groupes, l’épinglage de messages, les bannières et les codes d’invitation (détails dans la section protocole de cette semaine), de sorte que le chat de groupe sur Nostr dispose désormais à la fois d’une spécification plus riche et d’un client qui en exerce la majeure partie, ce qui raccourcit la boucle de rétroaction pour tous ceux qui construisent sur les groupes de relays.

Zapstore 1.1.0 rend la clé d’appareil portable et ajoute les mises à jour automatiques en arrière-plan

Zapstore est une boutique d’applications native Nostr où les versions sont signées par les clés des développeurs et où aucun opérateur central ne se porte garant d’elles. La version 1.1.0, la première version couverte ici depuis début mars, comble les deux plus grandes lacunes par rapport aux boutiques d’applications conventionnelles. La première concerne les mises à jour : des mises à jour automatiques en arrière-plan optionnelles téléchargent désormais via Wi-Fi et s’installent silencieusement ou par étapes, de sorte que les applications restent à jour sans passages manuels par la boutique. La seconde concerne la continuité d’identité : la clé d’appareil devient portable, chiffrée et sauvegardable via Amber par NIP-55, l’interface de signeur Android, de sorte qu’un utilisateur qui change de téléphone ne repart plus comme un appareil inconnu. La version déplace aussi le catalogue d’applications sur les relays sous forme d’events kind:10067 signés par l’appareil, ajoute les signalements vérifiés NIP-56 depuis le menu déroulant pour que les utilisateurs puissent signaler les applications problématiques d’une manière exploitable par d’autres clients, et vérifie la preuve C1 attachée à une version avant toute installation, resserrant le lien entre ce qu’un développeur a signé et ce qu’un appareil exécute.

Le kind de liste des ensembles de suivi favoris est fusionné et déménage immédiatement

Une histoire de coordination de spécification s’est jouée en une seule semaine. La PR #2413 a été fusionnée le 15 juillet, standardisant sous NIP-51 (listes) un kind de liste remplaçable pour les ensembles de suivi favoris : un kind dédié aux ensembles organisés de comptes suivis d’un utilisateur. En quelques jours, il s’est avéré que le kind:10011 attribué était déjà utilisé ailleurs, si bien qu’une PR #2417 de suivi est désormais ouverte pour renuméroter la liste en kind:10021. Rien n’a encore été livré pour le kind fusionné, ce qui fait de maintenant le moment le moins coûteux pour le renuméroter ; une fois que les clients commenceront à publier des events kind:10011, la collision deviendrait coûteuse à défaire. Les développeurs qui construisent des fonctionnalités consommant des listes devraient suivre la PR de renumérotation, et non le texte fusionné, jusqu’à sa résolution.

Trois versions de l’orbite Iris ont atterri ensemble, et elles s’emboîtent. nostr-pubsub est une bibliothèque de publication/abonnement neutre en transport pour les events Nostr ; ses premières versions suivies, v0.1.3 à v0.5.2, livrent un transport de relay navigateur construit sur le SimplePool de nostr-tools, la vérification des events à la frontière du transport pour que les signatures invalides n’atteignent jamais les abonnés, et des requêtes historiques bornées. fips-ts amène FIPS, le transport pair-à-pair Noise-sur-secp256k1 auparavant disponible comme pile Rust, dans le navigateur comme runtime TypeScript : les versions 0.0.24 à 0.0.30 ont ajouté un transport par canal de données WebRTC, la signalisation basée sur Nostr pour la découverte de pairs, un cache de pairs récents et un adaptateur IndexedDB pour le stockage navigateur, et le runtime est compatible au niveau du fil avec l’implémentation Rust de référence. La troisième pièce, nostr-social-graph v2.0.0, est une version majeure de la bibliothèque de graphe social : opérations de roster signées pour les graphes d’identité Nostr, flux d’approbation d’appareils amorcés depuis un URI canonique à trois champs, et facettes d’identité de transport FIPS avec des vecteurs de test Rust et TypeScript partagés. Le cadre qui relie le tout est la Iris Stack, le laboratoire d’intégration du projet qui relie ces bibliothèques avec Blossom, Hashtree et la messagerie chiffrée. Prises ensemble, une application web peut désormais découvrir des pairs via Nostr, ouvrir un canal FIPS chiffré vers eux et maintenir un graphe social signé, le tout en TypeScript.

Versions taguées

Amber v6.3.0 regroupe les approbations de signature bunker et ajoute le support Expert List

Amber est un signeur distant NIP-46 pour Android. v6.3.0 ajoute l’approbation groupée multi-requêtes pour la signature bunker, de sorte qu’un lot de demandes de signature en attente peut être examiné et approuvé ensemble au lieu d’une invite à la fois. La version ajoute aussi le support des events Expert List (kind 12022) et Expert Pack (kind 32022), un mode confidentialité qui masque le contenu sensible à l’écran, et un changement pour récupérer la liste de relays NIP-65 d’un compte avant ses métadonnées de profil afin que les flux de signature partent de l’ensemble de relays réel de l’utilisateur. Cela fait suite à la lignée v6.2.x couverte dans le numéro du 2026-07-08.

Suivi de Nostrord v2.2.0

Avec v2.3.0 en tête de la section Actualités de cette semaine, la case des versions taguées note seulement ce que l’article principal ne dit pas : v2.3.0 fait suite aux contrôles de DM de v2.2.0 couverts dans le #31, ce qui en fait la deuxième version hebdomadaire consécutive du client.

Armada v0.37.0 ouvre les espaces de travail Buzz depuis un second client

Armada, un client Nostr de type Discord, a publié v0.37.0 avec la prise en charge des relays Buzz comme mode d’espace de travail NIP-29 enrichi, détecté grâce aux métadonnées NIP-11 du relay. Le client affiche les publications et commentaires des forums Buzz sous les kinds 45001 et 45003, intègre les modifications et suppressions aux flux chronologiques, et ajoute des interfaces pour la présence, les workflows, les tâches, les réunions et les canevas partagés. Son espace de travail Projects lit directement depuis le relay les annonces de dépôts, patches, pull requests, issues et events de statut NIP-34 (commit d’implémentation), offrant aux espaces de travail Buzz un second client pour les conversations comme pour le travail sur les dépôts.

Wisp v1.2.0 ajoute un sélecteur multi-compte et des fils de réponses repliables

Wisp est un client Nostr axé sur la confidentialité avec un support de portefeuille intégré. v1.2.0 ajoute un sélecteur multi-compte pour passer d’un profil à l’autre sans reconnexion, des fils de réponses repliables pour les longues conversations, la suppression des paramètres de suivi des liens de notes avant leur ouverture, et une vue de l’historique des transactions du portefeuille. La version fait suite à la mise à jour Wisp couverte dans le numéro du 2026-07-08.

Divine Mobile 1.0.17 renforce la sécurité des relays et la livraison des DM

Divine Mobile, un client Nostr de vidéos courtes, a publié la version 1.0.17 avec un éditeur stop-motion persistant et des parcours Nostr renforcés. Les messages directs attendent désormais les réponses OK des relays, réessaient via une file durable et passent par les listes kind 10050 de relays de réception des destinataires (PR #6046) ; l’appairage NIP-46 conserve les défis auth_url comme étapes récupérables du signeur (PR #6151). La PR #6278 supprime l’acceptation permissive des certificats pour les WebSockets de relays en production et les requêtes HTTP utilisées pour les téléversements NIP-96, LNURL et les zaps, rétablissant la validation TLS de la plateforme hors des connexions de bouclage en mode débogage. Les téléversements interrompus peuvent aussi reprendre au dernier décalage confirmé par le serveur, de sorte qu’une publication passée en arrière-plan ne redémarre plus de zéro.

ClipRelay v0.1.2 (nouveau projet) synchronise les presse-papiers entre appareils via les relays Nostr

ClipRelay est une application multiplateforme nouvellement lancée (Android, macOS, Windows, Linux) qui synchronise votre presse-papiers entre vos propres appareils : copiez sur une machine, collez sur une autre. Tout le trafic passe par les relays Nostr sous forme d’events chiffrés NIP-44 adressés à vous-même, il n’y a donc aucun serveur à faire tourner et aucun compte à créer ; la clé privée reste en dehors de l’application. v0.1.2 corrige une panne de synchronisation subtile où une machine sortant de veille continuait à publier mais cessait silencieusement de recevoir, et resserre les indicateurs d’état des relays qui signalaient auparavant des abonnements morts comme sains. C’est la première apparition de ClipRelay dans la lettre.

Sonar v0.1-alpha.11 poursuit la lignée alpha

Sonar, l’article principal de la semaine dernière, a publié v0.1-alpha.11 avec du travail sur le moteur de liaison mesh Rust, des corrections BLE et mesh, et des diagnostics de relay ; un suivi incrémental de la lignée alpha couverte dans le #31.

nak v0.20.2 ajoute des workflows de pull requests NIP-34

nak, l’outil Nostr en ligne de commande, a publié v0.20.2 avec des commandes permettant de créer, récupérer et fusionner des pull requests NIP-34, ainsi que de récupérer des patches individuels ; l’outil autorise aussi les pushs sans réécrire l’annonce du dépôt. La plage de 11 commits de cette version ajoute également la gestion des groupes parents pour NIP-29, interroge davantage de relays de boîte d’envoi, rend configurables les délais de connexion aux relays et corrige la sélection du bunker lorsque seule la valeur --sec par défaut existe.

Les petits lancements de la semaine

Quatre versions plus modestes méritent une ligne chacune : noscall v0.6.0, l’application d’appels Nostr, a migré ses notifications push vers UnifiedPush, maintenant la signalisation des appels hors de l’infrastructure push de Google ; nostr-vpn v4.1.3, un VPN mesh qui utilise Nostr pour la signalisation, a unifié sa politique DNS de sortie entre les plateformes et restaure désormais la route et l’état DNS d’origine après les sessions WireGuard ou de sortie privée ; StableKraft v1.3.0, l’agrégateur de musique et de podcasts Nostr-plus-Lightning couvert en avril, a ajouté des commandes Android natives sur l’écran verrouillé et les casques, ainsi qu’un verrou de réveil limité à la lecture pour que l’audio survive à Doze ; et la nouvelle application Zapstore Hakari sauvegarde un journal de poids au moyen d’events Nostr chiffrés.

Amethyst livre l’AQ pré-version v1.13.0 sur l’isolation des napplets et l’autorité Concord

Amethyst a fusionné 88 PR cette semaine en vue de sa version v1.13.0. La PR #3650 est une passe d’assurance qualité pré-version couvrant l’isolation des comptes de napplets, les corrections d’autorité Concord et une trentaine d’autres correctifs. Les travaux de fin de période ajoutent sur Desktop l’affichage, la création et le vote de sondages NIP-88 complets, le décompte par relays déclarés et la recherche kind 1068 (PR #3664) ; la recherche NIP-50 classe désormais les résultats selon leur pertinence BM25, tandis que les observateurs de tags volumineux utilisent une fusion bornée (PR #3663). Une passe distincte sur le stockage des relays sélectionne les index de requête selon leur coût mesuré, ajoute des index tag-auteur-kind et ne sérialise chaque event actif qu’une seule fois par diffusion (PR #3660), avec des réductions de benchmark annoncées de 149 à 4 millisecondes pour une forme de requête et de 14,2 à 0,66 milliseconde pour une requête courante de salon DM.

Changements non publiés

Snort réécrit la synchronisation des requêtes autour d’une couverture prouvée par EOSE

Snort, un client web Nostr, a réécrit son parcours de requêtes et de synchronisation du cache dans le commit 8a62770. Le client enregistre désormais les fenêtres de requête qui ont atteint EOSE, utilise ces repères pour ignorer les plages de cache déjà couvertes, centralise la distribution des events derrière un seul écouteur du pool de relays et n’envoie les filtres de recherche qu’aux relays dont les documents NIP-11 annoncent NIP-50. Des correctifs ultérieurs sérialisent les mises à jour simultanées des repères et corrigent les limites inclusives des flux chronologiques, tandis que le commit 9d1721b rétablit un abonnement actif au flux de suivis segmenté, afin que les events arrivant après le chargement de la page ne restent pas figés hors de ses fenêtres mises en cache.

Shopstr lie la validation des paiements aux reçus signés et aux prix calculés côté serveur

Shopstr, un client de place de marché Nostr, a comblé deux failles d’intégrité des paiements. La PR #552 oblige Zapsnag à vérifier, pour chaque reçu kind 9735, la signature, le signeur, la demande de zap intégrée, les tags du destinataire et du produit, le montant BOLT11 et l’éventuelle préimage par rapport au hash de paiement de la facture avant de le considérer comme un achat. La PR #449 place la création des devis Cashu derrière une route de l’API Shopstr qui retrouve l’annonce et recalcule son prix côté serveur, de sorte qu’un montant modifié dans le navigateur ne puisse pas déterminer la facture du mint.

Mostr relie les conversations privées ActivityPub et les DM Nostr

Mostr, un pont entre ActivityPub et Nostr, transporte désormais dans les deux sens les objets ChatMessage individuels de Pleroma et les DM Nostr chiffrés (commit 36ee547). Les conversations privées ActivityPub deviennent des events kind 4 adressés au destinataire Nostr, tandis que les messages kind 4 envoyés à des utilisateurs Fediverse reliés sont déchiffrés et fédérés comme objets ChatMessage. Le pont limite ces events aux relays de DM configurés et protégés par NIP-42, et s’authentifie avec une clé de relay distincte. Ce parcours d’interopérabilité utilise le chiffrement historique NIP-04. L’encapsulation en gift wrap de NIP-17 reste en dehors de cette implémentation.

nostream fusionne huit PR sans publier de version

nostream, l’implémentation de relay TypeScript, a fusionné huit PR cette semaine sans publier de version. Le duo principal est formé par la PR #702 et la PR #676, qui offrent ensemble aux opérateurs de relays une pile fonctionnelle de contrôle d’accès combinant authentification et appartenance ; l’analyse approfondie NIP de cette semaine détaille précisément cette poignée de main. La PR #694 corrige les filtres génériques de tags #e, #p, #g et similaires, qui pouvaient renvoyer un exemplaire d’un event pour chaque ligne de tag correspondante, réduisant ainsi le trafic protocolaire en double au sein d’un abonnement.

FIPS v0.4.1 resserre la couche de transport Iris

jmcorgan/fips a publié v0.4.1, une version de maintenance qui borne l’état antipoison, corrige la convergence et la gestion de la MTU, et réduit l’utilisation du processeur. Le runtime TypeScript pour navigateur fips-ts, issu du groupe de projets Iris, est compatible sur le fil avec ce transport Rust ; les correctifs apportés ici se répercutent donc directement sur l’interopérabilité dans le navigateur.

Travaux de protocole et mises à jour NIP

Changements récents dans le dépôt NIPs :

Fusionnées :

NIP-29 (Groupes basés sur relay) : Sous-groupes (PR #2319, fusionnée le 2026-07-16) : NIP-29 définit des groupes hébergés par relay où l’appartenance, les rôles et l’historique du chat vivent sur un seul relay sous forme d’events adressables de la série kind:39000, avec des actions de modération portées par des events d’administration de la série kind:9000. Cette PR permet à un groupe de se déclarer sous-groupe en ajoutant un tag parent à ses métadonnées, pointant vers l’identifiant d d’un autre groupe sur le même relay. Les sous-groupes sont des groupes ordinaires à tous autres égards : l’appartenance ne se propage pas (rejoindre un parent ne confère l’appartenance à aucun enfant), les rôles d’administration ne s’héritent pas (la liste d’administrateurs kind:39001 de chaque sous-groupe fait autorité pour sa propre portée), et chaque sous-groupe garde ses propres events de membres kind:9000/kind:9001 indépendants. Les relays qui supportent la hiérarchie l’annoncent dans leur document d’information relay NIP-11 sous un objet nip29 avec "subgroups": true, afin que les clients puissent découvrir la capacité avant de tenter de créer des communautés imbriquées.
NIP-29 : Épinglage de messages (PR #2379, fusionnée le 2026-07-15 ; PR #2416, fusionnée le 2026-07-17) : les administrateurs de groupe peuvent désormais épingler des messages dans un groupe basé sur relay. Le mécanisme ajoute un nouvel event de modération, kind:9010 update-pin-list, qui porte la liste ordonnée complète des épinglés comme tags e référençant des identifiants d’events ordinaires, et un nouvel event optionnel au niveau du groupe, kind:39005 group pinned events, que le relay régénère pour refléter la liste d’épinglés acceptée la plus récente. Parce que chaque kind:9010 remplace toute la liste au lieu de basculer des entrées individuelles, épingler, désépingler, réordonner et vider les épinglés s’expriment tous en soumettant une nouvelle liste. La PR de suivi #2416 étend le format pour que les tags a soient également acceptés dans la liste d’épinglés, permettant aux administrateurs d’épingler des events adressables (articles longs, pages wiki et autres contenus remplaçables paramétrés) aux côtés des messages de chat ordinaires. Les relays peuvent plafonner le nombre d’épinglés, et le texte de spécification fusionné recommande d’afficher les épinglés dans l’ordre où les tags apparaissent.
NIP-29 : Tag banner et suffixe de code d’invitation (PR #2383, fusionnée le 2026-07-16 ; PR #2380, fusionnée le 2026-07-16) : deux ajouts d’affichage et d’embarquement aux métadonnées de groupe. PR #2383 ajoute un tag banner optionnel à l’event de métadonnées de groupe kind:39000, rejoignant les champs existants name, picture et about pour que les clients puissent afficher une image d’en-tête pour la page d’un groupe. PR #2380 définit un suffixe de code d’invitation pour les liens de partage de groupe : un code d’invitation peut être ajouté à l’identifiant naddr du groupe sous la forme naddr1...?invite=<code>. Parce que le jeu de caractères bech32 n’inclut pas ?, la partie avant le suffixe reste un naddr valide en soi, de sorte que les clients qui ne comprennent pas l’extension peuvent toujours résoudre le groupe. Les clients qui la comprennent pré-remplissent le tag code sur la demande d’adhésion kind:9021, qui s’associe à l’event de modération existant kind:9009 create-invite pour simplifier l’admission aux groupes fermés.
NIP-51 (Listes) : Ensembles de suivi favoris, kind:10011 (PR #2413, fusionnée le 2026-07-15) : NIP-51 définit les kinds de liste standard, répartis entre les listes remplaçables de la série kind:10000 (une par utilisateur) et les ensembles adressables de la série kind:30000 (plusieurs par utilisateur, indexés par tag d). Cette PR ajoute kind:10011, ensembles de suivi favoris, une liste remplaçable standard dont les tags a pointent vers des ensembles de suivi kind:30000. Miroir de kind:10012 (flux de relays), qui contient des tags a référençant des ensembles de relays kind:30002, le nouveau kind permet à un utilisateur de marquer des ensembles de suivi nommés, comme des listes organisées de collections de pubkeys publiées par lui-même ou par d’autres, et de faire en sorte que les clients les présentent pour un suivi en un geste ou un changement de flux. Notez que ce numéro de kind est déjà contesté : voir la PR de renumérotation ouverte ci-dessous.
NIP-46 (Nostr Connect) : Recommandation sur le délai silencieux (PR #2375, fusionnée le 2026-07-15) : NIP-46 est le protocole de signature à distance où un client envoie des requêtes chiffrées de style JSON-RPC à un signeur (bunker) via les relays et attend une réponse chiffrée. Le changement fusionné tient en une phrase de comportement sur le fil : les requêtes faites avec des méthodes inconnues ou non prises en charge DOIVENT recevoir une réponse d’erreur. Auparavant, un signeur qui recevait une méthode qu’il n’implémentait pas pouvait ne jamais répondre, laissant le client en attente jusqu’à l’expiration de son propre délai, sans moyen de distinguer « méthode non prise en charge » de « signeur hors ligne ». La réponse d’erreur imposée permet aux clients d’échouer rapidement et d’afficher une erreur compréhensible avant l’expiration du délai local.

PRs et discussions ouvertes :

Renumérotation de kind:10011 vers kind:10021 (PR #2417) : déplace la liste d’ensembles de suivi favoris nouvellement fusionnée de kind:10011 vers kind:10021, parce que 10011 est déjà utilisé ailleurs. La PR de renumérotation a été ouverte quelques jours après la fusion originale, de sorte que les clients implémentant les ensembles de suivi favoris devraient suivre cette PR et viser le numéro final, pas 10011.
NIP-47 (Nostr Wallet Connect) : Simplification du cœur (PR #2419) : propose de resserrer NIP-47, le protocole wallet-connect qui permet aux applications de demander des paiements Lightning à un portefeuille distant via Nostr, en une spécification cœur plus petite. Les fonctionnalités optionnelles et plus spécialisées sortiraient de 47.md vers un dépôt d’extensions dédié, nostr-wallet-connect/nwc, où les spécifications d’extension peuvent évoluer indépendamment du cœur. L’objectif affiché est de garder le cœur petit, stable et facile à implémenter, suivant la direction convenue lors d’appels NWC antérieurs de séparer une couche wallet-connect minimale des comportements optionnels plus riches. Vu à quel point NIP-47 est largement déployé parmi les portefeuilles et applications, quiconque parle NWC devrait suivre la discussion de restructuration.
Trusted Relay Assertions (brouillon, aucun numéro attribué) (PR #2418) : propose un standard pour publier des évaluations de confiance sur les relays Nostr, positionné comme la couche « ce que nous concluons » aux côtés de NIP-11 (ce qu’un relay déclare de lui-même) et NIP-66 (ce que les moniteurs ont mesuré). Les fournisseurs d’affirmations calculeraient des scores de confiance à partir de métriques observées, de la réputation de l’opérateur et des signalements d’utilisateurs ; les clients interrogeraient ces affirmations lors du choix des relays auxquels se connecter. Le brouillon introduit kind:30385 (Trusted Relay Assertion adressable, portant des tags de score, fiabilité, qualité, accessibilité, opérateur, politique et juridiction), kind:10385 (Trusted Provider List remplaçable, les fournisseurs d’affirmations choisis par l’utilisateur), et réutilise les labels NIP-32 pour les rapports sur les relays et les opérateurs. Aucun numéro de NIP n’a encore été attribué ; c’est un brouillon de stade précoce.
Opérateur AND pour les filtres (« NIP-91 », proposé, numéro pas encore dans le dépôt) (PR #2252) : sous NIP-01, les filtres de tags fonctionnent uniquement en OU : un filtre "#t": ["meme", "cat"] correspond aux events portant l’un ou l’autre tag. Cette proposition ajoute un modificateur & pour les tags indexables, de sorte que "&t": ["meme", "cat"] ne renvoie que les events portant les deux tags. Les relays effectuent l’intersection côté serveur et renvoient un résultat plus restreint. Les règles de compatibilité donnent la priorité à AND sur OR, ignorent dans OR les valeurs utilisées par AND sur les relays compatibles et obligent les clients à inclure les tags OR # standard pour les relays dépourvus de l’extension ; les clients intersectent localement ces résultats plus larges. Cette PR rouvre une proposition antérieure et cite plusieurs implémentations de relay, dont une image Docker de nostr-rs-relay, netstr et un relay worker Snort. NIP-91 n’apparaît que dans la branche de la PR et reste absent de l’index des NIP dans le README du dépôt ; le numéro est donc provisoire.
Applets web Nostr (« NIP-5D », proposé, numéro pas encore dans le dépôt) (PR #2303) : définit un protocole postMessage pour des applications web en bac à sable (« napplets ») s’exécutant dans des iframes ou webviews afin de communiquer avec une application hôte (« shell »). La spécification est délibérément un cœur mince : elle spécifie l’enveloppe de message, les règles de bac à sable (les iframes de napplets DOIVENT utiliser sandbox="allow-scripts" sans allow-same-origin, et les shells NE DOIVENT PAS exposer window.nostr NIP-07 à l’intérieur de l’iframe), l’identification de l’expéditeur via la référence de fenêtre infalsifiable MessageEvent.source, et non event.origin, et la négociation de capacités basée sur un manifeste. Les messages de protocole réels pour la signature, l’accès aux relays, le stockage et la communication inter-napplets sont délégués aux spécifications d’extension NAP (Nostr Applet Protocol), chacune propriétaire d’un domaine de capacité, la signature et le chiffrement étant toujours médiés par le shell afin que les clés n’entrent jamais dans le bac à sable. La proposition dépend de la spécification de manifeste de napplet NIP-5A et tombe à point cette semaine : le travail pré-version v1.13.0 d’Amethyst inclut l’isolation des comptes napplets, faisant de l’hébergement de napplets côté client un domaine d’implémentation actif. Comme pour « NIP-91 » ci-dessus, le numéro 5D est provisoire.

Analyse approfondie : NIP-42 et NIP-43

Faire tourner un relay qui n’est pas ouvert à tous signifiait autrefois tout inventer soi-même. Un opérateur de relay payant ou sur invitation devait maintenir une liste blanche hors bande, généralement un fichier texte de pubkeys collectés par DM, sans moyen standard de dire à un client connecté « prouve qui tu es » et sans moyen standard pour un utilisateur de demander l’admission ou de savoir s’il était membre. Chaque relay qui voulait des lectures ou des écritures contrôlées construisait son propre mécanisme privé, et les clients ne pouvaient interopérer avec aucun d’eux. NIP-42 standardise la moitié preuve d’identité de ce problème, et NIP-43 standardise la moitié appartenance. Cette semaine, nostream, le relay TypeScript, a fusionné la paire de bout en bout : PR #702 restreint les lectures des kinds chiffrés aux destinataires authentifiés, et PR #676 ajoute des stratégies d’events de demande d’adhésion et de départ, toutes deux fusionnées le 20 juillet.

NIP-42 : Authentification des clients auprès des relays

NIP-42 répond à une question : qui est sur cette connexion ? Un relay qui veut contrôler les lectures ou les écritures envoie un message AUTH portant une chaîne de défi, au moment de la connexion ou à la demande quand une requête nécessite une authentification. Le client répond avec son propre message AUTH contenant un event éphémère signé, kind 22242, et le relay répond avec un message OK exactement comme si l’event d’authentification était une écriture ordinaire. L’authentification reste ensuite valable pendant toute la durée de la connexion. Une séquence de messages AUTH peut authentifier plusieurs pubkeys sur une même connexion.

L’event d’authentification signé est un objet compact : un pubkey, un created_at, kind 22242, un tag relay, un tag challenge, un content vide et une sig sur l’id de l’event. kind 22242 étant éphémère — les relais ne doivent jamais le stocker ni le diffuser — aucun exemple publié n’existe à intégrer ; le tour des champs ci-dessous couvre ce qu’il contient.

Le pubkey est l’identité qui est prouvée, puisque le relay vérifie la sig sur l’id de l’event par rapport à lui. Le kind 22242 se situe dans la plage éphémère : l’event est un justificatif au niveau de la connexion, et les relays ne doivent jamais le stocker ni le diffuser à d’autres clients. Le tag relay lie la signature à une URL de relay afin qu’un event d’authentification capturé ne puisse pas être rejoué contre un relay différent, et le tag challenge le lie à la chaîne de défi spécifique que le relay a émise sur cette connexion, bloquant le rejeu d’une authentification capturée sur une connexion ultérieure. Le created_at doit être proche de l’heure actuelle, dans une fenêtre d’environ dix minutes, de sorte qu’un event d’authentification périmé expire de lui-même. Le champ content est vide ; rien n’est publié.

La spécification définit aussi deux préfixes lisibles par machine qui rendent le contrôle visible aux clients. Un relay qui rejette un abonnement parce que le client ne s’est pas encore authentifié répond avec un message CLOSED commençant par auth-required:, et une écriture rejetée reçoit un OK avec le même préfixe. Un client qui s’est authentifié mais n’a toujours pas la permission pour l’action reçoit restricted: à la place. Cette distinction est ce sur quoi PR #702 de nostream s’appuie : les lectures des kinds chiffrés peuvent désormais être fermées avec auth-required: jusqu’à ce que le pubkey demandeur prouve qu’il est le destinataire.

NIP-43 : Métadonnées et requêtes d’accès aux relays

NIP-43 répond à la question suivante : maintenant que le relay sait qui vous êtes, qu’êtes-vous autorisé à faire ? Là où NIP-42 est une poignée de main sur une connexion active, NIP-43 est un ensemble d’events publiés qui décrivent l’état d’appartenance et permettent aux utilisateurs de demander à le changer. Côté relay, un event kind 13534, signé par le pubkey du champ self du NIP-11 du relay, liste un tag member par pubkey, avec des arguments de rôle optionnels pointant vers des définitions de rôles publiées en kind 33534. Kind 8000 annonce l’ajout d’un membre et kind 8001 annonce un retrait, tous deux signés par la même clé de relay avec un tag p pour le membre concerné. Côté utilisateur, kind 28934 est une demande d’adhésion portant un code d’invitation dans un tag claim, kind 28935 est un event de code d’invitation éphémère que le relay génère à la volée quand un utilisateur demande un claim, et kind 28936 est une demande de départ.

Une demande d’adhésion est un objet tout aussi petit, et aucun relais public n’implémente encore NIP-43, donc il n’existe aucun event kind 28934 réel à intégrer ; le tour des champs ci-dessous couvre ce qu’il contient.

Le pubkey est l’utilisateur qui demande l’admission, et kind 28934 marque l’event comme une demande d’adhésion. Son tag - est le marqueur d’event protégé de NIP-70, indiquant aux relays de n’accepter l’event que de son auteur. Un tag claim porte le code d’invitation obtenu hors bande, et created_at doit correspondre à l’heure actuelle, à quelques minutes près, afin qu’une ancienne demande ne puisse pas être rejouée. Les relays répondent à la demande avec un message OK, réutilisent le préfixe restricted: de NIP-42 pour les échecs tels qu’un code expiré ou invalide, mettent à jour la liste kind 13534 et peuvent publier un event kind 8000 d’ajout de membre. L’appartenance n’est volontairement pas déduite d’un seul event : la spécification considère la liste signée par le relay comme une source parmi d’autres, et un client qui détermine si une personne est membre doit consulter à la fois le kind 13534 du relay et les propres events du membre. Les clients ne doivent envoyer de demandes d’adhésion, d’invitation ou de départ qu’aux relays qui annoncent ce NIP dans la section supported_nips de leur document NIP-11, et la PR #676 de nostream fournit le mécanisme côté relay qui transforme ces kinds de requêtes en changements d’appartenance réels.

Historique

NIP-42 est de loin le plus ancien des deux. Il est entré dans le dépôt NIPs le 2 janvier 2023, dans le commit c80be21c, où fiatjaf a radicalement simplifié un NIP antérieur d’authentification auprès des relays, rédigé par semisol, en ramenant un mécanisme de défi plus complexe à l’unique event éphémère signé que la spécification utilise encore aujourd’hui. NIP-43 est arrivé bien plus tard, le 30 octobre 2025, lorsque la PR #1079 de hodlbod a été fusionnée, ajoutant des métadonnées et des demandes d’accès aux relays directement fondées sur le préfixe restricted: de NIP-42. Cet écart de deux ans et demi montre combien de temps les opérateurs de relays payants et privés ont utilisé des listes blanches ad hoc avant que la couche d’appartenance ne soit standardisée.

Implémentations

Côté relay, nostream livre désormais les deux moitiés après les fusions de cette semaine. strfry implémente NIP-42, validant les events d’authentification kind 22242 dans son ingéreur et émettant des défis depuis sa configuration. nostr-rs-relay gère la poignée de main AUTH dans sa couche de connexion avec des tests couvrant la fenêtre de défi et d’horodatage. khatru, le framework de relay Go, suit le pubkey authentifié par connexion afin que les politiques puissent contrôler les lectures et les écritures dessus. Côté client, Amethyst signe des réponses kind 22242 aux défis des relays, y compris l’authentification par flux pour ses communautés chiffrées Concord. Les deux NIPs divisent le contrôle d’accès le long d’une ligne nette : NIP-42 est la preuve d’identité, scopée à une connexion, un défi et quelques minutes de validité, et il ne dit rien sur la politique. NIP-43 est la politique, exprimée comme des events de relay ordinaires : qui est membre, qui a été ajouté ou retiré, et comment un utilisateur demande ces transitions. La lacune que les implémenteurs devraient garder à l’esprit est que rien ne standardise encore des permissions plus fines au-delà des métadonnées de rôle optionnelles de NIP-43, de sorte que tout relay faisant plus qu’une division binaire membre/non-membre conçoit cette couche de son côté.

C’est tout pour cette semaine. Vous construisez quelque chose ou avez des nouvelles à partager ? Contactez-nous par DM NIP-17 ou trouvez-nous sur Nostr.