Nostr Compass #46

Cette semaine : Mostro ajoute la réassociation d’identité signée. Amethyst apporte des sondages privés aux groupes Marmot ainsi qu’une synchronisation chiffrée des réglages entre appareils. Du côté de swift-nostr, une vérification refuse désormais de signer les events dont la clé publique ne correspond pas à celle du signataire. Nous terminons avec Six ans d’octobres Nostr, 2021–2026.

À la une

Mostro

Mostro, le démon d’échange pair-à-pair coordonné par Nostr, a publié la version 0.20.1. Elle ajoute la réassociation d’identité signée, que le numéro de la semaine dernière décrivait comme non implémentée, et livre les exports de réputation qui n’existaient jusqu’ici que dans le code source. L’identité liée signe une autorisation à usage unique désignant le nœud et la nouvelle identité, valable une heure au maximum. Le démon enregistre l’identifiant de l’event et bascule au moyen d’un compare-and-swap : une signature en échec ou une course perdue ne modifie donc rien. Les opérateurs disposent aussi d’une RPC auditée, accessible uniquement en loopback, qui exige un jeton d’authentification et un motif. La réassociation ne révoque pas les attestations déjà émises.

Rien ne confirme que les fusions ultérieures figurent dans une version publiée. Un fournisseur de parité fixe avec le dollar US, activable sur option, ajoute USDT, USDC et DOC au flux Nostr mostro-rates uniquement lorsque l’opérateur l’active. Ni les fournisseurs réseau ni les cotations de pièces relayées ne l’activent implicitement. Un correctif de suivi renomme le fournisseur et sa clé de configuration en pegged, en remplacement de la clé stablecoins, jamais publiée. Il cote aussi BTC, LBTC et RBTC à un taux fixe de 1:1 en sats et publie les taux sous forme d’events de kind 30078. Ces hypothèses de parité configurées ne garantissent ni la parité ni le règlement. Les vérifications de parité en direct restent en dehors de ce mécanisme. Par défaut, le fournisseur est désactivé. Les devises acceptées conditionnent toujours les ordres ; les travaux sur le client, le carnet du protocole et le garde-fou de parité sont distincts. Les timelocks des cautions fonctionnent désormais indépendamment de l’escrow. L’expiration annoncée des ordres est plafonnée, et la fenêtre de prise dans le carnet d’ordres se ferme avant qu’une caution puisse expirer. Les cautions de maker existantes de 144 blocs expirent lors de la mise à jour, et ces ordres doivent être recréés. Les échanges en cours et le mode Cashu ne sont pas affectés, mais certaines configurations d’opérateur refusent de démarrer tant que le timelock de caution n’a pas été ajusté.

Extension Nostr WoT

L’extension Nostr WoT, un signataire pour navigateur doté de fonctions de web of trust, a publié la version 0.8.15. Celle-ci propose une option pour créer la clé de récupération à partir de 256 bits d’entropie tirés des propres dés ou pièces de l’utilisateur. Les lancers de dés sont hachés avec SHA-256 et les lancers de pièce sont utilisés comme bits bruts, dans un onglet isolé qui n’affiche pas la phrase de récupération. Lorsque les relays sont injoignables, le processus d’intégration s’interrompt désormais après un délai. La version 0.8.16 a ajouté des autorisations permanentes pour l’authentification auprès des relays (NIP-42) : les utilisateurs peuvent approuver AUTH une seule fois pour tous les relays d’un site ou pour chaque site connecté (implémentation de l’authentification auprès des relays). Les refus au niveau d’un relay ou d’un site priment sur ces autorisations, et les révocations sont revérifiées avant la résolution des requêtes en file d’attente. Les portées larges relèvent toujours d’un choix explicite de l’utilisateur et ne s’appliquent jamais à HTTP Auth (NIP-98). La limite de la file d’attente reste fixée à cinq : les requêtes excédentaires échouent donc toujours et sont réessayées. Avec la version 0.8.18, l’import et la récupération fusionnent en un seul parcours qui détecte les formats de clé et affiche un aperçu de l’identité, et une récupération Nosskey compatible conserve la même identité, les comptes existants et les passkeys d’origine.

Le SDK distinct destiné aux développeurs, nostr-wot-sdk, a publié la version 3.0.1 avec la prise en charge stable d’identity 1.1. La récupération par passkey, y compris via Nosskey, conserve la pubkey d’origine, et le code du fournisseur, de la récupération et de la signature repose désormais sur une seule implémentation (code source de la récupération et du fournisseur du SDK). Les paquets de redirection dépréciés fonctionnent toujours, mais les intégrateurs devraient migrer vers les points d’entrée maintenus.

Amethyst

Amethyst, le client Nostr pour Android et ordinateur, a publié la version 1.20.0 avec des sondages privés et d’autres fonctions de groupes chiffrés Marmot. On y trouve des votes privés remplaçables, des emoji personnalisés chiffrés, la suppression de messages par les administrateurs et les signalements, ainsi que des médias rattachés à l’epoch courante du groupe. Après la revue, l’auteur n’a pas relancé les vérifications d’interopérabilité entre clients et n’a pas testé la modification manuellement sur Android. Les clés de cache des branches concurrentes partageant un même numéro d’epoch subsistent, et les clés des médias chiffrés peuvent survivre aux messages éphémères. La synchronisation des réglages stocke six groupes de réglages de l’application sous forme de données NIP-78 chiffrées. Clés, signataires, portefeuilles, notifications, decks et marqueurs de lecture restent sur chaque appareil. La première modification d’un réglage publie les six groupes. Un compte en lecture seule conserve ses réglages en local, et le comportement sur deux appareils de signature n’a pas été vérifié.

Sur ordinateur, les notifications système suivent le filtre Notifications et ignorent les gift wraps extérieurs jetables ainsi que les DM mis en sourdine. Les tags d non fiables de plus de 255 octets ne provoquent plus d’erreurs. Les recherches par kind n’interrogent que les relays connectés et les relays de recherche du compte, à raison de 200 events au plus chacun. Dans les applications, la gestion JSON Kite de Quartz est utilisée pour les trames, les events, les filtres et les messages NIP-46 et NIP-55, même si la signature via ces deux protocoles n’a pas été vérifiée sur des appareils. Une séparation des bibliothèques ultérieure déplace dans des bibliothèques partagées les règles des protocoles Marmot et cordn dont d’autres clients auraient besoin.

Du code fusionné après la 1.20.0, qui ne figure pas encore dans une version publiée, fait tourner le chemin de réception Marmot de l’application sur la bibliothèque partagée. Chaque message déchiffré est persisté de manière idempotente. Au moment de rejoindre un groupe, une référence de départ est enregistrée afin que le premier changement de composition affiche sa ligne. Un message de kind 445 arrivé avant son commit est mis en attente puis rejoué plus tard, et le rattrapage côté administrateur commite les départs préparés. amy cordn migrate export désactive les commandes de session de l’ancienne installation jusqu’à un import ou jusqu’à la nouvelle commande de reprise. L’auteur a exécuté des tests amy en loopback ainsi que des tests de bibliothèque sur des copies locales. Il n’a ni éprouvé manuellement le chemin de réception de l’application réelle, ni exécuté la suite d’interopérabilité Marmot. Une mise à jour incompatible du format de napplet NIP-5D proposé lit le hash du manifeste d’une napplet comme un unique artefact /index.html, en remplacement de l’ancien agrégat de chemins ; les anciens bundles doivent donc être republiés. Les domaines NAP requis mais indisponibles échouent en mode fermé, tandis que les domaines optionnels restent absents. Les icônes font l’objet de vérifications de hash et de décodeur, le stockage est partitionné par kind de manifeste, artefact et instantané, et les blobs de ressources utilisent un base64 canonique. Aucun test manuel sur appareil, aucun test entre clients ni aucune publication sur des relays réels n’ont été effectués.

Les refus dans un signataire externe sont désormais gérés dans des coroutines qui n’avaient aucune protection, si bien qu’ils ne font plus planter l’application. Les livres numériques, magazines et numéros PressStr (kinds 33953, 34609 et 39731) s’affichent désormais. Un lecteur intégré ouvre les PDF, et les EPUB sont confiés au gestionnaire du système. Les cartes indiquent le type et la taille du fichier, ne téléchargent jamais un gros PDF simplement pour en afficher un aperçu, et ne récupèrent les numéros qu’auprès de l’auteur du magazine. L’auteur n’a pas fait état de tests sur appareil Android pour cette modification. Quand les aperçus enrichis sont désactivés, les factures et les LNURL apparaissent sous forme d’étiquettes compactes copiables, sans bouton Payer, et les cartes de facture affichent désormais leur heure d’expiration. amy gift wrap date désormais le seal et le wrap à des moments aléatoires distincts, chacun jusqu’à deux jours en arrière. --no-backdate désactive ce comportement. Le chemin des DM classiques reçoit son correctif séparément, dans Quartz. Sur ordinateur, chaque carte vidéo gère sa propre lecture : des cartes partageant la même URL ne s’approprient plus la vidéo les unes des autres. L’auteur l’a testé sur macOS, mais pas avec un cache froid. Un correctif proposé pour les liens sous Windows ouvre les liens via rundll32 en passant par son chemin complet et se rabat sur AWT. Faute d’avoir reproduit la cause racine, il s’agit d’un correctif probable et non confirmé.

Myco ajoute un stockage chiffré pour les napplets et des avis de mise à jour signés

Myco, un hôte Android pour les napplets Nostr, a publié les versions 0.12.0 et 0.12.1. Les napplets peuvent désormais stocker, via le runtime, des données NIP-44 auto-chiffrées, mais les applications disposant d’autorisations de lecture relay, outbox ou mesh peuvent voir le texte en clair : les données ne sont donc pas isolées par application. Les utilisateurs qui se sont connectés auparavant avec Amber doivent se reconnecter pour accorder les nouvelles autorisations de chiffrement et de déchiffrement. Signés par un éditeur épinglé, les avis de mise à jour n’atteignent que les appareils qui exécutent déjà la 0.12. En ligne, Myco peut consulter Zapstore quotidiennement, ainsi que Circle, tandis que le mode mesh seul n’interroge que Circle, ce qui remplace la pause initiale. Un rail Blossom local choisi explicitement conserve les fichiers sur l’appareil, sans serveur, dans la limite de 64 Mio par application et par jour. En cas d’échec d’envoi vers un serveur par défaut approuvé, une copie locale est également conservée. Aucun de ces deux chemins ne supprime les métadonnées EXIF. Ces versions ajoutent aussi la prise en charge d’Android TV et un sélecteur de fichiers NAPFS dans lequel l’utilisateur choisit les fichiers.

Versions publiées

Monostr

Monostr, un client social Nostr pour Android, a publié la version 0.26.0, sa plus récente. Les vidéos d’une durée maximale de deux minutes sont désormais compressées sur l’appareil, et les métadonnées de localisation sont supprimées. Découvrir, la recherche et le processus d’intégration proposent des listes d’abonnements sélectionnées. Dans les fils de discussion et les notifications apparaissent désormais les réponses du Fediverse envoyées sous forme de commentaires NIP-22.

Les fonctions de la version 0.25.0 sont conservées. Lorsque le message parent d’une réponse est introuvable, l’application cherche dans les indications de relays de la réponse et dans les relays de l’auteur du parent, ce qui implique de se connecter brièvement à des relays extérieurs à la liste de l’utilisateur. Par ailleurs, les relays et les abonnements aux messages en direct se reconnectent chaque fois que l’appareil change de réseau.

Sidecar

Sidecar, une extension de navigateur et signataire Nostr, a publié la version 1.16.3. L’éditeur et l’outil de surlignage publient désormais sur les relays propres au compte et ne comptent que les relays qui accusent réception de l’event, puis renvoient vers ces relays par un lien. Un accusé de réception montre que le relay a accepté l’event, pas qu’il le conservera. L’éditeur étendu ne se rabat plus sur les relays par défaut définis dans les Réglages. Chaque relay dispose de son propre délai de 12 secondes. Seule une publication qui échoue sur tous les relays est réessayée, une seule fois, sur de nouveaux sockets. Les résultats de sondage interrogent aussi quatre relays publics pour récupérer les bulletins. Une modification fusionnée après le tag ajoute un relay supplémentaire afin de capter les bulletins déposés hors des relays habituels. Sur un sondage en cours, le décompte est ainsi passé de 21 à 23 votes. Ce n’est que le résultat d’un seul sondage, qui ne dit rien de l’exhaustivité à l’échelle du réseau. Le décompte n’autorise toujours qu’un bulletin par personne et ignore les bulletins déposés après la clôture du sondage. La version antérieure 1.16.1 limite les autorisations de signature permanentes au compte et au site qui les ont approuvées, et à un seul enregistrement adressable lorsque l’event comporte un tag d. Jamais les autorisations ne couvrent le chiffrement ni le déchiffrement. Le profil ainsi que les listes d’abonnements, de mises en sourdine et de relays restent hors de toute autorisation. Les suppressions, les zap requests, l’AUTH des relays et le contrôle du portefeuille sont également exclus. Une extension verrouillée demande toujours le code PIN. Révoquer une autorisation ou oublier un site efface ses autorisations et ses fenêtres d’approbation.

Une pull request ouverte distincte ferait compter le paiement d’une offre CLINK comme un zap. Placée sous Unreleased dans le changelog, elle n’implémente pas Debits. Le panneau d’offre transmettrait une zap request signée de kind 9734 avec payer_data, afin que le service puisse publier un reçu de kind 9735. Les reçus iraient d’abord vers le relay de l’offre, puis vers les relays du destinataire, dédupliqués et plafonnés à six. Les relays du payeur ne sont pas utilisés. Si une offre répond avec le code 3 et une offre de remplacement décodable, Sidecar la suivrait une fois, avec une nouvelle requête et une nouvelle signature. Il n’écrirait jamais dans le profil du destinataire. À la date de clôture, la modification n’était toujours pas fusionnée.

Roadbeacon

Roadbeacon est un client de signalement de localisation, auparavant nommé Roadstr et distinct de l’application indépendante Roadstr. Il a publié la version 0.4.0 sous son nouveau nom en tant que nouveau paquet, avec un nouveau format d’event. Signalements et votes utilisent désormais les kinds partagés et interopérables 1315 et 1316. Les coordonnées reposent sur des trames d’entiers reconstructibles à l’identique, et la version web valide les signatures. Le paquet s’installe à côté de l’ancien sans migrer les données. Les events plus anciens restent valides sur les relays, mais le nouveau client ne peut pas les lire.

Jumble

Jumble, un client web Nostr, a publié la v26.10.1. Parmi les nouveautés figurent un éditeur d’articles longs et des mots masqués synchronisés entre appareils. On y trouve aussi des notifications système, ainsi que des lecteurs pour les contenus de groupe et Git. Les changements concernant les publications en attente et la mise en page, présentés dans un numéro récent, sont livrés avec cette version.

Un commit fusionné après la publication ajoute un réglage optionnel de réponse NIP-22. Désactivé par défaut, il est enregistré comme préférence locale. Une fois le réglage activé, les réponses aux notes textuelles de kind 1 partent sous forme de commentaires de kind 1111. Les fils de kind 1111 existants conservent leur racine. Les commentaires sur d’autres kinds ou sur du contenu externe restent en kind 1111. Si le réglage est désactivé, les réponses conservent l’ancien comportement en kind 1. L’application avertit que certains clients pourraient ne pas afficher ces commentaires.

nostr-idb

nostr-idb est une bibliothèque qui met en cache les events Nostr dans l’IndexedDB du navigateur. Elle a publié la version 5.1.1 avec des correctifs de requêtes. Les recherches par ID exact fonctionnent désormais pour les events remplaçables et adressables. Chaque contrainte de filtre et chaque limite par filtre s’appliquent maintenant, y compris aux écritures en attente et à l’historique des abonnements. L’élagage du cache et les events à horodatage nul sont corrigés. La taille du cache en mémoire, maxMemoryEvents, vaut par défaut maxEvents, et la valeur zéro le désactive.

Manent

Manent, un carnet chiffré qui se synchronise via Nostr, a publié la version 3.0.0 avec des notes vocales. Comme les autres notes, les enregistrements se synchronisent sous forme chiffrée. Les transcriptions sont générées hors ligne avec Whisper, une fois que l’application a téléchargé un modèle. Cette version livre aussi la récupération de l’authentification auprès des relays, déjà évoquée lorsqu’elle n’existait que dans le code source. Elle arrive désormais via la version 0.10.1 de NDK, la bibliothèque Nostr Development Kit.

NoorNote

NoorNote, un client Nostr pour ordinateur et web, a publié la version 1.9.2 avec une recherche plein texte locale à l’appareil. Elle porte sur les notes et les messages directs, et s’accompagne d’un mode cache seul. Dans la 1.9.2, une régression liée à l’effet de verre transparent rendait les menus déroulants, les menus et les notifications toast difficiles à lire. La version 1.9.3 leur rend leur lisibilité. Ces versions livrent également le filtre des horodatages futurs, qui n’existait auparavant que dans le code source. Désormais, un profil qui ne parvient pas à se charger reste en cours de chargement jusqu’à ce que son absence soit confirmée.

Earthly

Earthly, un client Nostr de création de cartes, a publié la version 0.1.22 avec des correctifs pour les relays et les paiements. L’authentification auprès des relays est désormais liée au compte actif. Pour les abonnements et les comptages récupérés, un comptage indisponible se distingue maintenant d’un vrai zéro. Ces comptages sont conservés d’une révision de carte à l’autre. Les totaux de zaps proviennent de véritables reçus de zap. Avant de dépenser, l’application attend la fin de la synchronisation du portefeuille. Les paiements en conditions réelles via Nostr Wallet Connect et via un mint n’ont toujours pas été testés (intégration de la version).

Chama

Chama, un client d’échange sous séquestre bâti sur des events Nostr, a publié la version 6.4.31. Celle-ci vérifie les sauvegardes de seed avant le financement. La clé d’échange on-chain de cet appareil ne peut entrer dans des conditions CREATE, JOIN ou de dépôt signées qu’après une étape préalable : un relay doit renvoyer la sauvegarde de seed signée que l’appareil a ouverte. Si la sauvegarde est manquante, retirée ou conflictuelle, l’échange est bloqué. Lors d’une nouvelle tentative, l’application renvoie à l’identique la sauvegarde enregistrée, sans générer de nouvelle seed. Cette relecture atteste la disponibilité à ce moment-là, pas la persistance. Les annonces à plusieurs unités utilisent désormais des commandes avec quantité.

La version 6.4.30 ne compte les commandes de vitrine que si les conditions signées par l’acheteur correspondent à l’annonce signée. Elle protège aussi contre les events tardifs de tiers sur les échanges dont le CREATE signé est daté du 1er décembre 2026 ou plus tard. Les échanges antérieurs conservent l’ancien comportement d’expiration (validation de l’expiration des échanges et de la vitrine).

Une pull request ouverte, non fusionnée à la date limite de nos sources, permettrait une seule sauvegarde de seed de portefeuille par identité. Au démarrage, la première création serait sérialisée au moyen d’une file d’attente interne à la page et de Web Locks. L’état du relay serait ensuite relu. Des navigateurs distincts ne reposent que sur cette relecture. Ce changement ne couvre ni un verrou distribué ni la réparation des sauvegardes conflictuelles existantes. Nous n’avons testé aucun parcours impliquant de l’argent.

Linky

Linky, un portefeuille Cashu qui se synchronise via Nostr, a ajouté des transferts on-chain expérimentaux, activables par un flag. Ils figurent dans la version 26.10.7 et dans la build Android 26.10.8. Un opérateur humain configuré traite les demandes d’envoi et de réception sous 24 heures, moyennant des frais. Les transferts ne sont donc ni atomiques ni trustless. Le changement de coordination s’appuie sur des messages d’application Nostr personnalisés et sur une configuration d’opérateur NIP-78. Il ajoute aussi un nouveau périmètre de synchronisation de liens. Ce périmètre synchronise les envois d’ecash en attente de l’opérateur. Ainsi, ses autres appareils ne peuvent pas payer, rembourser ou régler deux fois le même envoi. Une réception n’aboutit que lorsque le portefeuille de l’utilisateur reçoit le montant Cashu correspondant. L’opérateur et l’utilisateur ne se trouvent que sur les relays recommandés, et non via les listes de relays NIP-65 ou les listes de boîtes de réception de DM. Si tous les relays communs sont perdus, la coordination peut donc échouer.

LaWallet

LaWallet, un service de portefeuille et de compte bâti sur Nostr Wallet Connect, a publié la version 2.9.0 et la bêta Android 1.2.0. Toutes deux ajoutent une récupération assistée par carte NFC vers un nouvel identifiant de connexion Nostr (flux de récupération natif). Pour récupérer un compte, il faut un passage de carte récent, vérifié cryptographiquement. Il faut aussi un code QR de récupération à usage unique, valable 15 minutes. Les actifs sont déplacés en une seule transaction, mais les rôles ne sont pas transférés. Les anciennes autorisations OAuth sont révoquées et l’ancien identifiant de connexion est laissé vide. La récupération par carte est activée par défaut. Les titulaires de compte peuvent la désactiver dans les paramètres de sécurité et révoquer les codes en cours. Un portefeuille injoignable affiche désormais un solde nul, ce qui ne signifie pas qu’il est vide. Dans les builds dotées d’un point de terminaison de rapport, la bêta Android force l’activation des rapports d’erreurs Sentry, même si l’utilisateur les avait refusés auparavant. Les builds locales et F-Droid n’ont pas de point de terminaison.

Du code source a été fusionné après le tag. Avec ce code, le callback de la carte peut renvoyer OK avant le règlement NWC lorsque le solde couvre le paiement. Les systèmes de point de vente doivent donc confirmer eux-mêmes leur propre facture. Un plafond de paiement fixe remplace la limite fondée sur le solde.

