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

Cette semaine : Sprout devient Buzz et commence à publier personas, équipes et enregistrements d’agents gérés sous forme d’events relay Nostr, avec un état de lecture multi-appareil et des marqueurs par message qui remplacent l’ancien modèle de frontière des badges. Les Napplets de sandwich.farm arrivent comme protocole à frontière de confiance pour des apps Nostr composables distribuées sur Nostr et Blossom. Conduit, un monorepo de marketplace à trois apps sur Nostr, marché acheteur, portail marchand et constructeur de boutique, avec ses propres répertoires NIP et specs, fusionne 17 PRs qui renforcent le MVP, adopte son relay public par défaut et ajoute une analytique respectueuse de la vie privée. BitBlik livre un protocole d’échange P2P de BLIK vers Lightning par DM Nostr chiffrés, avec un coordinateur qui règle atomiquement les paiements fiat et les hold invoices Lightning. Amethyst prolonge le lancement de la semaine dernière consacré aux wallets, podcasts et entraînements avec Health Connect Workouts, Road Events, des réponses repliables, un suivi de santé de la latence relay avec classificateur, et un correctif de notarisation macOS. Amber implémente l’extension de métadonnées client NIP-46 proposée la semaine dernière, en affichant l’icône et l’identité des apps natives dans les écrans de demande du signataire. Haven lance le partage privé de position sur le protocole de messagerie chiffrée Marmot. CodeDeck permet de piloter depuis un téléphone des sessions Claude Code exécutées sur un ordinateur portable via des relays Nostr chiffrés, réduit ensuite l’appairage à un seul scan QR, puis ajoute la sélection du modèle par session. Grain livre une bibliothèque cliente Nostr en Go importable qui applique le modèle outbox. Mostro Core, Wisp et Dark Wisp, Citrine, FIPS, Kubo, avec des chaînes YouTube choisies par les parents et un feed enfant obligatoirement soumis à la confiance, ainsi que Pollerama, avec un score de web of trust, un moteur relay sur l’appareil et une rangée « Personnes que vous connaissez peut-être », publient des correctifs de suivi. Les changements sans version couvrent un coordinateur MLS dans le navigateur de sandwich.farm, une série d’améliorations UX de nostter, le correctif NIP-46 transversal et la refonte du compositeur de Zap Cooking, le cycle d’escrow Cashu de Shopstr, divine.video et Nostur. Les nouveaux projets suivis comprennent Social Agents Prototype, PRana pour le triage des issues git-over-Nostr et routstr-chat. Côté protocole, NIP-99 reçoit une proposition de checkout et d’escrow on-graph directement liée aux travaux commerciaux de Conduit, BitBlik et Shopstr. Comme il s’agit du dernier Compass de juin, ce numéro se termine par Six mois de juin dans l’histoire de Nostr.

À la une

Amethyst v1.12.1 à v1.12.6 prolongent le lancement de v1.12.0

Amethyst a fait suivre le lancement de v1.12.0 la semaine dernière de six correctifs rapides entre mercredi et vendredi. v1.12.1 ajoute Health Connect Workouts et une action Share-as-Image, et rend déterministe le flag Tor Active afin que le callback d’amorçage ne puisse pas entrer en concurrence avec la porte. v1.12.2 ajoute Road Events et les réponses repliables, v1.12.3 apporte le suivi de santé de la latence relay avec un classificateur et un tableau de bord, ainsi qu’un correctif de notarisation macOS, et v1.12.4 à v1.12.6 livrent des passes de traduction Crowdin et l’automatisation des crédits des traducteurs.

Sprout devient Buzz et publie personas, équipes et agents gérés sous forme d’events relay

Sprout, l’espace de travail auto-hébergeable de Block où humains et agents IA collaborent dans les mêmes canaux et où chaque message, réaction, étape de workflow, approbation de revue et event git est écrit comme event Nostr signé, a été renommé Buzz cette semaine. GitHub redirige maintenant l’ancien slug block/sprout vers block/buzz ; le dépôt, la licence et l’orientation du produit restent inchangés. Toutes les mentions de Sprout dans les numéros précédents concernent le même projet.

Le changement de nom s’accompagne d’un travail produit conséquent. Personas, équipes et enregistrements d’agents gérés sont désormais publiés comme events relay Nostr via la PR #1189, ce qui permet à une même identité d’agent d’apparaître dans plusieurs espaces de travail et journaux d’audit sans dupliquer l’état. Un nouveau panneau desktop affiche les attestations de propriétaire NIP-OA sur les profils (PR #1198), la frontière des badges non lus dans les fils de canaux cède la place à des marqueurs de lecture par message afin que les compteurs restent exacts sur plusieurs appareils (PR #1178), et la boîte de réception gagne l’attribution de l’auteur et de la source sur les events de rappel (PR #1176).