Une pull request ouverte, non fusionnée à la date limite de nos sources, permettrait de se connecter avec des passkeys compatibles issues d’autres applications. La connexion passerait par un fournisseur configuré ou par la récupération Nosskey. Le compte serait confirmé avant l’émission d’une session temporaire à durée limitée (#386). Un fournisseur peut signer sans importer la clé privée. L’importation est un choix distinct, qui doit être confirmé. Les captures d’écran de la pull request montrent des réponses de démonstration simulées. Elles ne prouvent pas qu’une connexion cross-origin fonctionne en conditions réelles.

Une autre fusion n’a pas non plus été confirmée dans une version publiée. Elle empêche le callback NWC et d’adresse Lightning de remplacer le portefeuille distant d’un utilisateur sur la seule base d’une erreur make_invoice. Une vérification de disponibilité et de solde peut à la place conserver le portefeuille et renvoyer une erreur 503. Le service mémorise aussi les soldes et l’état des fonds protégés, et ajoute une option de restauration (Restore). Ses seuils limitent toutefois ce qu’il peut protéger, tout comme l’historique antérieur, qui reste inconnu. Il ne garantit donc pas la sécurité de tous les fonds. Nous n’affirmons ni qu’un déploiement a eu lieu ni que des comptes utilisateurs ont été restaurés.

KithMoot

KithMoot, une application basée sur Nostr pour le chat en salon et les appels, fonctionne désormais sans les services publics de son éditeur. Entre le 21 et le 23 octobre, l’éditeur a retiré les codes de réunion publics, le service TURN partagé, les envois de fichiers et la lecture des fichiers stockés. Les codes de réunion sont remplacés par des liens d’invitation. Par défaut, les fichiers publics passent par Yakihonne, avec un avis lors du premier envoi, mais les utilisateurs peuvent choisir leur propre serveur. Les appels tentent toujours d’abord une connexion directe. Hide IP, en revanche, exige un serveur TURN fonctionnel et ne revient jamais à une connexion directe.

Dans la version de bureau 0.1.102 et la version Android 0.6.106, le STUN public de Cloudflare remplace celui de l’éditeur. Les utilisateurs peuvent aussi définir le leur. Les copies de sauvegarde servies ont été supprimées, mais les copies chiffrées hors ligne subsistent. Les versions de bureau 0.1.109 et Android 0.6.121 bloquent le chat lorsque les identifiants de l’appareil expirent, tout en conservant les brouillons. Elles lisent aussi le nom de profil de l’utilisateur lui-même séparément des recherches facultatives dans l’annuaire. Le moteur d’appel ordinaire n’est pas passé à l’aperçu expérimental du SDK temps réel. Le candidat de groupe MLS reste quant à lui désactivé par défaut.

La version de bureau 0.1.110 ajoute des visionneuses de pièces jointes en bac à sable pour les images, l’audio, la vidéo et les PDF, sur ordinateur et sur le web. Sur ordinateur, elles s’exécutent dans un renderer Electron dédié et non persistant. Ce renderer n’a ni accès à Node, ni stockage applicatif, ni accès au réseau externe. Le streaming est borné. Les visionneuses sont nettoyées à leur fermeture ou lorsqu’un message est rétracté. Deux exécutions se sont bloquées : celle de WebKit dans la pull request et une exécution supplémentaire avec un SVG hostile sur la version packagée. Nous ne les présentons pas comme vérifiées, et rien de tout cela ne constitue une certification de sécurité. La build macOS est notariée, tandis que celle pour Windows reste un aperçu non signé.

Une fusion ultérieure, dont la présence dans la 0.1.110 n’est pas démontrée, renouvelle les identifiants d’appareil expirés selon l’heure réelle de l’horloge. Le renouvellement intervient après une mise en veille et avant l’envoi. Le brouillon est conservé pendant que le signataire répond. Ce changement fait suite à un incident chez un testeur : ses identifiants ont expiré pendant la nuit sur un ordinateur portable en veille. Une requête au signataire qui ne revient jamais maintient toujours le renouvellement en suspens. Android présente par ailleurs une lacune de renouvellement distincte, non résolue. Une pull request ouverte, non fusionnée à la date limite de nos sources, mettrait en pause « Help other people connect ». Selon son auteur, l’application accepte une paire d’assistance entre pairs même si celle-ci ne transporte pas ses médias. Le repli vers un redirecteur ou vers TURN peut alors ne pas se produire, ce qui laisse un appel silencieux. La valeur par défaut de la bibliothèque resterait inchangée.

Marmot TS

marmot-ts, une bibliothèque TypeScript pour le protocole de messagerie de groupe chiffrée Marmot, a livré la v0.8.0 et la v0.9.0. Ces deux versions comportent des changements incompatibles. Les médias chiffrés V2 ajoutent une liaison à la source et déchiffrent les médias différés après un redémarrage. Les descripteurs d’envoi Blossom, les destinations et le texte chiffré sont validés avant la signature. L’historique des groupes persistés est récupéré rétroactivement par pages, avec de nouvelles tentatives pour les commits incertains. Les applications doivent désormais fournir des stores durables d’ingestion et de retour arrière. Leurs adaptateurs doivent rejeter les lectures échouées ou expirées. Les anciens groupes V1 doivent être recréés, car les helpers V1 ne sont conservés que pour l’historique.

Du code source fusionné ultérieurement dote les observateurs de key-packages, d’invitations et d’historique d’un AbortSignal facultatif. Leurs écouteurs sont rapidement nettoyés lors d’un retour, d’une exception levée ou d’une libération, même si une lecture de stockage est encore en cours. Lorsqu’un consommateur est en pause, les changements qui surviennent sont mémorisés puis fusionnés en une seule mise à jour. Après l’annulation, la lecture sous-jacente sur le backend se poursuit. Les échecs de requête provoquent toujours un rejet. Ce changement ne certifie pas l’interopérabilité à l’exécution.

Client de messagerie Nostr

nostr-mail-client, un client de messagerie électronique bâti sur Nostr, a publié la v0.19.0. Cette version propose un flux de connexion unique pour bunker, nsec et ncryptsec, qui inclut l’approbation de l’auth_url d’un signataire distant. Sans nouvelle connexion, le client suit désormais les modifications des listes de relays DM, de boîte de réception, de boîte d’envoi et privés. Il déduplique les notifications de courrier pendant la synchronisation. Les signatures d’e-mail sont synchronisées entre appareils sous forme chiffrée. Les pièces jointes d’e-mail qui dépassent le plafond de 25 Mo sont écartées, et un avis l’indique. Une adresse uniquement Nostr ne peut pas recevoir les réponses envoyées par e-mail.

CLI de conformité Napplet

napplet/web regroupe les paquets web et l’outillage des napplets, des applications web distribuées sous forme d’events Nostr signés. Le travail de vérification présenté dans le dernier numéro est désormais livré dans le paquet versionné @napplet/conformance-cli 0.4.0. Avant une exécution sans interface (headless), la CLI vérifie l’ID d’event du manifeste, sa signature et le hash exact du HTML brut. Elle signale les échecs de liaison à l’exécution, d’espace de noms et d’installation séparément des erreurs de napplet. Le repli intégré ne couvre que RESOURCE et GAMEPAD. Les hôtes personnalisés doivent donc transmettre explicitement les entrées de source et d’instantané.

La commande deploy de Napplet prépare désormais par défaut les fiches Zapstore, en réalisant des captures d’écran de chaque build sélectionné et en préparant un event Software Application de kind 32267 ; --no-screenshot et --no-zapstore désactivent ces étapes. Préparer des métadonnées ne revient pas à publier une release, et cette modification n’ajoute aucun event de release de paquet ni d’asset.

napplet-soy

napplet-soy, un espace de travail pour construire et publier des napplets, a tagué son outil en ligne de commande soyli en v0.31.2 et v0.31.3, qui ne constituent pas un déploiement Studio. Une fois la livraison Git confirmée, la publication marque comme fusionnées les propositions de collaboration Git (NIP-34) incluses, après avoir vérifié l’ascendance exacte et la cible ainsi que la révision courante, et elle réutilise les statuts présignés lors d’une reprise. Les révisions plus récentes d’une proposition restent ouvertes, et un tag contenant un commit n’est pas considéré comme la preuve que la branche cible l’a fusionné. Le code source derrière ces tags ajoute aussi une première vue de portefeuille Cashu (NIP-60) dans un espace de travail Manage unifié et maintient les napplets en cours d’exécution lors des changements d’onglet. Le programme de mise à jour de la version antérieure v0.31.1 suit l’identifiant stable du dépôt GitHub, si bien que les installations conservent leurs comptes et leurs projets lors du passage à Soytec. Les installations dotées de l’ancien programme de mise à jour doivent exécuter l’installateur une fois.

Le portefeuille Cashu NIP-60 encaisse les nutzaps NIP-61 et enregistre les sorties de mint préparées ainsi que les mises à jour de relay signées avant de les exécuter, de sorte que les requêtes incertaines peuvent être récupérées sans répéter un paiement. Les portefeuilles restent isolés par compte et les onglets du navigateur ne peuvent pas dépenser simultanément, mais les tests ont utilisé de faux mints et l’interopérabilité avec de l’argent réel n’est pas vérifiée. Les pages de contribution prennent désormais en charge les zaps ciblant l’auteur, qui paient l’auteur signataire de la release ou de la proposition choisie.

Le tag soyli v0.31.4 mentionne l’historique des contributions des auteurs et les zaps, ainsi que des changements liés à l’état prêt (readiness) NIP-5D, à l’audio et aux tests. Les appels de domaine n’attendent plus que le shell signale qu’il est prêt. Un hôte partagé coordonne l’audio dont les napplets sont propriétaires via NAPMEDIA, sans assouplir l’isolation des iframes. Ce tag n’est pas non plus un déploiement Studio. Cinq vérifications configurées ont réussi et cinq ont été ignorées. La conformité complète reste non démontrée, et les apps réparées attendent d’être republiées.

Pakstr

Pakstr, un outil en ligne de commande qui construit des apps Android et les publie sur Nostr, a tagué la v0.29.1. Avant la publication, il lit le certificat de signataire qu’un APK revendique dans son bloc de signature v2 ou v3 et compare son empreinte SHA-256 au sidecar attendu et à la preuve d’identité (revue de la publication). Les APK non signés, malformés ou à certificats multiples sont refusés, les sidecars obsolètes sont supprimés lors d’une reconstruction, et un nsec de publication invalide échoue avant le build. L’analyseur ne vérifie pas la signature de l’APK elle-même, laissée à Android et à apksigner ; il détecte donc les builds obsolètes, non signés ou dotés du mauvais certificat, mais ne peut pas prouver qu’un build n’est pas falsifié. ZIP64, les signataires multiples et la rotation de clés ne sont pas pris en charge.

MDK

MDK, le SDK et runtime des groupes chiffrés Marmot, a publié la v0.14.0 stable. Cette version apporte la transmission (handoff) et le stockage des fichiers multimédias, un rattrapage hors ligne ordonné, la préservation des listes de suivi et le changement de clé (rekeying) brut des clés SQLCipher, sans modification de MLS ni du format filaire. Le guide de release 0.14.0 et le guide d’intégration 0.14.0 exigent que les apps livrent un ensemble cohérent de bindings, de bibliothèque native et d’en-têtes, que MarmotKit 0.14.0 empaquette pour Apple et Android. Sur les plateformes Apple, le binaire est un XCFramework statique brut : les apps l’associent donc au binding Swift correspondant et copient sa ressource PrivacyInfo.xcprivacy dans le produit wrapper qu’elles désignent ; réussir les vérifications d’archive de la release ne prouve pas qu’un export App Store aboutira. La base de données et le stockage migrent dans un seul sens, en changeant la clé de chaque page une fois. Les retours à une version antérieure restent non pris en charge. Les médias et les données de transmission du compte doivent être exclus des sauvegardes. L’agent WN reste en préversion, et les crates ne sont pas sur crates.io. Des limites connues persistent : l’historique arrivant avec plus de cinq epochs de retard devient indéchiffrable sans avertissement. Les médias perdus en transit lors d’un passage d’epoch ne sont pas corrigés ; un problème de compatibilité d’ordonnancement du contexte de groupe demeure également.

L’ascendance des tags montre que le tag stable embarque aussi cinq modifications liées à la synchronisation et aux médias. Les rafraîchissements d’abonnements de groupe ne réempaquettent que les familles de lots REQ modifiées ; une famille en échec conserve ses routes actives pour la synchronisation suivante, tandis que le commit partiel signale toujours une synchronisation échouée. Les envois et les modifications de groupe continuent d’entrer dans la file durable lorsqu’un rafraîchissement préalable à l’envoi échoue, même si l’achèvement peut rester CompletionUnknown. Le REQ d’un relay injoignable reste dû sous le même ID jusqu’à la reconnexion ; une couverture dégradée ne constitue donc pas un historique complet. L’approbation de réparation de l’onboarding attend toutes les sources de découverte et renvoie RetryableFailure lorsqu’une source déclarée expire. La rétention des médias par compte, activable sur option, de Keep forever jusqu’à 30 jours, nettoie les médias selon leur date de réception ou de dernier retéléchargement explicite, et non de dernière consultation, sans supprimer l’historique des messages. Les hôtes doivent gérer la nouvelle valeur FFI CleanedBySetting.

Après le tag, le code source fusionné a poursuivi des travaux sur le multi-appareil et le push qu’aucune release ne revendique encore. Les demandes d’historique postérieures à l’adhésion persistent à travers les commits et les redémarrages, comblant un trou entre le Welcome et les messages en direct. Le décompte des membres par compte met fin aux fausses notifications concernant une personne lorsqu’un deuxième appareil rejoint ou quitte le groupe, et le traitement des Welcome ignore les livraisons destinées aux appareils frères sans faire échouer l’adhésion ni consommer de clé. Pour le push, MDK diffuse par gossip les enregistrements et tombstones signés par le propriétaire après les commits sur un nouveau stockage de gossip push, repartage les jetons après des ajouts de membres et notifie tous les appareils d’un destinataire, bien que les propres appareils de l’expéditeur ne reçoivent toujours aucune notification. Un nouveau remplissage aléatoire à chaque déclenchement empêche la déduplication de supprimer les réveils. La publication des KeyPackages adopte les propres listes de relays du compte et échoue, en préservant la liste stockée, si une liste est incomplète ou ne contient aucun relay utilisable. Des statuts typés d’epoch obsolète et de média en attente de résolution indiquent aux apps s’il faut téléverser à nouveau ou synchroniser puis renvoyer, et les changements d’état de transfert arrivent immédiatement, avec une progression en octets regroupée par lots.

Le code source plus récent relatif aux appareils de compte représente une avancée vers une release ultérieure, pas une 0.15 stable. Trois nightlies du 28 octobre, étiquetées comme réservées aux tests, sont épinglées au commit b8d0a49, antérieur à des fusions ultérieures ; leurs assets ne contiennent donc pas l’ensemble de ce code. MDK sélectionne des KeyPackages compatibles par appareil pour au plus 20 appareils récents par compte, et la déconnexion ne retire que l’emplacement de publication de cet appareil. Les paquets nouvellement créés durent 30 jours plus une heure et sont rafraîchis six à sept jours après leur publication. La découverte cherche chaque appareil, mais des défaillances de relay peuvent en omettre certains ; réinviter peut aider, sans garantie de récupération automatique. Des vérifications de capacités authentifiées par feuille remplacent le cache par compte. Les nouveaux groupes exigent le composant account-devices 0x800d lorsque tous les fondateurs le prennent en charge, et les appareils mis à niveau l’annoncent désormais. Ces groupes rejettent les appareils plus anciens qui en sont dépourvus, tandis que les groupes existants restent inchangés. Sous cette exigence, MDK rejette les données de composant, les feuilles non prises en charge, plus de 20 feuilles par compte et les tentatives de supprimer l’exigence, laissant les groupes hérités et ceux sans cette exigence tels qu’ils étaient. Par ailleurs, il refuse les données initiales fournies par l’hôte pour les composants d’app dont le schéma ne comporte aucune donnée, avant la création de tout groupe, Welcome ou event.

Dans les groupes 0x800d, le moteur obtient une autorité d’ajout et de retrait sur son propre compte, avec une classification des commits tenant compte de l’état parent, qui distingue les commits d’auto-mise à jour, d’auto-retrait, du même compte et d’administrateur, le privilège du même compte exigeant des propositions par valeur. Le traitement correspondant des Welcome accepte les Welcome du même compte uniquement dans ces groupes et seulement après les vérifications de l’état des composants et de la signature ; les autres groupes nécessitent toujours un administrateur actif. Les intentions d’envoi d’ajout et de retrait sur son propre compte obtiennent un tour équitable dans l’ordonnanceur, mais les API des apps n’exposent pas encore les intentions d’envoi du même compte. Le retrait de la propre feuille d’un appareil décide désormais de son appartenance locale : la présence d’un appareil frère ne permet donc plus à un appareil retiré de conserver ses actions de membre.

Le gossip push ajoute des annonces kind 447 mises en file durable, portant des préfixes de condensé de 8 octets des enregistrements et des tombstones, envoyées à l’adhésion, lors d’un changement d’enregistrement et selon une cadence de messages de sept jours, et les pairs réparent les enregistrements manquants signés par le propriétaire au moyen de réponses classées et échelonnées, avec suppression des doublons et une limite de 24 heures par feuille. En récupération, cut et cancel n’inventent plus de nouvelle perte, et 24 tentatives sans progrès mettent une obligation en attente derrière un avertissement d’historique incomplet. Le registre de couverture ne fonctionne que comme enregistreur fantôme, tandis qu’un balayage découpé dans le temps reprend des tranches en commençant par les plus anciennes, sans ordonnanceur de production pour l’instant. Les fichiers d’audit, activables sur option, expirent 30 jours après la dernière écriture, avec un nettoyage au démarrage et toutes les heures. La suppression peut intervenir un jour plus tard ; le journal de sécurité distinct consacré aux révélations de clés est exclu de cette expiration.

Un crate d’appairage utilise un X25519 éphémère, un engagement, une comparaison de sept emojis que l’utilisateur vérifie sur les deux écrans, et des confirmations HMAC aboutissant à un ConfirmedLink. Son adaptateur filaire ne couvre que le transport et reste désactivé par défaut en attendant une spécification ; l’interface utilisateur ainsi que les suites concernant le Welcome et le lien de groupe sont inachevées, et l’interopérabilité de cette implémentation reste non vérifiée. Le code source du device-roster 0x800e applique des mises à jour différentielles à un groupe caché à compte unique, mais annoncer 0x800e nécessite une dérogation de politique de test ; les builds de production ne peuvent donc pas encore créer ni rejoindre un groupe d’appareils.

D’autres propositions MDK restent ouvertes. L’une cesserait de considérer une fin de NIP-67 comme la preuve d’une couverture complète, car le balayage non planifié n’offre aucune garantie d’exhaustivité. D’autres ajouteraient le rejeu de points de contrôle, la réadhésion automatique et l’activation de 0x800d dans les groupes existants. Trois propositions antérieures d’API native sont toujours ouvertes selon une vérification récente de leur statut. La récupération des pièces jointes historiques inspecterait les emplacements sources et vérifierait le condensé authentifié et l’expiration avant d’écrire les octets vérifiés dans un fichier privé sous bail, en gardant la timeline sans accès réseau ; une copie livrée est un instantané qui ne peut pas être révoqué. Des handles de sélection de discussions à l’échelle d’un filtre couvriraient toutes les discussions correspondant à un filtre au-delà de la page chargée, en excluant les arrivées ultérieures, et la sélection des administrateurs fondateurs pour la création de groupes wn-agent choisirait des administrateurs fondateurs invités et rejetterait les non-membres avant le téléversement.

nosfry

nosfry, un relay Nostr écrit en Rust, a publié nosfry v0.2.0 pour ses éditions native et Workers/SQL. Cette version apporte des fonctionnalités non publiées en v0.1 : la suppression NIP-09, l’expiration NIP-40, NIP-42 AUTH avec les events protégés NIP-70, COUNT NIP-45, la synchronisation Negentropy NIP-77, les requêtes de disparition NIP-62 et l’API d’administration NIP-86. Elle ajoute aussi des abonnements bornés avec un budget sortant et une politique d’écriture, et présente permessage-deflate comme activé par défaut. Ses affirmations de performance et de conformité ne sont pas reproduites de manière indépendante, et elle ne prétend pas interopérer avec toutes les implémentations.

Quatre modifications de durcissement ont été fusionnées le 25 octobre, après le tag 0.3, et ne figurent dans aucun binaire publié. Les compartiments de connexions et de débit des workers regroupent les adresses IPv6 par /64, tandis que la liste de blocage d’IP NIP-86 continue de correspondre aux adresses exactes (#78), et les analyses NEG-OPEN imputent leur consommation au budget mémoire global de synchronisation par paliers de 1024 enregistrements pendant la collecte (#73). Pour les groupes d’ex aequo partageant le même horodatage, le tas reste borné par la limite de la requête (#72). Les instantanés de modération NIP-86 s’appliquent aux lectures stockées et à la diffusion en direct tels qu’ils ont été capturés au moment de la requête, si bien qu’une requête ouverte ne prend pas en compte instantanément les nouveaux bannissements (#68).

Une autre fusion, elle aussi non publiée, limite le processus d’écriture à un budget de 64 Mio d’octets et vide les files de publications en attente au moyen de transactions plus volumineuses, chacune plafonnée selon le travail effectué, tout en conservant la synchronisation LMDB durable. Les chiffres de benchmark du projet proviennent de ses propres variantes de sondes, et non de nos mesures.

nostream

nostream, un relay Nostr écrit en TypeScript, a publié nostream 3.7.0 et nostream 3.8.0. La version 3.7.0 livre les opérations d’administration, les journaux d’audit, les webhooks signés et les métriques que nous avions auparavant signalés comme présents uniquement dans le code source. Elle ajoute un cycle de vie optionnel (opt-in) pour les écritures payantes et corrige l’analyse des heures au format ISO ainsi que l’expiration pour LNbits 1 et les versions ultérieures. La mise en miroir statique est supprimée ; ses paramètres sont désormais ignorés, avec un avertissement, au profit de la synchronisation NIP-77. L’image de conteneur 3.7.0 n’a pas pu être publiée, car son tag Docker contenait un @ interdit, et la 3.8.0 corrige les tags et ajoute la relance des builds d’image échoués. À l’API et à la console d’administration, la version 3.8.0 apporte en outre des listes de pubkeys et de kinds, ainsi que des contrôles d’IP et de contournement de la limitation de débit, accompagnés de statistiques sur les principaux publieurs, les IP et les déclenchements de la limitation de débit ; elle corrige aussi une collision de clés Redis survenant lors d’un changement de stratégie de limitation de débit ou d’une mise à niveau. Le code source seul ne confirme pas que les images sont désormais publiées, et aucune facturation déployée n’est revendiquée.

Une réécriture distincte en Rust, sur la branche rewrite/main, a fusionné dans 740ef69 son premier cœur de protocole réseau capable de répondre à un vrai client, et au commit 2b2287f, le registre de stratégies implémente les 14 branches de stratégie restantes. Ce prototype, qui n’est pas l’implémentation par défaut, reste distinct de main en TypeScript et des versions stables 3.x, et ses résultats de revue et de CI proviennent de l’auteur. La prise en charge de NIP-43 et de NIP-56 reste désactivée par défaut. Une requête vanish peut encore perdre une course face à une publication concurrente : vanish ne constitue donc pas une garantie de confidentialité. La demande de l’auteur concernant une revue manuelle du code d’accès et d’identité reste d’actualité.

swift-nostr

swift-nostr, un SDK Nostr en Swift, a publié la version 0.9.0 le 27 octobre. Cette version ajoute des types dédiés pour les clés, les identifiants d’event, les URL, les horodatages, les coordonnées et les identifiants d’abonnement, des EventTemplates que n’importe quel signataire local ou distant peut signer, des erreurs typées, des abonnements détenus par le pool ainsi qu’un routage RelayRoute passant par le pool, par des relays précis ou par l’outbox NIP-65. Event.verify lève désormais une exception en cas de signature invalide ; passer de la 0.8 exige donc des modifications du code source. La précédente 0.8.0 était une version de durcissement dont les notes indiquent qu’elle vérifie les events remplaçables, les expéditeurs de gift-wrap ainsi que les réponses NIP-46 et NWC, déduplique les réponses provenant de plusieurs relays et ajoute un chiffrement NIP-44 piloté par le signataire ou à clé partagée, avec des contrôles de zap plus stricts constituant un changement incompatible. Il s’agit des affirmations de l’auteur, et non d’un audit.

Les correctifs postérieurs à la 0.8 que nous avions évoqués précédemment sont désormais livrés dans la 0.9.0. Les signataires refusent les events dont la clé publique diffère de la leur, et le désabonnement n’ouvre plus un relay déconnecté pour envoyer CLOSE. L’appel d’envoi principal lève notConnected et l’abonnement établit la connexion de manière explicite, même si les transports NWC et NIP-46 reconnectent toujours un relay perdu lors d’une nouvelle requête. Les appels NWC et de signataire distant obtiennent des erreurs typées et une annulation immédiate, bien qu’une requête déjà envoyée puisse encore être exécutée. Les flux de notifications NWC et de défis d’authentification se terminent lorsque les relays s’arrêtent, les attentes de connexion échouent dès que tous les flux de relays ont pris fin, et les requêtes de tag des filtres sont stockées une seule fois, soit une clé JSON par tag. Un WalletConnectRequest générique prend en charge des méthodes NIP-47 personnalisées à réponse unique, avec les vérifications habituelles de result_type et d’erreur, tandis que multi_pay reste à part. Grâce à un RemoteSignerMethod extensible, il est possible d’appeler des méthodes NIP-46 au-delà de l’ensemble intégré et d’obtenir la chaîne de résultat ; dans les deux cas, le portefeuille ou le signataire doit prendre en charge la méthode. EventTemplate avec signer.sign permet aux signataires NIP-46 distants d’utiliser des helpers, comme les requêtes de zap, qui nécessitaient auparavant un EventSigner local, avec des modifications associées dans plusieurs modèles de données ainsi que dans NIP-29 et les constructeurs NIP-98. Ce changement modifie l’API, pas le format sur le réseau.

Le code fusionné après le tag 0.9.0 ne fait pas partie de cette version. Un appelant qui annule un envoi conserve désormais les relays sains, et les types d’ouverture et de résultat des DM sont plus simples, l’auteur du rumor étant lié au signataire. FileAttachment unifie les métadonnées des fichiers chiffrés. Une paire unique setSigner et removeSigner empêche une définition distante obsolète d’annuler la déconnexion ; removeSigner arrête les réponses AUTH mais ne révoque pas les requêtes distantes déjà envoyées. Les paramètres de reconnexion et de déduplication disposent de leurs propres types de configuration.

haps

haps, un installateur de logiciels signés avec des clés Nostr, a publié haps v0.1.22. Cette version s’appuie sur haps v0.1.18, qui exécutait les compilations depuis les sources sous Linux et macOS dans un répertoire personnel privé et une copie de travail accessible en écriture, avec l’accès réseau désactivé par défaut. Des options explicites allow-build-network et allow-host-build peuvent passer outre ce comportement. Sous Windows, les compilations depuis les sources exigent host-build. Les applications installées restent hors du bac à sable. haps v0.1.19 a ajouté une confirmation unique d’audit et d’installation qui relie la source épinglée et la recette de compilation au hash de la charge utile compilée, de sorte qu’un binaire d’éditeur correspondant peut être installé selon la politique de cette compilation examinée. Réutiliser un examen de confiance ne compte pas comme un nouvel audit indépendant. Les installations depuis des catalogues signés immuables exigent toujours un audit, et les avertissements publiés nécessitent un consentement distinct dont la valeur par défaut est Non. La version 0.1.22 ajoute des recherches bornées et des vérifications d’éditeur sur la source complète. Les recherches partagent désormais des délais courts, le client lançant les requêtes dès que le premier relay se connecte, et les recherches d’instantanés renvoient les résultats vérifiés trouvés dans un budget unique de 3 secondes. Avant de modifier toute référence de source, la publication refuse de s’exécuter si elle ne trouve pas un assistant git intégré qualifié, un assistant installé séparément correspondant au binaire compagnon épinglé, ou un assistant annonçant complete-blob-dag-v1. La couverture de base de l’examen des dépendances, les garde-fous sur les liens symboliques et la taille ainsi que les nouvelles tentatives bornées sont conservés, ce qui ne constitue pas un nouvel audit indépendant. Une seule installation à froid réussie ne démontre pas que les dépassements de délai intermittents lors des transferts sont corrigés, et les paquets d’assistants épinglés dépendent toujours de la chaîne d’outils de l’hôte.

Swarm protège son API d’administration avec l’authentification NIP-98

Swarm, un serveur de publication et d’administration connecté à Nostr, a publié la v0.2.0 avec l’authentification HTTP NIP-98 pour son API d’administration, en plus du cookie existant du tableau de bord. Le serveur vérifie la signature de l’event de kind 27235, une fenêtre d’horodatage allant de cinq minutes dans le passé à une minute dans le futur, la méthode HTTP, le chemin et la requête, la pubkey épinglée de l’opérateur et un hash facultatif de la charge utile. Accepter un hôte transféré suppose la présence d’un proxy de confiance en amont. Le point de terminaison /environment, autrefois public, exige désormais une authentification d’administrateur.

Une fusion ultérieure, dont la publication dans une version n’est pas confirmée, ajoute la publication croisée facultative vers X pour les notes de kind 1 des membres d’équipe liés. Les notes programmées et celles arrivant par WebSocket empruntent le même chemin. Les réponses comportant des tags e sont ignorées, rien n’est rattrapé rétroactivement et les doublons sont supprimés par ID d’event. Côté CMS, l’authentification NIP-98 est utilisée. La publication dépend d’OAuth en local ou d’un service délégué de confiance : elle n’est donc ni décentralisée ni sans confiance. La publication vers le service X de production n’a pas été testée.

fips2go active les liens directs vers les domaines mesh vérifiés

fips2go, un client mesh Android qui trouve des pairs et des revendications de domaine grâce à des annonces Nostr, a publié les versions 0.9.6 à 0.10.0. La version 0.10 active par défaut les liens directs vers les serveurs des deux domaines vérifiés le plus récemment au maximum, en ne comptant que les domaines épinglés via DNSSEC ou plusieurs résolveurs. Ces liens exposent l’adresse IP publique du téléphone et ses horaires de connexion à ces serveurs, et révèlent son choix de serveur aux relays publics, mais les utilisateurs peuvent les désactiver. Un enregistrement TXT déjà épinglé pour un serveur et un port exacts se résout désormais sans nouvelle revendication Nostr, tandis que les nouveaux serveurs, les ports déplacés et les enregistrements sans port doivent toujours attendre. Lorsqu’un changement de réseau nécessite de nouvelles routes VPN sans que la configuration ait changé, l’application remplace uniquement le tunnel et conserve son nœud, ses liens et ses sessions. Les changements de point d’accès, les autres changements de configuration et le repli en cas d’échec reconstruisent toujours le nœud.

fips-pub-domains répond aux recherches épinglées avant de récupérer les revendications

fips-pub-domains, qui résout des liaisons signées avec Nostr entre domaines publics et adresses mesh, a publié les versions 0.2.9 et 0.2.10. Un enregistrement TXT épinglé pour un serveur et un port exacts peut désormais répondre avant la fin de la récupération des revendications en arrière-plan, selon la même politique d’épinglage, alors qu’un nouveau serveur ou port attend toujours une revendication. Au démarrage sur ordinateur et après des changements de réseau, le résolveur préchauffe jusqu’à 16 serveurs épinglés, ce qui révèle la présence en ligne à ces derniers et aux nœuds de routage. Pendant le premier délai d’attente de 20 secondes, il réessaie toutes les trois secondes et s’arrête plus tôt dès qu’un serveur répond.

Deux modifications fusionnées après ces tags ne sont pas publiées. L’une ajoute un rôle ServiceClaim fips-ca sans port, avec sa propre chaîne DNSSEC et sa propre attestation, distinct de fips-dns, sans lancer de nouvelle PKI ni modifier la politique de liaison DNS. L’autre ajoute des commandes CLI verify et zone qui lisent les fichiers d’épinglage sans les écrire. Dans ce code, une attestation ne porte que son propre témoin précédent, et les entrées des autres rôles sont revérifiées. Une option require-previous refuse les données manquantes mais ne sait pas distinguer une panne d’un enregistrement inexistant.

Codr

Codr v0.8.0, un pont permettant de piloter des sessions de programmation sur ordinateur depuis des discussions chiffrées White Noise, ajoute une mise à jour du worker qui est confirmée dans la discussion et doit avoir lieu dans un délai de dix minutes. Elle récupère des enregistrements ngit auprès d’un mainteneur épinglé et des octets Blossom vérifiés par somme de contrôle, sans repli sur GitHub. Elle refuse les changements de connecteur ou de cohorte de stockage et, si le démarrage échoue, elle restaure l’ancien exécutable. Pour l’instant, la mise à jour n’a été exécutée que sur des fixtures de test. Les fichiers et médias parviennent désormais à une session occupée sans l’interrompre, jusqu’à 25 Mio et quatre pièces jointes. La transcription Gemini facultative envoie les notes vocales déchiffrées à Google et est désactivée par défaut. Les versions 0.4 à 0.7 ont acheminé le texte du téléphone vers les sessions occupées, ajouté /cancel ainsi que des menus de projet, d’agent et de modèle, et sont passées à MDK 0.14. La migration depuis 0.13 ne fonctionne que dans un sens et exige une sauvegarde et une approbation.

Une discussion de contrôle facultative réservée au propriétaire (control_chat=true, désactivée par défaut) crée son groupe au prochain démarrage du worker. /new lance une session de projet avant qu’aucune discussion ne soit liée. Si la création est incertaine, elle n’est pas retentée automatiquement.

Une pull request ouverte, non fusionnée à la date limite de nos sources, permettrait à la création de groupe pour une nouvelle session de programmation de traiter comme vide une transcription pas encore écrite. Les transcriptions invalides ou ambiguës seraient toujours rejetées. Cela rétablirait les invitations sur téléphone pour les nouvelles sessions /new avant le premier prompt, sans changer la manière dont les sessions sont autorisées.

nostr-media

nostr-media 0.17, une extension WordPress pour héberger des médias Nostr, renforce la mise en miroir Blossom. Elle vérifie désormais l’autorisation de hash signée de kind 24242 avant de récupérer une URL de miroir et refuse les requêtes non autorisées sans rien télécharger. Les récupérations passent par l’API HTTP sécurisée de WordPress, qui n’autorise que les hôtes HTTP(S) publics et valide les redirections, avec un plafond de 20 secondes, trois redirections et 128 Mio ; les octets téléchargés sont toujours hachés et vérifiés. Les en-têtes Authorization, X-SHA-256 et X-Content-Type sont comparés sans tenir compte de la casse. La protection contre la falsification de requêtes côté serveur ne vaut que ce que vaut l’API sécurisée de WordPress.

NosTube

NosTube, un site vidéo construit sur Nostr, a publié le serveur 0.1.25 et l’application de bureau 0.2.51 afin de retirer sa confiance à une autorité de certification compromise. Le relay Rust du serveur ne lui fait plus confiance pour les connexions WebSocket ou HTTPS, et la construction des images exige désormais un paquet de CA système Debian figé. La version de bureau applique la même mesure d’atténuation à sa couche TLS et à son sidecar almond. Ces affirmations de sécurité proviennent des notes de version. Les notes ultérieures du serveur 0.1.27 disent DO NOT USE pour cette image, car elle embarque une libbrotli1 obsolète, et renvoient vers la 0.1.28, dont nous n’avons pas confirmé la publication.

bitchat

bitchat, une messagerie fonctionnant sur un mesh Bluetooth et sur Nostr, a publié la 1.8.0, avec des travaux de performance pour les discussions de localisation Nostr (geochat) et des horodatages bornés sur les rumors des DM. L’application reconnaît désormais les messages de l’utilisateur par l’ID de l’expéditeur, et non par le pseudonyme (correctif d’identité de l’expéditeur). Les groupes privés épinglent leur créateur, et l’ID de pair mesh reste en dehors des DM par geohash. Les chiffres de performance sont ceux du projet et nous ne les avons pas reproduits.

Une pull request ouverte, non fusionnée à la date limite de nos sources, maintiendrait la discussion géographique connectée pendant les pannes de relay en passant par les cinq relays les plus proches plus cinq relays de secours partagés, avec un plafond de dix connexions par route (#1822). Les messages seraient mis en file d’attente avant le chargement de l’annuaire des relays, et les abonnements et écritures en attente migreraient sans changement d’identité. La validation a été faite par l’auteur lui-même, et la modification du compagnon Android fait l’objet d’une pull request distincte.

Une autre pull request ouverte, elle aussi non fusionnée, ajouterait la vidéo en direct sur le mesh Bluetooth d’iOS et de macOS à l’aide d’un format LIVE_VIDEO_V1 personnalisé, et non d’un transport Nostr. Les trames publiques seraient signées et leur fraîcheur vérifiée. Les trames de DM transiteraient à l’intérieur du chiffrement Noise ; les enregistrements seraient envoyés sous forme de messages. L’auteur indique qu’un flux d’Android vers iPhone a été reçu. L’envoi depuis un iPhone, les paires iOS-iOS et la vidéo en direct en DM n’ont pas été testés.

ngit

ngit, l’outil en ligne de commande pour la collaboration Git sur Nostr, a publié la v3.0.4. Les connexions aux relays, ainsi que HTTPS sur Android, ne font plus confiance à une autorité de certification compromise. Les invites interactives se prémunissent désormais contre les saisies vides, et les commandes respectent les filtres hors ligne. Lors des mises à jour du suivi distant, les commits qui n’ont pas encore été publiés sont préservés. Les diagnostics distinguent aussi une source manquante d’une requête n’ayant renvoyé aucun résultat.

Hasheus

L’outil de vérification de fichiers auparavant appelé verify s’appelle désormais Hasheus et a publié la 2.0.0. Il vérifie les fichiers par rapport à des hashes publiés sur Nostr, en reprenant désormais les descriptions et URL de vérificateurs de confiance et en hachant les gros fichiers par blocs. Le bandeau de vérification n’apparaît que sur le fichier publié exact. Il gère aussi les profils malformés, déduplique les vérificateurs et signale une erreur en cas de relay manquant. Une somme de contrôle correspondante confirme le fichier, pas les affirmations de l’éditeur à son sujet.

Alby JS SDK

Le SDK JavaScript d’Alby a publié la 9.0.0. Les clients NWC accordent désormais à chaque requête publiée une attente fixe de 5 secondes pour recevoir le OK du relay, et échouent avec Nip47PublishTimeoutError s’il n’arrive pas, tandis que les délais de réponse par méthode restent inchangés. Une réponse qui ne se déchiffre pas entraîne désormais un rejet, et le texte d’échec du relay est conservé (gestion des erreurs de requête). Le changement incompatible supprime les méthodes multi_* obsolètes, et le code utilisant Nip47SingleMethod devrait passer à Nip47Method. Un OK du relay signifie que le relay a accepté la requête, pas qu’un paiement a réussi.

Alby Hub

Alby Hub, un nœud Lightning auto-hébergé qui sert des portefeuilles via Nostr Wallet Connect, a publié la 1.24.4. Ce correctif retire la confiance accordée à une autorité de certification compromise dans ses connexions TLS natives LDK et Go, dont dépend le service de portefeuille NWC du hub. Il corrige aussi le démarrage de l’extension CLN de factures retenues (hold invoices).

Orchard

Orchard, un catalogue de logiciels Flatpak, a publié la 0.3.0. Cette version relie l’interopérabilité des publications de logiciels à NIP-82 et à la préparation des ressources Flatpak en vue d’une publication via ngit ou d’autres outils NIP-82. NIP-82 est une spécification de catalogue logiciel proposée qui n’a été ni attribuée ni acceptée : Orchard implémente donc un brouillon susceptible d’évoluer.

Bell

Bell, un agrégateur Android de conversations Nostr, rassemble les réponses et citations de plusieurs comptes dans une seule liste chronologique. Ses notes de la 0.1.0 excluent les likes, les zaps, les simples reposts et les mentions génériques ; les comptes signent via Amber ou restent en lecture seule. Les versions 0.6.0 à 0.9.0 ont ajouté des règles de masquage par compte et une vue des seuls non-lus avec sélection multiple pour marquer comme lu. Selon leurs notes, la récupération conserve les réponses et réactions signées exactes, sans doublons automatiques. Les versions 0.10.0 et 0.10.1 permettent aux utilisateurs de masquer des publications individuelles sur l’appareil, avec annulation et restauration. Le masquage ne supprime rien des relays, et les nouvelles réponses apparaissent toujours. Les signalements de spam couvrent à la fois la publication et son auteur, sont envoyés publiquement depuis un compte explicitement choisi et ne font pas office de blocages privés. La 0.11.0 ajoute le repost après que l’utilisateur a examiné la publication d’origine et le compte d’envoi. L’avatar d’un compte détermine qui répond, réagit ou reposte. Pouvoir publier des reposts ne signifie pas que les notifications de simples reposts sont désormais agrégées. Les fils en cache peuvent rester incomplets, et l’écoute en arrière-plan, facultative, dépend des règles d’Android en matière d’énergie et de réseau, sans promesse de livraison permanente ou immédiate.

SkateSpots

SkateSpots est une carte communautaire de spots et de boutiques de skate. La version 1.7.4 a ajouté une discussion communautaire chiffrée de bout en bout, dans laquelle un bot communautaire approuve automatiquement les nouveaux appareils, que les administrateurs peuvent aussi approuver. La 1.7.0 a fait du relay communautaire la source de référence pour les spots et les boutiques. La 1.7.3 a corrigé les QR codes d’invitation Android pour la discussion privée de crew, introduite dans des versions antérieures. Les versions 1.7.8, 1.7.10, 1.7.15, 1.7.19, 1.7.20, 1.7.21 et 1.7.22 étendent cette discussion de crew. Contrairement à l’approbation par bot de la discussion communautaire, c’est un membre existant du crew qui approuve les nouveaux appareils par QR code ; les membres et les appareils peuvent être retirés, et la promotion d’un fondateur republie le tag d’administrateur. Les réactions, les tombstones de suppression et les accusés de lecture circulent sous forme de contrôles MLS chiffrés. Les tombstones ne sont pas des suppressions définitives sur les relays, et les accusés automatiques ne proviennent que des signataires silencieux. Un observateur en arrière-plan utilise la clé propre du membre, jamais une clé d’administrateur, et transforme les demandes d’adhésion en DM NIP-17 ou en avis de la cloche environ une fois par minute. Pour les utilisateurs d’Amber, les avis d’adhésion attendent l’ouverture de la cloche, tandis que les signataires silencieux peuvent les précharger, de sorte qu’Amber ne reçoit aucune sollicitation en arrière-plan. Les compteurs de non-lus utilisent les ID d’enveloppes NIP-17 en attente sans les déchiffrer, excluent les copies envoyées par l’utilisateur lui-même et ne révèlent ni ne confirment aucun sujet. La livraison instantanée ou continue en arrière-plan n’est pas garantie. Les versions 1.7.19 à 1.7.22 ajoutent aussi une recherche globale dans le jeu de données, qui ne s’exécute que lorsque la palette de commandes est ouverte, et elles mémorisent l’état de la carte et des calques. Nous n’avons pas testé ces modifications sur appareil ni audité leur sécurité de manière indépendante.

Emanator

Emanator, un client Nostr multicompte, peut désormais lancer des conversations privées NIP-17 dans la 1.5.0, alors que les versions précédentes ne faisaient que répondre aux fils existants. Les utilisateurs choisissent un compte d’envoi doté de la messagerie, puis recherchent des contacts par nom ou par NIP-05, ou collent un npub ou un nprofile. Les conversations existantes sont réutilisées et, si le destinataire n’indique aucune boîte de réception de DM, l’application propose une livraison au mieux ainsi qu’une option héritée. Sous la 1.4.1. Les nouvelles tentatives conservent les events signés déjà acceptés. Seuls les anciens events qu’aucun relay n’a acceptés peuvent être signés et datés à nouveau.

Feather

Feather, un client Nostr Android dont nous avions parlé pour la dernière fois dans le numéro 45, pendant sa série 0.9, a depuis atteint la 1.8.4. Les notes de la série 1.x ajoutent la consultation et le signalement natifs des tickets NIP-34 via les relays annoncés d’un dépôt. Les actions signées attendent désormais dans une boîte d’envoi locale que WorkManager livre en arrière-plan, en envoyant les messages parents avant les réponses. La 1.8.0 ajoute les publications d’images de kind 20 avec brouillons enregistrés et livraison hors ligne, et la 1.8.4 ajoute un masquage facultatif après un signalement réussi. Depuis la 1.7.0, la traduction passe par l’application distincte Offline Translator et ses packs de langues, sans repli sur le cloud.

OUTKAST

OUTKAST, un client Nostr Android, ajoute dans la 2.2.1 une découverte Réseau effectuée sur l’appareil, qui fait remonter des notes de comptes non suivis que des personnes que vous suivez ont aimées ou repostées au cours des 48 dernières heures. D’après les notes, le classement compte les réactions, les réponses et les zaps en nombre (et non en montants de sats), puis pondère le nombre d’amis et la nouveauté, sans serveur de classement. Dès que vous suivez 40 comptes ou plus, une note doit être soutenue par au moins deux amis. Les résultats s’arrêtent à 100 notes, sans pages plus anciennes. Les notes décrivent aussi des fils personnalisés à partir de personnes ou de listes choisies, ainsi qu’un éditeur photo qui enregistre les modifications en JPEG dépourvus de métadonnées, tandis que les originaux non modifiés sont téléversés intacts.

CustID

CustID, une application de signature Nostr, exige désormais dans la 0.2.2-beta une approbation biométrique pour les requêtes NIP-46 ASK sur les identités protégées par biométrie, même si une authentification récente peut satisfaire l’invite. Les règles d’approbation et de rejet mémorisées, y compris les approbations plus anciennes, s’appliquent désormais silencieusement via NIP-46 comme via NIP-55. L’activation de l’approbation automatique affiche d’abord un avertissement de confirmation, et l’annuler ne change rien. Cette bêta ajoute aussi des tags client NIP-89 aux events qu’elle publie. Ils sont activés par défaut et indiquent aux lecteurs quelle application a publié un event ; un réglage Confidentialité permet de les désactiver.

Nostr Vault

Nostr Vault, un client Nostr, ajoute dans la 3.0.0 des connexions facultatives entre appareils FIPS, appairées par adresse ou par QR code, afin qu’un Mac ou un téléphone de rechange resté à la maison puisse servir de coffre. Le coffre synchronise les notes et l’historique, récupère les photos existantes via le mesh et, une fois le mesh activé, démarre avec le relay après un redémarrage. Publier des médias publics nécessite toujours un serveur de médias public. La version corrige aussi des situations de concurrence entre comptes autour des abonnements et de l’inscription, attend que les relays d’écriture de l’utilisateur aient accusé réception d’une publication avant d’annoncer sa réussite, et garde les DM d’inconnus dans Demandes.

Holoboard

Holoboard, un tableau où l’on paie pour placer des publications, livre la version Android 1.1.0 en même temps qu’un parcours guidé « Ajouter au tableau » sur son site web et son backend, qui se termine par un paiement. Les invités peuvent soumettre du texte et des liens ou une publication Nostr existante. Les factures préparées reprennent dans le même profil de navigateur sur le même appareil, et le QR code de la facture reste accessible sans compte ni portefeuille connecté. À lui seul, l’APK ne fait que rafraîchir l’icône du lanceur et l’écran de démarrage : les changements du tableau dépendent donc du site web et du backend correspondants. Il n’existe aucune connexion par e-mail ou mot de passe.

Hopp

Hopp, une application de podcasts avec des boosts value-for-value, dépasse les travaux sur l’identité et les paiements de la série 0.2.x abordés dans le numéro 45. La version 0.3.0 ajoute une synchronisation et une restauration chiffrées entre appareils via Nostr, sans serveur Hopp, couvrant les abonnements, la progression, les favoris, la file À suivre, les habitudes d’écoute et les réglages de téléchargement. La restauration conserve la bibliothèque existante, et une vue d’état affiche l’état des relays et des éléments en attente. Selon les notes, les partages de boosts au résultat inconnu sont protégés contre les nouvelles tentatives en double, et les budgets tiennent désormais compte de Release Boosting et de Boost2Unlock.

Nostrautica

Nostrautica, une application compagnon d’événements, ajoute dans la 0.15.1 des packs d’événement hors ligne qui enregistrent les personnes, les mises en relation, les conférences, la page de l’événement, les publications et les photos de profil pour les lieux où le signal est faible. Sa messagerie gagne les noms dans les mentions ainsi que les modifications et suppressions, et les envois en attente peuvent être retentés ou abandonnés. La version 0.16.0 passe à MarmotKit 0.14, une bibliothèque de messagerie de groupe Marmot, pour un rattrapage hors ligne avec moins de connexions aux relays de groupe, et conserve les messages non lus lors du nettoyage lié à la rétention. La migration du stockage est irréversible, si bien que les anciennes versions de l’application ne sont plus prises en charge ensuite. Les notes affirment que l’interopérabilité avec la messagerie White Noise ou avec le web n’est pas modifiée.

Staircase

Staircase, une application de discussion de groupe Nostr de relay.tools, ajoute dans la 0.1.25 un mode de notification Fréquent qui vérifie environ toutes les 5 ou 10 minutes, puis se déconnecte. En veille profonde, c’est la planification d’Android qui décide du moment, de sorte que la livraison en arrière-plan n’est ni instantanée ni garantie. Les modes Périodique et Fréquent effectuent une vérification bornée lorsque le réseau revient, au plus toutes les deux minutes ; le mode Instantané est inchangé. L’état d’une demande d’adhésion à un groupe cesse d’attendre dès qu’une demande est traitée ou expire, sans préciser lequel des deux. Les relays coordinateurs personnalisés restent sous le contrôle de l’utilisateur et ne sont pas écrasés par une liste publiée.

En développement

Coracle

Coracle, un client web Nostr, a fusionné un correctif de routage sur master. Cliquer sur un élément de menu comme Listes ou Groupes alors que cette même fenêtre modale est déjà au premier plan ne fait désormais plus rien. Auparavant, chaque clic empilait un panneau identique supplémentaire. Échap les fermait un par un. Les fenêtres modales distinctes et la navigation normale entre pages fonctionnent comme avant. Il s’agit de source fusionnée, non liée à une version.

nostter

nostter, un client web Nostr, a fusionné cinq correctifs de son parcours de zap. Une réponse pay_invoice de Nostr Wallet Connect n’est désormais considérée comme un succès qu’avec le bon type de résultat et une preimage valide, le champ d’erreur étant null ou omis. Les réponses malformées sont rejetées. Le client rx-nostr dédié est toujours libéré, même lorsque son initialisation échoue. Dix secondes sans réponse du portefeuille sont traitées comme un résultat inconnu, et non comme un échec. Les erreurs de facture et de signature s’affichent en ligne et conservent le montant et le commentaire pour une nouvelle tentative, et les échecs de facture sont signalés séparément des échecs NWC. Le bouton de zap reste activé pour les zaps répétés. Sa marque orange apparaît aussi lorsqu’une facture QR est affichée, ce qui ne confirme pas qu’un paiement manuel a abouti. Rouvrir la boîte de dialogue ne la réinitialise que lorsqu’elle est inactive. La fermer après l’arrivée de la facture ou de la signature empêche un nouveau paiement NWC, mais un paiement déjà soumis se poursuit.

Une pull request ouverte afficherait, après un résultat inconnu, un avertissement invitant à vérifier l’historique du portefeuille avant de payer via le QR code de repli, et supprimerait l’ouverture automatique du portefeuille. Un dépassement de délai ne signifie pas que le portefeuille n’a rien débité.

Pollerama

Pollerama, un client de sondages et de fil d’actualité, a fusionné une file de requêtes par relay. Cette file ajuste le nombre de requêtes exécutées simultanément, ralentit lorsqu’un relay limite le débit, découpe les filtres trop volumineux et normalise les URL des relays. La vue Mine des packs conserve désormais un abonnement permanent, de sorte que les réponses lentes des relays apparaissent quand même. Des problèmes connus de requêtes répétées dans l’application restent ouverts, et les messages directs n’ont pas été testés avec cette modification.

Grimoire

Grimoire, un client social Nostr, a fusionné des correctifs pour la synchronisation des messages directs. Le curseur d’historique n’avance plus sur des pages de relays fusionnées qui ne remontent qu’en partie dans le temps, et une garde d’interruption empêche une passe de déchiffrement de reremplir les messages et les marqueurs de lecture après qu’une déconnexion les a effacés. Un rattrapage interrompu s’arrête avant de déplacer le curseur ou de marquer l’historique comme épuisé. Des lacunes subsistent : un seul relay qui répond peut encore marquer l’historique comme épuisé alors que d’autres données manquent, et un refus définitif d’un signataire fait toujours avancer le curseur.

nostr-vpn

nostr-vpn, un VPN qui utilise des clés Nostr pour la découverte de pairs, a fusionné un correctif de reconnexion mobile. Lorsqu’une sonde de découverte est déjà due, le client réarme désormais les chemins épuisés vers des pairs connus. Il ne le fait que si rien n’a été reçu récemment et qu’aucun chemin connecté ou en attente n’existe, et au plus une fois toutes les 300 secondes. Les chemins sains et en attente ne sont pas touchés, et le format de transmission est inchangé. L’auteur a testé le correctif sur une fixture native isolée, pas sur des réseaux cellulaires. Une deuxième modification fusionnée retire les secrets d’adhésion au réseau des paquets doctor en excluant de la sortie de diagnostic le secret d’adhésion d’enrôlement et l’état brut du démon. La clé privée Nostr y était déjà masquée. Les paquets partagés avant cette modification restent exposés : toute personne en ayant partagé un devrait renouveler les secrets d’adhésion concernés.

Plusieurs modifications liées sont encore des propositions ouvertes et n’ont été ni fusionnées ni publiées. Pour les secrets stockés, l’une conserverait les secrets d’adhésion au réseau dans le stockage de secrets de la plateforme via le chemin de migration existant. Une autre limiterait les secrets sidecar de la machine Windows à SYSTEM et aux Administrateurs, en couvrant les fichiers DPAPI qui contiennent les clés de nœud Nostr. Cette restriction ne s’applique qu’à la prochaine écriture d’un fichier, et il existe un bref intervalle entre la création du fichier et l’application de l’ACL. Les chemins de configuration personnalisés ne sont pas couverts, et l’auteur n’a pas testé sur une machine Windows multi-utilisateur. Pour l’appartenance signée, une proposition rejetterait les approbations d’adhésion dont l’instantané de liste des membres ne correspond plus au disque, de sorte que l’administrateur recharge et réessaie tout en préservant les appareils approuvés simultanément. Une autre tolérerait cinq minutes de décalage d’horloge de l’administrateur et exigerait toujours un signataire d’adhésion configuré, même lorsque la liste locale des administrateurs est vide, tout en conservant la liaison au secret de la requête. Une troisième départagerait les listes de membres de même horodatage par hash d’artefact. Les pairs qui voient les deux listes choisiraient la même liste unique ; chacune conserve son propre contenu d’appartenance. Une dernière proposition exigerait une confirmation pour les demandes d’adhésion par lien profond et pour les fournisseurs de sortie payants. Sous macOS et Linux, les liens d’adhésion attendraient une étape explicite d’ajout d’appareil. macOS retiendrait aussi les liens de fournisseurs payants en attente de confirmation. Son exécution native sur l’une ou l’autre plateforme n’a pas été démontrée. Tous les résultats de tests sont rapportés par l’auteur.

Buzz

Buzz, un relay communautaire doté de clients pour ordinateur et mobile, a fusionné des travaux sur les groupes et les agents. Les agents peuvent s’authentifier selon la spécification JWT NIP-FI du projet, qui vérifie le propriétaire humain déclaré par l’émetteur ; refuser ou déconnecter ce propriétaire met fin aux sessions de ses agents, et l’appartenance du propriétaire à la communauté peut faire admettre un agent. Les Huddles acceptent aussi les enregistrements vérifiés d’agents gérés provenant de l’utilisateur actuel ou du propriétaire du Huddle, en plus du rôle de bot à attestation de propriétaire NIP-OA. Ce repli est une politique de compatibilité et ne fait pas confiance aux enregistrements de tiers inconnus. Il ne constitue pas une preuve d’identité. Aucune des deux spécifications n’est une NIP acceptée.

Les canaux d’annonce ouverts peuvent admettre des invités en lecture seule via join_role=guest, et les canaux ouverts non répertoriés sont masqués lors de la découverte par les non-membres, mais lisibles par quiconque possède l’ID du canal. Les events d’admission peuvent ajouter jusqu’à 100 membres, un succès partiel étant possible. Le correctif des paramètres de canal, signalé la semaine dernière comme proposition ouverte, a désormais été fusionné : les modifications sont validées dans une seule transaction avec leurs requêtes et leurs avis. Un passage de public à privé qui échoue est entièrement annulé, ce qui empêche les membres retirés de réapparaître par le biais de cette annulation. Sur mobile, les échecs de configuration des notifications push ne cassent plus l’application, qui réessaie un nombre limité de fois et propose une récupération manuelle ; les tests reposent sur des canaux simulés et le comportement des appareils APNs n’est pas vérifié. Les masquages synchronisés ne provoquent plus de démarrage vide et sont désormais vérifiés par rapport aux abonnements push réels aux DM ; ce correctif repose sur un seul journal d’iPhone. Dans le mesh de relays, les enregistrements de pairs morts expirent après cinq minutes sans battement de cœur, les connexions actives étant exemptées.

Les fusions plus récentes ne sont pas confirmées dans une version. Les ajouts de membres de kind 9000 sont désormais validés en même temps que leurs écritures dans la liste des membres : une modification qui échoue n’enregistre ni l’un ni l’autre, et le même event signé peut être retenté. Pour les kinds 9001, 9021 et 9022, l’ancienne lacune subsiste. Les diagnostics en mode fantôme de NIP-FI journalisent désormais la clé Nostr vérifiée et un motif privé fixe pour les cas qui seraient refusés, sans journaliser les jetons ni les revendications. Cela ne change rien à l’admission ni à l’application des règles. La spécification d’agent NIP-AP propre à Buzz, un document du projet en dehors des NIP acceptées, exige désormais un agentType défini par le client dans les paramètres. Les lancements avec les paramètres d’un autre type sont refusés, un champ manquant conserve sa signification héritée, et un changement de type peut supprimer les paramètres imbriqués de l’ancien type. La sélection d’agent solo échoue de manière fermée sur les politiques d’agents gérés de kind 30177 les plus récentes lorsqu’elles sont malformées. Les données plus anciennes restent exclues. Elle désigne les agents par le nom géré par leur propriétaire, tandis que les illustrations et les auteurs des messages utilisent toujours les profils.

Sur mobile, la création, la liste et la suppression d’agents hébergés utilisent la preuve de propriété NIP-OA et les enregistrements de kind 30177, avec des nouvelles tentatives durables sous la même identité, et conservent les instructions privées dans un stockage sécurisé. Son verrou d’hébergement défini à la compilation est désactivé dans les versions App Store et internes : il ne s’agit donc pas d’une disponibilité publique. Le démarrage à froid sur invitation hébergée iOS conserve l’intention d’invitation, importe une clé correspondante et récupère depuis une sauvegarde. Seul l’auteur a testé le parcours principal, et le point de terminaison de repli pour l’appartenance ainsi que la nouvelle inscription restent non résolus. La récupération de l’enrôlement push attend avec un délai exponentiel, puis remplace une requête enregistrée rejetée avec un 401 par un nouveau défi borné et une clé App Attest. Elle conserve les intentions après un 400 ou des erreurs transitoires et traite normalement un 404 ordinaire. Cette récupération n’a pas été vérifiée sur de vrais appareils. Les liens de messages vers des canaux publics que l’utilisateur n’a pas rejoints récupèrent les métadonnées de kind 39000 et s’ouvrent en lecture seule, tandis que les verrous des canaux privés et des DM restent inchangés. Les liens sont mis en file d’attente pendant les reconnexions, et une seule recherche lente peut retarder les liens suivants jusqu’à huit secondes.

Plusieurs pull requests ouvertes n’étaient pas fusionnées à la date limite de nos sources. Une capacité buzz_v1 désactivée par défaut remplacerait l’état de lecture côté client par des API NIP-98 de barre latérale, d’état de lecture et de couverture privées à l’appelant, avec des révisions par personne et des signaux d’invalidation de kind 24300 réservés aux relays. Sans cette capacité, les relays conservent NIP-RS, et les grandes bases de données doivent d’abord construire leurs index de manière concurrente. Les résumés de fils n’examineraient que les 1 000 dernières réponses, renverraient les 10 derniers auteurs et enverraient des mises à jour en direct au plus une fois par seconde par pod : ils ne listeraient donc pas tous les participants passés. Les réponses des agents aux réactions s’inséreraient dans le fil du message ayant reçu la réaction, en utilisant le dernier tag e NIP-25 valide et en se rabattant sur l’ancien point d’ancrage. Les agents reposant sur Hermes obtiendraient un shell MCP limité à l’agent pour publier dans les canaux et les DM. Il refuse de s’exécuter sans son pont et masque les identifiants, mais l’installation, le redémarrage et la publication réelle ne sont pas vérifiés. Un correctif de l’adaptateur ACP enverrait les noms d’initialisation v1 et v2, se replierait sur la v1 stable et épinglerait la version majeure validée. Cela répare le transport des agents et ne constitue pas une modification du protocole Nostr. La fonction mobile Lecture à voix haute utiliserait le moteur de synthèse vocale du téléphone et ignorerait le code, les liens et les pièces jointes. C’est le moteur choisi par l’utilisateur qui détermine où la parole est traitée. Un générateur de charge pour relay autonome simulerait des humains et des agents NIP-OA et ferait échouer les exécutions dépassant les limites fixées d’erreurs et de latence. Il ne modifie aucun code de relay et ne prouve pas la tenue à l’échelle en production.

Mosaico

Mosaico, un démon qui coordonne des agents dans des groupes basés sur des relays (NIP-29), a fusionné une présence fondée sur des battements de cœur. Un agent n’est désormais considéré comme présent dans un canal que tant qu’il publie un event de statut doté d’un horodatage d’expiration (NIP-40) fixé à 90 secondes dans le futur et renouvelé toutes les 30 secondes. Un processus exécuté localement ne vaut plus présence à lui seul. L’appartenance persiste pendant qu’un agent est hors ligne, afin qu’il puisse reprendre. Un modèle de lecture de groupe reconstruit est construit une seule fois par changement de relay avec un curseur d’arrivée canonique, si bien que la discussion n’est plus perdue lorsqu’un abonnement de groupe large est remplacé.

Trois fusions ultérieures ne sont pas confirmées dans une version. Les abonnements de remplacement utilisent désormais de nouveaux ID de REQ et s’ouvrent avant la fermeture de l’ancien. Un profil retiré est publié en dehors du chemin critique en latence, et un agent qui quitte un canal retire sa présence tout en restant membre NIP-29. Les sondes à l’appui sont celles de l’auteur, pas nos propres mesures. La comptabilisation des nouvelles tentatives fondée sur la revendication préalable est stockée durablement dans le schéma 27 et survit à la relecture des relays. Elle applique un délai exponentiel de 30 secondes à une heure sur un unique minuteur séquentiel et abandonne après 10 échecs. Un event manquant n’est pas traité comme une suppression et, comme la fenêtre conservée contient 4 096 entrées, la livraison de chaque event n’est pas garantie. Les instantanés limités aux groupes réveillent désormais les consommateurs de groupe, et les remplacements à horodatage égal conservent l’ID d’event le plus bas, comme le prévoit NIP-01. Les modifications portant uniquement sur le contenu réveillent toujours le consommateur général. Un repli ciblé en cas de parent manquant peut attendre le prochain changement de groupe ou un délai de 15 secondes.

Sonar

Sonar, une messagerie combinant Nostr, le chiffrement MLS et un mesh Bluetooth Low Energy, a fusionné un correctif de démarrage pour les connexions cellulaires. La PR attribue la lenteur du premier affichage au rattachement du relay push, qui détient un verrou du stockage. Sur Android, le démarrage contourne ce verrou lorsque le nœud local est déjà ouvert, comme lorsque l’enregistrement push l’a ouvert avant le démarrage à froid. Sur iOS, l’application demande à l’extension du service de notifications de cesser de se connecter et de vider sa file afin que l’application puisse s’afficher.

Shopstr

Shopstr, une place de marché Nostr, a fusionné la prise en charge de la suppression d’annonces proposée la semaine dernière. Une demande de suppression d’event (NIP-09) signée par un vendeur retire désormais l’annonce du cache et la marque d’une tombstone, de sorte qu’un article supprimé ne peut ni réapparaître ni être acheté depuis le cache, tandis que les remises en vente plus récentes restent visibles. Certaines suppressions échappent encore au système : une suppression arrivant avant son annonce est ignorée, les anciennes demandes sans tag k ne correspondent pas à la requête aux relays, et les suppressions passées ne sont pas rattrapées. Les relays peuvent aussi conserver les events supprimés. Par ailleurs, les messages gift-wrapped malformés ne bloquent plus les vues Commandes et Mes annonces, et les vendeurs peuvent désormais consulter leurs propres commandes, les autres utilisateurs recevant toujours une erreur 403.

Trois pull requests ouvertes, non fusionnées à la date limite de nos sources, visent l’intégrité des commandes. #665 enregistrerait une seule fois les participants de chaque commande via un enregistrement NIP-98, en prenant l’acheteur dans l’authentification et le vendeur dans l’annonce signée, et les écritures ultérieures ne pourraient pas les modifier. Un enregistrement qui échoue n’empêcherait pas le paiement, et les nouvelles commandes non résolues ne seraient pas devinées à partir des tags. Les commandes héritées ne sont couvertes que jusqu’à une date limite restreinte, et une lacune dans la façon dont le statut est stocké par ID de commande reste non corrigée. #666, qui dépend de #665, n’appliquerait les messages de statut de commande gift-wrapped (NIP-59) que lorsqu’ils proviennent de l’acheteur ou du vendeur enregistrés pour la commande, et non de n’importe quel expéditeur authentifié. Les commandes non résolues restent en attente, la confirmation d’un acheteur après paiement ne compte pas comme confirmation du vendeur, et les messages falsifiés restent de simples messages de discussion sans modifier l’état de la commande. #664 lirait les métadonnées des jetons de keyset Cashu v2 pour l’enregistrement et les décisions d’escrow sans recherche de keyset sur le réseau, et corrigerait la somme des preuves. Le décodage des jetons lors de la création de commande nécessite encore un correctif distinct.

Conduit

Conduit, une place de marché Nostr dotée d’applications appariées pour acheteurs et marchands, a fusionné un enregistrement de compte chiffré unique. Les métadonnées du portefeuille, la seed, l’identité native, l’adresse, les préférences et la progression de la configuration résident désormais dans un seul enregistrement de données d’application personnalisées arbitraires (NIP-78), chiffré avec des charges utiles chiffrées versionnées (NIP-44) et vérifié quant à sa signature, son propriétaire et l’identité dérivée ; les deux applications le trouvent dès que le signataire donne son approbation. La bascule est incompatible avec l’existant : les anciens chemins de sauvegarde et de récupération sont ignorés, et les sauvegardes héritées restent en place sans migration automatique. D’autres fusions ajoutent la connexion avec un nsec existant, conservé dans le stockage local du navigateur, exigent des conditions de livraison signées exactes lors de la modification de familles de produits, et déplacent la récupération du paiement vers IndexedDB, avec relecture avant de la marquer comme enregistrée.

Conduit est aussi passé au NWC SDK 8.1.1, ce qui apporte sa validation des montants, ses tentatives de connexion bornées, sa gestion des pools fermés et ses correctifs pour les réponses en cours. Le choix de portefeuille, le chiffrement et la politique de paiement de Conduit sont inchangés. Le déploiement de l’application reste non confirmé. Deux pull requests en brouillon n’étaient toujours pas fusionnées à la date limite de nos sources. L’activation du paiement persisterait, relirait et transmettrait l’état du paiement dans une fenêtre d’exécution fixe de deux minutes que les nouvelles tentatives ne réinitialisent pas. Les reçus Nostr, la récupération de compte privé et les modifications de stock ou d’exécution des commandes nécessiteraient chacun une preuve signée distincte. Conservés 24 heures après coup, les reçus ne rétablissent pas l’autorité de paiement, et les vérifications avec fonds réels, sur appareil et par les mainteneurs restent en suspens. Les produits réservés aux événements marqueraient les annonces NIP-99 de kind 30402 comme masquées à l’aide d’une extension conduit_event_only. Elles resteraient hors du catalogue normal et du paiement, et nécessiteraient une affectation autorisée exacte à une occurrence d’événement. Les données signées masquées restent publiques, et les autres clients ne prennent en charge que l’indicateur de masquage standard.

LNbits

LNbits, le serveur de portefeuilles et de comptes Lightning, a fusionné une option permettant d’envoyer ses notifications Nostr sous forme de messages privés NIP-17. Les administrateurs peuvent choisir entre les messages chiffrés hérités NIP-04 et les messages directs privés NIP-17, qui sont la valeur par défaut des nouveaux réglages. Pour NIP-17, le serveur recherche la liste des relays de boîte de réception de DM du destinataire, en utilisant les relays NIP-05 comme indices de découverte et comme destination lorsqu’aucune liste n’existe. Une liste vide publiée fait échouer l’envoi. Chaque envoi est limité à 30 secondes et nécessite qu’au moins un relay de boîte de réception l’accepte, et il ne se rabat jamais sur NIP-04.

Zeus

Zeus, le portefeuille mobile Bitcoin et Lightning, a inclus son correctif de la comptabilisation du budget Nostr Wallet Connect lorsque l’actualisation après paiement échoue dans la préversion v13.2.4-rc1, ainsi que le correctif antérieur faisant en sorte que make_invoice de Nostr Wallet Connect renvoie sa propre facture. Avant ce correctif, une erreur d’actualisation après un envoi NIP-47 sautait la comptabilisation du budget et renvoyait une erreur pour un paiement qui avait pu réussir. Désormais, une preimage renvoyée débite le budget via le repli existant, et un dépassement de délai retient le montant comme dépense en attente, même si le paiement est absent de la liste. D’autres lacunes, notamment les paiements LND en cours, peuvent subsister. La v13.2.4-rc2 a suivi, avec uniquement des mises à jour de dépendances.

Deux correctifs plus récents ont depuis été fusionnés dans le code source et ne sont confirmés dans aucune des deux release candidates. La correction de l’expiration par défaut fait appliquer par le décodeur BOLT11 local l’expiration par défaut de 3600 secondes prévue par la spécification lorsqu’une facture ne comporte pas de champ d’expiration. Ces factures étaient jusque-là traitées comme n’expirant jamais : la vérification qui bloque le paiement des factures expirées ne s’appliquait donc pas, et la validation des factures NWC dans NostrConnectUtils présentait la même lacune. La correction des sauvegardes propres à chaque portefeuille réinitialise l’horodatage de la sauvegarde des mints sur Nostr pour chaque portefeuille ecash. Avant ce correctif, un portefeuille restauré à partir de sa seed dans la même session qu’un autre portefeuille ecash pouvait hériter de l’horodatage de ce dernier. Il pouvait alors écarter ses propres sauvegardes plus anciennes sur les relays comme obsolètes et enregistrer une liste de mints vide, ce qui désactivait la restauration automatique. Une sauvegarde qui se termine après un changement de portefeuille peut encore écrire son horodatage sous le mauvais portefeuille. Les portefeuilles déjà touchés conservent leur liste vide enregistrée et nécessitent la restauration manuelle dans Mint sync, ou bien l’ajout à nouveau de leurs URL de mints. Leur ecash reste auprès du mint. Les deux pull requests indiquent qu’aucun test sur appareil n’a été effectué.

npub.cash

npub.cash reçoit des paiements Lightning pour des identités Nostr et les convertit en ecash Cashu. Le projet a fusionné une modification du serveur qui publie les reçus de zap sur les relays demandés par le payeur. Le serveur analysait déjà les relays indiqués dans une requête de zap, mais les ignorait lors de la publication des reçus payés. Désormais, les reçus sont envoyés à ces relays lorsque la requête en nomme au moins un, tandis que les requêtes dont la liste de relays est absente ou vide utilisent toujours les relays configurés par défaut.

eHagaki

eHagaki, un client web Nostr également distribué sous forme de Web Component intégrable, a publié les versions 1.31.0 et 1.31.1. La version 1.31.0 ajoute les reposts (NIP-18), les réactions (NIP-25) et la gestion des médias téléversés, finalise le routage outbox (NIP-65) avant qu’un event ne parte vers un signer externe, et peut conserver l’historique des publications ainsi qu’un cache dans un relay Citrine local. Sa migration IndexedDB réinitialise l’historique des publications affiché localement, mais conserve les brouillons et les demandes de suppression enregistrées ; l’historique détenu par les relays peut être récupéré à nouveau, alors que les publications uniquement locales doivent faire l’objet d’une sauvegarde ou d’un export avant la mise à niveau. La version 1.31.1 synchronise les serveurs de téléversement NIP-96 via le kind 10096, en parallèle du kind 10063 de Blossom, conserve les réglages de relays partiels encore utilisables et intègre les correctifs de la liste des serveurs de téléversement et de la synchronisation des serveurs de médias. La récupération de la liste des serveurs de téléversement via les relays de lecture déclarés conserve la liste valablement signée la plus récente malgré les délais dépassés d’autres relays, et laisse les réglages inchangés si aucune liste n’arrive. La synchronisation des serveurs de médias traite séparément les préférences Blossom et NIP-96 et ne publie jamais de liste raccourcie après un échec de recherche.

D’autres correctifs de fiabilité fusionnés ne sont pas encore confirmés dans une version publiée. Après une erreur 401 ou 403, les utilisateurs peuvent s’inscrire auprès des serveurs NIP-96 yabu.me ou nostrcheck.me depuis l’écran des médias ; la signature NIP-98 couvre l’URL POST réelle et le hash du corps, un changement de compte ou de destination annule la requête, une protection bloque les doubles envois et les requêtes à l’issue inconnue ne sont pas renvoyées. eHagaki ne fournit jamais de mot de passe, et les étapes de code d’invitation ou de paiement renvoient vers le site officiel du fournisseur. Les longues listes de fichiers Blossom sont paginées par tranches de 24 éléments à partir d’un instantané local borné, qui rejette les réponses de plus de 8 MiB ou de plus de 10 000 entrées et qui est abandonné lors d’un changement de compte, de session ou de serveur ; atteindre la fin signifie que l’instantané est épuisé, et non que le serveur n’a plus de fichiers. La récupération du remote signer NIP-46 reconstruit la connexion et rejette explicitement les anciennes requêtes en attente au bout de 30 secondes, sans les renvoyer. Les téléversements vers le serveur Blossom de Primal encodent l’autorisation signée existante en Base64 standard avec remplissage, tandis que les autres serveurs conservent le Base64URL.

Deux fusions plus récentes ne sont pas non plus confirmées dans une version publiée. La publication partage désormais des attentes de requêtes aux relays bornées et vérifiées, et garde la livraison et la progression liées à la session, en remplacement de plusieurs minuteurs distincts. Le premier accusé de réception valide d’un relay compte comme un succès, pendant que la livraison aux relays restants se poursuit. La progression n’affirme jamais une livraison à tous les relays, et changer de compte ou se déconnecter interrompt la livraison en arrière-plan. L’historique des publications peut, sur demande, rafraîchir les réponses, réactions et suppressions associées dans une limite de trois secondes. Les résultats déjà reçus sont conservés après un dépassement de délai partiel, et une suppression qui n’arrive pas n’est pas considérée comme la preuve qu’il n’en existe aucune.

Formstr Drive

Formstr Drive, une application chiffrée de partage de fichiers fondée sur Nostr et Blossom, a fusionné son travail de récupération des DriveKey, que nous avions présenté précédemment comme une proposition ouverte. L’application lit chaque relay joignable avant d’écrire un trousseau combiné, de sorte que les anciennes clés convergent à mesure qu’elles deviennent visibles. Elle ne crée une nouvelle clé que lorsque deux des quatre relays de l’application ne renvoient rien et qu’il n’existe ni historique ni version. Un relay d’écriture qui ne répond pas peut encore masquer une ancienne clé pendant un certain temps, et les builds plus anciens ne savent pas lire le nouveau format JSON.

Le projet a aussi séparé les fichiers déchiffrés, partages, dossiers et outbox de chaque compte. Changer de compte bloque les signatures et importations en attente du compte précédent, même si un blob préparé peut rester sans référence. Les nouveaux comptes doivent désormais choisir explicitement un serveur de téléversement, sans bascule silencieuse, tandis que les valeurs par défaut automatiques antérieures sont conservées. Le serveur voit toujours la pubkey, le moment des téléversements et les octets chiffrés. Les avertissements de doublon exigent désormais des octets actifs identiques sur le même serveur et dans le même dossier. Les parcours Android pour la séparation des comptes et la confirmation des doublons ne sont pas testés, et nous n’avons pas confirmé que l’un de ces changements figure dans une version publiée.

diVine

diVine, un client Nostr de vidéos courtes, a fusionné des changements touchant la messagerie, les comptes et les défis. Ses premières versions bêta n’ont que des notes génériques, si bien que rien de tout cela n’est établi dans les builds distribués. Les instantanés de compte chiffrés champ par champ synchronisent les préférences, les décisions sur les badges et les éléments ignorés, réessaient localement les changements en attente et bloquent les publications risquées en cas de lecture incomplète. Les marqueurs de lecture des DM conservent le protocole existant, la lecture des notifications passe par l’API du serveur et « tout marquer comme lu » nécessite une connexion ; les autorisations du système, les identifiants et le consentement lié à l’âge restent sur l’appareil.

Dans les DM, l’éditeur et la feuille de partage se ferment une fois le message mis en file d’attente en toute sécurité ; la livraison en arrière-plan ne s’exécute pas lorsque l’application est fermée, et la livraison n’est comptabilisée qu’après l’accusé de réception d’un relay. Les nouvelles tentatives échouées sont décomptées de façon cohérente de la limite de tentatives. Les anciens messages NIP-04 de forme invalide sont écartés et consignés dans un registre, mais les bulles vides déjà stockées subsistent et la compatibilité avec les signers externes et les autres appareils n’est pas établie. Les aperçus floutés facultatifs des DM vidéo provenant d’expéditeurs de confiance sont désactivés par défaut et toujours floutés avec un avertissement sur le contenu ; la vidéo est tout de même téléchargée, donc le flou n’apporte aucune confidentialité réseau. Dans les groupes, bloquer un membre masque uniquement ses messages ; un avertissement précise qu’il reçoit toujours les vôtres. Le départ d’un salon est enregistré de façon persistante. La création de nouveaux groupes reste derrière un drapeau désactivé par défaut. Ces changements s’appliquent aux groupes existants ; l’examen confiance et sécurité est en attente.

Deux fonctionnalités auparavant ouvertes ont été fusionnées. La mise en cache des vidéos reçues en DM conserve les fichiers déchiffrés par compte pendant 30 jours au maximum ou jusqu’à 300 MB ; le chargement automatique dans les discussions de confiance et depuis les utilisateurs suivis révèle l’heure de visionnage à l’hébergeur des médias, et les vidéos d’inconnus nécessitent un appui. Un retrait côté serveur ne révoque pas immédiatement les octets en cache, qui peuvent être évincés plus tôt. La recherche du propriétaire d’un nom d’utilisateur consulte l’annuaire NIP-05 du serveur de noms pour les recherches de handles Divine en première page et n’épingle qu’un propriétaire actif ; les noms recherchés apparaissent dans les journaux du serveur, et il ne s’agit pas d’une validation NIP-05 générale.

Les listes de personnes passent en disponibilité générale, dans le prolongement du travail combiné sur la découverte et la gestion. Les liens de soutien sur les profils sont activés par défaut, et l’éditeur attend une lecture stricte du kind 0 brut sur chaque relay, en préservant les fournisseurs masqués et les modifications non enregistrées ; la promotion dans les stores et le déploiement côté backend n’ont pas eu lieu. Les tags d’attribution du client suivent la préférence NIP-89 actuelle lors des nouvelles tentatives et des modifications de métadonnées, en retirant le tag client d’un autre client avant la signature, tandis que les publications programmées déjà signées ne changent jamais. Les liens courts externes authentifiés, désactivés par défaut, signent le POST NIP-98 exact et son corps en moins de deux secondes et se rabattent sur les URL canoniques, que les DM et les events Nostr conservent toujours ; la création via la passerelle est déployée en position désactivée, avec des étapes de déploiement encore à venir.

Les créateurs peuvent autoriser la réutilisation d’une vidéo publique au moyen d’un tag explicite, une option désactivée par défaut et verrouillée en position désactivée au moment de la publication par un audio sous licence sans œuvres dérivées ; il s’agit d’une convention côté client, et non d’un DRM. Le travail sur les défis, réservé aux tests, couvre une fondation protocolaire signée, la signature des participations avec vérification des règles et du consentement, un stockage durable par compte et des parcours natifs d’examen et de retrait dans des builds de test spéciaux. L’accusé de réception d’un relay ne signifie pas l’approbation de l’organisateur. La découverte en production est désactivée. La livraison backend, les tests d’acceptation avec de vrais comptes et une séquence de publication coordonnée entre clients restent à réaliser.

Des fusions plus récentes ne sont pas non plus confirmées dans une version publiée. Lorsque la boîte de réception DM kind 10050 d’un destinataire ne peut pas être lue, la file d’envois retenus NIP-17 réutilise désormais l’ID du gift wrap destinataire déjà accepté par un relay, ce qui préserve l’identité de ce wrap d’une tentative à l’autre. Si une nouvelle tentative trouve la boîte de réception, le client peut republier sur les relays annoncés. Si aucune boîte n’est trouvée, il s’en tient à la copie acceptée et compte sur les relays pour la conserver. Les messages peuvent encore s’afficher comme Failed. La livraison au destinataire ou sa lecture ne sont toujours pas prouvées ; les nouvelles tentatives pour les réactions et les suppressions restent en dehors de ce changement. Le préchargement des notifications publiques et l’actualisation du fuseau horaire utilisent un cache de miniatures borné et un index SQLite partagé, à l’exclusion des DM et des campagnes. Ils nécessitent une version native normale ainsi qu’un changement de service coordonné, et l’exécution en arrière-plan n’est pas garantie. L’éditeur vidéo gagne cinq transitions, pour un total de 20, rendues nativement en aperçu et à l’export. Le mode mouvements réduits limite délibérément les vignettes d’aperçu. L’espacement des flashs peut se rabattre sur un fondu enchaîné. Nous n’avons pas testé l’implémentation native en conditions réelles.

Quatre pull requests ouvertes n’étaient pas fusionnées à notre date limite de collecte des sources. Les stickers vidéo sociaux, empilés sur un travail antérieur autour des stickers d’information, écriraient de petits tags de stickers à plat avec des métadonnées de mention (p), de hashtag (t) et de lien (r). Le lecteur superposerait des zones cliquables et avertirait avant l’ouverture de liens externes. Les autres clients ne voient que les stickers incrustés dans la vidéo, à moins d’implémenter ces tags, qui ne constituent pas un NIP accepté. Les mentions dans les discussions Concord soumises à un drapeau garderaient les identités à l’intérieur de messages chiffrés authentifiés. Dans l’application, les alertes ne proviendraient que d’expéditeurs suivis et non bloqués, dans les salons que l’utilisateur a ouverts, avec un plafond de 50 lignes et un état de lecture enregistré. Elles ne déclencheraient ni notifications push du système ni déploiement public des discussions, et les vérifications de collision d’identité, de rejeu et de blocage ne sont couvertes que par des tests ciblés. Les tags de rumor NIP-17 nommeraient une seule fois l’auteur de la réaction avec le kind réel, et les suppressions encapsulées abandonneraient les tags p trompeurs. Les gift wraps étaient déjà adressés aux bons destinataires, donc ce changement ne corrige pas une fuite de destinataires. Les rumors déjà en file d’attente restent inchangés, le comportement dans les autres clients n’est pas testé et un compromis sur le classement par salon demeure. Le prochain build natif activerait par défaut le partage par liens courts existant, tandis que la version web resterait désactivée. Les parcours désactivé, déconnecté et en erreur conserveraient les URL canoniques complètes. La distribution dans les stores, l’état de préparation du service et les vérifications sur appareil ne sont pas prouvés.

rust-nostr

rust-nostr, un ensemble de bibliothèques Rust pour le protocole Nostr, a fusionné une modification incompatible de la façon dont les abonnements sont réémis. SubscriptionData indique désormais l’état EOSE actuel de chaque relay. La réémission place en file d’attente le CLOSE et le REQ du filtre enregistré en une seule étape atomique, même en cas de déconnexion, ce qui garantit leur mise en file mais pas l’arrivée des deux trames au relay. La reprise après une interruption des notifications ne supprime plus silencieusement un abonnement et n’envoie plus de requête en double. Des messages EOSE ou des events tardifs issus du REQ précédent peuvent encore se superposer au nouveau, car rien sur le réseau ne permet de les distinguer. Il s’agit de code source fusionné, et nous n’avons pas confirmé sa présence dans une version publiée.

nostr-sdk-ffi

nostr-sdk-ffi, les bindings qui permettent à d’autres langages d’utiliser le SDK de rust-nostr, a fusionné un accès brut aux clés de conversation NIP-44 v2, de sorte que les hôtes Concord n’ont plus besoin d’embarquer leur propre code ECDH et HKDF. Il s’agit d’une fine couche autour de la dérivation existante, sans nouvelle cryptographie. L’auteur a fait état d’un build Python et d’un aller-retour produisant la même clé des deux côtés, mais n’a ajouté aucun test unitaire dédié. Il s’agit uniquement de code source fusionné.

NDK

NDK, un kit de développement Nostr pour Dart, a publié 0.11.0-dev.2, une préversion avec des changements incompatibles. Ce n’est pas une 0.11.0 stable, et elle n’a aucun lien avec le NDK JavaScript. Cette version ajoute les clés ncryptsec chiffrées par mot de passe NIP-49, avec une interface d’exemple. Ses notes indiquent que le déchiffrement borne logN, rejette les octets de sécurité inconnus et met à zéro les tampons dérivés ; ces affirmations reposent sur les notes et sur le code source fusionné, et nous n’avons vu ni audit indépendant ni exécution de vecteurs de test. Les requêtes signalent désormais un résultat notSent portant l’échec de connexion ou d’envoi, et les requêtes vers des relays injoignables se terminent dès qu’aucun relay ni filtre restant ne peut répondre, sans attendre l’expiration d’un délai. Les diffusions vérifient la présence d’un signer avant de marquer un event comme en cours d’envoi, les ID des requêtes de zap utilisent le created_at enregistré, et les métadonnées de relay NIP-11 sont récupérées à la demande via un cache partagé, si bien qu’elles ne bloquent plus chaque synchronisation.

La préversion inclut également des changements jusque-là présents uniquement dans le code source. Les listes NIP-65 qui répètent une URL de relay sont désormais fusionnées correctement, en combinant les marqueurs de lecture et d’écriture et en préservant l’ensemble des relays d’écriture de l’outbox ; l’auteur a relevé 5 listes mal lues sur 932 profils lors d’une observation unique. Une vérification préalable facultative de téléversement BUD-06 demande au serveur, avec l’autorisation propre au téléversement, s’il accepterait un blob, puis rapporte le statut et le motif, comme le font désormais aussi les véritables refus de téléversement. Une réponse 404 signifie que la prise en charge est inconnue, et une vérification réussie ne garantit pas le succès du téléversement. Une modification incompatible des délais de réconciliation NIP-77 scinde le délai unique en délais d’ouverture et d’inactivité, avec une erreur typée, en excluant le temps passé à attendre l’authentification. Il n’existe pas d’échéance globale : une synchronisation qui continue de progresser peut donc durer indéfiniment, et nous n’avons pas vu ce changement vérifié face à un relay réel.

Des pull requests ouvertes proposent une mise en cache NIP-05 indexée par identifiant, avec mise en cache négative, une API de cache renvoyant ID et horodatages pour NIP-77, la gestion de l’état de disponibilité des WebSockets, l’intégralité des champs NIP-11 et l’achèvement des requêtes lorsqu’une connexion est refusée. Une autre proposition, toujours ouverte lors d’une vérification récente de son statut, permettrait de créer et de récupérer des comptes avec les passkeys des plateformes navigateur et Flutter, en suivant une ébauche de conception d’identité par passkey avec des modes de clé dérivée et stockée, ainsi que des métadonnées héritées explicites. Les handles inconnus sont refusés et ne sont jamais traités comme un nouveau compte, et la récupération doit être vérifiée de façon indépendante avant qu’un enregistrement stocké soit conservé. L’auteur note que l’interopérabilité n’a pas été validée auprès de tous les fournisseurs de passkeys.

Applesauce

Applesauce, un ensemble de bibliothèques TypeScript pour Nostr, compte de nouveaux changements de code source accompagnés de changesets, et nous n’affirmons pas l’existence d’une version publiée correspondante. Des clients de messagerie autonomes et une authentification explicite auprès des relays ajoutent des clients NIP-04 et NIP-17 pour un compte fixe, qui émettent des requêtes d’authentification NIP-42 explicites et réessaient des envois signés préparés. Des conversations encapsulées et des magasins de rumors à portée limitée exposent les rumors de kind 14 et des modèles de fils sans lancer de travail côté signer ou réseau. Le déchiffrement est désactivé par défaut, les envois encapsulés nécessitent des relays kind 10050 pour chaque participant, expéditeur compris, et l’acceptation par un relay ne vaut pas réception par le pair. La restauration bornée du cache de contenu déchiffré utilise par défaut une concurrence de 8, ce qui peut réordonner les events à moins de la régler sur 1. Les applications doivent elles-mêmes cloisonner et chiffrer ces caches en clair. Viennent ensuite le transport NDR et un client coordinateur Cordn distinct. NDR doit persister son propre état de ratchet distinct, et Submitted désigne une remise locale, non une réception par le pair. Cordn ne gère que le transport, est mis de côté dans l’exemple et n’implémente pas MLS. L’intégration ContextVM de Kehto par fenêtre donne à chaque fenêtre de napplet une identité ContextVM éphémère, sans authentification de compte ni paiements. Avec des dépôts durables détenus par l’application et la récupération des nutzaps, les nouveaux dépôts et rachats de portefeuille nécessitent un magasin de récupération fourni par l’application consommatrice ainsi que la restauration NUT-09 du mint. Le journal persiste des preuves dépensables, des secrets et des facteurs d’aveuglement : il doit donc être chiffré et cloisonné par compte. La reprise ne s’exécute que lorsqu’elle est appelée explicitement, réutilise les ID signés et conserve le journal jusqu’à une acceptation positive par un relay, et l’annulation n’invalide pas la facture. Les instantanés de timeline groupés avec un état de portefeuille synchrone regroupent les mises à jour de la timeline par fenêtres de 16 ms, tandis que l’état des jetons du portefeuille reste synchrone. Le planificateur de requêtes COUNT, proposé la semaine dernière, a maintenant été fusionné. Il démarre à 8 sous un plafond de concurrence et double jusqu’à la première erreur de limitation de débit ou de transport ; chaque erreur divise le plafond par deux et ajoute une période de refroidissement. Les dépassements de délai remontent sous forme de CountFailure sans abaisser le plafond. La latence ne sert qu’à orienter le choix des relays ; le benchmark sur trois relays reste insuffisant pour des affirmations générales sur les performances.

eventstore

eventstore, la bibliothèque de fiatjaf proposant des backends de stockage pour les events Nostr, a fusionné deux correctifs de requêtes. Aucune version étiquetée les contenant n’a été vérifiée. Tous les backends suivent désormais la règle NIP-01 sur les listes de filtres vides : une liste ids, authors, kinds ou de tags vide ne correspond à rien, tandis qu’une liste de tags absente (nil) n’impose toujours aucune restriction. Un correctif du comptage des events dans LMDB fait avancer le curseur HyperLogLog après une correspondance, si bien que les comptages ne bloquent plus indéfiniment. Le comptage n’applique plus non plus de vérification d’auteur, de kind ou de tag lorsque le filtre n’en comporte pas, ce qui lui faisait renvoyer zéro.

zsp

zsp, l’outil en ligne de commande de Zapstore pour publier des applications Android sur Nostr, a publié la version 2.0.0. Le README à ce tag présente un assistant dans lequel une personne prouve qu’elle possède le certificat de signature C1, ainsi qu’une commande zsp skill qui fournit aux agents des instructions de publication. Il interdit de confier aux agents le keystore, son mot de passe ou toute clé privée, afin que la preuve reste humaine. La version détecte aussi les keystores JKS et PKCS12 d’après leur contenu, si bien que les magasins PKCS12 nommés .jks ou .keystore se chargent aussi bien dans l’assistant que dans le parcours de publication. Nous n’avons pas testé de publication avec cet outil.

nsite-gateway

nsite-gateway, qui sert des sites web statiques publiés sur Nostr, a publié la version 3.6.6. La modification du code source passe à Applesauce 7 et rétablit l’expiration des events. Les versions antérieures substituaient délibérément un gestionnaire d’expiration désactivé pour contourner un bogue amont d’écrêtage des minuteurs, de sorte que des events de site expirés pouvaient rester actifs indéfiniment dans le magasin de la passerelle. Le correctif amont étant en place, la passerelle utilise de nouveau le magasin d’events normal. L’expiration régit ici ce que la passerelle conserve et sert ; elle ne supprime pas les events des relays ni des caches tiers. Nous n’avons pas testé de passerelle déployée.

44billion

44billion, un lanceur d’applications Nostr, a modifié la façon dont il mémorise les autorisations. Les autorisations enregistrées sont désormais liées à l’application, au nom de l’autorisation, au kind de l’event et à la portée, et une autorisation générique de kind -1 n’autorise plus des kinds spécifiques. Les portées ne sont granulaires que pour les paires kind et portée enregistrées disposant de libellés traduits ; les portées inconnues se rabattent sur une portée vide couvrant le kind entier, et le registre démarre vide. La version 5 du schéma IndexedDB réinitialise volontairement les autorisations de la version 4 et supprime au démarrage les autorisations à portée non prise en charge, tout en conservant les autres données de l’application. L’API personnalisée de chiffrement personnel comprend des fonctions utilitaires de style NIP-44 v3 qui ne constituent pas un standard accepté. Il s’agit d’une modification du code source sans version publiée ni déploiement identifiés.

Un code source plus récent ajoute des réglages d’accès aux données des applications qui regroupent les autorisations mémorisées par application et permettent aux utilisateurs de révoquer une autorisation ou une application entière sans rechargement. La révocation ne concerne que les futures requêtes protégées. Les données déjà stockées ou copiées ne sont pas supprimées, et les traitements déjà en cours peuvent ne pas être arrêtés. Une modification du cache des ressources Blossom ne considère une ressource en cache comme complète qu’après la vérification du SHA-256 du corps entier et l’enregistrement d’un marqueur validé correspondant. Les fragments provisoires issus d’anciens caches sont revalidés, et le streaming ne signale plus de faux fragment final. Cela ne signifie pas qu’aucun octet n’est exposé avant la validation, et il n’y a pas de nouvelle version binaire.

Blossom Servers

L’annuaire Blossom Servers a ajouté des rapports de capacités communautaires pour chaque URL de serveur, chacun attribué à son contributeur. Les déclarations manuelles et les observations faites depuis le navigateur sont conservées séparément et sortent des filtres au bout de 90 jours et de 24 heures respectivement. Dans leur ensemble, les vérifications examinent les réponses HTTP et les méthodes annoncées, ainsi que les défis d’authentification et de paiement. Les vérifications anonymes depuis le navigateur envoient une requête HEAD proposant les métadonnées d’un PNG de 68 octets sans rien téléverser, de sorte qu’une réponse 200 ne prouve pas qu’un véritable téléversement fonctionne. Le chargement des discussions est désormais cloisonné, et l’attribution au contributeur remplace l’autorité d’opérateur auparavant implicite. Un rapport ne prouve pas qui exploite un serveur et ne dit rien de la disponibilité globale ni d’une conformité BUD complète ; les contributeurs peuvent être en désaccord ou se tromper. Nous n’avons vérifié ni déploiement ni version publiée.

Un code source plus récent ajoute des relays d’application et de recherche configurables et lit les comptes et les outbox via NIP-65. Une liste de recherche publique kind 10086 existante est prioritaire. L’enregistrement ne met à jour la liste publique que si elle existe déjà et reste local sinon. L’enregistrement local de publication n’est mis à jour qu’après l’accusé de réception de l’event par au moins un relay, ce qui ne signifie pas que tous les relays l’ont reçu. Aucune version publiée ni aucun déploiement ne sont confirmés.

Ditto

Ditto, le client Nostr de Soapbox, a corrigé les métadonnées H.264 produites par des encodeurs WebCodecs défectueux afin que les vidéos transcodées puissent être lues sur iOS. Il détecte les octets d’en-tête NAL SPS et PPS dupliqués ainsi que les bits réservés erronés dans l’enregistrement avcC, et les répare avant que le muxer Mediabunny n’écrive les métadonnées MP4, en laissant inchangés les enregistrements bien formés ou non reconnus. La version 2.45.1 est sortie, mais nous n’avons pas confirmé qu’elle contient le correctif, ni testé la lecture sur un appareil iOS physique. Le changement cible ce défaut H.264, et non l’ensemble des codecs ou des vidéos.

Signer de bureau Amber et correctif NIP-46 sur Android

Amber, le signer Nostr pour Android, a fusionné le 27 octobre du code source pour un signer NIP-46 de bureau en Compose (Windows/macOS/Linux) qui reproduit le modèle d’autorisations par application et par kind d’Android (commit). NIP-55 reste réservé à Android. Le code de bureau prend en charge plusieurs comptes et des connexions nostrconnect/bunker avec des relays et un historique propres à chaque application, ainsi que Tor et des notifications dans la zone de notification. Un stockage PKCS12 chiffré, protégé par une phrase secrète Argon2id obligatoire, conserve les clés, avec des bases de données chiffrées par compte. Nous n’avons vérifié ni le packaging de bureau ni le comportement à l’exécution.

Une autre modification fusionnée, qui concerne l’application Android et non le signer de bureau, actualise les abonnements aux relays NIP-46 et les filtres de connexion après la déconnexion d’un compte. Amber cesse ainsi d’écouter pour les clés d’un compte supprimé. La notification masquée de l’écran de verrouillage affiche désormais aussi la description de la requête. La notification gagne en utilité, mais cela n’apporte aucune confidentialité supplémentaire. Aucune nouvelle version stable contenant l’un ou l’autre de ces changements Android n’est confirmée.

Intents de napplets et données d’application synchronisées dans noStrudel

Le client web noStrudel a fusionné plusieurs modifications du code source, sans tag ni déploiement confirmés. Les intents entre napplets sont résolus via le catalogue et les déclarations de manifeste z/i, et les charges utiles acceptées sont remises après le chargement du cadre cible avec un ID d’expéditeur attesté par le runtime ; les intents non pris en charge sont rejetés et les gestionnaires à cible explicite nécessitent une confirmation de l’utilisateur (commit). Les napplets installées et les gestionnaires par défaut sont synchronisés par compte dans des données d’application kind 30078 chiffrées en NIP-44, avec une fusion à trois voies (commit), et les moniteurs de relays NIP-66 sélectionnés sont synchronisés via des données d’application NIP-78 chiffrées (commit). Quant aux messages NIP-17, ils hydratent les gift wraps en cache et rapprochent trente jours de messages depuis les relays DM une fois par session, en utilisant NIP-77 lorsqu’il est pris en charge, l’historique plus ancien étant chargé à la demande (commit).

Nostr Feedz archivé

Nostr Feedz, qui associait RSS aux contenus longs et aux vidéos de Nostr, indique désormais dans son README qu’il est archivé et n’est plus maintenu (commit). L’avis renvoie vers Readstr, de PrivKey, un fork qui poursuit le développement. Il s’agit d’un changement de statut de maintenance, et nous n’avons pas vérifié si GitHub marque le dépôt comme archivé ni si les comptes et les données sont repris.

Zap Cooking : listes protégées, correctifs de signer et inscription par passkey

Zap Cooking, un client Nostr de partage de recettes, a fusionné un important lot de modifications du code source web ; le déploiement ou la publication ne sont pas confirmés. Les écritures de listes enregistrées kind 30001 commencent désormais par une lecture et sont sérialisées par compte, en préservant les tags étrangers et le contenu chiffré à partir de la base complète la plus récente, et elles sont refusées lorsque la liste de relays est inconnue ou que le quorum n’est pas atteint (#869). Le quorum exige au moins deux réponses EOSE de relays capables de gérer les listes, plus la moitié des relays d’écriture compatibles de l’utilisateur, et une réponse vide de nostr.wine ne peut pas prouver une absence (#878). Les collections personnalisées partagent cet écrivain protégé, les opérations plus anciennes en file d’attente sont rejouées sous de nouvelles protections (#885), et un EOSE agrégé vide ne suffit plus à afficher une liste comme vide (#872).

Une méthode d’authentification explicite corrige un bogue de minification en production qui confondait les classes de signer, si bien que le chiffrement NIP-46 et NIP-07 utilise le signer actif, et non une clé locale périmée ; la sauvegarde du portefeuille sur les relays reste bloquée pour NIP-46 (#896). Une connexion lancée depuis un enregistrement ou une réaction reprend cette action. Un zap en attente conserve le montant et la cible, mais nécessite toujours d’appuyer sur Send. Les refus du signer affichent une erreur, sans nouvelle signature silencieuse sous une clé étrangère (#867).

L’inscription crée l’identité localement, avec une synchronisation du coffre chiffré par passkey activée par défaut ; une clé de sauvegarde est exigée si la synchronisation est désactivée ou si le téléversement échoue, et Google Drive sert uniquement à la restauration (#893). La configuration WebAuthn PRF en une seule invite laisse le coffre non confirmé et le nsec en clair dans le navigateur jusqu’à ce qu’un déchiffrement ultérieur réussi du coffre confirme celui-ci et supprime la clé en clair (#907). L’extension de cette invite à l’inscription repose sur un enregistrement non signé qui ne constitue pas une authentification : quiconque dispose d’un défi serveur récent peut forger un enregistrement accepté, et un attaquant connaissant l’ID de l’identifiant peut remplacer une entrée non confirmée (TTL de 30 jours) et priver le véritable utilisateur de synchronisation (#911). Ce sont des compromis documentés, et non des garanties de sécurité.

Les liens vers les notes sont encodés en nevent NIP-19 avec jusqu’à trois indications de relays observés, ce qui aide les clients à trouver des events faiblement répliqués sans garantir leur disponibilité (#873). Les réponses du profil incluent les commentaires NIP-22 kind 1111 ancrés sur des events (#877), et une correction de l’analyseur de coordonnées maintient dans les packs et les plans les recettes dont le d-tag est une URL (#888). L’expérience de paywall pour les recettes premium est abandonnée après qu’un audit mené par l’auteur du code a révélé un contournement via la pubkey de la requête, les anciennes publications kind 35000 restant lisibles en tant que contenu stocké (#862).

Une proposition ouverte, pas encore fusionnée, porte sur les listes de mise en sourdine (#921). Une récupération indisponible de la liste de mise en sourdine resterait distincte d’une récupération réussie qui renvoie une liste ou aucune liste. Le changement cesserait de mettre en cache pendant cinq minutes une récupération indisponible sous forme de liste vide. Les échecs d’analyse seraient réessayés, avec un avertissement lorsque le déchiffrement des mises en sourdine privées échoue. L’ouverture de la cloche de notifications rechargerait la liste. L’objectif est d’empêcher qu’une liste de mise en sourdine vide et silencieusement périmée laisse des auteurs mis en sourdine apparaître dans les notifications. Cela ne fait pas en sorte que tous les échecs bloquent le contenu, et ce n’est pas déployé.

Paiements de zaps via NWC dans Lumilumi

Lumilumi, un client web Nostr, dispose d’une pull request en brouillon qui permettrait de payer les factures de zap via Nostr Wallet Connect (NIP-47) en un seul appui (#1120). L’URI de connexion permettant les dépenses est stockée uniquement en local et exclue de la sauvegarde des réglages kind 30078 en clair. Les requêtes utilisent NIP-44 lorsque le portefeuille annonce nip44_v2, et se rabattent sinon sur NIP-04. L’auteur l’a vérifiée avec un portefeuille simulé, sans paiement réel, et le brouillon n’était pas fusionné à notre date limite de collecte des sources.

Recherche d’identifiants dans Wisp

Une pull request ouverte pour le client Nostr Wisp, non fusionnée à notre date limite de collecte des sources, permettrait à la recherche de reconnaître les identifiants NIP-19 et NIP-05 collés, les clés hexadécimales et les liens web vers des entités avant de se rabattre sur une requête textuelle NIP-50 (#681). Les recherches s’appuient sur les indications de relays et sur le cache local. La recherche afficherait les résultats au fil de l’eau en attendant l’EOSE des relays interrogés, avec un plafond de 15 secondes, si bien que les relays lents ne sont plus écartés. L’auteur indique avoir testé uniquement sur émulateur, et non sur un appareil physique.

Prise en charge d’Android TV dans Zapstore

Zapstore, le magasin d’applications fondé sur Nostr, a une pull request v2 ouverte pour Android TV, non fusionnée à notre date limite de collecte des sources (#407). Elle prendrait en compte les ABI 32 bits et gérerait la navigation Leanback à la seule télécommande, avec une solution de repli lorsque l’écran d’autorisation d’installation n’est pas disponible. Les builds 32 bits dépourvus d’Arti affichent explicitement une connexion Direct uniquement, tandis que les builds 64 bits auxquels Arti manque échouent en mode fermé. Le build TV utilise un signer de débogage local destiné aux tests et non à la distribution, et l’unique test sur téléviseur de l’auteur a utilisé un relay compilé localement parce que le bundle public n’était pas disponible.

Propositions de durcissement et NIP-11 pour strfry

strfry, le relay Nostr en C++, fait l’objet de deux propositions non fusionnées à notre date limite de collecte des sources. #281 répond aux constats SF-01 à SF-13 d’un audit du relay en bornant la profondeur JSON, les charges utiles décompressées, les files d’attente et les libellés de métriques, en corrigeant un plantage sur un filtre negentropy vide et en hachant les index pour les tags longs. Elle passe au format de base de données 4, si bien que ceux qui l’adoptent devraient exporter puis réimporter leurs données. Les tests qu’elle réussit sont ceux de l’auteur. Le brouillon #278 n’annoncerait que les limitations NIP-11 effectivement appliquées, plus des frais et un payments_url facultatifs, payment_required valant false par défaut et les prix configurés n’implémentant pas les paiements.

Paiements Bark dans nostrcheck-server

nostrcheck-server, un serveur d’hébergement de médias Nostr, a une pull request en brouillon qui ajoute un fournisseur de paiement barkd (Bark) (#62). Elle créerait des factures Lightning via l’API REST de barkd et joindrait éventuellement aux réponses 402 une URI X-Ark BIP-321 propre à chaque fichier, avec la même facture Lightning comme solution de repli. Un portefeuille rattaché au même serveur Ark paie via Ark, les autres utilisent Lightning, et un paiement réglé déverrouille le fichier une seule fois. Les tests utilisent un barkd simulé, et elle dépend de la pull request BUD-07 ouverte #61. Elle n’était pas fusionnée à notre date limite de collecte des sources et n’est pas une fonctionnalité de share.yabu.me.

Écritures payantes dans le nostr-relay de mattn

Une pull request en brouillon pour le nostr-relay de mattn, non fusionnée à notre date limite de collecte des sources, ajouterait des écritures payantes facultatives via un portefeuille Bark, désactivées par défaut (#37). Les pubkeys prépaieraient les frais d’écriture via barkd, avec un filtre de kind facultatif, et les auteurs sans crédit recevraient une réponse restricted: accompagnée d’une URL de paiement. Chaque rechargement passerait par Ark ou Lightning au moyen d’URI BIP-321 ou de NWC, les frais étant listés dans NIP-11. Les tests utilisent un démon simulé, et il n’est pas encore décidé si cela doit figurer dans l’arborescence du projet ou derrière un hook.

Protection contre le rejeu à la reconnexion dans ContextVM

ContextVM, qui transporte MCP sur Nostr, a une pull request ouverte pour son SDK TypeScript qui empêcherait les exécutions en double après une reconnexion aux relays (#113). Le transport côté serveur conserverait les ID d’events vérifiés jusqu’à sa fermeture, et un cache d’enveloppes distinct et borné bloque les doublons réencapsulés. La mémoire croît avec le nombre d’events vérifiés uniques pendant la durée de vie du transport. Le correctif n’était pas fusionné à notre date limite de collecte des sources et ne figure dans aucun paquet publié.

Lecture de médias et approbations dans le shell Kehto

Kehto, un shell web pour les napplets Nostr, a fusionné la lecture NAP-MEDIA le 28 octobre. Les hôtes Paja et playground partagent désormais un lecteur audio et vidéo encadré par des politiques. Celui-ci utilise les codecs du navigateur pour les sources URL et Blossom finies, et lit les flux en direct MP3 ou ADTS AAC en HTTPS lorsque MediaSource prend en charge le codec, en démarrant avant la fin de la réponse. L’autorité de session reste liée au point de terminaison, à la fenêtre source et à l’ACL. Une révocation ou un démontage retire les URL Blob, arrête la lecture et annule les flux. La méthode ResourceService.openStream, réservée à l’hôte, utilise les autorisations et la politique existantes fondées sur l’origine du point de terminaison, et n’ajoute aucun message de ressource sur le réseau. La remise terminale est conservée. L’ancien alias sendCommand fonctionne toujours. Par ailleurs, les callbacks à deux arguments détectables continuent de fonctionner, avec un avertissement. Les anciens callbacks unaires passent à des objets de commande. Le résolveur du navigateur rejette les URL non HTTPS, les identifiants et les adresses IP privées littérales. Il désactive aussi les redirections et les référents. Comme il ne peut pas inspecter le DNS, il ne garantit pas la protection contre les adresses privées au moment de la résolution : les résolveurs de production nécessitent des vérifications au moment du DNS, et le comportement par défaut du navigateur s’appuie sur CORS et sur la protection des réseaux privés. HLS, DASH, Ogg en direct, les sources Nostr, les files d’attente, la persistance et la reprise automatique au retour du focus restent non pris en charge. L’auteur fait état de 155 tests Chromium et de 112 secondes de lecture radio depuis un artefact Funclet non modifié, que nous n’avons pas réexécutés. Il s’agit d’un travail uniquement au niveau du code source. Le paquet Napplet 0.32 publié ne contient pas certains types du brouillon. NAP-MEDIA reste à l’état de brouillon ; aucune conformité dans une version publiée n’est revendiquée.

Une seconde modification fusionnée rend les approbations de signature et de publication propres à chaque version. Chaque approbation est liée à l’éditeur vérifié, au hash de l’artefact et au signer actif. Les approbations peuvent être révoquées, et les approbations de signature seule et de publication seule sont distinctes. Une ancienne autorisation n’est jamais étendue silencieusement. Le consentement pour une URL de développement modifiable ne vaut que pour ce chargement, et un changement de point de terminaison ou de compte rejette les requêtes en attente. NAP-LINK n’ouvre un lien qu’après un clic explicite dans une fenêtre modale de l’hôte, avec noopener. Le changement ne prétend pas avoir été testé de façon exhaustive face à des sources radio CVM externes, et une fusion dans le code source ne démontre pas une publication sur npm.

Pact

Pact, un protocole Nostr dédié aux relations entre agents et au consentement des opérateurs, authentifie désormais les réponses Nostr Wallet Connect. Chaque résultat doit porter la signature du portefeuille et faire référence à sa requête, et Pact vérifie le type de résultat et le hash de paiement ainsi que toute préimage renvoyée. Le rachat bénéficie d’écritures atomiques dans le registre et de protections sur la consommation et la nouvelle tentative des requêtes, et d’autres voies de falsification du consentement sont fermées. Un correctif complémentaire plafonnant les paiements MCP les laisse désactivés tant que PACT_MCP_ALLOW_PAYMENTS=1 n’est pas défini et vérifie un plafond par défaut de 1 000 sats à la fois sur le montant déclaré et sur le montant BOLT11. La fenêtre de la boîte de réception privée s’arrête désormais à 200 wraps et signale la troncature. Les tests de l’auteur reposent sur des simulations.

nostr.watch

nostr.watch, un moniteur de relays Nostr, ajoute une prise en charge explicite de la découverte et du transport FIPS, et les recherches dans l’overlay ne retombent plus sur le DNS-over-HTTPS public. Les hôtes fournissent toujours le DNS et le routage IPv6, car le moniteur n’embarque ni démon ni proxy FIPS et n’offre aucun anonymat. Une vérification plus stricte des npub n’accepte les npub qu’à l’intérieur de noms d’hôte .fips analysés. Les sondes automatiques NIP-11 et NIP-05 passent dans un ServiceWorker détenu par l’application, ce qui retire le contexte de l’onglet propriétaire du chemin de navigation piloté par une extension qui avait été observé ; cela a été vérifié dans Firefox 155 standard avec une extension de test contrôlée. La suite de conformité comprend quinze vérifications NIP-01 bornées, avec une couche de conversation prenant en charge des connexions indépendantes. L’auteur fait état de tests réussis et d’exécutions sur un maillage isolé, et non d’un audit sur relay public ou de sécurité du navigateur.

Bitcredit Core

Bitcredit Core, un protocole pair-à-pair de crédit et de lettres de change qui utilise Nostr, vérifie désormais qu’au moins un relay d’écriture est connecté avant qu’une opération sur un bloc ne persiste quoi que ce soit localement ou ne déclenche ses effets. La récupération se réinitialise également proprement. La validation des chaînes candidates, signalée comme ouverte la semaine dernière, a depuis été fusionnée : les chaînes sont donc validées et préparées avant d’être persistées. Ces étapes réduisent le risque d’un état local incohérent. Un relay connecté ne peut pas garantir que les relays acceptent l’event ni que le règlement aboutit, et cette vérification ne rend pas à elle seule la persistance locale durable.

Une fusion plus récente, non confirmée dans une version publiée, ajoute un gestionnaire de transactions au service d’identité. Les blocs d’identité, l’état et la confirmation d’e-mail sont désormais validés de manière atomique avant toute propagation sur Nostr, et de nouveaux tests vérifient que rien n’est envoyé lorsque la validation échoue. Cela ne couvre que le service d’identité. La persistance des lettres de change et des entreprises ne bénéficie pas de cette validation atomique, et l’acceptation par les relays comme le règlement ne sont toujours pas garantis.

MLS-KMP et compatibilité avec Marmot

MLS-KMP, la bibliothèque MLS en Kotlin sous-jacente à marmot-kmp, avait auparavant corrigé plusieurs comportements sur le réseau pour s’aligner sur d’autres implémentations MLS, si bien que les membres en 1.2.0 et ceux utilisant ce code plus récent sont en désaccord dans les cas énumérés, et les groupes doivent se mettre à jour ensemble. L’état enregistré est passé à la version 10, que les versions plus anciennes ne peuvent pas restaurer. La tâche de compatibilité Marmot en aval n’est pas bloquante. Ses tests ne se sont pas exécutés dans l’environnement où ce changement a été rédigé ; Marmot doit encore s’adapter à authorizeProposal et à GREASE. Une modification antérieure des app-components impose les composants dont Marmot a besoin pour suivre MDK v0.14. Nous n’avons pas vérifié son adoption dans Amethyst.

Un code source fusionné plus récent, non revendiqué pour la version 1.3.0 publiée, répare la compilation de l’exécuteur d’interopérabilité nocturne et indique la réussite, l’échec ou l’omission pour chaque script. Notre remarque antérieure selon laquelle l’exécuteur réel n’avait jamais tourné est donc dépassée : les auteurs font état d’exécutions fonctionnelles, même si la dernière exécution était encore en cours à l’ouverture du changement et que nous n’avons pas relu de résultat CI final. La tâche OpenMLS reste non bloquante, omet 22 scénarios non pris en charge ou provoquant un panic et ne couvre que la ciphersuite 0x0001 : elle ne certifie donc pas l’interopérabilité. Ce changement corrige également la recherche de PSK ReInit par ID de groupe conservé, la transcription intermédiaire de l’epoch zéro, le secret aléatoire du premier epoch et la gestion du PSK de reprise lors des commits externes. Pour la transcription de l’epoch zéro, le code suit désormais la section 11 de la RFC 9420 afin de s’aligner sur OpenMLS : les jonctions externes dans l’epoch 0 diffèrent donc de la 1.3.0 et des versions antérieures, et les groupes plus anciens enregistrés conservent l’ancien hash jusqu’à leur premier commit. Le moteur d’origine dérivait son premier secret d’epoch à partir de zéro ; les auteurs n’ont identifié aucune exploitation, car les commits ultérieurs portent un UpdatePath neuf, et le correctif ne démontre pas que tous les problèmes de sécurité sont résolus.

Obelisk Relay

Obelisk Relay a fusionné dans sa branche par défaut un correctif pour les groupes NIP-29 privés. Les administrateurs globaux du relay pouvaient déjà envoyer des REQ pour les groupes privés, mais le filtre de visibilité des events rejetait encore les events correspondants. Les administrateurs du relay peuvent désormais lire ces events, et les contrôles d’accès des membres restent en place. Un groupe privé au niveau du relay n’est pas chiffré de bout en bout, et le changement rend explicite la visibilité dont dispose l’administrateur du serveur. Le correctif est un travail sur le code source fusionné, destiné aux développeurs et aux opérateurs.

Plume

Plume, le client de bureau en Rust et Tauri, a fusionné un changement qui maintient une seule WebSocket persistante, avec reconnexion, par relay. Les opérations de flux, de profil, de publication et de messages directs partagent toutes cette connexion. Les abonnements et les ID d’events y sont multiplexés. Des délais croissants séparent les tentatives de reconnexion ; les connexions se ferment à la sortie de l’application. Avant ce changement, chaque opération ouvrait un nouveau socket qui n’était ensuite jamais libéré. Le changement examiné est un travail sur le code source fusionné ; aucune mesure de performance n’est établie ici. Il ne promet ni récupération sans perte ni livraison garantie.

Hashtree

Le runtime TypeScript 0.5.22 de Hashtree permet aux fournisseurs côté navigateur de conserver dans IndexedDB jusqu’à 256 annonces publiques de pairs signées et à jour, cloisonnées par identité et par application. Les fournisseurs peuvent les recharger avant la découverte sur le réseau. Les REQ ordinaires des pairs peuvent rejouer ce cache lorsque les règles d’admission existantes le permettent, et la découverte privée reste dans une portée de propriétaire distincte. Par ailleurs, une modification fusionnée de l’adaptateur Rust annule les lectures d’index abandonnées, si bien que les commandes n’attendent plus l’expiration complète du délai de transport. La pull request indique que hashtree-nostr-pubsub 0.2.87 a été publié, et ce paquet est versionné séparément du runtime TypeScript. Des commits du client Rust, présents uniquement dans le code source, ajoutent la combinaison des origines Blossom héritées, de lecture et d’écriture pour les lectures et une nouvelle tentative unique, par source, en cas de réinitialisation de connexion typée au stade de la requête, sans mise en cache des réponses partielles. Une seule installation à froid sur un Mac ne prouve pas que les dépassements de délai intermittents lors des transferts sont corrigés.

nostr-pubsub

nostr-pubsub TS 0.5.20 conserve un stockage borné d’events signés et ajoute la persistance IndexedDB, des transactions atomiques entre onglets, l’expiration et la relecture locale pour les REQ Nostr ordinaires. La même source décrit séparément une API facultative de stockage sur fichier en Rust natif, avec des instantanés atomiques et un bail d’écriture exclusif, distincte du paquet TypeScript. Dans l’implémentation du stockage d’events durable, les rechargements revérifient les signatures et les gagnants des events remplaçables au sens de NIP-01, et rejettent les events éphémères ainsi que les horodatages en avance de plus de cinq minutes sur l’heure actuelle. Les stockages ne sont jamais ouverts implicitement, et c’est l’appelant qui choisit la portée de l’annonce publique. FIPS restaure les annonces signées de kind 37195 avant la découverte réseau et vérifie toujours la fraîcheur, le schéma et l’espace de noms. Les caches de découverte anonymes ou privés doivent rester séparés de la relecture publique, et un routeur qui récupère des données sur le réseau ne doit pas servir de source de relecture. Comme la rétention est bornée, cela ne permet pas un amorçage hors ligne indéfini.

FIPS-TS

Runtime FIPS-TS 0.0.57 accepte un fournisseur de découverte durable appartenant à l’application, qui publie les annonces signées de kind 37195 et s’y abonne via l’interface existante. Lorsqu’un fournisseur est injecté, le transport n’ouvre aucun client de relay Nostr et accepte une liste de relays vide, et l’arrêt draine les abonnements en attente. L’appelant est responsable de la durée de vie du fournisseur et du stockage restauré. Les vérifications d’espace de noms, de signature et d’expiration s’appliquent toujours. L’autorisation des pairs reste obligatoire. Les annonces en cache ne garantissent pas l’amorçage hors ligne, car le nouveau routage authentifié et la signalisation WebRTC nécessitent toujours un transporteur FIPS joignable.

Flotilla

Flotilla a fusionné trois modifications du code source. Partager dans le chat permet aux utilisateurs de partager des notes autonomes et des commentaires NIP-22 dans n’importe quel salon ou conversation. Citer un message dans une conversation n’ajoute plus l’auteur cité aux p-tags et ne crée plus de bifurcation dans la liste des membres. La reprise des téléversements interrompus restaure les téléversements de pièces jointes depuis les brouillons et permet aux utilisateurs de se remettre d’un échec de téléversement en affichant une erreur. Si la compression échoue, le fichier original est utilisé à la place, ce qui peut conserver ses métadonnées. L’attente des marqueurs de lecture enregistrés retient les écritures de marqueurs de lecture de la page jusqu’au chargement de l’état de lecture enregistré, afin que les mises à jour de lecture précoces ne soient pas perdues au démarrage.

following.space

Une pull request ouverte pour following.space, non fusionnée à la date limite de nos sources, rétablirait la création, la modification et la suppression de follow packs, ainsi que la possibilité de suivre les membres d’un pack. Elle utiliserait Applesauce pour la découverte des comptes et des relays outbox, et partagerait les packs sous forme d’adresses naddr. Elle prend en charge les signataires par extension de navigateur, un secret conservé uniquement en mémoire et les signataires bunker. Ni le code ni les tests décrits par l’auteur ne démontrent l’existence d’un service déployé ou la compatibilité avec tous les signataires.

Routstr

Trois pull requests de Routstr étaient ouvertes et non fusionnées à la date limite de nos sources. Dans le service principal, la découverte de l’état de santé des fournisseurs rejetterait les URL annoncées et les redirections qui se résolvent vers des adresses non globales, tout en conservant la gestion du proxy onion. Les auteurs décrivent une exposition à la falsification de requêtes côté serveur (SSRF) ainsi que des tests, mais il ne s’agit ni d’un correctif déployé ni d’une exploitation confirmée. Dans le SDK, l’attribution d’une URL à un fournisseur suivrait la clé ayant signé l’event de kind 38421. Une pubkey inscrite dans son contenu reste non vérifiée. Parmi les 81 events que l’auteur a vérifiés sur le relay par défaut, aucun ne contenait de listes de fournisseurs fondées sur le contenu. Rien ne permet donc d’affirmer que des URL connues ont été exploitées, ni que tous les fournisseurs sont désormais sûrs. L’épinglage automatique des chemins de modèles passerait de constantes intégrées à des instantanés signés dans des events adressables de confiance de kind 38427. Le SDK conserverait le dernier instantané valide et des repères de protection contre les retours en arrière, et un instantané vide servirait de coupe-circuit. Ce changement casse l’API des adaptateurs personnalisés. Aucun event de politique n’a été publié, et le déploiement reste une étape à la charge de l’opérateur.

SatSigner

Une pull request ouverte pour SatSigner, non fusionnée à la date limite de nos sources, remanie sa couche Nostr de relays, de cache et de synchronisation. Le fait de ne pas trouver un event (réponse de fin des events stockés envoyée par un relay) serait distingué des délais d’expiration comme de l’absence totale de relay. Le contenu en cache périmé serait signalé. Les events seraient stockés avant que le traitement ne fasse avancer les curseurs, et les identifiants des rumors des gift wraps seraient vérifiés. Supprimer une identité effacerait ses tables Nostr, mais une synchronisation de kind 0 peut écraser une modification locale du profil. Une suite empilée sur celle-ci ajouterait des diagnostics caviardés, des affiches vidéo à charger d’un toucher dans le fil Nostr avec au plus trois lecteurs, ainsi qu’un rattrapage à la reprise de l’application sans démanteler le pool de relays. Elle ajoute aussi des tests de relay qui injectent des pannes. Le nouveau module vidéo natif nécessite une recompilation de l’application, et la validation sur appareil est en attente. Aucune de ces deux modifications n’a été livrée ni n’a passé de vérification à l’exécution.

Bray

Bray 3.5.4 ajoute l’authentification de relay NIP-42 à son client et à son démon bunker NIP-46. Les relays privés qui exigent AUTH peuvent désormais servir à lire les messages adressés au bunker. Les modifications ultérieures du code source ne sont pas établies dans ce tag.

Dans le code source fusionné par la suite, le serveur MCP de Bray démarre en lecture seule lorsqu’aucun signataire n’est configuré ou que BRAY_READ_ONLY est forcé, et il prend cette décision avant d’ouvrir le moindre secret. Dans ce mode, aucun portefeuille n’est chargé, la signature, le chiffrement et le déchiffrement sont refusés, et seuls 111 de ses 261 outils, à savoir les outils de consultation, sont disponibles. La CLI et le SDK exigent toujours un signataire, et un fichier de secret configuré mais vide reste une erreur. Les nouvelles attestations utilisent désormais un espace de noms de labels d’attestation NIP-32, en remplacement de nip-va. La requête existante sur le type #l trouve à la fois les anciens et les nouveaux labels, tandis que signet-protocol conserve sa propre copie 2.5.5. Il ne s’agit pas d’une acceptation officielle en tant que NIP, et cela ne signifie pas que toutes les bibliothèques imbriquées ont migré. Rien n’indique que l’une ou l’autre de ces modifications figure dans la 3.5.4.

Extension de navigateur Alby

Une pull request ouverte pour l’extension de navigateur Alby Lightning, non fusionnée à la date limite de nos sources, ferait en sorte que son assistant de permissions rejette les entrées bloquées mémorisées en une seule lecture. Cela élimine une situation de concurrence dans laquelle la suppression d’une entrée de refus pouvait permettre à un gestionnaire Nostr d’agir sans demander de confirmation. Le chemin équivalent des entrées bloquées pour BTC et Liquid n’est actuellement pas atteignable. Il ne s’agit pas d’un correctif déployé, et aucune exploitation n’a été confirmée.

Politique d’écriture du relay MintRadar

Le code source de MintRadar ajoute une politique d’écriture côté opérateur pour le relay Nostr du projet. Elle limite les annonces publiques de kind 38172 et les avis de kind 38000 à 16 384 caractères JSON sérialisés par event et à 120 par heure par /64 IPv6, les préfixes IPv6 compressés étant ramenés à leur forme canonique. Un plafond souple de 3 000 par heure s’applique aux sources très actives, et un plafond absolu de 6 000 par heure ne compte que les events acceptés, toutes sources confondues. Les clés privilégiées ne sont soumises à aucune limite. Quant aux nouvelles connexions, elles sont limitées à 120 par minute avec une rafale de 60. Il s’agit de code et de configuration d’opérateur, et non d’une preuve de déploiement en production ni d’une protection complète contre le déni de service.

Nouveaux projets

bosstro

Bosstro est un nouveau client Android destiné aux résolveurs de litiges de Mostro. Le code source de son MVP est publié, avec une interface Flutter reposant sur le cœur Rust de Mostro. Les résolveurs signent avec une clé de résolveur dédiée, jamais avec la clé du nœud, et le nœud accorde à chacun un droit de lecture ou de lecture-écriture. Les résolveurs autorisés peuvent prendre en charge des litiges, rejoindre des discussions chiffrées entre acheteur et vendeur incluant des images et des PDF, et payer l’acheteur ou rembourser le vendeur. Les clés résident dans un stockage adossé à l’Android Keystore, mais les builds de développement Linux et web ne disposent pas de ces protections. Les sommes de contrôle publiées ne prouvent pas l’identité de l’éditeur.

cordn-kmp

cordn-kmp est une nouvelle implémentation Kotlin Multiplatform de Cordn, construite sur Quartz et mls-kmp pour JVM, Android, iOS, macOS et Linux. Son CordnGroupManager sans interface crée des groupes, invite, rejoint, envoie et rattrape son retard via un coordinateur MCP sur Nostr, un modèle différent de la distribution par relay de Marmot. Les frontends fournissent leur propre persistance, et l’affirmation d’interopérabilité avec ts-mls figurant dans le README provient de l’auteur.

Le projet a depuis publié la 1.1.0, qui se compile avec la version publiée de Quartz 2.4.0, si bien que l’exigence antérieure d’une copie locale de Quartz non publié derrière un drapeau de compilation ne s’applique plus aux versions taguées. La 1.2.0 supprime la méthode publique CordnExposure.differsFromMarmot() et laisse aux frontends la comparaison avec une autre liaison. Malgré le numéro de version mineure, il s’agit d’un changement d’API incompatible. Une proposition avait appelé cette version 2.0.0, et la publication effective utilise 1.2.0.

emosphere

EmoSphere est une carte des humeurs Nostr dont le code source est désormais public, et son README décrit la version 0.5.1. Chaque appareil génère sa propre clé et publie des events signés de kind 1074 portant une émotion et une intensité, une courte note facultative et une localisation approximative que les utilisateurs peuvent désactiver. Les publications apparaissent sur une carte du monde avec relecture temporelle et un fil d’abonnements. Ces signaux sont publics et pseudonymes, de sorte que les relays peuvent lire l’humeur et la localisation, puis les relier à une clé au fil du temps. Android conserve les clés dans un stockage sécurisé, tandis que la version web utilise localStorage.

matrix-appservice-nostr

matrix-appservice-nostr est le code source d’un prototype de service d’application Matrix associé à un relay Nostr. Les utilisateurs Matrix peuvent créer ou importer des identités Nostr, puis publier, suivre, répondre, réagir et envoyer des DM depuis des salons Matrix, avec des identifiants NIP-05 sur le domaine de la passerelle. Le contenu et les médias restent sur le backend Matrix, et le relay reconstruit les events à partir des originaux enregistrés. Les clés sont chiffrées en AES-GCM avec un secret configuré, ou conservées à distance via NIP-46. Les utilisateurs doivent faire confiance à l’opérateur, et une redaction Matrix (suppression de contenu) ne retire que la copie détenue par la passerelle.

Sept commits plus récents ajoutent des identités Nostr fantômes. La passerelle les crée automatiquement pour les utilisateurs Matrix autorisés qui interagissent vers l’extérieur, avec des profils qui reflètent ceux de Matrix. La création d’un profil complet met à niveau le compte existant sur place et conserve la même clé. Les administrateurs de la passerelle peuvent accorder à des utilisateurs ou à des homeservers extérieurs un accès complet ou fantôme, ou bien un accès passif limité à un salon pour répondre, réagir et voter. Une autorisation ou un bannissement visant un utilisateur précis prime sur les règles du homeserver, qui priment elles-mêmes sur les règles du salon. La permission complète permet de créer un profil mais n’en publie pas automatiquement. Révoquer l’accès conserve les clés, l’historique et les salons, mais arrête la publication vers l’extérieur là où elle n’est plus autorisée. Les identités importées ne sont jamais écrasées par un profil reflété. Ces vérifications s’appuient sur du code et des tests, mais sans aucune vérification d’interopérabilité à l’exécution ni de sécurité, et il faut toujours faire confiance à l’opérateur pour la gestion des clés. Les stickers sont désormais envoyés sous forme d’images.

nostr-scrutiny

Nostr Scrutiny publie un code source et des fiches d’information datés du 24 octobre comparant cinq clients Nostr : Amethyst, Damus, Nostrich, Primal et Quill. Chaque fiche couvre les déclarations de confidentialité du client dans les boutiques d’applications et son code publié, ainsi que les requêtes réseau observées lors d’une première visite dans un navigateur. Conçu en HTML statique simple, le site affirme ne pratiquer aucun pistage propriétaire (first-party). Les fiches constituent un inventaire daté de faits, et non une certification de sécurité ni un audit cryptographique. Conflit d’intérêts déclaré : l’auteur développe également Quill.

v2

Solid Chat v2 est un code source client nouvellement publié qui utilise une seule clé did:nostr pour écrire dans des salons de pods Solid avec l’authentification HTTP NIP-98 et pour envoyer des DM enveloppés en gift wrap NIP-17. La signature fonctionne via NIP-07, NIP-46 ou une nsec locale, avec le chiffrement NIP-44 et des enveloppes de kind 1059. Les salons sont en clair, protégés uniquement par l’ACL de chaque pod. Les médias des DM chiffrés sont téléversés sur Blossom, et les recherches de profils passent par un annuaire nostr.social. Une nsec locale réside dans localStorage, si bien qu’un signataire externe est plus sûr.

witchat

Witchat est le code source d’un client bitchat non officiel pour Windows et Linux. Il permet de discuter sur un maillage Bluetooth de proximité et se replie sur des gift wraps Nostr entre favoris mutuels. Il rejoint aussi des canaux geohash publics sur Nostr, en utilisant des events de kind 20000 pour les messages et de kind 20001 pour la présence. L’interopérabilité avec les transports de bitchat est une affirmation de l’auteur, et les binaires Windows ne sont pas signés. Les relays Nostr peuvent voir les adresses IP et les métadonnées des canaux, et les diffusions de proximité ne transitent actuellement que par Bluetooth.

wn-notify

wn-notify est une CLI Python non officielle, reposant uniquement sur la bibliothèque standard, qui envoie des messages et des fichiers à des groupes White Noise par l’intermédiaire d’un wn-agent local, via le socket Unix marmot.agent-control.v2 ; c’est le connecteur qui détient les clés, l’état MLS et les relays. La CLI vérifie la présence de final_sent et des identifiants de message. Face à un résultat inconnu, elle se termine avec un code non nul en le signalant comme inconnu et conserve la clé d’idempotence pour une nouvelle tentative manuelle, car elle ne réessaie jamais d’elle-même. Un accusé de réception confirme la publication sur le relay, et non que quelqu’un a lu le message. Seul wn-agent 0.13.0 a été testé.

xmradar

XMRadar est une extension de navigateur qui copie des publications web et des articles X vers Nostr. Chaque publication est approuvée au moyen d’un signataire NIP-07 externe. La version 0.2.0 ajoute les pourboires en Monero sur X pour les auteurs qui possèdent une identité Nostr.

L’implémentation ne publie un reçu de kind 9042 qu’une fois que l’utilisateur a déclaré avoir envoyé un pourboire et l’a confirmé. Ce reçu rend publics les npubs des deux participants, le montant et l’adresse. Il ne contient ni identifiant de transaction, ni clé de transaction, ni preuve de paiement. Grâce à un petit montant aléatoire en piconeros, le portefeuille du destinataire peut faire correspondre le paiement et publier une confirmation de kind 9044. Signée par le destinataire, cette confirmation ne constitue pas une preuve onchain indépendante. L’interface distingue les pourboires confirmés par le destinataire des déclarations non confirmées. Les pourboires de l’utilisateur lui-même restent en attente pendant 30 minutes. Les déclarations non confirmées ne comptent qu’une fois par payeur, au montant du plus petit reçu vers l’adresse actuelle ; ces déclarations peuvent être falsifiées. Chaque total est tenu par auteur, et non par publication. La découverte d’adresses via NIP-A3 et les preuves X de NIP-39 est désactivée par défaut. Lorsqu’elle est activée, les relays et X peuvent voir quelles identités l’utilisateur consulte.

agent-inbox

agent-inbox est un nouvel outil qui permet à des agents d’IA de se joindre les uns les autres au moyen de courts identifiants (handles) sur Nostr. Un unique fichier Python envoie des gift wraps NIP-17 standard chiffrés avec NIP-44 v2, peut publier sur un tableau public et inclut des fixtures issues des vecteurs de test officiels. Les handles sont des suffixes tronqués de clés publiques, et non des identités certifiées. Le README avertit que sa cryptographie en Python pur ne s’exécute pas en temps constant, et nous ne l’avons pas auditée. N’importe quel client NIP-17 peut tout de même envoyer un message à la npub d’un agent.

CarryChat

CarryChat est une nouvelle messagerie de type stockage et retransmission (store-and-forward) qui achemine des lots de messages de taille limitée par n’importe quel chemin disponible. Nostr lui sert de transport sur Internet, tandis que des liaisons locales comme Bluetooth LE et le simple échange de fichiers couvrent les situations hors ligne. Le code source comprend le transport Nostr ainsi que ses tests. Le README présente cette version comme une première version 0.2 et précise que les tests de LoRa sur le terrain avec du matériel physique ne sont pas terminés. Nous ne l’avons pas testé sur des appareils.

Treize commits plus récents, jusqu’à 311f176, remplacent des espaces réservés de la feuille de route par du code source fonctionnel. Ils couvrent Wi-Fi Direct, un adaptateur radio MeshCore, des liaisons Reticulum, des cartes de contact NFC et un transport audio, avec du code Kotlin, Rust et d’interface utilisateur. Sur le canal audio, le récepteur vérifie les signatures des cartes de contact et accepte les trames de message normales, mais refuse les fragments de fichiers. NFC n’échange que des cartes de contact, pas de messages. Il s’agit de développement du code source postérieur à la version 0.2.0 précédente, et non d’un nouveau binaire vérifié. D’après le README, MeshCore et LoRa, Reticulum, Wi-Fi Direct et NFC attendent encore des tests sur le terrain ou avec deux téléphones. Les modifications ne revendiquent ni compatibilité matérielle, ni anonymat, ni sécurité. L’audio haute fréquence dépend du matériel et n’est pas inaudible partout. Nostr demeure un transport Internet par relays parmi d’autres, aux côtés des liaisons locales.

Cosign et Marble

Cosign est un nouveau protocole doublé d’une bibliothèque, en bêta, qui divise une clé de signature Nostr en parts de seuil FROST. L’appareil d’un utilisateur peut signer conjointement avec un serveur, mais les serveurs ne peuvent pas signer seuls. Une part de sauvegarde sur papier prend en charge les procédures de récupération et de renouvellement des parts décrites dans le README, dont la sécurité n’a pas été vérifiée. Marble, un client Android et navigateur, utilise Cosign pour les fils et la signature. La bibliothèque FROST sous-jacente a été auditée, mais le protocole propre à Cosign n’a fait l’objet d’aucun examen indépendant.

Dans un code source plus récent, le client navigateur de Marble associe les notes non envoyées au compte connecté. Avant de publier, il détecte lorsqu’un autre onglet ou une session distante a mis fin à la connexion, et une requête provenant d’un client déconnecté affiche Signed out. La recherche instantanée interroge Ditto et les relays, pas le Web en général. Pour rechercher parmi les publications d’un auteur, elle vérifie les publications déjà chargées avant d’interroger les relays. Le spam probable est replié derrière un avis dépliable. Un contournement Not Spam ne s’applique qu’à ce navigateur et qu’à cet auteur. Ces aides à la recherche ne constituent pas la preuve d’un examen de sécurité.

Cosign 0.12.7 n’autorise les fusions de listes de membres qu’en provenance des serveurs, ce qui empêche qu’une part de sauvegarde sur papier soit promue à un autre rôle. Après une synchronisation d’époque, les serveurs obsolètes sont signalés comme en retard. Les résultats partiels invalides sont refusés ; la réparation automatique reste désactivée. Chaque partiel de déchiffrement comporte désormais des preuves de Chaum-Pedersen, vérifiées avant que les partiels ne soient combinés. Les clients plus anciens ignorent ces preuves, et la partie Android de Marble les recevra avec sa prochaine build. Ces descriptions de sécurité proviennent de l’auteur de la version, et nous n’avons pas audité la cryptographie.

Le code source Android NIP-55 commité après le tag 0.12.7 corrige une situation de concurrence lors de la première connexion, quand l’autorisation du serveur est encore en cours d’acheminement via les relays. Les recherches de clé publique répondent désormais immédiatement. La signature et le déchiffrement attendent en dehors du thread d’interface et font une seule nouvelle tentative, uniquement lorsqu’une connexion fraîchement autorisée reçoit une réponse de révocation. Le code distingue aussi un serveur injoignable d’un serveur qui répond par un refus. Ce correctif ultérieur du code source n’est établi ni dans le tag 0.12.7 ni dans un binaire Marble actuel.

Dream Nests

Dream Nests est un nouvel annuaire en lecture seule des salons audio Nostr en direct, qui rassemble les salons Nests et les events d’activité en direct, ainsi que leur chat. Pour les lecteurs d’écran, l’application web utilise des titres et des annonces de région live de niveau polite, et de courts earcons servent de signaux sonores. Elle lit les flux HLS publics en écoute seule. Les salons Nests s’ouvrent dans Nests, tandis que les salons Corny Chat et HiveTalk s’ouvrent sur leurs propres sites, si bien que la prise de parole reste dans ces applications. Les indicateurs de micro proviennent des métadonnées de présence, et non d’une détection d’activité vocale. Nous n’avons pas testé l’accessibilité sur des appareils. Le dépôt documente une URL publique en ligne.

fips-pub-pki

fips-pub-pki est un nouveau code source pour des certificats Nostr signés permettant à un domaine de déléguer à des sous-émetteurs, avec une validation de chemin hors ligne. Les ancres de confiance proviennent du projet compagnon fips-pub-domains, qui combine des déclarations DNSSEC avec des épinglages et des témoins. Le vérificateur n’interroge jamais le DNS. La révocation repose sur l’expiration et sur des marqueurs explicites, et non sur la suppression d’events des relays. Selon le README, les tests en direct sur le maillage avec un domaine public et un téléphone ne sont pas terminés. Aucun NIP n’ayant été soumis ni aucun kind enregistré, il s’agit d’une expérience, et non d’un remplaçant de TLS.

Magnetar

Magnetar est une nouvelle pile de recherche pour les events torrent NIP-35. Elle associe un crawler et un backend de recherche à une application Android qui conserve un cache SQLite local, et elle construit la confiance envers les éditeurs à partir des abonnements tout en vérifiant la vitalité des essaims. La première préversion 0.1 inclut le code du crawler ainsi que des tests pour Android et pour le serveur. L’auteur ne l’a validée qu’avec des tests automatisés et un émulateur, pas sur de vrais téléphones. Une confiance fondée sur les abonnements ne peut pas rendre un torrent légal ou sûr, et le backend n’est pas un index faisant autorité.

Magnitude Relay

Magnitude Relay est un nouveau relay Nostr en Rust signé VectorPrivacy, optimisé pour les DM en gift wrap de Vector et le trafic Concord, avec synchronisation NIP-77 et indicateurs de saisie. Ses opérateurs indiquent qu’il a remplacé strfry sur deux endpoints Vector existants. Son dépôt comprend des harnais de tests adversariaux et de benchmark, mais les chiffres de vitesse publiés proviennent des propres exécutions de l’auteur et n’ont pas été reproduits de manière indépendante.

Depuis, il a intégré un empaquetage Docker et Compose destiné aux opérateurs. Il s’exécute sous un utilisateur non privilégié, avec un volume de données, une liaison uniquement locale et un healthcheck. Les observations de production et d’import de la pull request proviennent de l’auteur, et arm64 n’a pas été testé. L’empaquetage à lui seul ne démontre pas la conformité au protocole.

Un code source plus récent limite par défaut les nouvelles connexions par IP à une rafale de 300, puis à 60 par minute. Régler la limite sur 0 la désactive, et le loopback en est exempté. L’en-tête d’IP réelle d’un proxy n’est pris en compte que s’il provient de localhost, et les connexions rejetées reçoivent un HTTP 429 avant l’ouverture du WebSocket. Publiquement, les refus du relay ne sont signalés que sous forme agrégée, et le détail par IP n’est disponible que sur le socket d’administration. La synchronisation NIP-77 en masse exclut les events éphémères et les events qui expirent dans les 600 secondes, tandis que la diffusion en direct transmet toujours les events à courte durée de vie. Lorsque les liens de confiance changent, le relay saute les sondes redondantes de visibilité des gift wraps, mais les gift wraps sont toujours synchronisés. Il s’agit de modifications du code source sans benchmark de production mesuré.

nostr_doctor

nostr_doctor est une nouvelle bibliothèque Dart, accompagnée d’une CLI et d’une interface Flutter, qui vérifie si les clients peuvent découvrir les données d’un compte. Elle commence par les métadonnées de profil et les listes de relays NIP-65, puis couvre les relays de DM privés et les brouillons, ainsi que les serveurs Blossom et les paramètres nutzap. Pour vérifier la découverte de la liste de relays, elle sonde la liste remplaçable. Nous avons examiné cet outil de diagnostic sous forme de code source, sans vérifier de version publiée de l’application. Ses résultats ne reflètent que les relays qu’il interroge et ne montrent pas une disponibilité globale.

nostr-indexer-relay

nostr-indexer-relay est un nouveau relay en Go qui ne stocke que des listes de relays NIP-65. Son crawler repère les relays mentionnés dans ces listes, vérifie s’ils prennent en charge NIP-77 et se synchronise avec d’autres indexeurs actifs via negentropy. Il comprend une page de recherche publique et une interface d’administration, et se présente comme étant à un stade précoce. Il s’agit d’un index ciblé de listes de relays, et non d’une archive Nostr ni d’un relay de contenu généraliste.

nostr2gh

nostr2gh est une nouvelle passerelle qui transmet les events de patch et de pull request NIP-34, ainsi que leurs mises à jour, de Nostr vers GitHub par l’intermédiaire d’un relayeur sur liste blanche. Un contributeur pousse une branche vers un emplacement accessible par fetch et signe un event Nostr ; un ami disposant d’un compte GitHub fonctionnel ouvre ensuite la PR pour lui. L’outil aide les contributeurs qui n’ont pas accès à GitHub, mais il ne contourne pas automatiquement un bannissement et n’autorise pas l’exécution automatique de patchs non fiables.

Relay Radio

Relay Radio est une nouvelle application web en lecture seule qui transforme un fil Nostr en direct en son, avec des earcons et la synthèse vocale du navigateur, ainsi qu’une région live de niveau polite facultative pour les utilisateurs de lecteurs d’écran. Les auditeurs choisissent une station globale sélectionnée ou une station construite à partir des personnes qu’ils suivent, couvrant notes, réponses, reposts, réactions et zaps. Elle ne publie jamais et ne paie jamais à la place de l’auditeur. Le filtrage du contenu se fait au mieux, de sorte qu’il ne peut pas garantir que tout ce qui est lu à voix haute est sûr.

Hibiki

Hibiki est une napplet de fil autonome pour Torii, et son code source qualifie la version 0.2.1 de premier fil fonctionnel. Un nœud récupère les publications et les médias publics, tandis que le classement fondé sur les goûts de l’utilisateur s’exécute dans le navigateur. Le fil tourne dans une iframe en bac à sable, sans accès réseau direct, et ne traite la réputation de spam signée qu’à titre indicatif. Nous n’avons pas vérifié de manière indépendante la frontière de confidentialité.

Le code source fusionné jusqu’à la version 0.2.6 ajoute des réponses en ligne et des résumés d’actualités extractifs, et les likes ne modifient plus le classement des publications. Une version taguée reste non confirmée. La prise en charge de l’aperçu dans le lecteur Watch ajoute des images d’aperçu. Les zaps arrivent avec les pages de profil. Le nœud vérifie le montant et le hash de description de chaque facture. Chaque paiement nécessite la confirmation du propriétaire ; le payeur utilise WebLN ou un QR code. Le nœud ne détient ni fonds ni clés. Les factures des adresses Primal n’ont pas de hash de description, si bien qu’un correctif ultérieur les accepte lorsque le montant correspond exactement. Elles sont marquées bound:false, et le propriétaire est averti que le portefeuille risque de ne pas confirmer. Cela affaiblit le lien entre la facture et la requête de zap et n’en fait pas des confirmations NIP-57 valides. En cas d’erreurs 5xx ou de délais d’expiration du portefeuille, une seule nouvelle tentative est effectuée et la raison LNURL est affichée. L’auteur n’a pas signalé de zap de bout en bout réussi avec un vrai portefeuille.

wax

wax est un nouveau signer en Common Lisp qui dérive des clés de rôle à partir d’une graine BIP-39 et fait passer chaque requête par un garde de politique : celui-ci refuse par défaut, sauf si un callback d’approbation ou une liste d’autorisation le permet. Des séquences d’enveloppes propres à chaque appelant protègent contre le rejeu. Ses noms de méthodes ressemblent à ceux de NIP-46, mais le cœur ne fournit aucun transport réseau. Nous n’avons pas audité la sécurité du signer.

WhatZaps

WhatZaps est une nouvelle extension de navigateur qui paie des contacts WhatsApp via Lightning, grâce à la prise en charge de WebLN dans l’extension Nostr WoT. Elle associe un contact à un profil Nostr, vérifie son adresse de paiement et demande toujours une confirmation explicite avant de payer. La commande /zap n’est pas envoyée comme message de discussion, et le parcours par réaction ou par bouton paie sans rien publier. Il s’agit de paiements Lightning qui s’appuient sur Nostr pour retrouver des identités, et non de reçus de zap NIP-57 signés. Nous n’avons pas testé sa mise en correspondance des messages dans le navigateur.

Sondages chiffrés Agora

Agora est un prototype pour navigateur destiné aux sondages de groupe chiffrés. Il combine le parrainage entre membres et des tickets de vote aveugles, et achemine le trafic via des relays Nostr et WebRTC. Le README présente la conception selon le principe « une personne réelle, un vote », mais cela suppose de faire confiance à l’émetteur des tickets, qui peut en fabriquer, ainsi qu’au parrainage en tant que forme de confiance sociale. La conception n’offre aucune résistance à la coercition. Les relays peuvent voir les horaires et les adresses IP ; les résultats dépendent des events que reçoit un client. Le projet n’a aucun lien avec l’ancien projet de chat ghobs91/Agora.

Cinderous SDK

Cinderous SDK v0.83.0 est un nouveau prototype disponible en source qui attribue à chaque appareil sa propre clé et synchronise des documents avec un historique de type Git via Nostr et WebRTC, en se rabattant sur des relays si nécessaire. C’est l’appelant qui choisit et déploie les relays, et le SDK n’inclut aucun relay public par défaut. Son chiffrement repose sur un schéma expérimental, CinderEK, associé à un Double Ratchet, qui n’a fait l’objet d’aucun audit externe. L’échange de clés hybride ne rend pas les signatures secp256k1 résistantes aux ordinateurs quantiques, et le README décrit le SDK comme non prêt pour la production.

evil-napplets

evil-napplets a ajouté les niveaux 02 à 08 de son échelle d’attaques, destinés à tester les hôtes qui exécutent des napplets selon le modèle à origine opaque du brouillon NIP-5D. Les napplets malveillants sondent les frontières des capacités et du pont, puis rapportent ce que l’hôte a autorisé. Le mode démonstration est celui par défaut, et les modes actifs doivent être activés explicitement. Les tests actifs ne doivent être lancés que contre des hôtes que le testeur est autorisé à sonder. La suite est un banc d’essai de red team : un hôte qui la réussit n’est donc pas pour autant démontré sûr. Il s’agit d’un projet distinct d’evil-napps, qui cible une autre architecture d’application.

evil-napps

evil-napps est une nouvelle suite, disponible en source, qui sonde les frontières d’autorité dans les lanceurs NAPP. Elle couvre le pont du lanceur ainsi que le signer NIP-07 exposé aux applications. Le stockage SharedDB entre aussi dans son périmètre. Les bundles NAPP associent des métadonnées à un fichier index, un format différent de l’artefact HTML unique utilisé par les napplets NIP-5D. D’après le README, la suite s’exécute par défaut en mode démonstration et ne lance des sondes actives que sur demande explicite. Ses tests et son harnais ne certifient aucun lanceur.

Feedstr

Feedstr est un nouveau lecteur RSS en Rust qui synchronise sous forme chiffrée, via Nostr, les flux, l’état de lecture et les favoris. La synchronisation peut être désactivée flux par flux. Il prend en charge l’import et l’export OPML et gère les articles longs NIP-23. Le dépôt contient des arborescences de sources pour le cœur, Android, le web et Flatpak. Selon le README, le logiciel est à peine testé et son utilisation n’est pas recommandée ; des instructions d’installation et d’utilisation arriveront bientôt.

Boîte à outils de reçus de dépôt NKIP

KYC-rip/nkip-0001 est une nouvelle boîte à outils TypeScript, maintenue par XBToshi, consacrée aux reçus de dépôt NKIP-0001. NKIP-0001 est un format de reçu applicatif et non un NIP Nostr accepté. La boîte à outils gère les reçus de dépôt signés en Ed25519, les engagements salés, les events témoins Nostr et la récupération du sel par chiffrement NIP-44. Sa protection dépend du fait que l’application retienne l’adresse de dépôt jusqu’à ce que le témoin ait été observé. Le SDK ne conditionne pas l’accès aux commandes et ne garantit pas les versements. Les détails figurent dans le README.

nostr-parse

nostr-parse est un nouveau parseur Rust de VectorPrivacy destiné aux events Nostr signés. Il impose strictement la forme d’event à sept champs, exige des entiers non négatifs, limite les kinds à la plage u16, vérifie les champs hexadécimaux et valide les chaînes échappées. Les erreurs sont signalées avec leur décalage (offset) dans l’entrée. Les appelants peuvent produire des allocations possédées compactes ou des portions empruntées pointant dans l’entrée, et parse_unsigned accepte les rumors NIP-59 non signés. L’analyse ne recalcule pas l’ID de l’event et ne vérifie pas la signature Schnorr : il revient donc toujours aux appelants d’effectuer eux-mêmes ces vérifications.

cl-deposits

cl-deposits est une nouvelle implémentation en Common Lisp de Bitcoin Deposits. Dans cette conception, un opérateur tient sur Nostr des registres en chaîne de hachage, signés et cosignés par un quorum, adossés à des réserves Taproot. Le dépôt comprend le code source et un devnet doté de tests d’inspection. D’après le README et la ROADMAP, l’auteur a rejoué les fixtures de référence, exécuté un devnet signet et testé l’interopérabilité avec deposits-rust dans les deux sens. L’auteur indique aussi que le chemin de réception Lightning fonctionne, et cite InvoiceLock et Fulfill pour les paiements comme prochaines étapes. Les utilisateurs dépendent de l’opérateur, du quorum de cosignature et des hypothèses relatives aux réserves.

Streets

Streets, un client web Nostr en colonnes qui affiche côte à côte fils d’actualité, notifications et recherche, a fusionné une modification qui enregistre l’emoji de réaction par défaut dans le document de deck NIP-78 du compte (kind 30078). Les utilisateurs n’ont plus à le choisir de nouveau après s’être reconnectés ou sur un autre appareil. Auparavant, ce choix n’était stocké que dans le localStorage de l’appareil. Le document de deck étant chiffré avec NIP-44, la synchronisation entre appareils exige une connexion via une extension ou un signer prenant en charge le chiffrement. Avec les autres modes de connexion, le réglage reste sur l’appareil. Si un compte n’a aucune réaction enregistrée, la valeur existante de l’appareil est utilisée, si bien que le réglage ne revient pas au cœur. Une valeur enregistrée invalide est écartée sans que le reste du deck soit abandonné. La modification figure dans le code source, et les notes de version de la 1.22.0 sont encore à l’état de brouillon.

Labradorite

Labradorite, une application Android permettant de piloter des sessions d’agents de codage sur un ordinateur Linux appairé, a publié les versions 0.1.0 et 0.2.0. Le téléphone ne sert que d’interface de contrôle. Sur l’ordinateur, un daemon exécute l’agent et échange des messages Marmot MLS via des relays Nostr ordinaires, avec un groupe par session. Il n’accepte que les npubs figurant sur une liste d’autorisation, vide par défaut (source). La version 0.1.0 démarre ou reprend des sessions approuvées, diffuse en continu le texte, les appels d’outils et les diffs, et gère les approbations et les questions. Elle propose aussi des commandes Git et une navigation de fichiers en lecture seule. Avec la version 0.2.0, les messages de suivi sont mis en file d’attente comme des tours distincts, peuvent être annulés depuis le téléphone, et le travail en file d’attente survit aux redémarrages du daemon ; l’historique manqué est en outre rejoué après reconnexion. Ce sont des affirmations de l’éditeur, et nous n’avons pas audité sa sécurité de façon indépendante.

Nomisma

Nomisma est un registre de dépenses partagées pour Android, en bêta prototype, qui associe deux participants via des messages Nostr privés. Il se contente de suivre les soldes et ne transfère ni ne règle aucun argent. La version 0.1.3 reconnecte automatiquement les appareils appairés, retente l’envoi des modifications persistées avec des délais croissants et ajoute l’authentification de relay NIP-42. Elle renvoie aussi les opérations manquantes. Les deux appareils ne comparent une empreinte SHA-256 des entrées, des payeurs et des répartitions qu’une fois leurs horloges vectorielles par auteur en accord. Comme le relay par défaut a changé, les deux appareils doivent disposer de la 0.1.3 et de réglages de relay identiques. Les points de contrôle sont emballés en gift wrap avec une expiration NIP-40 de 15 minutes, ce qui demande aux relays de les supprimer sans garantir leur effacement. Les notes signalent des correctifs concernant le chargement de la bibliothèque native, l’ordre des arguments Schnorr et la dérivation de clés NIP-44, et nous n’avons pas audité sa sécurité de façon indépendante. La signature de l’utilisateur passe par Amber, mais des clés éphémères existent aussi sur l’appareil. Les notes de distribution se contredisent au sujet du certificat de signature de l’APK : nous n’avons donc pas qualifié ici la compatibilité des mises à jour.

Onyx

Onyx est un prototype de journal intime privé disponible en source, et non une version qualifiée. Il conserve sur l’appareil des fichiers Markdown datés, qui font foi, et les sauvegarde sur des relays sous forme d’events kind 30078 chiffrés. Des d-tags salés évitent d’exposer directement les dates des entrées. La restauration nécessite la clé de chiffrement locale distincte, que les utilisateurs doivent donc sauvegarder, car la npub seule ne permet pas de restaurer le journal. Un correctif du 27 octobre ajoute une garde qui vérifie l’intégrité des champs de la requête avant publication : le kind, le contenu, la pubkey, les tags et l’horodatage de l’event renvoyé par le signer doivent correspondre à la requête. Le correctif rejette aussi les téléchargements provenant du mauvais auteur, conserve les modifications locales plus récentes et remplace les données de manière atomique lors de la restauration. Les auteurs et horodatages des events restent publics. Le texte en clair transmis à la commande de chiffrement peut apparaître brièvement lors d’une inspection locale des processus, et supprimer une entrée n’efface pas les copies présentes sur les relays.

Zzub

Zzub 0.0.41 est un client communautaire issu d’un fork de Buzz. D’après les notes succinctes de l’éditeur, cette version ajoute les réponses RSVP aux événements du calendrier avec prise en charge des fuseaux horaires, les zaps de profil, l’affichage des badges NIP-58 et un bouton de huddle permettant de rejoindre une réunion en direct. Côté agents, les commandes gagnent une option de redémarrage, la modification d’une liste d’exemptions de budget et de nouveaux types de cartes de tâche. Au démarrage, les canaux en cache sont désormais utilisés.

Travaux sur le protocole et les spécifications

NIP-CD définit des commandes invoquées en texte brut

La spécification NIP-CD, d’abord intitulée Commands et désormais intitulée Slash Commands, a été fusionnée dans le dépôt des NIPs le 21 octobre (revue de la proposition). Un exécuteur annonce une commande dans un event de kind 31992 qui en indique le déclencheur, le titre, la description, les arguments positionnels typés et les portées. Les utilisateurs l’invoquent en texte brut au début du contenu de l’event, éventuellement qualifiée par la npub de l’exécuteur : aucun tag propre à la commande ni aucune prise en charge côté client n’est donc nécessaire. Un déclencheur seul peut correspondre à plusieurs exécuteurs. Les clients peuvent proposer l’autocomplétion, mais ne peuvent pas l’exiger.

Marmot adopte plusieurs appareils par compte

Marmot, un protocole de messagerie de groupe chiffrée fondé sur MLS pour Nostr, a fusionné ses règles de comptes multi-appareils (revue de la proposition) le 26 octobre, sous une forme révisée par rapport au brouillon antérieur. Dans un Commit, un invitant peut ajouter au plus 20 KeyPackages pour un même compte. Chaque appareil détient exactement un emplacement de publication aléatoire valable à vie et ne copie jamais l’état MLS ni les KeyPackages privés. Les packages devraient durer 30 jours, avec un renouvellement à 7 jours. Les invitants envoient à chaque appareil éligible son propre Welcome, et le retrait d’un compte retire toutes ses feuilles.

Marmot permet aux membres de gérer les feuilles de leur propre compte

Marmot a adopté un composant d’appartenance au même compte, marmot.group.account-devices.v1 (ID 0x800d), qui ne transporte aucune donnée. Lorsque la négociation du groupe exige ce composant, un membre peut valider dans un commit des Adds et des Removes pour son propre compte sans autorité d’administrateur. Dans le cadre de ce composant, le membre ne peut ni retirer la feuille propre à l’auteur du commit, ni retirer d’autres comptes, et le statut d’administrateur du compte reste inchangé. Les groupes existants doivent activer le composant et respecter ses invariants de prise en charge.

Les déclencheurs push de Marmot reçoivent un remplissage neuf

Depuis une modification fusionnée le 26 octobre, Marmot exige désormais un remplissage neuf dans chaque déclencheur push. Chaque déclencheur de kind 446 contient au moins un fragment de remplissage CSPRNG neuf de 1 084 octets, ce qui laisse au plus 31 jetons chiffrés réels dans le budget de 32 fragments. Sans remplissage neuf, des octets de jetons identiques permettraient à la déduplication par hachage de contenu de supprimer des notifications ultérieures légitimes. Les serveurs hachent tous les fragments. Ils ne doivent pas rejeter un déclencheur structurellement valide parce qu’ils ne parviennent pas à détecter le remplissage. Le remplissage masque le nombre de jetons aux relays et aux observateurs, mais le serveur de notification qui déchiffre peut toujours le voir.

Marmot ajoute la réparation des jetons push pour les nouveaux membres

Le 26 octobre, Marmot a fusionné la réparation des jetons push pour les nouveaux membres, et une modification ultérieure a précisé sa formulation finale. Le propriétaire du Commit qui ajoute un nouvel arrivant devrait envoyer les instantanés des jetons actifs de kind 448 ainsi que les marqueurs de suppression (tombstones) de kind 449. Grâce à un ensemble facultatif d’empreintes dans une annonce de kind 447, les pairs peuvent n’envoyer que les enregistrements manquants. Les trois feuilles les mieux classées répondent selon des minuteries échelonnées, avec une limite de fréquence de 24 heures par feuille annonceuse. Même lorsque leurs propriétaires sont hors ligne, les enregistrements signés relayés et les marqueurs de suppression conservés réparent l’état manquant des jetons.

Proposition de clés Nostr détenues par des passkeys

Une proposition de clés Nostr détenues par des passkeys s’appuie sur Nosskey, un schéma existant permettant d’utiliser des passkeys avec des clés Nostr. Des handles étiquetés distinguent une identité dérivée par PRF/HKDF d’une clé stockée, et des enregistrements de relay chiffrés de kind 31778 lient la partie de confiance (relying party), l’auteur et le credential. Des métadonnées manquantes ou inconnues ne doivent pas créer silencieusement une nouvelle identité. L’autorisation de l’origine de la partie de confiance s’applique toujours, et les données Nosskey héritées nécessitent un lecteur de migration explicite. Faute de sauvegarde séparée, une identité dérivée est perdue avec sa passkey.

Proposition de délégation DNS pour les identifiants NIP-05

Une proposition de délégation DNS, non fusionnée, destinée aux identifiants NIP-05 fondés sur le DNS, ajoute un mécanisme de repli qui ne s’applique que lorsque la recherche HTTPS d’origine renvoie 404 ou 410. Les clients lisent alors un enregistrement TXT _nip05 qui pointe vers un fournisseur HTTPS. Les délais d’expiration, les échecs TLS ou CORS, les redirections et les incohérences de clés ne déclenchent jamais le repli, et le DNS ne stocke aucune clé. DNSSEC est recommandé mais facultatif. Avec un DNS non signé, le TLS du fournisseur ne peut donc pas authentifier de manière indépendante l’autorisation donnée par le domaine d’origine. Les anciens clients ne peuvent pas résoudre les identifiants qui reposent uniquement sur la délégation.

Un catalogue d’applications logicielles proposé comme NIP-82

Une proposition de catalogue d’applications logicielles utilise NIP-82 comme numéro proposé dans cette pull request ouverte et non fusionnée ; ce numéro n’a été ni attribué ni adopté. Elle réunit des kinds pour les applications (32267), les versions (30063), les ressources (3063), la curation (30267), les preuves de possession de certificat (30509) et une liste de relays de catalogue (10067). Les ressources indiquent leur plateforme et leur environnement d’exécution, ainsi qu’un hachage du fichier. Pour Android, les ressources ajoutent un hachage du certificat de signature. Une signature de preuve montre que l’éditeur contrôle le certificat, mais les lecteurs doivent tout de même vérifier son expiration et sa révocation.

Des URI BIP 321 proposées comme cibles de paiement NIP-A3

Une proposition non fusionnée ajoutant un type de paiement bip321 aux cibles de paiement NIP-A3 permet à un event de kind 10133 de contenir une URI bitcoin: complète, sous forme d’instructions de paiement statiques et réutilisables. Comme la cible est réutilisée, la proposition interdit un montant ainsi qu’un paramètre de facture BOLT11 lightning à usage unique. C’est le payeur qui choisit le montant, et le portefeuille sélectionne un moyen de paiement qu’il prend en charge, le repli sur une adresse Lightning étant conservé.

Proposition de zaps payés via des cibles BIP 321

Selon une proposition de zaps payés via des cibles BIP 321, l’expéditeur paie la cible bip321 NIP-A3 réutilisable d’un destinataire via Ark (un protocole Bitcoin hors chaîne), Lightning ou sur la chaîne, puis publie un zap de kind 9740. Le détenteur de la clé de reçu confirme le règlement avec un kind 9741. Les deux numéros de kind restent provisoires. La référence de paiement est chiffrée avec le chiffrement versionné NIP-44 à destination d’une clé de reçu que le destinataire choisit d’activer, et seule cette clé peut confirmer le paiement. Les tiers ne peuvent pas vérifier les détails du paiement : la confirmation repose donc sur la confiance accordée à la signature du destinataire. La proposition ne remplace pas les zaps Lightning NIP-57.

Paiements Ark proposés pour Nostr Wallet Connect

Une proposition d’extension Ark non fusionnée pour Nostr Wallet Connect, le protocole NIP-47 qui permet à des applications de contrôler un portefeuille distant, ajoute une instruction Ark à la prise en charge existante du paiement et de la réception BIP 321, ainsi qu’un enregistrement de paiement Ark pour lookup_payment, sans nouvelle méthode. Un portefeuille n’utilise l’instruction que s’il prend en charge la version d’adresse et le réseau et qu’il partage le même serveur Ark. Sinon, il essaie une autre instruction de l’URI. Les montants doivent être exprimés en satoshis entiers, sans arrondi en millisatoshis, et les enregistrements distinguent un paiement cosigné par le serveur des fonds que le destinataire a collectés et peut dépenser.

En-tête de paiement Ark proposé pour les serveurs Blossom

Une proposition d’en-tête de paiement Ark dans Blossom, le protocole de stockage de blobs multimédias sur des serveurs HTTP, ajoute X-Ark aux réponses HTTP 402 « paiement requis » de BUD-07. L’en-tête transporte une URI BIP 321 contenant une adresse Ark nouvelle, générée pour chaque requête, ainsi que le montant. En option, l’URI peut aussi transporter le même paiement sous forme de facture Lightning. Comme preuve, les clients réessaient avec l’adresse Ark payée après le règlement. Ceux qui ont utilisé la solution de repli réessaient avec la préimage Lightning. Une requête HEAD n’est pas réessayée avec une preuve, et les clients passent au GET ou au PUT.

Proposition de cashtags pour mentionner des actifs dans les notes

Une proposition de cashtag définit une tokenisation facultative de $ suivi de deux à six lettres ASCII, en excluant le code, les URL et les références Nostr. Un unique tag cashtag fixe le mode d’affichage et peut associer un identifiant d’actif choisi par l’auteur, car un ticker seul ne permet pas d’identifier un actif de manière unique. Les lecteurs vérifient que le symbole correspond à la chaîne et à l’adresse, puis signalent les incohérences sans les réétiqueter. Des tags t facultatifs, de la forme $ticker, permettent la recherche standard sur les relays.

Retrait de la spécification Napplet pour manette de jeu

Le dépôt NAPs, où sont publiées les spécifications Napplet, a fusionné la suppression de la spécification gamepad le 27 octobre. La modification supprime NAP-GAMEPAD.md et annule l’adoption antérieure. Aucun NAP de manette de jeu n’est actuellement adopté.

Les tags de hauteur de Cyberspace évitent les collisions avec les tags de groupe

Cyberspace, un protocole spatial bâti sur Nostr, a fusionné plusieurs de ses propres spécifications, appelées DECK. Ce sont des spécifications du projet, et non des NIP officielles. La spécification renomme désormais le tag de hauteur des sacs et du chat de h en H. Le tag en minuscule entrait en conflit avec les tags de groupe NIP-29 et provoquait le rejet ou le mauvais classement d’events. Les lecteurs ne se rabattent sur un h hérité que lorsque H est absent. Seule la spécification du projet change. Cela ne modifie pas NIP-29 et ne prouve pas que les clients déployés interopèrent.

Audio caché dans Cyberspace

DECK-0007 définit l’audio caché comme un fichier Blossom chiffré, référencé par un rumor non signé placé dans un sac ou un coffre signé. Ainsi, la personne qui l’a caché ne se voit pas attribuer une publication publique signée séparément et pouvant être lue. Chaque placement utilise une clé et un texte chiffré nouveaux, mais n’importe qui peut tout de même partager la clé. La spécification n’affirme pas que le chiffrement garantit la confidentialité de la personne qui le trouve, ni que ses règles d’URL bloquent toutes les SSRF, et la prise en charge par les lecteurs est encore en cours.

Modèles publics et animation dans Cyberspace

Les objets peuvent désormais référencer des modèles SNO publics avec des animations de flottement (bob) et de rotation (spin), et reviennent à l’ancien rendu lorsqu’un modèle est invalide ou indisponible. Les modèles en ligne peuvent changer ou disparaître, et aucune adoption à grande échelle n’est revendiquée.

Spécifications Cyberspace pour les objets, le chat et les commentaires

Les DECK facultatives 0004 à 0006 documentent le code existant pour les objets, les coffres, les annonces, le chat local chiffré et les commentaires scellés, avec des vecteurs de test synthétiques. Plusieurs problèmes restent ouverts. Les signatures des sacs et des coffres diffèrent, et les commentaires scellés exposent l’identifiant et le kind du parent par le biais de tags publics. Les détenteurs peuvent passer outre les annonces. Le chat présente des lacunes en matière de rejeu et de liaison au contexte, et les références de coffre ne sont pas implémentées. Cette documentation ne corrige aucun problème de sécurité et ne constitue pas un déploiement.

Proposition d’events multi-auteurs

Un article long signé, Multi-Author Nostr Events as a Soft Fork, propose des events dont le hash d’identifiant couvre plusieurs pubkeys d’auteurs, chaque auteur signant le même identifiant. Les anciens clients verraient une enveloppe compatible secp256k1 transportant les données de la nouvelle forme ainsi que des tags Q servant d’indices de recherche. Les pairs négocieraient la nouvelle forme pour chaque connexion. L’article généralise la proposition post-quantique antérieure de l’auteur, qui ajouterait une future clé en tant que coauteur supplémentaire. Il s’agit d’une proposition non numérotée, et non d’une NIP acceptée. Le remplacement des naddr coécrits et le transport binaire restent des questions ouvertes.

Les abonnements de synchronisation NIP-AR de Buzz envoient un instantané complet avant les têtes en direct

Une pull request Buzz ouverte propose des abonnements de synchronisation WebSocket NIP-AR (#8522). Le relay enverrait un ensemble cohérent d’artefacts lu en REPEATABLE READ et n’émettrait EOSE qu’une fois cet ensemble complet, puis diffuserait en continu les têtes courantes en direct ; l’enregistrement Redis en direct a lieu avant la lecture initiale. Une déconnexion ou un retard de Redis met fin à l’abonnement avec CLOSED et impose une resynchronisation, tout comme les changements d’accès, les caviardages ou une file pleine. Les abonnements sont plafonnés à 4 096 artefacts. À la date limite de nos sources, la modification n’était pas fusionnée et n’était aucunement disponible en production.

Lectures HTTP incrémentales des artefacts NIP-AR dans Buzz

Une autre pull request Buzz ouverte ajoute des lectures HTTP incrémentales pour les artefacts NIP-AR (#8523). Les clients paginent selon les horodatages de modification de la base de données et des identifiants stables, avec un chevauchement de 120 secondes, et reçoivent soit la révision courante, soit une suppression. Ils peuvent récupérer des identifiants connus. Les résultats suivent un modèle de cohérence à terme. La proposition ne promet pas d’instantané complet, et l’absence d’un artefact ne signifie ni sa suppression ni une perte d’accès. Sa dernière révision exige l’appartenance ou une portée #h explicite pour les canaux ouverts non répertoriés, et une modification du répertoriage réinitialise la progression incrémentale. Le feature gate, BUZZ_ARTIFACT_INCREMENTAL_ENABLED, est désactivé et exige que chaque composant d’écriture et chaque migration (désormais 0074 à 0076) soient en place. Ce délai de 120 secondes est une hypothèse de fonctionnement. À la date limite de nos sources, la modification restait ouverte.

Projet de texte NIP-AM pour les lecteurs délégués de métriques

Une pull request de documentation Buzz, à l’état de brouillon, spécifie des lecteurs délégués pour les métriques NIP-AM sans modifier l’autorisation à l’exécution (#8582). L’event de kind 44200 chiffré pour le propriétaire reste inchangé, et l’agent émet une copie NIP-44 distincte pour chaque autorisation active, liée à l’identifiant exact de l’event d’autorisation rédigé par le propriétaire. Le kind 30180 proposé pour les autorisations et les plafonds de lecteurs restent des questions ouvertes, tout comme l’historique, la révocation et l’association publique. Une révocation signée ne peut pas effacer les copies qu’un destinataire détient déjà, et le brouillon n’était pas fusionné à la date limite de nos sources.

DECK-0003 permet à un parent de transporter les objets qu’il place

Une pull request Cyberspace ouverte propose DECK-0003 §1.10, une table racine de charges utiles d’objets SNO intégrées (#81). Une entrée présente dans la copie du parent l’emporte sans récupération sur le réseau, même lorsqu’elle est invalide. Chaque entrée est limitée à la pubkey de l’auteur, avec une taille et une profondeur bornées ainsi que des limites de cycles. Les lecteurs plus anciens récupèrent les objets manquants et affichent un espace réservé. La proposition décrit des implémentations mises en attente de cette modification, qui n’était pas fusionnée à la date limite de nos sources.

DECK-0004 définit des portes liées à la hauteur avec des clés de salle dérivées

Une pull request Cyberspace ouverte ajoute à DECK-0004 les §3.6 et §3.7 sur les apparences et les portes (#82). Les portes sont liées à la hauteur, et la clé de salle vaut SHA-256(séparateur de domaine ‖ clé d’emplacement ‖ secret de porte), le sac de la salle étant chiffré avec cette clé. Une salle peut avoir plusieurs portes ou des portes imbriquées, et la pose d’un nouveau verrou renouvelle la clé. Le texte ne comporte aucun vecteur de test tant qu’une première implémentation n’existe pas, et il n’était pas fusionné à la date limite de nos sources.

Extension d’annonce de peering NIP-11 pour nostream

Une pull request nostream ouverte étendrait le document NIP-11 du relay avec une section de peering (#999). Elle annonce les kinds de flux avec des bornes temporelles et des conditions de règlement, ainsi qu’un endpoint de contact et une preuve de travail de peering. Seul enabled: false désactive la section, et des conditions vides signifient un peering sans règlement. Une offre annoncée n’est pas un pair accepté. La modification n’implémente ni accord entre pairs ni fédération payante. Elle n’était pas fusionnée à la date limite de nos sources.

NIP-CD ajoute des listes facultatives de commandes installées

Un complément à NIP-CD a été fusionné dans la branche par défaut du dépôt des NIP le 27 octobre (fusion), et la spécification s’intitule désormais Slash Commands. Elle définit une liste facultative de kind 10992, conforme à NIP-51, dans laquelle un utilisateur conserve des tags d’adresse pointant vers des définitions de commandes de kind 31992, chacune identifiée par la pubkey de l’exécuteur et la valeur d, avec un indice de relay facultatif. Les utilisateurs peuvent tenir cette liste à jour, et les clients devraient l’utiliser pour l’autocomplétion et les puces affichées. La liste est une préférence d’affichage et de découverte. Elle n’autorise pas les exécuteurs, et l’invocation en texte brut fonctionne toujours sans elle, sans tags propres aux commandes et sans prise en charge obligatoire par les clients. NIP-CD reste un brouillon facultatif, et la fusion n’indique pas quels clients ont adopté la liste.

Marmot restreint sa règle de préparation équitable pour les appareils de compte

Marmot a fusionné le 28 octobre une correction de sa règle d’ordonnancement pour les groupes qui exigent des appareils de compte. Après qu’une passe de convergence bornée a atteint l’état Stable, une intention en file d’attente autorisée par un administrateur, ou une intention permise émanant du même compte, bénéficie d’une tentative de préparation avant que le seul travail entrant en file d’attente puisse forcer une nouvelle passe. SelfUpdate et Leave sont exclus de cette garantie d’équité supplémentaire, bien que tout membre puisse toujours les valider dans un commit. La modification corrige une formulation antérieure qui couvrait toutes les intentions autorisées, et les groupes qui n’exigent pas d’appareils de compte conservent leur ordonnancement précédent. Le format sur le réseau ne change pas, et une tentative de préparation ne garantit pas un Commit valide, accepté ou canonique.

Marmot propose un registre d’appareils caché pour les groupes de compte

Une proposition Marmot ouverte, non fusionnée, ajouterait un composant device-roster-v1 d’identifiant 0x800e pour un groupe caché dont toutes les feuilles appartiennent à un même compte. Un groupe porte ce registre dès sa création ou ne le porte jamais. Le registre enregistre les appareils, les emplacements rejetés, les KeyPackages rejetés et les correspondances de feuilles, et c’est le premier composant à utiliser des mises à jour par diff explicites et indépendantes de l’ordre, appliquées au parent candidat. Les emplacements retirés peuvent conserver des correspondances de feuilles pour les groupes dont leurs appareils frères ne peuvent pas les retirer. Un appareil ne fait confiance à un groupe d’appareils que s’il a créé ce groupe ou l’a rejoint par un Welcome authentifié par un lien confirmé ; le marqueur 0x800e seul n’accorde donc aucune confiance. L’Add fondateur désigne le KeyPackage exact issu du lien confirmé. Un appareil lié volé peut modifier le registre jusqu’à ce qu’il soit retiré. Le plafond d’appareils s’applique aux appareils. Les enregistrements de correspondances de feuilles et de rejets ont des limites de taille par entrée, mais aucun plafond sur le nombre d’enregistrements. Les données du registre ne sont jamais copiées vers d’autres comptes, et le groupe reste caché des conversations, des compteurs, des notifications et des destinations. Selon le corps de la proposition, MDK garde les octets du registre derrière un interrupteur de test, sans nouvelle interface ordinaire.

Marmot propose des retours plus clairs en cas d’échec d’activation des appareils de compte

Une autre proposition Marmot ouverte, non fusionnée, permettrait aux clients d’expliquer les échecs d’activation des appareils de compte. Un client peut signaler qu’un groupe ne peut pas activer les appareils de compte. Ce retour au niveau du groupe ne peut pas nommer les membres ou les appareils qui bloquent l’activation. Un membre qui n’est pas administrateur actif apprend seulement qu’il n’a pas le statut d’administrateur. Si une sélection de branche est perdue ou si une vérification d’activation régénérée échoue, l’utilisateur doit formuler une nouvelle demande. Jamais le client ne réessaie automatiquement l’activation. La règle existante selon laquelle l’activation exige une nouvelle demande de l’utilisateur provenant d’un client autorisé reste inchangée. Il s’agit d’un projet de texte normatif, qui ne montre aucun comportement implémenté ou déployé.

Marmot propose une vérification par emoji pour l’appairage de nouveaux appareils

Une proposition Marmot ouverte, non fusionnée, décrit l’appairage d’un nouvel appareil au moyen d’un échange inspiré de m.sas.v1 de Matrix, utilisant X25519, HKDF et HMAC. L’utilisateur compare sept emoji légendés sur les deux écrans, sans lire ni saisir de code. La possession de la clé du compte n’authentifie jamais un appareil. Cinq rumors non signés (Request, Answer, Reveal, Confirm et Cancel) sont enveloppés à destination de la pubkey du compte et lient le compte, la session, le nouveau KeyPackageRef, l’emplacement de l’appareil existant et des clés nouvelles. L’appareil existant confirme en premier et ajoute exactement le KeyPackageRef confirmé. Le nouvel appareil ne confirme qu’après vérification, et il n’accepte un Welcome que pour l’identifiant de groupe authentifié par l’échange confirmé. Les kinds 452 à 456 sont proposés, et les kinds 457 à 489 sont réservés. Un détenteur de la clé du compte peut toujours falsifier un Cancel pour provoquer un déni de service, même après confirmation. La limite horaire d’Answer ne persiste pas d’un redémarrage à l’autre. Les relays peuvent voir la rafale d’enveloppes et l’adresse du compte ; certains cas de fusion et de Welcome restent reportés. Les implémentations gardent ces formats désactivés par défaut, et deux vecteurs à réponse connue fournis par l’auteur ne constituent pas un audit indépendant de sécurité ou d’interopérabilité.

La proposition NIP-5D sur les napplets resserre ses champs média et source

La proposition ouverte NIP-5D sur les napplets a déjà été présentée. Ses modifications du 28 octobre ont désormais été fusionnées dans la branche de la proposition, et non dans la branche par défaut du dépôt des NIPs ; elles révisent les champs facultatifs de média et de source introduits le 17 octobre. Les tags de capture d’écran et d’aperçu réutilisent désormais les champs clé-valeur de NIP-92, avec une valeur x obligatoire en SHA-256 minuscule et des champs facultatifs m, dim, size, alt et duration. Avant tout rendu, les lecteurs doivent vérifier l’empreinte et décoder le format réel. Si un champ m valide est présent, le format décodé doit en outre correspondre à ce type MIME. Les entrées dont le x est absent, répété ou invalide sont ignorées ; les champs facultatifs invalides sont écartés sans que les autres médias utilisables soient rejetés, et les aperçus multiples sont ignorés. Un source-commit doit se résoudre en un identifiant Git complet exact, et les archives source en HTTPS exigent une correspondance SHA-256 exacte au niveau de l’octet. Les champs source dupliqués ou mal formés sont ignorés, et des données source inutilisables ne doivent pas bloquer la lecture du HTML. Un commit ou une archive qui correspond ne prouve pas que la compilation est reproductible, et aucune conformité des clients n’est revendiquée.

Six ans d’octobres sur Nostr

Au fil de six mois d’octobre, les changements datés de Nostr se sont déplacés vers l’extérieur, du cadrage des messages jusqu’aux applications construites dessus. En 2021, la spécification de base a établi que les messages des clients sont encadrés sous forme de tableaux JSON de premier niveau. Les octobres suivants ont apporté la recherche côté client et les factures Lightning, les preuves d’horodatage et les demandes de tâches, les variantes de médias et les portefeuilles d’ecash, puis la collaboration sur le code et les métadonnées des messages privés. D’autres changements survenus les mêmes mois ont rendu les identités et les connexions plus faciles à transporter d’un programme à l’autre, de l’état visible des relays aux clés de signataire distinctes, en passant par l’appairage des portefeuilles. Ce mois d’octobre, le même document a défini ce à quoi correspond une liste de filtres vide, si bien que les relays qui lisent un JSON identique disposent désormais d’une règle commune quant aux events qu’elle sélectionne.

Octobre 2021 : rendre le transport sans ambiguïté

Le 4 octobre, NIP-01, la spécification de base du protocole, a été révisée pour que les messages des clients soient des tableaux JSON de premier niveau. Les préfixes informels EVENT, REQ et CLOSE sont devenus le premier élément de chaque tableau, et l’exigence d’un chemin fixe /ws a été abandonnée : n’importe quel point de terminaison WebSocket convenait donc. Cela a clarifié une spécification déjà accompagnée de code. Des clients écrits indépendamment ont besoin d’un cadrage exact avant que quoi que ce soit de plus élaboré puisse interopérer.

Le 23 octobre, le sens relay-vers-client a reçu des messages EVENT et NOTICE explicites. Un EVENT envoyé par un relay porte l’identifiant d’un abonnement REQ existant, ce qui permet à un client gérant plusieurs abonnements sur une même connexion d’associer les résultats aux requêtes ; NOTICE, lui, transporte un texte lisible par un humain. Un vocabulaire aussi restreint se prête à plusieurs implémentations, ce qui convient à des relays exploités séparément.

Le texte de NIP-01 du 23 octobre montre aussi ce que couvre une signature. L’ID d’un event est l’empreinte d’un tableau JSON UTF-8 compact contenant un zéro initial, la clé publique de l’auteur, l’horodatage, le kind, les tags et le contenu, et l’auteur signe cette empreinte avec une signature Schnorr sur la courbe secp256k1. L’enveloppe WebSocket et l’identifiant d’abonnement restent en dehors de ces données signées. Il découle de ce texte qu’un même event signé peut arriver sur différents abonnements, ou par différentes connexions, sans être signé de nouveau. Une REQ renvoie d’abord les events stockés correspondants, puis reste active jusqu’à ce que le client envoie CLOSE, ferme le socket ou réutilise l’ID d’abonnement pour une nouvelle REQ. Toutes les conditions d’un même filtre doivent être satisfaites, tandis que plusieurs filtres dans une même REQ retiennent les events qui satisfont l’un quelconque d’entre eux. Dans cette version, les noms des filtres diffèrent de ceux d’aujourd’hui. Le comportement de NOTICE n’était pas spécifié, et rien ne garantissait la durée de conservation des events par les relays ni qu’une requête les renvoie tous. Cinq ans plus tard, la même spécification reviendrait sur la signification des filtres à l’intérieur de REQ.

Octobre 2022 : un fil devient utilisable sur téléphone

Le 8 octobre, Damus, un client Nostr pour iOS, a ajouté la recherche de hashtags, de profils et d’events. Le changement a touché sa vue des résultats de recherche et son modèle de fils de discussion, ce qui permettait à un lecteur d’accéder directement à une identité signée ou à un event précis, en plus de faire défiler le texte entrant. Cette recherche fonctionnait au sein de la navigation propre au client ; il ne s’agissait pas d’une recherche plein texte côté relay.

Huit jours plus tard, Damus a remplacé les simples lignes de sa configuration des relays par une vue affichant l’état de chaque connexion. Une pastille colorée reflète le pool de relays du client. Le vert signifie connecté et le jaune en cours de connexion ou de reconnexion, le rouge désignant tout autre état et le gris précédant la première lecture. La vue s’actualise à son affichage, puis toutes les deux secondes. Le balayage pour supprimer, qui existait déjà, a été déplacé dans la nouvelle vue. Avec ces pastilles visibles, un fil bloqué n’avait plus à être interprété comme le silence d’un auteur, car un lecteur pouvait voir laquelle de plusieurs connexions indépendantes était active et laquelle réessayait. Une pastille verte indique un socket ouvert. Elle n’indique pas qu’un relay a accepté ou conservé un event. Elle n’indique pas non plus qu’une requête a renvoyé tout ce que le relay détient. Le commit atteste l’implémentation dans le code source fusionné. Ce changement de code n’établit aucune date de publication sur l’App Store.

Le 19 octobre, Damus a ajouté un analyseur pour les factures Lightning BOLT11 ainsi que des widgets de facture dans les publications, les discussions et les messages directs. Chaque widget affiche la description de la facture et son montant en satoshis, et son bouton Pay transmet l’URI lightning:, via iOS, à un gestionnaire installé. Le client social présente la publication signée, et un portefeuille distinct effectue le paiement. Ces widgets sont antérieurs à la convention ultérieure des reçus de zap : ce sont donc des affichages de factures, et non des zaps standardisés.

Octobre 2023 : les events portent des preuves et des demandes de travail

Le 11 octobre, les attestations OpenTimestamps de NIP-03, qui ancrent dans Bitcoin des preuves concernant des events, sont passées d’un champ ots de l’event à un event distinct de kind 1040. Cet event désigne l’original au moyen d’un tag e et transporte dans son contenu le fichier OpenTimestamps complet en base64, avec au moins une attestation Bitcoin. L’id de l’event référencé est lui-même l’empreinte que la preuve atteste, de sorte qu’un vérificateur apprend que l’event existait à la date attestée. Cette date provient de Bitcoin, et non du created_at de l’auteur. La preuve date l’event et n’affirme rien sur son contenu.

Le 12 octobre, indépendamment du changement relatif à l’horodatage, la dérivation de clés de NIP-06 a reçu deux vecteurs de test. Une phrase mnémonique est une suite de mots qui encode une graine de récupération ; les vecteurs couvrent une phrase de 12 mots et une de 24 mots, chacune avec ses clés privée et publique attendues en hexadécimal ainsi qu’en encodages nsec et npub. NIP-06 utilisait déjà BIP-39 pour transformer la phrase mnémonique en graine binaire et le chemin BIP-32 m/44'/1237'/<account>'/0/0 pour dériver une clé, le compte zéro étant le choix de base pour une clé unique. L’ajout d’octobre fournissait des réponses connues, et non une récupération de phrase mnémonique ni un nouvel algorithme de dérivation. Un client peut désormais vérifier que sa dérivation et ses encodages reproduisent l’identité documentée. La concordance avec les vecteurs rend les implémentations comparables. Elle ne certifie aucune implémentation particulière et ne prouve pas que les imports de tous les portefeuilles et clients concordent. Protéger une graine contre le vol est une question distincte, que les vecteurs n’abordent pas.

Le 29 octobre, NIP-90, la norme des data vending machines, a été fusionnée dans le dépôt des NIPs avec des kinds de tâche fixes. Elle réservait les kinds 5000 à 5999 aux demandes de tâche et fixait le kind de chaque résultat à celui de la demande plus 1000. Les retours utilisaient le kind 7000. Une demande peut pointer vers du texte, des URL ou des tâches antérieures. Elle peut aussi préciser la sortie attendue et proposer une offre facultative. La tâche réside donc dans des events signés auxquels n’importe quel prestataire peut répondre, en dehors de l’API d’un fournisseur unique. Un brouillon antérieur avait utilisé les kinds 68001 et 68002.

Octobre 2024 : alternatives de médias et ecash portable

Le 15 octobre, les events vidéo de NIP-71 ont adopté les tags imeta pour les variantes vidéo. Dans les kinds adressables alors en vigueur, 34235 et 34236, l’URL de chaque variante, ses dimensions, son type MIME, son image d’aperçu et ses solutions de repli étaient regroupés dans un seul tag. Un client qui choisit une résolution doit savoir quelle miniature et quelle solution de repli lui correspondent, ce que des métadonnées aplaties ne pouvaient pas indiquer. Ces numéros de kind sont historiques : le NIP-71 actuel utilise les kinds 21 et 22.

Dix jours plus tard, les portefeuilles Cashu de NIP-60 et les nutzaps de NIP-61, tous deux introduits dans des brouillons antérieurs, ont été fusionnés ensemble en tant que spécifications. Ils s’appuient sur Cashu, un protocole d’ecash dont les jetons sont émis par des mints. NIP-60 conserve sur des relays des preuves de portefeuille chiffrées, afin que des applications compatibles puissent accéder au même état de portefeuille. Selon NIP-61, l’event de kind 10019 d’un destinataire liste des mints de confiance, des relays et une clé de verrouillage, et l’event de kind 9321 d’un expéditeur transporte des preuves verrouillées sur cette clé, que le destinataire peut encaisser. Les utilisateurs dépendent toujours des mints qui émettent les jetons, et les applications doivent se prémunir contre le double encaissement des mêmes preuves.

Le 29 octobre, la signature à distance de NIP-46, dans laquelle un service distinct détient la clé qui signe pour le compte d’un utilisateur, a été révisée pour qu’une chaîne de connexion bunker:// porte la clé publique du signataire distant. L’identité de l’utilisateur est obtenue séparément : le texte révisé exige des clients qu’ils distinguent les deux clés et qu’ils appellent get_public_key après la connexion. Le client génère sa propre paire de clés pour l’échange et adresse ses requêtes chiffrées à la clé du signataire, tandis que sign_event renvoie un event signé avec la clé de l’utilisateur. Ces deux clés peuvent coïncider, mais ce n’est pas obligatoire. La clé figurant dans la chaîne de connexion identifie uniquement le service de signature. Le compte de l’utilisateur est la clé publique que renvoie get_public_key. NIP-60 avait traité l’état partagé des portefeuilles quatre jours plus tôt ; cette révision traite une question distincte, l’identité du signataire. Les exemples de ce commit utilisent encore le transport chiffré que NIP-46 spécifiait à l’époque, et le changement ne dispense pas de faire confiance à un signataire distant ni ne prouve qui détient la clé de l’utilisateur.

Octobre 2025 : mises à jour de la collaboration et métadonnées des messages privés

Le 8 octobre, Nostr Wallet Connect, NIP-47, a reçu des liens profonds pour appairer une application avec un portefeuille. Un portefeuille peut enregistrer nostrnwc://connect ou un nostrnwc+{app_name}://connect propre à l’application, et une application demandeuse ouvre ce lien avec son icône encodée en URI, son nom et un schéma de rappel. Une fois la connexion créée, le portefeuille ouvre le rappel avec un paramètre value contenant le code d’appairage, une URI nostr+walletconnect://. Trois ans après que Damus a confié des factures à un portefeuille via iOS, l’appairage sur un seul téléphone n’impliquait plus nécessairement de scanner un code QR affiché sur le même écran ni de copier une longue chaîne d’une application à l’autre. L’ajout ne couvre que cette transmission. Il ne modifie aucune méthode de paiement et ne paie rien par lui-même. Les deux applications doivent implémenter les gestionnaires, et le texte de la spécification ne prouve pas que tous les portefeuilles le font. Il ne règle pas non plus les budgets de dépense, les écrans de consentement ni la question de savoir quelle application peut posséder sans risque un schéma de rappel.

Le 16 octobre, la collaboration git de NIP-34 a reçu des events de pull request de kind 1618 et de mise à jour de kind 1619, à côté de ses events de patch existants. Une pull request désigne un commit de pointe et des emplacements de clonage, et une mise à jour déplace cette pointe. Il est recommandé de garder les patchs sous 60 ko, les pull requests servant aux soumissions plus volumineuses. Pour ces soumissions plus volumineuses, la voie recommandée est ainsi passée de corps de patch transportés dans les events à des références signées vers des commits, tandis que les changements plus petits peuvent toujours circuler sous forme de patchs. Nostr transporte la coordination et les références signées, et les serveurs Git fournissent toujours les objets de commit vers lesquels pointent ces références.

Le 27 octobre, le gift wrap de NIP-59 a reçu une recommandation visant à rendre aléatoires, indépendamment l’un de l’autre, les horodatages du seal et du gift wrap lors de l’ajout de tags d’expiration. Le gift wrap enveloppe un message dans ces deux couches, et donner à chaque couche son propre horodatage aléatoire réduit la mesure dans laquelle leur chronologie peut être corrélée. L’attention s’est ici déplacée du chiffrement du contenu vers la limitation de ce que la corrélation des métadonnées peut révéler. Le chiffrement masque le message lui-même, mais la chronologie et les autres métadonnées entourant l’enveloppe restent observables, et les choix d’implémentation déterminent la facilité avec laquelle elles peuvent être reliées. Cette recommandation n’ajoute aucun nouveau chiffrement et ne rend pas les participants anonymes.

Octobre 2026 : significations partagées des requêtes et services déclenchés par le texte

Le 5 octobre, les pièces jointes multimédias de NIP-92 ont étendu les tags imeta aux profils de kind 0. Un profil peut ainsi décrire son picture et son banner avec des URL de repli, un blurhash (un encodage compact d’un aperçu flouté), des dimensions, un texte alternatif et d’autres métadonnées de pièce jointe. NIP-92 existait avant ce changement. La nouveauté tient à ce que les métadonnées groupées que NIP-71 appliquait aux variantes vidéo en 2024 s’étendent désormais aux images de profil. L’association est exacte. Un tag ne s’applique que lorsque son URL est identique à celle de l’image de profil ou de la bannière. Les clients DEVRAIENT (SHOULD) ignorer les tags qui ne correspondent à aucune des deux, et ils DEVRAIENT (SHOULD) essayer les replis lorsque l’URL principale échoue. Comme un nouvel event de kind 0 remplace le profil précédent, un éditeur DEVRAIT (SHOULD) reporter les métadonnées d’une image inchangée et supprimer les tags des images qui ne sont plus utilisées. Un texte alternatif ou des dimensions périmés ne décriront ainsi pas discrètement une autre image. Cette règle de mise à jour compte autant que les nouveaux champs. Un tag imeta ne garantit pas qu’une image reste disponible ni qu’elle se charge plus vite. Il n’offre pas non plus de protection de la vie privée, et les clients ne sont pas tenus d’afficher chaque champ.

Le 17 octobre, NIP-01 a été clarifié pour qu’une liste vide dans un filtre ne corresponde à aucun event, ce qui diffère de l’omission de l’attribut. Une modification ultérieure a supprimé la formulation incohérente « un ou plusieurs » et a recommandé aux clients d’éviter d’envoyer des listes qui ne peuvent produire aucune correspondance. En octobre 2021, ce document avait fixé le cadrage des messages JSON de REQ : le message REQ est un tableau, et chaque filtre est un objet JSON qu’il contient. En octobre de cette année, il a tranché la sémantique des filtres en précisant ce que signifie une liste vide à l’intérieur d’un tel filtre. Des relays qui analysent la même trame de manière identique pouvaient en effet quand même renvoyer des résultats différents.

Le 21 octobre, NIP-CD, alors intitulé Commands, est passé du statut de proposition à celui de projet de spécification fusionné. Il décrit des commandes slash. Les events de kind 31992 définissent les commandes. Une invocation est du texte brut qui commence au premier caractère du contenu d’un event, de sorte que les clients n’ont besoin d’aucune prise en charge particulière pour l’envoyer. Une proposition de suivi, accompagnée d’un commit antérieur sur une branche distincte, a été fusionnée le 27 octobre. Elle a renommé la spécification Slash Commands et ajouté des listes facultatives de commandes installées de kind 10992, que les clients devraient utiliser pour l’autocomplétion et le rendu. Ces listes enregistrent une préférence de l’utilisateur. Elles n’autorisent aucun exécutant et ne conditionnent pas l’invocation en texte brut. Les jobs NIP-90 reposent sur des events structurés de requête et de résultat, alors qu’une commande reste lisible comme du texte ordinaire.