Les canaux temporaires expirent maintenant par défaut au bout de sept jours (PR #1182), les remplacements de relay propres à un agent respectent le relay configuré avant de revenir à celui de l’espace de travail (PR #1131), et la build Windows embarque désormais une chaîne d’outils Git-for-Windows complète pour l’outil shell (PR #1145).

Napplets : des apps Nostr composables avec une frontière de confiance définie

Sandwich.farm a annoncé napplet.run cette semaine comme protocole d’applets Nostr composables, ou napplets : de petits programmes qui accomplissent une tâche, s’exécutent dans des environnements sandboxés et sont résolus sur Nostr et Blossom avec la même forme d’event que les nsites. Le projet se répartit sur trois dépôts : napplet/web, qui contient les paquets web et a créé 51 tags de version de sous-paquets cette semaine lors d’un lancement coordonné (@napplet/core, @napplet/sdk, @napplet/nap, @napplet/shim, @napplet/conformance) ; napplet/naps, la piste de specs NAPs avec 15 PRs fusionnées ; et kehto/web, le runtime web avec 41 PRs fusionnées et un playground sur kehto.github.io/web/playground. La PR de spec correspondante est NIP-5D #2303, ouverte par dskvr de sandwich.farm.

Le principe architectural est une frontière de confiance définie au niveau du protocole. Un shell arbitre les opérations dangereuses, signature, accès aux clés et écritures relay, un runtime gère l’implémentation et l’UX de plus haut niveau, tandis que les napplets restent portables, jetables et plus difficiles à capturer par un hôte unique. Les napplets peuvent communiquer entre elles au sein d’un même shell et le design exclut tout verrouillage à un runtime. L’auteur met les napplets en regard de NMP, de Pablof7z, et de Tiles, de Soapbox, comme trois approches parallèles du même problème, et note que le support NIP-5A et NIP-5D d’Amethyst v1.12.6 donne aux napplets au moins un client publié dès leur lancement. Le projet rappelle aussi son histoire : l’ancien napp.run de sandwich.farm, prototype d’app native NIP-07, et le navigateur dryft, fork de Thorium, ont tous deux nourri le design actuel avant d’être abandonnés.

Conduit renforce le MVP de sa marketplace et adopte son relay public par défaut

Conduit est le monorepo à trois apps de la marketplace conduit.market, Market pour les acheteurs, Merchant Portal et Store Builder, sous l’organisation Conduit-BTC. Il comprend ses propres répertoires nips/ et specs/, qui définissent des primitives commerciales Nostr propres à Conduit, et s’appuie sur l’extension Scope-2 Conduit-BTC/conduit-relay de khatru. Les deux dépôts ont ouvert plus tôt cette année ; le projet a fusionné cette semaine 17 PRs qui renforcent le MVP de la marketplace.

Les PRs livrées se concentrent sur la correction du marché : états de sécurité des annonces (PR #110) et durcissement des prix des produits et des zones d’expédition côté marchand (PR #115). Côté relay, la PR #102 corrige la détection des capacités commerciales, la PR #112 ignore les indices de relays tiers non sécurisés, et la PR #128 définit le domaine relay public de Conduit comme valeur par défaut des nouveaux clients. Une analytique respectueuse de la vie privée arrive dans les PR #109 et PR #129, tandis qu’une mise à jour de dompurify ferme un avis OSV (PR #116). Ce travail s’inscrit dans une vague commerciale NIP-99 plus large cette semaine : la PR #2323 propose une couche de checkout on-graph pour les marchés NIP-99 couvrant le flux de commande, l’escrow et les litiges ; la Gamma Markets Market Spec, qui étend depuis longtemps NIP-99 au e-commerce complet, devient la couche de spec sur laquelle Conduit et d’autres construisent ; et Shopstr a livré la même semaine un cycle d’escrow Cashu.

BitBlik lance un protocole d’échange P2P de BLIK vers Lightning sur Nostr

BitBlik a ouvert cette semaine comme protocole d’échange pair à pair BLIK ↔ Lightning construit sur Nostr. BLIK est le système polonais de paiement instantané émis par les banques ; le coordinateur BitBlik règle atomiquement entre le fiat BLIK, payé par les takers, et des hold invoices Lightning, financées par les makers, tandis que le cycle de l’échange s’exécute sur Nostr. L’app Flutter, la CLI et le coordinateur partagent un paquet core, et le projet est distribué via le monorepo GitHub bit-blik/bitblik, la build web www.bitblik.app et l’app Zapstore app.bitblik.

Le protocole utilise des messages directs Nostr chiffrés, NIP-44, pour le RPC entre client et coordinateur. Les offres sont publiées comme events remplaçables paramétrés de kind 38383, les requêtes RPC en kind 25195, les réponses RPC en kind 25196 et les mises à jour d’état en kind 25197. Le coordinateur retient une hold invoice Lightning pendant qu’un taker soumet un code BLIK, libère la préimage après confirmation du transfert BLIK, puis achemine le règlement de l’invoice vers le maker.

Versions taguées

Amber v6.2.2 implémente les métadonnées client NIP-46

Amber, le principal signataire distant Android NIP-46 maintenu par greenart7c3, a livré v6.2.2 la semaine même où la PR de spec correspondante a été fusionnée. La version affiche les icônes des apps natives et les nouveaux champs de métadonnées client sur les écrans de demande et dans la liste des apps, conserve les métadonnées à chaque connexion, et capture l’icône et le nom de l’app native au moment de la connexion et de l’acceptation. Ce changement correspond directement à la PR NIP-46 #2381 de DocNR, qui ajoute des métadonnées client facultatives à la demande de connexion afin que les signataires puissent afficher un nom et une icône explicites pour l’appelant. Amber v6.2.2 ajoute également le support du kind 30618 et sépare relays par défaut et relays de connexion dans l’écran Active relays.

La version resserre la surface de sécurité du signataire. Les corps déchiffrés des requêtes et réponses NIP-46 ne sont plus écrits dans les logs, tandis que les charges utiles de chiffrement et de déchiffrement sont stockées sous forme de ciphertext et déchiffrées à la demande. Toute sortie logcat est conditionnée par BuildConfig.DEBUG, les appelants navigateur, dont le paquet est nul, doivent toujours demander, et les copies de nsec, ncryptsec et mots de seed dans le presse-papiers sont marquées sensibles puis effacées après un délai. Des exclusions explicites de sauvegarde et d’extraction de données ajoutent une défense en profondeur. La version corrige aussi un crash dû au défilement imbriqué dans Active relays, un crash de clé dupliquée dans LazyColumn causé par une déduplication concurrente des demandes bunker, et une course EOSE dans la recherche de mises à jour.

Haven lance le partage privé de position sur Marmot

Haven a ouvert cette semaine comme app Android et iOS de partage privé de position, résistante à la censure, qui s’exécute sur Nostr avec le protocole Marmot. Le dépôt a livré cinq versions entre v0.1.0 et v0.1.4 en quatre jours, les premières d’un nouveau projet. Haven est écrit en Dart et Flutter et publié sur Zapstore comme app signée par le développeur. Marmot, la couche de messagerie chiffrée de bout en bout fondée sur MLS pour Nostr, fournit l’état de groupe et la distribution du ciphertext ; Haven étend ce modèle de la messagerie au partage de position, l’état chiffré de chaque groupe transportant les mises à jour que ses membres ont accepté de partager.

CodeDeck : du codage agentique à distance sur Nostr

CodeDeck a ouvert cette semaine comme interface de codage agentique multisession pour Android et desktop, construite avec Tauri v2, React 19 et un backend Rust. Elle permet de piloter depuis un téléphone des sessions Claude Code exécutées sur un ordinateur portable via des relays Nostr chiffrés. Le projet a livré v2026.06.17, v2026.6.18 et v2026.6.20 dans la même fenêtre de quatre jours. Le modèle de transport utilise Nostr comme plan de contrôle chiffré : un téléphone CodeDeck publie des commandes sous forme d’events chiffrés auxquels souscrit le bridge situé près de l’ordinateur, qui publie en retour la sortie de session sur les mêmes relays.

v2026.06.17 intègre le mesh FIPS nostr-vpn comme service VPN Android de l’app, de sorte qu’un ordinateur portable peut compiler, installer, lancer et piloter de n’importe où des builds de développement sur un téléphone de test physique, CodeDeck étant le seul logiciel installé sur celui-ci. v2026.6.18 réduit l’appairage et l’invitation au mesh à un seul scan QR, et v2026.6.20 ajoute la sélection du modèle par session afin que chacune démarre avec le modèle choisi.

Grain v0.8.0-rc1 livre un moteur client Nostr complet

Grain, le relay Go maintenu par 0ceanSlim, a créé le tag v0.8.0-rc1 et devient à la fois un relay Nostr et la bibliothèque cliente Go importable sur laquelle il repose. Là où v0.7.x se concentrait sur l’administration du relay depuis un navigateur, la série v0.8 livre client/core, un moteur client Nostr autonome appliquant le modèle outbox, entièrement en Go et sans dépendance cgo ou HTTP. Le moteur possède un pool partagé de relays, résout les listes de relays de chaque utilisateur et achemine toute lecture et publication selon le modèle gossip / outbox : les notes d’un utilisateur se lisent depuis ses relays outbox, tandis qu’une réponse publiée atteint les relays inbox de l’auteur parent. Le frontend web de Grain est désormais le consommateur de référence de cette bibliothèque, ce qui en fait à la fois une app utilisable et un exemple complet pour les projets Go en aval.

La version apporte le chiffrement natif NIP-44 v2 et v3, l’AUTH relay NIP-42, les listes de relays NIP-65, NIP-17, NIP-51 et NIP-37, les tags client NIP-89, ainsi que le support média Blossom et NIP-96. Les apps Go qui devaient auparavant réimplémenter le routage relay peuvent maintenant directement import le moteur.

Mostro Core v0.13.1 prolonge Protocol v2

Mostro Core a livré v0.13.1 après le déploiement de Protocol v2 la semaine dernière, en ajoutant une variante d’erreur PriceTooStale au contrat de flux de prix du protocole. Côté daemon cette semaine, la PR #752 renvoie aux clients une erreur CantDo(NotFound) pour les ids de commande invalides au lieu de les ignorer silencieusement, la PR #785 aligne la version interne du protocole sur le transport actif, la PR #778 livre la phase 3 du fournisseur de taux fiat El Toque pour CUP et MLC, et la PR #782 renomme le tag d’information NIP-33 protocol_versions en protocol_version pour l’aligner sur la spec.

Wisp v1.1.2 et la variante Dark Wisp

Wisp, le client Android Kotlin et Jetpack Compose de barrydeen, a livré v1.1.2. La version maintient distinctes les branches de wallet envoyées à soi-même dans l’ordre déterministe des transactions (PR #586), crée paresseusement les lecteurs vidéo en ligne pour résister aux notes riches en médias (PR #592), corrige une ConcurrentModificationException dans l’ensemble event-relays (PR #595) et répare la mesure intrinsèque du contenu des bulles de chat pour éviter un crash SubcomposeLayout (PR #596). Elle apporte aussi un filtre de feed incrémental avec évaluation du spam hors verrou. L’équipe Wisp a également publié Dark Wisp v1.1.0 sur Zapstore cette semaine, une variante multidevise ajoutant des cibles de zap ZEC, DASH, BCH et LTC, ainsi qu’un mode anonyme.

Citrine v3.0.1

Citrine, le relay Nostr local Android de greenart7c3, a livré v3.0.1 avec un seul correctif : désenregistrer un récepteur Pokey non enregistré ne provoque plus le crash du relay.

FIPS v0.4.0-rc2

FIPS, le Free Internetworking Peering System, a créé le tag v0.4.0-rc2 comme release candidate de validation du packaging au-dessus du format filaire v0.3.x. La série v0.4.0 ajoute un transport mixnet Nym et la découverte LAN mDNS facultative pour joindre les pairs, remanie le plan de données afin d’augmenter le débit d’un nœud unique et de réduire le CPU par paquet, déplace la surface de lecture opérateur hors du chemin critique afin que l’observabilité reste réactive sous charge, livre une TUI fipstop remaniée, et renforce le rekey FMP et FSP pour qu’il n’interrompe pas le trafic en cas de perte de paquets. Il s’agit d’une release candidate ; la version stable v0.4.0 est provisoirement prévue pour le 2026-06-21.

Kubo v2026.06.12 et v2026.06.20 verrouillent le feed enfant soumis à la confiance et ajoutent YouTube choisi par les parents

Kubo, l’alternative Nostr-native à YouTube Kids de JeroenOnNostr construite sur le Trust Extended Permissions Protocol (TEPP), a livré deux versions cette semaine. v2026.06.12, dont le versionnage calendaire produit le versionCode YYYYMMDD, rend obligatoire le feed enfant soumis à la confiance : chaque post, profil, réaction et repost que l’enfant peut voir ou avec lequel il peut interagir passe désormais par TEPP et se limite aux personnes admises par le parent. Les nouvelles installations démarrent avec la porte de confiance activée et le cercle de l’enfant initialisé pendant l’onboarding, si bien que le feed est protégé dès le premier lancement. La version ajoute aussi un chat de groupe géré pour les parents, achemine les events de confiance vers l’ensemble de relays privés de la famille et échoue en mode fermé, en n’affichant rien, plutôt que de laisser filtrer du contenu non validé quand les données de confiance ne chargent pas.

v2026.06.20 ajoute les chaînes YouTube choisies par les parents : ceux-ci peuvent rechercher une chaîne et l’ajouter au feed enfant, afin que les enfants ne voient que les vidéos de chaînes approuvées, avec un chemin rapide HTTP et une UI optimiste qui remplacent un ajout d’environ dix secondes. La version supprime aussi l’option de désactivation de Trust Extended Permissions, car le projet repose sur une confiance obligatoire, ajoute une page Support, corrige les @mentions du chat de groupe pour afficher un @name cliquable plutôt qu’un nostr:npub1… brut, ajoute l’autocomplétion des mentions, et fonde la publication de la confiance sur l’état d’application réel plutôt que sur un flag miroir. Les deux versions sont suivies dans Zapstore comme app Android com.kubo.app signée par le développeur.

Pollerama v1.9.0 à v1.9.4 ajoutent un score de web of trust, un moteur relay sur l’appareil et une rangée « Personnes que vous connaissez peut-être »

Pollerama d’abh3po, le client de sondages et feeds Nostr de la famille Form* sur pollerama.fun, a livré cinq versions sur Zapstore cette semaine. v1.9.0 apporte un moteur relay sur l’appareil : un relay local intégré stocke désormais tout ce que l’utilisateur a vu et répond d’abord depuis le cache local, si bien que feeds, profils et fils chargent instantanément, même hors ligne, et restent synchronisés avec le réseau en arrière-plan. Tout le trafic relay, en lecture comme en écriture, traverse ce moteur hors du thread principal, et notes, profils, réactions et zaps déjà chargés proviennent directement du stockage local au lieu d’être récupérés à nouveau.

v1.9.2 corrige les feeds Home et Notes, ainsi que toute vue Following ou Network, qui pouvaient rester vides au lancement ou à la reprise. La liste de suivi est désormais mise en cache indépendamment du moteur de synchronisation. Les notes partagées dans les DM chargent de manière fiable grâce aux indices de relay, même lorsque l’utilisateur ne suit pas leur auteur. Un panneau de réglages Network affiche les connexions relay, la taille du cache et l’état de synchronisation, avec des contrôles pour se reconnecter ou vider le cache local. v1.9.3 corrige un crash au lancement et une régression de chargement du feed Home.

v1.9.4 introduit sur les profils un score de confiance fondé sur le web of trust, c’est-à-dire le nombre de personnes suivies par l’utilisateur qui suivent aussi ce profil, affiché dans une puce réseau, ainsi qu’une rangée « Personnes que vous connaissez peut-être », dont les suggestions issues du web of trust sont classées selon le nombre de contacts communs. Les réglages Network affichent maintenant la taille du web of trust et la date du dernier calcul, avec un bouton de recalcul à la demande. Le worker web of trust calcule scores et recommandations en arrière-plan afin de ne pas bloquer l’app.

Autres versions taguées

nogringo/nostr-mail-client v0.13.1 rétablit la connexion par app de signature NIP-55 pour Amber, Aegis et Primal, et cesse de demander sans arrêt aux apps de signer les contacts. Cameri/nostream v3.0.0 retire unsafe-inline de la factory de l’app web et implémente des nonces de script. LaWallet NWC v1.0.0 publie la première 1.0 du projet avec activation de carte par lien QR partageable, reconnaissance de Remote Wallet et création automatique d’une Lightning Address. Formstr Nostr Calendar v2.0.0 à v2.0.2 ajoutent une PWA, corrigent les events remplaçables hors ligne (PR #194) et lient les méthodes du signataire afin que la soumission de formulaires privés fonctionne (PR #199). Les versions plus modestes de Spl0itable/NYM, codeswot/ZapBook, 77elements/noornote, mattn/nostr-relay, mattn/algia, mouse484/astraea, dergigi/boris, fiatjaf/nak, Spl0itable/nosflare et nostrord/nostrord complètent la semaine.

Changements sans version

Cordn Ad-hoc CVM : un coordinateur MLS dans le navigateur

Cordn Ad-hoc, la nouvelle app web de sandwich.farm, ouvre publiquement cette semaine comme coordinateur MLS exécuté dans un onglet navigateur pour les groupes Cordn ad hoc. Le modèle est inhabituel : un onglet exécute le processus coordinateur Nostr ContextVM, publie sa pubkey de coordinateur, reçoit des requêtes MCP par les relays Nostr et stocke dans le navigateur les key packages MLS, welcomes, demandes d’adhésion et messages de groupe, sans backend. L’app empêche l’exécution simultanée de plusieurs coordinateurs portant la même pubkey et fournit à l’opérateur un log de debug des events Nostr bruts, requêtes décodées et heartbeats d’instance.

SnowCait/nostter livre 19 PRs d’amélioration UX

nostter, le client web Nostr de SnowCait, a fusionné 19 PRs cette semaine sans créer de version. Le remplacement de nostrapp.link par app-manager.nostter.app (PR #2234) et l’ajout de deck.nostter.app à l’allowlist frame-ancestors (PR #2233) regroupent les surfaces du projet sous le domaine nostter.app. Les events remplaçables des personnes suivies sont mis en cache dans IndexedDB (PR #2231), tandis que l’état seen-on des relays retrouve sa réactivité avec des options seen-on et via séparées (PR #2230).

Zap Cooking corrige un bug NIP-46 transversal et refond le compositeur

Zap Cooking, le client Nostr de partage de recettes, a fusionné 16 PRs cette semaine. Le changement à la portée la plus large est la PR #452 : les signataires distants Primal attribuaient aux events la pubkey du signataire lui-même, ce qui cassait les téléversements, zaps et authentifications de tout client passant par Primal. Zap Cooking a détecté et corrigé ce chemin ; le correctif reste local au client, mais le bug concerne tout l’espace NIP-46. Le compositeur est reconstruit dans la PR #458 avec compte à rebours, UI unifiée pour réponses et commentaires, et onglets Write/Preview. Trois correctifs SSR, PR #460, PR #461, PR #462, ainsi que la PR #454, stabilisent les routes de profils et de recettes. L’exploration gagne des rangées à défilement par glisser, un curseur avatar lié au profil et un correctif des onglets collants pour les communautés (PR #456).

Shopstr livre un cycle d’escrow Cashu et des outils de vitrine

Shopstr, la marketplace NIP-99, a fusionné cette semaine plusieurs PRs substantielles. La PR #512 implémente pour la marketplace un cycle complet d’escrow Cashu P2PK, relié à la vague commerciale plus large de la même semaine par la PR NIP-99 #2323, proposition de couche de checkout on-graph, et par le lancement de Conduit. La PR #543 ajoute des outils de lecture pour lister les entreprises, obtenir leurs détails, récupérer une vitrine et connaître la réputation du vendeur. La PR #229 permet de coller une URL pour les images de profil et de boutique, et la PR #359 ajoute un timestamp à la récupération des statistiques de la marketplace.

Travail mobile et desktop de divine.video

divine.video, le client de courtes vidéos en boucle de rabble qui restaure les archives Vine, a fusionné cette semaine des PRs centrées sur la lecture et le montage : les vidéos adressables sont dédupliquées dans le feed (PR #5465), les filtres locaux de tags Nostr établissent désormais une correspondance exacte pour éviter les résultats parasites (PR #5463), l’éditeur vidéo restaure sans crash les brouillons comportant des calques de stickers (PR #5474), et le badge Messages compte les chats non lus de personnes suivies auxquels l’utilisateur n’a pas répondu (PR #5473).

Nostur livre les métadonnées client NIP-46 et corrige le rafraîchissement des DM

Nostur, le client iOS de Fabian, a fusionné quatre PRs dans le dépôt canonique après la version 1.29.0 de la semaine dernière. La PR #74 ajoute les métadonnées client aux demandes de connexion bunker NIP-46, sous la même forme que la proposition de DocNR et l’implémentation d’Amber v6.2.2 cette semaine. Les PR #75 et PR #76 corrigent le rafraîchissement des DM et les chemins de reprise après le retour d’un iPhone au premier plan, et la PR #78 ajoute le scan QR à la configuration NWC personnalisée.

Nouveaux projets suivis et découverts

Social Agents Prototype : collaboration d’agents IA Nostr-native avec approbation humaine

Social Agents Prototype est un outil IA expérimental construit sur Nostr qui explore la communication décentralisée d’agent à agent. Les agents diffusent des questions atomiques sur le réseau, seuls les agents concernés répondent, et chaque message envoyé ou reçu passe par une porte d’approbation humaine avant le transit. L’auteur est Sruly Rosenblat. Le projet occupe cette semaine le même espace de collaboration entre agents que Buzz et NIP-100 SNIN, mais adopte une autre forme : Social Agents Prototype modélise les agents comme des participants qui diffusent et écoutent, dont chaque message doit recevoir l’accord d’un humain. La semaine montre plusieurs approches parallèles du même problème.

PRana : une liste de travail pour les issues NIP-34

PRana de DocNR est une liste de travail des issues NIP-34 correctement ouvertes dans des dépôts git-over-Nostr volontaires. L’outil se place une couche au-dessus de la pile git-over-Nostr : il consomme les events d’issue NIP-34 des dépôts participants et les présente comme file de triage. Son lancement coïncide avec la PR NIP-34 #2384, qui propose de retirer le tag maintainers pour résoudre les problèmes d’expiration, ce qui touche directement la manière dont PRana et les outils similaires déterminent l’autorité sur les issues des dépôts.

routstr-chat : accès local aux LLM via le protocole Routstr sur Nostr

routstr-chat de l’équipe Routstr est une interface de chat entièrement locale qui utilise le protocole Routstr pour accéder à n’importe quel modèle LLM sur Nostr. Routstr achemine les demandes d’inférence grâce aux annonces de fournisseurs publiées sur Nostr, kind 38421, et règle les paiements en Cashu, comme l’expliquait la Newsletter #20. Le client de chat constitue la surface utilisateur de ce protocole ; le daemon de routage Routstrd gère la découverte et le paiement, tandis que l’app fournit l’UI de conversation.

Travail protocolaire

Mises à jour des NIP

L’activité NIP de la semaine a été particulièrement dense : deux fusions et une vague de propositions ouvertes substantielles.

Les métadonnées client NIP-46 arrivent dans Amber et Nostur

La PR NIP-46 #2381, proposée par Clave la semaine dernière, possède désormais des implémentations publiées des deux côtés. Amber v6.2.2 lit le nouveau champ facultatif optional_client_metadata des demandes de connexion bunker et affiche les icônes et métadonnées des apps natives sur ses écrans de demande et dans sa liste d’apps. La PR Nostur #74 ajoute ce champ côté client. Ensemble, les trois projets comblent le manque d’identité de l’appairage bunker : une association bunker:// transporte maintenant les mêmes name, url et image qu’une app pouvait déjà annoncer par nostrconnect://.

NIP-86 signevent et un event complémentaire de rôles relay

La PR #2389 de staab a fusionné une opération signevent dans NIP-86, l’API de gestion de relay, afin que les administrateurs puissent gérer des events NIP-43 au nom du relay. La proposition complémentaire ouverte, PR #2390 de staab, définit un event de rôles relay permettant aux relays de déclarer leurs rôles et aux administrateurs d’y affecter des membres ou de les en retirer. Les deux PRs sont conçues pour se composer : NIP-86 donne les opérations aux administrateurs, l’event de rôles leur donne le modèle d’autorisation.

NIP-99 : couche de checkout on-graph pour les marketplaces

La PR #2323 de Colabonate est le lien central de la semaine. Présentée comme une demande de retours sur le design, la proposition relève deux lacunes dans l’ensemble NIP-99 et Gamma Market Spec : un flux de checkout vivant on-graph, avec état après buy now, création de commande, paiement et confirmation de livraison sous forme d’events Nostr adressables et publics lisibles par tout client, puis escrow et résolution des litiges pour les transactions où les signaux du web of trust ne suffisent pas, notamment objets de grande valeur, premières transactions entre contreparties, marketplaces anonymes et livraisons physiques. La proposition élimine les silos entre clients pour les marketplaces comme NIP-99 l’avait fait pour les annonces. Elle arrive la même semaine que le lancement de Conduit, qui fournit ses propres répertoires nips/ et specs/, la PR Shopstr #512, cycle complet d’escrow Cashu, BitBlik, échange P2P BLIK ↔ Lightning avec ses propres primitives d’escrow, et l’entrée du dépôt autonome Gamma Markets Market Spec dans le suivi actif.

NIP-34 : retirer le tag maintainers pour résoudre les problèmes d’expiration

La PR #2384 de dhalsim retire le tag maintainers des annonces de dépôts NIP-34 et répond à l’issue #2382. Ce tag ne possédait aucune sémantique d’expiration définie, ce qui empêchait les outils en aval de savoir quand une attribution de mainteneur restait valide. Le changement a une large portée : il touche les patches flotilla-budabit, seul dépôt NIP-34 suivi avec une activité substantielle cette semaine, la distribution NIP-34 sur huit dépôts de l’équipe Iris, le miroir NIP-34 de BitBlik, le nouveau miroir NIP-34 d’Amber et l’outil PRana de DocNR. Les relecteurs croisés de la PR comprennent DanConwayDev de ngit, vitorpamplona d’Amethyst, TheAwiteb et chebizarro.

États des groupes NIP-29, travail en cours

La PR #2372 de dtonon propose une représentation des états de groupes pour NIP-29, partagée comme travail en cours afin de recueillir des retours. Elle poursuit l’évolution de NIP-29 couverte dans le #27 sous une nouvelle forme.

NIP-79 Stories et NIP-76 Reels Feed, tous deux d’anaskmh

Deux specs de médias courts du même auteur ont été proposées cette semaine. La PR #2386 propose NIP-79 Stories : diapositives photo, vidéo et texte éphémères en plein écran qui expirent après 24 heures, avec le kind 19 pour chaque diapositive, le kind 34237 comme event adressable contenant des tags e ordonnés pour séquencer une story à plusieurs diapositives, et un reçu seen-by facultatif respectueux de la vie privée en kind 15750. La PR #2385 propose NIP-76 pour un feed Reels de vidéos courtes. Ces deux specs sont des approches parallèles à ce que livrent déjà des clients vidéo tels que divine.video, et non des implémentations de celui-ci.

kind 1111 comme réponse aux notes kind 1

La PR #2358 de zhoreeq retire du corpus NIPs la phrase qui déconseillait auparavant d’utiliser les réponses de fil de commentaires kind 1111, NIP-22, sur les notes kind 1 (issue #2250). Le diff est réduit mais l’effet large : tout client souhaitant employer la forme de commentaire en fil de NIP-22 sur des notes ordinaires kind 1 reçoit maintenant un soutien explicite.

Six mois de juin dans l’histoire de Nostr

L’historique du dépôt en juin suit Nostr depuis l’enfance du protocole jusqu’à un substrat d’applications composables. En 2021, le travail tenait encore dans un seul dépôt de protocole. En 2022, le processus de standardisation et les premiers clients sérieux devinrent des projets distincts. La vague publique de 2023 rendit urgents les relays, les paiements et des identités plus riches ; 2024 remplaça les premiers raccourcis de signature et de messagerie ; 2025 porta ces contrats vers les groupes privés, la collaboration git, les médias et le commerce ; et 2026 lança des produits qui utilisent Nostr comme une couche au sein d’espaces de travail pour agents, d’échanges et d’outils de développement. La progression part de la preuve que des events signés peuvent circuler par les relays pour faire de ce fait un simple détail d’implémentation.

Juin 2021 : l’enfance du protocole

Nostr avait environ sept mois. Le post de protocole original de fiatjaf et le dépôt fiatjaf/nostr contenaient encore la quasi-totalité du projet public. Quelques développeurs pouvaient relire chaque changement et l’implémentation de référence était un script Python. Il ne s’agissait pas encore d’un écosystème de clients, mais de l’affirmation que les utilisateurs pouvaient signer des events et choisir leurs relays sans qu’une plateforme leur attribue une identité.

Il n’existait pas de dépôt NIPs dédié, si bien que propositions et exemples d’implémentation partageaient encore l’historique principal du protocole. Cette portée compacte constituait alors un avantage : un nouvel implémenteur pouvait comprendre le protocole de bout en bout. En contrepartie, chaque nouveau comportement dépendait toujours du même petit groupe, limite que la séparation des dépôts et la vague de clients de 2022 commenceraient à lever.

Juin 2022 : création du dépôt NIPs

À la mi-2022, Nostr comptait assez de contributeurs pour justifier le dépôt séparé nostr-protocol/nips, créé en mai. Une vingtaine de specs couvraient désormais le format d’event de base, les listes de suivi, les DM chiffrés, les métadonnées relay et les identifiants bech32. Sortir les documents du dépôt de code original a changé la gouvernance du projet : les clients pouvaient évoluer indépendamment tandis que les comportements filaires partagés recevaient des propositions et des revues explicites.

Les premiers clients web publics, dont Astral et Anigma, existaient sous des formes précoces, et le dépôt Damus de William Casarin avançait vers une distribution TestFlight. La base d’utilisateurs restait petite et très technique, mais le système possédait maintenant deux surfaces de multiplication : davantage de personnes pouvaient créer des apps sans maintenir la spec, et davantage de personnes pouvaient améliorer la spec sans posséder le client d’origine.

Juin 2023 : vague d’adoption après Damus

En juin 2023, la vague publique qui avait suivi le lancement de Damus dans l’App Store avait changé le problème d’ingénierie. Primal et Iris construisaient pour des personnes qui n’avaient pas suivi les premiers échanges sur le protocole, tandis que strfry proposait un relay haute performance aux opérateurs confrontés à davantage de trafic. Le réseau n’avait plus seulement besoin d’implémentations supplémentaires, mais de clients et relays capables de rester réactifs à mesure que croissaient utilisateurs, abonnements et historiques d’events.

Le travail protocolaire s’est donc concentré sur le routage et le transfert de valeur. Les listes de relays NIP-65 ont donné au modèle outbox émergent une source de vérité portable, tandis que les zaps NIP-57 reliaient events et identités aux reçus Lightning. Le changement d’étape était pratique : identité et publication avaient attiré les utilisateurs, mais le routage relay sélectif et l’interopérabilité des wallets permettaient au réseau élargi de devenir autre chose qu’un feed public surchargé.

Juin 2024 : signataires, gift wrap et mise à niveau de la messagerie

En juin 2024, la signature commençait à sortir des clients individuels. La spec NIP-46, nsecBunker et Amber donnaient aux apps web et Android des moyens de demander des signatures sans importer la clé secrète d’un utilisateur. Cela renversait une hypothèse initiale : la portabilité ne signifiait plus copier un nsec dans chaque client, mais laisser des signataires spécialisés imposer une frontière autour de celui-ci.

La messagerie changeait pour la même raison. NIP-17 combinait le chiffrement NIP-44 au gift wrapping NIP-59 pour réduire les métadonnées exposées par NIP-04, tandis que NIP-89 permettait aux clients de recommander des handlers pour les types d’events qu’ils ne rendaient pas. Les discussions sur MLS-over-Nostr commencèrent dans cet environnement. Vie privée et découverte d’applications devenaient des contrats entre clients, préparant les groupes privés et des apps plus riches propres à certains events plutôt qu’un client tentant de contenir chaque fonctionnalité.

Juin 2025 : Marmot, maturité de git-over-Nostr et longue traîne des clients

En juin 2025, MLS-over-Nostr disposait de la spec Marmot formelle et de White Noise comme implémentation publique. Les events git NIP-34, ngit et GitWorkshop avaient également mûri jusqu’à former un flux de revue de code utilisable. Ces projets partageaient une même étape de design : ils utilisaient les relays pour la coordination tout en déplaçant l’état sensible des groupes ou les objets de dépôt vers des couches spécialisées, plutôt que de traiter un client de notes texte comme l’application entière.

Le commerce et les médias ont suivi le même modèle. Les wallets NIP-60 et les nutzaps NIP-61 ont intégré l’état Cashu à des events portables ; Wavlake, Divine et les implémentations de marketplace NIP-99 utilisaient des kinds dédiés pour la musique, la vidéo et les annonces. Nostr ressemblait de moins en moins visiblement à « un réseau social » : les apps conservaient le substrat d’identité et de relays, mais introduisaient stockage, paiements, modération et présentation propres à leur domaine.

Juin 2026 : un mois riche en lancements

Juin 2026 a apporté des lancements qui traitaient Nostr comme un composant de produits plus vastes. Buzz a ouvert un modèle auto-hébergé d’espace de travail comme relay pour humains et agents ; Napplets a défini une frontière de confiance pour les apps composables sur Nostr et Blossom ; et Conduit a placé des apps de marketplace aux côtés de ses propres documents de protocole. Ces projets ne demandaient plus si des events signés pouvaient soutenir la collaboration. Ils déterminaient quel travail appartenait aux events, lequel relevait des blobs ou de l’état local, et quelles permissions un hôte devait conserver.

BitBlik utilisait Nostr pour un échange pair à pair entre fiat et Lightning, CodeDeck transportait des sessions de codage par des relays chiffrés, et Haven appliquait Marmot hors d’une messagerie conventionnelle. La distance avec le dépôt prototype de 2021 ne tient pas seulement au nombre de projets. C’est un changement d’abstraction : les équipes pouvaient commencer avec identité portable, découverte de relays, chiffrement et paiements comme composants existants, puis consacrer leur travail de design à la frontière propre à l’application située au-dessus.