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

Cette semaine : la spécification Marmot est marquée comme adoptée sur 42 fichiers alors que MDK coupe la version 0.9.0 à la version 0.9.3 avec des avatars de groupe chiffrés, la prise en charge des signataires externes et les bindings MarmotKit iOS et Android. Mostro expédie Transport v2 sur les messages directs NIP-44 avec des portes anti-spam et une fenêtre de coexistence dans mostrod v0.18.0 et Mobile v1.3.0. Bitchat 1.6.0 ajoute la preuve de travail NIP-13 aux messages du canal Geohash, une passerelle maillée vers Nostr optionnelle qui permet à un téléphone en ligne de relier toute une foule, des offres groupées de pré-clé, une vérification transitive et des groupes privés chiffrés gérés par le créateur. Ambre analyse les abonnements aux profils par compte, récupère les listes de relays NIP-65 avant les métadonnées du profil et ajoute une notification d’état Tor en direct avec une action de redémarrage. rust-nostr ajoute l’expiration NIP-40 aux gift wraps et aux générateurs NIP-17 DM, ancrés à l’horodatage aléatoire de l’emballage. Amethyst fusionne 43 PR de renforcement de la synchronisation par néguentropie, d’infrastructure de recherche en texte intégral NIP-50 et de types d’événements pour des secteurs verticaux de niche. Nostrord livre les versions 2.0.0 et 2.1.0 avec un pool de relays replié, une détection WebSocket zombie et une connexion de cache complète en premier sur le disque. Ngit v2.6.2, Jumble v26.7.1, Signataires de compote de pommes 6.2.2, Bray v1.33.0, Deepmarks 1.0.0, Bitcredit Core v0.5.13, Coop Mobile v0.2.4, Granary v11.0, Nostr-relay v0.0.244, Manent v1.4.0, Routstrd v0.3.7, Nymchat 1.0.1 et 21Meetup 1.1.0 est également disponible, et SafeBox marque la phase 3 pratiquement terminée aux côtés d’un runbook de déploiement de prison FreeBSD et d’un spin-off OpenETR pour les enregistrements électroniques transférables. Le référentiel NIP fusionne un alignement des noms NIP-51 et NIP-37 et ouvre cinq propositions : Adresses Web NIP-AD Nostr, Gestion des revendications de code d’invitation NIP-86, un format de couleur de rôle HSL, NIP-80 provenance du support attestée par le matériel et un correctif de pagination dans NIP-01. Les plongées approfondies couvrent NIP-13 (preuve de travail) et NIP-40 (horodatage d’expiration).

Histoires principales

Marmot marque la spécification comme adoptée et MDK publie les versions v0.9.x

Le référentiel du protocole Marmot a fusionné le PR #170 le 3 juillet, modifiant 42 fichiers de Status: draft for internal review (et experimental draft) à Status: adopted. Le titre README est passé du cadre du dépôt comme un travail en cours au “Protocole Marmot” comme texte adopté, les documents de l’ère MIP ont été recadrés comme la version obsolète du protocole, et la section “Statut de la révision” (“Ce texte n’est pas encore adopté”) est devenue “Guide de révision” pour l’édition de la spécification actuelle. L’étiquette v2 disparaît partout : la formulation de contraste MIP (“nouveau dans la v2”, “la spécification v2 reste”) est remplacée par “cette spécification” et “sous cette spécification”. De par leur conception, deux documents conservent leur statut de brouillon : implementation-model.md reste non normatif et le document propre à la fonctionnalité multi-appareils reste un brouillon.

Le même référentiel a atterri PR #171 alignant les invariants de politique d’administration, d’adhésion et de changement de rôle. La vérification inter-composants selon laquelle une suppression ne peut pas orphelin d’un administrateur est désormais déclarée comme une propriété de chaque époque résultante, évaluée par rapport à l’ensemble d’administrateurs de l’époque précédente lorsqu’une validation ne comporte pas de mise à jour de la politique d’administration. La règle de branche candidate de Convergence est renforcée de sorte que « valide » signifie une validité de validation complète, y compris des vérifications d’époques résultantes entre composants, ce qui empêche une validation violant un invariant de créer un bord candidat sur n’importe quelle branche. Les notifications d’état dérivées d’une validation remplacée DOIVENT être retirées lorsque la sélection de branche la remplace, ce qui ferme le bogue “la perte du renommage en tant que message système réussi” au niveau des spécifications. Une nouvelle section « Réalisation de la suppression » dans member-departure.md définit l’entrée de réalisation principale (la validation canonique acceptée supprimant votre dernière feuille) et la solution de secours pour les clients qui n’ont jamais appliqué la validation de suppression : les preuves post-expulsion authentifiées apparaissent désormais comme un résultat SelfEvicted avec une sémantique de conservation inactive pour la copie de groupe supprimée. PR #236 a ensuite renforcé la validation des limites de câblage, fixant l’acceptation à vie du KeyPackage à 84 jours plus une marge d’asymétrie d’une heure, ajout d’une table de cardinalité de balise Nostr pour le groupe h, le gift wrap p, bienvenue e et relays et les balises KeyPackage, et indiquant que les identifiants d’événement Nostr et les métadonnées non vérifiés ne sont pas des preuves fiables de routage, de relecture ou de télémétrie.

En aval, l’espace de travail MDK a supprimé v0.9.0 le 6 juillet avec une version complète de l’espace de travail, suivi de v0.9.1, v0.9.2 et v0.9.3 au cours des deux jours suivants. La version 0.9.0 effectue une rotation des entrées de trousseau de clés obsolètes lorsqu’une nouvelle base de données SQLite est créée et applique une discipline de validation avant mutation à travers la couche de stockage. La v0.9.1 achemine chaque connexion sortante via un point d’étranglement de numérotation de sécurité hôte via PR #732, fermant ainsi la classe de bogues où différents sites d’appel atteignaient le réseau avec une validation différente. La v0.9.3 expose les avatars de groupe chiffrés aux bindings uniffi via download_group_image et image_hash_hex via PR #771, ajoute la prise en charge des signataires externes et marque wn-opencode prêt pour la production via PR #781. Parallèlement aux coupes MDK, MarmotKit fournit des bindings iOS et Android à chaque version (un MarmotKit.xcframework plus des bindings Swift pour iOS et des bindings Kotlin ainsi que des bibliothèques JNI pour Android, toutes deux générées à partir d’un hachage de validation MDK épinglé), et un nouveau canal de version wn-agent fournit des installateurs shell qui épinglent la version de l’agent WN à une balise de version immuable afin que les applications en aval puissent extraire l’agent actuel avec une seule commande curl.

Mostro v0.18.0 et Mobile v1.3.0 expédient Transport v2 sur NIP-44

Mostro est le protocole de trading Bitcoin peer-to-peer qui gère les carnets de commandes, le dépôt et la résolution des litiges sur les événements Nostr, coordonnés par un démon (mostrod) auquel les clients parlent via des DM cryptés. Jusqu’à cette semaine, le protocole de connexion entre les clients et mostrod était Transport v1. Mostro v0.18.0 débarque Transport v2, câblant le protocole sur les messages directs NIP-44 avec des portes anti-spam et une prise en charge de la double réception côté serveur. PR #776 est le changement de fil de phase 1, PR #780 ajoute les portes anti-spam de phase 2 pour le protocole v2, et PR #785 fait en sorte que la version du protocole interne suive le transport actif afin qu’un client v2 et un client v1 puissent coexister pendant la fenêtre de migration. Un PR #782 associé corrige une balise d’information NIP-33 en renommant protocol_versions au singulier protocol_version. Parallèlement au travail de transport, la version propose un chemin de cotation en direct unifié de phase 4 avec application du cache et de l’obsolescence (PR #783) et un fournisseur fiat-cross El Toque couvrant les paires cubaines CUP et MLC (PR #778). PR #779 ajoute une notification de partie coupée en cas de litige afin qu’un utilisateur qui a perdu son lien entende directement le démon ; le comportement précédent n’est apparu que sous la forme d’un solde de portefeuille manquant.

Mostro Mobile v1.3.0 est la moitié client de la migration. PR #613 migre l’application vers Riverpod 3.x, phase A (PR #620) ajoute la prise en charge de la double réception des messages directs NIP-44 sur l’isolat principal et en arrière-plan afin qu’un mostrod v2 et un client v1 puissent parler pendant la migration, phase B dans PR #624 ajoute le double envoi, le PR #632 réapplique le double envoi après la coupure de Riverpod 3.x, et la phase C dans le PR #637 finalise la migration. Le communiqué ajoute également une couverture des méthodes de paiement africaines : PR #625 ajoute les méthodes de paiement en kwacha du Malawi et PR #627 ajoute le KES (Shilling kenyan), le MZN (Metical mozambicain), le TZS (Shilling tanzanien), l’UGX (Shilling ougandais), le ZAR (Rand sud-africain) et le ZMW (Shilling zambien). Kwacha) tout en développant le NGN (Naira nigérian). Un flux de restauration attend désormais la connectivité des nœuds avant d’émettre des demandes de restauration, et la gestion tenant compte des causes distingue une barre oblique de liaison basée sur un litige d’une barre oblique basée sur un délai d’attente.

Bitchat 1.6.0 ajoute la preuve de travail NIP-13 et une passerelle opt-in mesh-to-Nostr

Bitchat 1.6.0 est l’application de chat Bluetooth-mesh qui utilise Nostr pour ses canaux de géohash et son transfert DM. La version contient deux choses en forme de Nostr qui valent la peine d’être lues. PR #1382 ajoute NIP-13 (preuve de travail) aux messages sortants du canal de géohash (type 20 000 événements éphémères) : chacun envoie une balise ["nonce", "<value>", "<target>"] avant la publication, ciblant 8 bits zéro non significatifs, ce qui représente en moyenne 256 tentatives de hachage et se termine en moins d’une milliseconde sur un Mac de la série M. Les événements entrants avec PoW validé assouplissent la limite de taux d’admission par expéditeur, de sorte qu’un spammeur paie le calcul par message tandis qu’un expéditeur régulier n’en ressent pas le coût. La portée est délibérément étroite : seuls les messages de canal de type 20 000 exploitent le PoW, et les battements de cœur de présence (type 20 001), les notes de localisation de type 1 et les DM sont intacts.

PR #1384 ajoute le mode passerelle, une liaison montante opt-in mesh-to-Nostr pour les canaux geohash. Lorsqu’un utilisateur maillé uniquement (pas d’Internet, pas de relay accessible) envoie un canal géohash et qu’un autre homologue sur le maillage annonce la capacité .gateway, l’événement signé de type 20000 est enveloppé dans une nouvelle enveloppe TLV MessageType.nostrCarrier = 0x28 et envoyé directement à une passerelle. L’homologue de la passerelle publie l’événement sur Nostr au nom de l’expéditeur et rediffuse le trafic du canal entrant sur le maillage avec la durée de vie par défaut. Les dépôts en liaison montante empruntent le chemin de l’enveloppe de messagerie (multi-sauts dirigés et relayés) ; diffusion de trajets en liaison descendante. La signature a lieu avant que l’événement ne quitte l’expéditeur, de sorte que la passerelle peut décider de publier ou non, mais ne peut pas falsifier l’attribution. La motivation déclarée concerne les scénarios de catastrophe et de protestation dans lesquels un téléphone connecté dans une foule suffit à donner à l’ensemble du canal geohash une liaison montante Nostr fonctionnelle.

La même version contient un deuxième lot de travaux adjacents à Nostr. PR #1381 ajoute des ensembles de pré-clés pour le premier contact asynchrone secret sur le chemin de messagerie du courrier, afin qu’un expéditeur puisse rédiger un message à un homologue qui est hors ligne et le transmettre au maillage sans avoir préalablement effectué une poignée de main Noise en direct. PR #1380 ajoute une vérification transitive : un homologue qui a terminé la poignée de main Noise avec une personne que vous avez déjà vérifiée est désormais garant de la session Noise, de sorte que le graphique de confiance se propage un saut à la fois au lieu d’exiger une nouvelle vérification en personne pour chaque nouveau contact. PR #1383 ajoute des groupes privés chiffrés gérés par le créateur sur le maillage, PR #1376 détecte, restitue et utilise les jetons Cashu ecash avec une commande /pay, et PR #1379 ajoute un tableau d’affichage Geohash signé persistant superposé sur le maillage. synchroniser. PR #1372 étend le stockage et le transfert avec des coursiers ouverts, un routage de pulvérisation et d’attente, une boîte d’envoi persistante et une fenêtre d’historique public de six heures. Bitchat 1.5.4 a été livré plus tôt dans la semaine avec le correctif des favoris de bout en bout dans PR #1367 qui nettoie les doublons de la liste de pairs, la synchronisation Nostr et la corruption de clé /fav.

Sorties taguées

Amber v6.2.3 étend les abonnements aux profils et ajoute une notification d’état Tor

Amber v6.2.3 est une passe de performances et d’exactitude sur le signataire Android NIP-46, et les PR fusionnés dans la semaine qui l’entoure pointent vers un thème cohérent. La version elle-même ajoute un paramètre d’intervalle de récupération de profil configurable avec des options jamais et toujours (PR #492), affiche une photo de profil dans la feuille inférieure du changement de compte et étend les abonnements au profil par le compte actuel afin qu’un signataire détenant plusieurs comptes arrête de déployer des abonnements pour les comptes avec lesquels l’utilisateur ne se connecte pas actuellement. L’analyse des autorisations du bunker bénéficie d’une gestion explicite des erreurs en cas d’échec de l’analyse. Plusieurs violations StrictMode sont corrigées : une DiskReadViolation de la journalisation onSuccess de Coil, une violation du magasin de clés lors du chargement du compte sur le thread principal, des lectures dans le thread principal pour le nom et l’image du compte dans la feuille de commutation du compte, et une construction impatiente de KeyPair() sur les écrans de connexion et d’inscription désormais déplacées du thread principal. Dans les jours qui ont suivi la livraison de la version 6.2.3, le PR #493 a réorganisé le chemin de démarrage pour récupérer la liste de relays NIP-65 de l’utilisateur avant les métadonnées du profil (de sorte que la récupération du profil interroge les relays sur lesquels l’utilisateur publie), et le PR #494 a transformé la notification Tor intégrée en un statut en direct. indicateur avec une action de redémarrage, Ainsi, un utilisateur dont le démon Tor meurt pendant une session de signature voit l’échec et peut le renvoyer sans quitter le signataire. PR #495 a activé Android Lint en mode strict d’avertissements en tant qu’erreurs dans la base de code.

Jumble v26.7.1 fait de Blossom le service de téléchargement par défaut dans une version axée sur DM

Jumble v26.7.1 est un client Web Nostr axé sur les messages directs et les médias. La version repense les paramètres de téléchargement multimédia et fait de Blossom le service de téléchargement par défaut, remplaçant l’ancien service par défaut NIP-96. La gestion des DM bénéficie d’un menu de messages mobiles, d’actions de message de bureau améliorées, d’un bouton « Faire défiler jusqu’au dernier », de réactions en cas d’appui long sur les supports DM et d’un chemin de nouvelle tentative pour les DM sortants ayant échoué à partir de la liste des messages. L’édition personnalisée des emoji bénéficie d’une vue détaillée, la taille des bulles de message s’améliore pour les factures et le contenu intégré, plusieurs problèmes de défilement DM et d’ordre des messages sont résolus et les problèmes de post-édition concernant l’insertion d’emoji, la copie de texte et le glissement de fichiers sont résolus. L’orientation de l’image est corrigée lorsque les métadonnées sont supprimées lors du téléchargement et que les téléchargements Linux ARM64 sont ajoutés à la matrice des versions.

Applesauce Signers 6.2.2 supprime une dépendance nbunksec

applesauce-signers@6.2.2 supprime la dépendance @sandwichfarm/encoded-entities du sous-package au profit d’un assistant nbunksec intégré via commit d654349. L’encodage de session de bunker NIP-46 d’Applesauce, ajouté la semaine dernière, ne nécessite plus la bibliothèque d’encodage externe, réduisant ainsi une surface de chaîne d’approvisionnement pour les clients en aval qui consomment le package des signataires.

Ngit v2.6.2 arrête les événements d’état PR en double lors de la poussée de la branche par défaut

Ngit v2.6.2 est une version de correction de bugs pour la CLI git-over-Nostr. git push vers la branche par défaut arrête de publier des événements de statut de fusion/application de PR en double pour les PR déjà marqués comme appliqués, car la détection de fusion lit désormais l’état du dépôt Nostr pré-push (la source de vérité permettant de savoir si un PR a déjà été résolu du côté NIP-34 du flux de travail) ; l’heuristique précédente reposait sur les éléments internes de git et dupliquait l’événement de statut. Les référentiels actifs utilisant ngit pour les flux push git-over-Nostr cessent d’émettre des événements de statut kind-1621 en double dans leur audience.

Bray v1.33.0 CLI récupère un profil de bunker, un personnage et Tor sortant

Bray v1.33.0 est une version Nostr SDK-plus-CLI. Le bunker --profile <name> obtient une clé de connexion auto-stable et un relay de secours afin qu’un profil enregistré puisse survivre à une panne de relays ; bunker --persona <name> signe comme une identité d’arbre nsec dérivée, permettant à un signataire d’agir comme plusieurs clés publiques à partir d’un seul arbre dérivé ; et toutes les récupérations HTTP peuvent être acheminées via un proxy Tor SOCKS une fois configuré. La version ajoute des sous-commandes de portefeuille pour NIP-47 NWC, NIP-29 les opérations d’écriture des administrateurs de groupe (création, mise à jour, ajout d’utilisateur, suppression d’utilisateur, définition de rôles), les verbes d’administration NIP-86 et les assistants de boîte d’envoi NIP-65. Les verbes de publication récupèrent les indicateurs de sortie --jsonl, --csv et --tsv, un verbe req pour les requêtes de filtre NIP-01 génériques, un verbe event pour la construction d’événements arbitraires, une commande publish-raw qui signe et diffuse des événements prédéfinis, un one-shot bunker sign. Commande de signature NIP-46 et un indicateur --relay par commande sur chaque commande de publication. Le travail de sécurité couvre trois lots de reports d’audit : discipline de mise à zéro des secrets, authentification du support de transport HTTP et renforcement des limites de débit, et validation SSRF sur les URL de relays. L’archive tar npm est livrée sur 533 844 octets avec une version reproductible en octets identiques vérifiée sur deux exécuteurs CI indépendants.

Deepmarks 1.0.0 durcit la surface de signets Nostr

Deepmarks 1.0.0 est une étape 1.0 de renforcement de la sécurité pour un service public de bookmarking Nostr. Chaque signet reste un événement Nostr signé que tout client peut lire. L’API et le gestionnaire d’archives se trouvent dans une position réseau privilégiée (ils peuvent atteindre Redis interne, le chemin de relays du bunker et les métadonnées du cloud), de sorte que la protection SSRF est porteuse, et la version corrige un contournement critique des littéraux IPv6 dans isPrivateIp : les littéraux IPv6 entre crochets étaient classés comme publics, donc [::1], [fd00::1] et IPv4 mappés. Les [::ffff:10.0.0.4] ont tous atteint leurs objectifs internes via une connexion double pile. Le garde supprime désormais les crochets et replie l’IPv6 mappé IPv4 et compatible IPv4 vers le v4 intégré avant la vérification de la plage privée sur les deux cases. Les profils kind:0 ingérés à partir de relays externes sont désormais vérifiés par signature au niveau du récepteur afin qu’un relay hostile ne puisse pas falsifier un nip05 ou un lud16 pour une clé publique de victime arbitraire, et les URL des signets sont vérifiées par schéma à chaque récepteur de rendu afin qu’un signet kind:39701 soit publié directement sur le relay avec un javascript: ou data:. La balise d cesse d’atteindre un <a href>. Les reçus Zap survivent désormais à une panne passagère du bunker : le gestionnaire de règlement revendique atomiquement le zap en attente, ne le finalise qu’une fois la signature réussie, et libère la réclamation en cas d’échec afin qu’un invoice_updated relivré puisse réessayer. Le drain de distribution /publish utilise BLMOVE dans une liste de traitement par travailleur avec une récupération déclenchée par pulsation afin qu’un travailleur en panne préserve un événement signé pour lequel le client était déjà 202.

Bitcredit Core v0.5.13 déchiffre les métadonnées de bloc sur le fil Nostr

Bitcredit Core v0.5.13 supprime une couche de cryptage des événements publics Nostr utilisés par le protocole de facture de crédit. Les métadonnées de bloc (identifiant de bloc, hachage, signature) sont désormais non cryptées sur le fil Nostr ; seules les données de bloc elles-mêmes restent cryptées avec la clé de facturation correspondante. Les nouvelles applications traitent les anciennes chaînes, les anciennes applications ne traitent pas les nouvelles chaînes. La version ajoute également une fonction de service de facturation pour récupérer la chaîne de facturation et fait passer la publication à un modèle de seuil optimiste : une fois qu’un seuil de relays configuré (celui par défaut) accepte une publication, les relays restants reçoivent l’événement de manière asynchrone afin que la publication ne soit plus bloquée par le relay le plus lent.

Coop Mobile v0.2.3 et v0.2.4

Coop Mobile a été livré v0.2.3 le 4 juillet et v0.2.4 le 7 juillet, poursuivant ainsi la cadence de sortie régulière du client de messagerie directe Android NIP-17. La v0.2.3 ajoute le rendu d’images et de liens en ligne dans les messages de discussion, les pièces jointes d’images, la saisie vocale en texte et une boîte de dialogue de confirmation pour la suppression des contacts. La v0.2.4 corrige un indicateur qui est resté bloqué pour toujours, améliore la prise de contact Nostr Connect et ajoute l’importation ncryptsec1 (le format de clé privée chiffrée NIP-49) ainsi qu’un écran d’identité d’importation repensé.

Granary v11.0 ajoute la prise en charge des événements vidéo NIP-71

Granary v11.0 est la bibliothèque de conversion multiprotocole qui alimente le pontage inter-réseau de Bridgy Fed. Le module Nostr reçoit trois changements visibles. Les événements vidéo NIP-71 (types 21, 22, 34235 et 34236) sont désormais convertis en notes ActivityStreams 1 avec pièces jointes vidéo, et le convertisseur extrait l’image imeta (vignette), la durée de la vidéo, la balise published_at de niveau supérieur et la balise alt comme un displayName de secours sur la première pièce jointe vidéo ou audio. Du côté de l’API, sign est renommé hash_and_sign et verify génère désormais ValueError en cas d’échec ; le constructeur Nostr génère ValueError sur une URL de relays non valide, et Nostr.query ignore le défi AUTH NIP-42 lorsque l’appelant n’a pas défini de privkey. Un correctif de conversion de suivi arrête les plantages lorsqu’un objet Nostr article arrive sans id. Tout pont ou lecteur consommant des événements vidéo NIP-71 via Granary peut désormais les afficher dans le format attendu par le lecteur cible.

Nostr-relay v0.0.244 ajoute un backend Firestore

mattn/nostr-relay v0.0.244 ajoute un backend Firestore via PR #12, étendant la couche de stockage du relay Go avec une option Google Cloud Firestore aux côtés de ses backends existants. Le changement est minime mais ouvre Firestore en tant qu’option de base de données gérée sans serveur pour un opérateur de relays.

Manent v1.4.0 corrige NIP-42 AUTH et ajoute des flux de presse-papiers multimédia

Manent v1.4.0 est l’application de stockage de notes et de fichiers cryptées construite sur Nostr avec le cryptage NIP-44, la prise en charge des signataires NIP-46 et NIP-55, NIP-65 le routage de la boîte d’envoi et le stockage Blossom. La version corrige l’authentification par relays NIP-42 (précédemment interrompue), corrige les téléchargements Blossom vers les hôtes http:// (précédemment mal gérés) et réécrit le flux de compression. Du côté des médias, les utilisateurs peuvent désormais copier une image dans le presse-papiers, coller une image depuis le presse-papiers, glisser-déposer des fichiers, recadrer et faire pivoter des images, lire des vidéos et des gifs et prendre une vidéo en appuyant longuement sur l’icône de l’appareil photo. Sous Linux, le presse-papiers principal est accessible via le clic central de la souris. Le chargement et le défilement des notes reçoivent plusieurs optimisations.

Routstrd v0.3.7 fait du stockage d’événements Nostr la source persistante de vérité

Routstrd v0.3.7 est le démon local du réseau d’inférence d’IA décentralisé Routstr, qui achemine les requêtes LLM via la découverte du fournisseur Nostr type 38421 et les avis LGTM type 38425. La version ajoute une sous-commande routstrd update qui télécharge de nouveaux binaires pour routstrd et cocod et redémarre gracieusement les démons en cours d’exécution ; le démon appelle désormais refreshNostrEvents() au démarrage et toutes les 21 minutes afin que la découverte et les avis des fournisseurs restent à jour sans intervention manuelle. Le @routstr/sdk fourni passe de 0.3.12 à 0.3.15, supprimant la couche ProviderRegistry au profit de l’utilisation directe du DiscoveryAdapter, nettoyant les modèles des fournisseurs Nostr disparus afin qu’ils ne s’infiltrent plus dans les classements et traitant le magasin d’événements Nostr comme une source persistante de vérité (le TTL erroné de 210 minutes sur les événements mis en cache a disparu). La gestion des remboursements Xcashu se resserre : les jetons de remboursement sont essayés avant les originaux dans le chemin d’erreur, les 404 réessayent 3 fois à des intervalles de deux minutes et les 425 trop tôt sont traités sans lancer.

Nymchat 1.0.1 est lancé en tant qu’application Web progressive sur NIP-17

Nymchat 1.0.1 (également connu sous le nom de NYM, Nostr Ynstant Messenger) est une application Web progressive et une messagerie native iOS/Android pour le chat éphémère sur Nostr, pontée avec Bitchat. Les canaux utilisent des événements éphémères de type 20 000 pour les canaux de géohash et de type 23 333 pour les canaux nommés ; les messages privés et les discussions de groupe comportent des événements emballés dans un gift wrap NIP-17 (type 1059) avec des clés de destinataire éphémères rotatives et une récupération automatique après compromission. Les utilisateurs peuvent générer une paire de clés éphémères par session sans inscription ou se connecter avec une identité persistante via les extensions de navigateur NIP-07, un signataire à distance NIP-46 ou un nsec. Le chiffrement facultatif de l’identité locale de l’appareil utilise un mot de passe, un code PIN, une clé d’accès ou un déverrouillage biométrique via WebAuthn PRF (clé d’accès et biométrie) ou PBKDF2 (mot de passe et code PIN), la clé en texte clair n’étant jamais écrite sur le disque lorsque le chiffrement est activé. Les appels vocaux et vidéo utilisent des gift wraps NIP-17 pour la signalisation et WebRTC pour le chemin multimédia. Les réactions aux messages utilisent NIP-25, les emoji personnalisés utilisent NIP-30 et l’application Web est servie sous forme de fichiers statiques ainsi que des fonctions Cloudflare Pages agissant comme un proxy de confidentialité pour les relays et les médias.

21Meetup 1.1.0 lance les badges de présence signés Nostr

21Meetup 1.1.0 est une application Flutter pour la communauté allemande Einundzwanzig Bitcoin qui enregistre la participation aux rencontres via des balises NFC et des codes QR roulants. Chaque badge de participation est un événement Nostr (type 21000) signé par l’organisateur de la rencontre à l’aide du BIP-340 Schnorr, de sorte qu’un participant accumule un ensemble d’événements signés attestant de rencontres spécifiques à des hauteurs de bloc spécifiques. Le code QR roulant tourne toutes les 10 secondes, de sorte qu’un badge ne peut pas être créé à distance et que le tag NFC n’est lisible qu’à proximité physique. Un score de confiance est calculé localement à partir des badges collectés ; le score peut être présenté sous forme de code QR pour vérification lors des échanges peer-to-peer. L’application cible la réputation de la communauté Bitcoin, et non les réseaux sociaux Nostr à usage général, mais les événements de badge eux-mêmes sont des événements Nostr ordinaires que tout lecteur peut vérifier.

Nostrord v2.0.0 et v2.1.0 replient le pool de relays et soignent les WebSockets zombies

Nostrord v2.0.0 est une version majeure du client KMP/WASM Nostr qui parle NIP-29, NIP-42, NIP-44, NIP-46, NIP-57, NIP-65 et NIP-98. v2.0.1 expédié un jour plus tard via PR #166 avec un correctif de bureau bloquant les versions : le package 2.0.0 (deb, rpm, msi, dmg) s’est écrasé au démarrage avec NoClassDefFoundError: java/sql/DriverManager car l’image jlink du jpackage manquait du module java.sql dont dépend le pilote SQLDelight sqlite sur ; le correctif ajoute java.sql à l’image d’exécution, et le même PR achemine l’envoi optimiste via la couche réseau afin que le message atteigne le relay (le chemin de code précédent mis en cache silencieusement et jamais livré), ainsi que le comportement du clavier et du défilement sur le Web mobile.

v2.1.0 a suivi le 7 juillet avec le « pli du pool de relays » (PR #176), qui unifie le socket de relays focalisé NIP-29 auparavant séparé dans le pool partagé. Un planificateur de reconnexion couvre désormais tous les relays, NIP-42 la signature d’AUTH est limitée à une nouvelle tentative, les publications sont fermées en cas d’échec et une nouvelle tentative sur authentification requise, les courses de tempête de demandes dans requestPrivateGroupData et fetchGroupPreviews sont fermées, la liste de groupes d’utilisateurs de type 10009 récupère le lot par relays, et l’abonnement en direct mux_chat couvre désormais tous les relays. a rejoint le groupe (pas seulement celui ouvert) et s’auto-répare lorsqu’un relay abandonne silencieusement l’abonnement. Les modifications côté interface utilisateur remplacent la ligne “Envoi…” de changement de disposition par une icône d’horloge puis de vérification en ligne et transforment le défilement arrière bloqué en une ligne de nouvelle tentative explicite. PR #179 a atterri le même jour pour détecter les WebSockets zombies sur Android : les réseaux mobiles et le mode Doze tuent TCP sans trame proche, donc écrit localement dans le tampon du socket mort sans lancer et isConnected() reste vrai même si rien ne sera jamais reçu. NostrGroupClient tamponne désormais lastInboundAtMs sur chaque trame, gagne markDead() (qui annule la boucle de trame afin que le chemin normal de reconnexion et de réabonnement s’exécute) et probeLiveness() (un REQ que tout relays doit répondre dans les 5 secondes), déclenché sur un délai d’attente OK avec zéro trame entrante ou sur un multiplexeur périmé plus un silence de trame de socket. Un deuxième correctif de bogue dans le même PR empêche l’écriture des messages optimistes dans le cache persistant au moment de l’insertion ; ils n’écrivent désormais qu’après confirmation de livraison. v2.1.1 expédié un jour plus tard via PR #178 ajoutant les données réelles de la plate-forme iOS, la prise en charge des tests natifs et les icônes d’application aux côtés du travail zombie-WebSocket v2.1.0.

Modifications inédites

rust-nostr ajoute l’expiration NIP-40 aux constructeurs de gift wraps et de DM privés

rust-nostr fusionné PR #1384 ajoutant une option expiration à GiftWrapBuilder et PrivateDirectMessageBuilder. La bibliothèque prend un Duration de l’appelant : la balise d’expiration NIP-40 est ancrée au created_at aléatoire de le gift wrap (created_at + durée), ce qui la dissocie de l’heure d’envoi réelle. Laisser un appelant transmettre un horodatage absolu divulguerait l’heure d’envoi à un observateur de relays (soustrayez la durée et vous récupérerez l’heure d’envoi d’origine), de sorte que la bibliothèque construit la balise en interne à partir de l’horodatage de bouclage aléatoire. L’étiquette d’expiration est placée sur l’événement de gift wrap, pas sur le sceau kind:13 (qui NIP-59 nécessite d’avoir des étiquettes vides). NIP-17 transmet la même valeur au constructeur de gift wraps de PrivateDirectMessageBuilder. Le changement ferme le problème n° 1381 et atterrit via le même modèle de constructeur que rust-nostr utilise pour extra_tags. rust-nostr a également fusionné PR #1387, consolidant nostr-relay-builder en nostr-sdk, une démarche d’aplatissement de l’espace de travail.

Amethyst passe la semaine à renforcer la synchronisation de la néguentropie et à ajouter la recherche NIP-50

La [branche principale] d’Amethyst (https://github.com/vitorpamplona/amethyst) a fusionné 43 PR sur trois thèmes cohérents. Le thread le plus important est la synchronisation néguentropique sur la limite géode-strfry : un mode d’échec de fenêtre refusée qui envoyait le client dans une boucle de partage de fenêtre recule désormais proprement (PR #3480), la dépendance negentropyKmp sous-jacente passe à la version 1.1.1 (PR #3475), un Le benchmark géode-à-strfry d’un million d’événements arrive avec un miroir de parité strfry (PR #3478), et les benchmarks de production rejoignent la matrice CI aux côtés d’optimisations de synchronisation plus larges (PR #3458, PR #3466). Les collections simultanées sans verrouillage remplacent le modèle précédent de mutex par relays et un correctif de thread de socket UDP suit (PR #3459).

Le deuxième fil de discussion est l’infrastructure de recherche en texte intégral NIP-50. Une interface SearchableEvent atterrit afin que les événements puissent transporter directement les métadonnées d’index (PR #3452), et les extensions de recherche NIP-50 sont désormais supprimées avant d’interroger SQLite FTS afin que le moteur de recherche local ne s’étouffe plus avec la syntaxe d’extension côté serveur (PR #3464). Les relays de recherche par défaut sont centralisés (PR #3446).

Le troisième fil concerne les intégrations de protocoles pour les secteurs verticaux de niche. La prise en charge des événements de détection d’oiseaux Birdstar (type 2473) atteint un client Android (PR #3473), et les états de sauvegarde de la carte mémoire PS1 peuvent être publiés en tant qu’événements signés sur le type 38192 (PR #3482). Pour compléter la semaine : un paramètre de composition de signature ajoute automatiquement du texte personnalisé aux publications (PR #3450), la vue des notifications du bureau est repensée avec des toasts natifs du système d’exploitation et un filtre partagé (PR #3457), la colonne Messages détecte un verrou de confidentialité (PR #3432), NostrServer.ingest ajoute un chemin d’écriture local avec saut de vérification par soumission (PR #3469), et les contrats equals/hashCode sont réparés dans le chemin de vérification OpenTimestamps (PR #3477).

Buzz continue de renforcer le relay et définit le type 44200 pour les métriques de rotation des agents

Buzz (le projet anciennement nommé Sprout) a généré 123 PR fusionnés entre le 1er et le 7 juillet. Deux fils supportent la majeure partie du poids. Le premier est un nouveau type d’événement pour la télémétrie des agents : PR #1441 définit les métriques de tour d’agent chiffrées durables NIP-AM comme étant le type 44200, qui envoie la télémétrie en tant qu’événement signé dans les propres archives de relays de l’utilisateur, en conservant les métriques sur l’infrastructure appartenant à l’utilisateur. Une archive locale pour le type suit (PR #1555), le chemin de suppression du type est rendu atomique (PR #1562) et le nom du modèle est transmis via le chemin d’émission afin que les lecteurs en aval puissent distinguer quel modèle a produit quel tour (PR #1564).

Le deuxième fil conducteur concerne les performances du relay. L’envoi après la validation est différé et un clone de vérification est évité (PR #1453), les allers-retours de base de données d’ingestion et de distribution sont regroupés avec des baisses d’ack p99 mesurées de 7 à 16 pour cent et des chutes de queue p999 de 29 à 53 pour cent par rapport à l’astuce précédente (PR #1454), l’exécution de requêtes multi-filtres s’exécute avec concurrence limitée (PR #1457) et lot de trames de données WebSocket sortantes à l’envoi (PR #1464). Parallèlement au travail de performance, un jeu d’icônes d’espace de travail par communauté que les administrateurs configurent et que le relay sert via NIP-11 étend le document d’information de NIP-11 avec une surface de personnalisation par communauté (PR #1463), les propriétaires d’agents peuvent supprimer les messages de leur agent via le type de relays : 5 événements ainsi que l’UX de bureau et mobile correspondant (PR #1519), le traçage OpenTelemetry rejoint les métriques Prometheus sur le relay (PR #1398), et le registre des noms de dépôt git est déplacé vers Postgres (PR #1432).

Divine Video connecte une vérification de signature de relays et une extraction NostrConnect

L’application mobile de Divine Video a fusionné 97 PR dans la fenêtre, et le fil de discussion orienté vers Nostr concerne le renforcement des limites de confiance et le nettoyage de l’authentification. PR #5774 vérifie les signatures d’événements de relays entrants, fermant ainsi une classe de bogues de confiance dans le relay ; PR #5828 crypte le jeton push FCM dans l’événement de désenregistrement kind-3080 afin que le jeton de l’appareil de l’utilisateur cesse d’apparaître en texte clair sur le relay lorsqu’il se désabonne ; et PR #5831 fragmente la REQ de suppression kind:5 afin qu’un utilisateur avec un historique de suppression volumineux ne déborde plus la trame de relays. Du côté de l’authentification, le PR #5826 extrait un NostrConnectCoordinator pour le flux nostrconnect://, nettoyant ainsi le chemin du code de bunker initié par le client NIP-46 avant un refactor d’authentification plus large suivi sous le problème n° 4741. PR #5709 mappe les republications de type 16 lorsque notification_type est absent afin qu’une notification de republication s’affiche correctement même lorsque le client expéditeur omet l’indice.

Zap Cooking corrige la connexion au bunker NIP-46 et ajoute la recherche de recettes NIP-50

L’interface de Zap Cooking a fusionné 18 PR dans la fenêtre autour d’un thème : permettre aux surfaces d’authentification Nostr de se remettre d’une panne. PR #503 corrige la connexion au bunker avec une poignée de main de connexion explicite, la gestion de l’authentification et la détection d’erreurs afin qu’un utilisateur attachant un signataire externe voie un véritable message d’erreur en cas d’échec là où la coupe précédente a bloqué l’écran de connexion. PR #495 ajoute l’authentification NIP-98 aux chemins de téléchargement d’image et de texte du point de terminaison de l’extrait-recette afin que les téléchargements soient attribués par clé publique. Un fil de fonctionnalités distinct permet la recherche de recettes en texte intégral NIP-50 via le backend de relays de recherche nosstrarchives (PR #483), permettant à un utilisateur d’interroger des recettes dans le corpus de relays sans index côté client. Le rendu du contenu est livré avec : le contenu et les médias des notes citées apparaissent désormais directement dans la note parente remplaçant le précédent lien de secours enterré (PR #491), les aperçus de liens et le dimensionnement des hashtags (PR #492), les requêtes de recherche multi-mots fonctionnent (PR #482), et les cartes d’aperçu social côté serveur sont généré pour les notes, les lectures et les liens de profil (PR #494).

Swift-nostr-client v0.6.0 progresse vers une première version stable

yysskk/swift-nostr-client a été livré v0.6.0 aux côtés de 30 PR fusionnés. La bibliothèque Swift Nostr se rapproche d’une première surface d’API stable pour les clients Swift Nostr qui évitent de relier les chaînes d’outils MDK ou MarmotKit.

Le protocole Nostr Applet (NAPS) renforce le routage et la diffusion NAP-OUTBOX

NAPS a connu une semaine de nettoyage significative, principalement dans NAP-OUTBOX. Le titre est des limites plus strictes : moins de routage contrôlé par l’appelant, moins de détails de relays divulgués et une forme de résultat d’événement partagé qui peut contenir des conseils de relays et des side-cars de ressources, liés à NAP-RESOURCE. La publication est également plus claire : règles explicites de boîte d’envoi, de boîte de réception et de distribution de relays. Effet net : moins d’ambiguïté, meilleure interopérabilité.

La chaîne d’outils Napplet renforce l’alignement des protocoles et livre sa CLI

Cette semaine, les packages de Napplet sont passés du « SDK utile » à une chaîne d’outils de protocole plus stricte. La grande histoire est l’alignement avec les spécifications NAP en direct : prise en charge des requêtes NAP-COUNT, cycle de vie appartenant au runtime d’OUTBOX et side-cars RelayEventResult ont tous atterri, rendant les lectures et les abonnements médiés par le shell plus précis. Plusieurs domaines ont également été améliorés : prise en charge du registre CVM, enveloppes d’erreur DM, contexte de session MEDIA, champs de comptage LISTS, résultats de profil COMMON et schéma htree: RESOURCE. En ce qui concerne les outils, le nouveau @napplet/cli constitue une étape majeure, ajoutant la découverte de configuration, la planification du déploiement, la signature, les téléchargements Blossom et la génération de manifestes. Enfin, le prélude de cale injectable par l’hôte et le travail de préparation JSR ont rendu la pile plus facile à injecter, à publier et à vérifier.

primal-android étend la surface du signataire distant

Primal Android a fusionné 18 PR dans la fenêtre. Du côté de Nostr, PR #1075 implémente les méthodes switch_relays et logout pour le rôle de signataire à distance de l’application, étendant ainsi la surface de signataire NIP-46 de Primal. PR #1083 ajoute un cadre de migration d’applications locales contrôlé par splash, et PR #1080 implémente la prélecture de flux de notes dans le modèle de vue splash. Le reste est une finition de l’interface utilisateur dans les barres supérieure et inférieure d’accueil, les astuces d’exploration et l’écran de profil.

Wisp ajoute un commutateur multi-comptes et des tests d’analyseur Blossom

Wisp a fusionné 9 PR. PR #604 ajoute un sélecteur multi-compte avec un chemin d’annulation explicite sur le flux d’ajout de compte. PR #613 ajoute des tests unitaires pour Blossom.parseServerList, renforçant ainsi l’analyseur de liste de serveurs Blossom. PR #574 réécrit la feuille de zap pour la mise en page iOS avec une surface de paramètres de zap instantané, PR #605 transforme l’historique des transactions en une feuille inférieure balayable vers le haut, PR #611 analyse les hashtags avec des lettres Unicode non ASCII, PR #609 maintient la pagination du flux de notes de profil et restitue les médias de la galerie en ligne, et PR #603 conserve les lignes vides avant les segments de profil en ligne et de hashtag.

TAO et Wired augmentent le signal PoW à 21 bits et font apparaître de nouvelles racines PoW

smolgrrr/TAO et smolgrrr/Wired (le même ensemble de validations a atterri dans les deux dépôts) ont fusionné 13 PR. PR #84 élève l’objectif de preuve de travail post-signal par défaut à 21 bits zéro non significatifs, et PR #80 fait apparaître les racines d’alimentation d’une nouvelle activité PoW afin qu’un client puisse classer la chronologie en fonction des travaux récents du NIP-13 ; le classement précédent était l’âge brut de l’événement. PR #75 restaure un sélecteur d’emoji personnalisé et PR #65 ajoute des aperçus vidéo de la première image. Il s’agit du deuxième client Nostr cette semaine à s’appuyer sur NIP-13 en tant que filtre de première classe pour le contenu généré par les utilisateurs, complétant le PoW de Bitchat à l’échelle du canal.

keep-android peaufine NIP-46 UX et obtient un correctif TOCTOU

privkeyio/keep-android a livré v1.1.5 aux côtés de 13 PR fusionnés, puis v1.1.6 le 8 juillet épinglant le noyau de maintien sous-jacent à la v0.5.0. Keep est un coffre-fort d’identité mobile (traité dans le Numéro 29 en tant que CustID). La version 1.1.5 était un peaufinage UX sur le flux de défi NIP-46. La version 1.1.6 ferme une course de vérification puis de définition (TOCTOU) dans set_active_share à partir de la caisse Keep-Mobile sous-jacente, fait apparaître l’URL et la méthode autorisées sur l’invite d’approbation d’authentification HTTP NIP-98 afin qu’un utilisateur puisse voir ce qu’il signe et bascule la vérification de l’état RNG pour qu’elle échoue (renvoie une erreur) au lieu de paniquer. Un test instrumenté couvre le coupe-circuit de flux d’approbation NIP-55. Les fonctionnalités CLI v0.5.0 fournies avec la version sous-jacente (déverrouillage par seuil-OPRF, logiciel DKG, portefeuilles HD FROST) ne sont pas encore apparues dans l’application Android ; La v1.1.6 fournit uniquement les correctifs de sécurité.

Heartwood expédie le pont de signature relays-série

forgesworn/heartwood v0.7.0 fait atterrir le pont de signature relays-série qui était en vol la semaine dernière, câblant le plan de données en mode HSM pour le chemin de signature série de Bray. PR #11 est le pont lui-même, PR #13 ajoute une couverture de trame série et corrige le décalage de charge utile read_frame du périphérique, et PR #14 extrait le codec de trame série dans une caisse heartwood-frame partagée.

SafeBox publie un rapport d’avancement de la phase 3 et un runbook de prison FreeBSD

SafeBox est un coffre-fort de données portable privé sur Nostr qui combine NIP-47 Nostr Wallet Connect, nAuth, nembed et transfert d’enregistrements par relays via QR et NFC en un seul service déployable par l’opérateur. Un rapport d’avancement de juillet 2026 publié le 6 juillet indique que la phase 3 est pratiquement terminée : 49 commits ont été effectués depuis le rapport d’avril, portant le référentiel à 1 136 commits, et les quatre engagements d’ingénierie de la phase 3 (renforcer les expériences de la phase 2, prendre en charge les instances interopérables, préparer l’échelle, ajouter une discipline relative aux produits commerciaux) sont en grande partie respectés. Le rapport définit la prochaine étape comme un projet pilote limité et révèle qu’un fournisseur de télécommunications sous NDA explore un projet pilote de dossiers de santé sur SafeBox.

Le travail concret sur Nostr a atterri plus tôt dans la phase 3 et est résumé dans le rapport : les actions de mutation de NWC sont désormais mises en file d’attente pour éviter les courses de preuves, les fusions Lightning échouées protègent les preuves avant de revenir, les auditeurs NWC de longue durée s’actualisent désormais de manière proactive afin qu’une session survit au-delà de son seuil d’inactivité ; le comportement précédent était un blocage silencieux et les rappels LNURL utilisent des origines canoniques avec des réponses JSON et CORS explicites. L’échange d’enregistrements QR et NFC a obtenu une spécification de flux unifiée couvrant les modes de présentation présentés par le destinataire, présentés par l’expéditeur et multi-appareils avec une gestion plus claire du KEM (Key Encapsulation Mechanism) et une protection contre la relecture via la bibliothèque Open Quantum Safe. Le commit dans la fenêtre est 6866dae, qui ajoute un déploiement de prison FreeBSD et runbook de construction liboqs aux côtés d’une spécification de l’appliance FreeBSD, documentant les instantanés ZFS, l’isolation de la prison, la gestion des services rc.d, la configuration du proxy inverse au niveau de l’hôte et la procédure de restauration pour un Déploiement SafeBox sur matériel FreeBSD/ARM.

Le rapport annonce également OpenETR comme une spin-off distincte appliquant l’architecture de contrôle cryptographique et d’enregistrements portables de SafeBox aux documents transférables électroniques : connaissements, récépissés d’entrepôt, billets à ordre et certificats. Le dépôt d’OpenETR a enregistré 7 commits le 7 juillet, dont ea612a9 séparant l’attestation de l’enregistrement principal, ca153a3 sur la gestion du mandat par rapport à l’effet, et ba84b61 ajoutant une comparaison aux informations d’identification vérifiables. formats.

Travaux de protocole et mises à jour du NIP

Fusionné : NIP-51 et NIP-37 alignent le nom du type 10013

PR #2404 est un correctif de cohérence pour la prose uniquement. Dans NIP-37, le type 10013 est nommé Relay List for Private Content ; dans NIP-51 sous Draft relays, le même type a été décrit avec une formulation différente. NIP-51 utilise désormais le nom NIP-37 pour le même type d’événement. Aucun changement de comportement des fils et aucune nouvelle sémantique de balise ; la valeur est que NIP-51 est la spécification générale pour les événements sous forme de liste et NIP-37 est le suivi du contenu privé, et une dénomination mal alignée entre les deux fait qu’il est facile de manquer qu’ils décrivent le même type.

Ouvrir : adresses Web NIP-AD Nostr via la recherche .well-known

PR #2406 s’ouvre en tant que successeur d’un PR #2393 fermé avec un brouillon de spécifications complet à AD.md. NIP-AD définit des URL Web qui comportent une contrepartie Nostr facultative. Un client qui voit une URL telle que https://golf.com/players demande https://golf.com/.well-known/nostr.json?ad=/players, qui renvoie un objet JSON mappant les chemins aux paires {filter, relays}. Le filtre renvoyé est un filtre NIP-01 standard (genres, auteurs, #d, limit, etc.) et les noms de tableaux de relays que le client doit interroger. Avec "limit": 1, l’URL se résout en un seul événement ; sans cela, à une liste. Dans un navigateur Web normal, l’URL affiche le HTML comme n’importe quelle autre URL, de sorte que le même domaine peut servir les utilisateurs Web et les clients Nostr à partir d’un seul chemin canonique. Les cas d’utilisation indiqués incluent les noms de groupe NIP-29 résolus en un événement de type 39000 sur un relay spécifique (supprimant le besoin de cultiver des identifiants de groupe), les recherches de site NIP-5A, les flux hébergés qui publient un filtre {"ids": [...]}, le rendu natif du njump.me/nevent1... collé et les URL d’événements spécifiques au client, et des blogs alimentés par Nostr qui existent à la fois nativement au sein de Nostr et pour les visiteurs extérieurs. La disposition de réutilisation .well-known/nostr.json plus chemin en tant qu’objet est choisie afin que le résolveur puisse être un fichier statique.

Ouvert : gestion des réclamations NIP-86 pour les codes d’invitation

PR #2408 propose d’ajouter trois méthodes à NIP-86 : listclaims (paramètres [], renvoie un tableau de codes d’invitation NIP-43, createclaim (paramètres [claim], renvoie true) et deleteclaim (paramètres [claim], renvoie true). Aujourd’hui, NIP-86 permet à un administrateur relays de gérer les utilisateurs et les attributions de rôles, mais n’a pas de surface de code d’invitation. Le cas d’utilisation de l’auteur du PR est l’intégration d’un relay communautaire : un administrateur crée un code d’invitation associé à un rôle, collecte le paiement avant la création de l’identité de l’utilisateur, transmet le code d’invitation à l’utilisateur, et un robot écoute l’événement de réclamation de type 28935 résultant sur le relay et attribue automatiquement le rôle. Les trois méthodes permettent à ce flux de s’exécuter entièrement via le RPC de gestion des relays.

Ouvert : couleur du rôle sous forme de tuple (h, s, l)

PR #2402 modifie le format de couleur de rôle dans NIP-43 d’une seule valeur hue (0 à 360) à un tuple de hue (0 à 360), saturation (0 à 1) et lightness (0 à 1). Les chaînes vides sont autorisées pour n’importe quel composant afin que les clients puissent fournir leurs propres valeurs par défaut pour une palette cohérente, et le texte des spécifications recommande de fournir uniquement hue, à moins qu’une couleur spécifique comme l’argent ne soit souhaitée. Le changement passe par NIP-86 dans le même PR : createrole et editrole prennent désormais [id, label, description, [h, s, l], order] ; la signature précédente portait un paramètre monochrome dans le même emplacement. La motivation est que la teinte seule oblige les clients à choisir la saturation et la légèreté pour l’opérateur, de sorte que différents clients jouent le même rôle à des intensités visiblement différentes.

Ouvert : provenance des supports certifiés par le matériel NIP-80

PR #2409 ouvre NIP-80, un format d’événement pour la provenance des médias ancré dans le matériel de capture. Une caméra signe chaque photo au moment de la capture et publie la preuve sur des relays gérés par le contenu lui-même, de sorte que la vérification survit à la suppression des métadonnées, au réhébergement et au retrait de la plateforme. La proposition définit six nouveaux types d’événements : le type 1080 pour les attestations de capture, le type 1081 pour les attestations de dérivation couvrant les opérations de redimensionnement, de recadrage, de recompression ou de rédaction (avec un mode de révélation ou une option de connaissance nulle), le type 1082 pour les révocations (événements réguliers, permanents, de portée auteur, monotones), le type 11080 pour les annonces d’appareils, le type 31080 pour les approbations d’appareils et le type 31081 pour un appareil configuré pour les attestations anonymes (marqué expérimental et éventuellement divisé en un NIP compagnon). Les primitives réutilisées incluent la sémantique des balises NIP-94 x, NIP-92 imeta, NIP-65 pour la découverte de révocation, Blossom pour le stockage multimédia et, en option. Ancrage de l’horodatage NIP-03. Le modèle de signature associe une clé de périphérique BIP-340 à une clé matérielle ECDSA, car les éléments sécurisés traditionnels ne produisent pas encore de signatures BIP-340 (Microchip ATECC608 prend en charge P-256, NXP SE050 prend en charge secp256k1 mais uniquement ECDSA, Les modules TPM 2.0 et Infineon OPTIGA Trust M couvrent le P-256/RSA, Apple Secure Enclave et Android StrongBox utilisent le P-256). La portée indiquée ne tente explicitement pas de prouver que la scène est réelle : une attestation prouve que cette image exacte provient de cet appareil à peu près à la même époque et a été modifiée uniquement de manière déclarée et prouvable, et la spécification interdit aux clients de regrouper les résultats dans un simple badge “authentique”. Un prototype fonctionnel OpenVeilCam, un environnement d’exécution de caméra Rust pour Raspberry Pi utilisant l’élément sécurisé ATECC608, est en cours de mise à jour pour publier les types d’événements proposés aux côtés d’un vérificateur autonome.

Ouvert : renforcement de la pagination NIP-01

PR #2407 ajoute une sous-section « Pagination et limites » à NIP-01. Les règles concrètes : un relay qui impose un limit maximum DOIT le définir supérieur au plus grand nombre d’événements partageant un seul created_at dans sa base de données, afin qu’aucune seconde ne puisse remplir une page et bloquer la pagination. Les clients effectuant une pagination en arrière DOIVENT répéter les demandes avec until = oldest (inclus) et DOIVENT dédupliquer par id (puisque la seconde la plus ancienne est récupérée à chaque tour), et la pagination est terminée lorsqu’un tour ne produit aucun nouvel événement après la déduplication. Si une page complète contient des événements les plus anciens et les plus récents partageant un created_at, le client DOIT réessayer cette seconde avec un limit plus grand, et si le relay bloque le plus grand limit et renvoie toujours une page limitée à une seconde, le client DOIT soit avancer avec until = oldest - 1 (en traitant les événements non récupérés comme supprimés) soit abandonner. La recherche de personnes normale NE DOIT PAS définir limit ; le maximum du relay fait autorité, et une valeur plus petite réintroduit le décrochage. Augmenter limit pour drainer une seconde bloquée est la seule exception. Ce correctif est important car un curseur naïf since/until manque les événements avec des horodatages en double ou les retraite, et le texte NIP-01 actuel n’indique à aucun des deux côtés comment échapper au piège.

NIP Deep Dive : NIP-13 (Preuve de travail)

NIP-13 définit un mécanisme de preuve de travail pour les événements Nostr. Il existe parce que le spam de type courrier électronique est trivial à produire sur un réseau de relays public : n’importe qui peut générer une paire de clés et inonder un sujet, et il n’y a aucun coût économique par événement. NIP-13 permet à un auteur d’événement d’imposer un coût de calcul par événement qu’un spammeur devrait payer globalement, mais qu’un expéditeur régulier ne paie qu’une seule fois par message. Les relays et les clients peuvent alors exiger ou préférer des événements qui répondent à un seuil de difficulté.

Le mécanisme

Un auteur d’événement sélectionne une cible de difficulté exprimée en bits et extrait l’identifiant de l’événement (le hachage sha256 de l’événement sérialisé) jusqu’à ce qu’il contienne au moins autant de bits zéro en tête. Étant donné que l’ID de l’événement inclut l’horodatage created_at, les balises et le contenu, l’exploration nécessite de modifier quelque chose dans le corps de l’événement pour rechercher l’espace de hachage. NIP-13 définit une balise nonce exactement dans ce but :

["nonce", "<nonce_value>", "<target_bits>"]

Le nonce_value est n’importe quelle chaîne choisie par le mineur ; le target_bits est la difficulté à laquelle le mineur s’est engagé. Un vérificateur compte les premiers bits zéro de l’ID d’événement et compare avec target_bits. Le target_bits dans la balise est une réclamation, et un vérificateur mesure le nombre réel de zéros non significatifs de l’identifiant pour le confirmer.

Le nombre de bits zéro en tête dans une sortie aléatoire sha256 suit une distribution géométrique : chaque bit supplémentaire double le travail attendu. 8 bits représentent en moyenne 256 tentatives de hachage, 20 bits en moyenne environ un million et 28 bits en moyenne environ 268 millions. La cible 8 bits de Bitchat pour les messages Geohash Channel coûte moins d’une milliseconde de CPU sur le matériel moderne et se termine en dessous de toute latence perceptible. La valeur par défaut de 21 bits de TAO et Wired est d’environ deux millions de tentatives de hachage par publication, ce qui est rapide sur un ordinateur portable mais coûteux à grande échelle pour une ferme de robots. NIP-13 n’impose pas de difficulté ; chaque relay et client choisit le sien.

Exemple d’événement

Une note minimale de type 1 extraite de NIP-13 ressemble à :

{
  "id": "000000000e9d97a1ab09fc381030b346cdd7a1a8a6f27c9c88f68c8b9d0f6c8a",
  "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
  "created_at": 1720368000,
  "kind": 1,
  "tags": [
    ["nonce", "72847", "28"]
  ],
  "content": "hello, this cost me 28 bits of PoW",
  "sig": "b1a5c9c74cff59f8a48e5c3b3d8e1c8e7e2c1d4a8e2b9f7d1c3e8b4f6a2c8d1e9f4b3c7a1d8e5b2f9c6a3d7e1b8f4c9a2d6e3b7f1c8a4d9e2b5f8c1a7d4e6b9f3c2"
}

Le id commence par sept zéros hexadécimaux (28 bits zéro en tête, correspondant au target_bits dans la balise nonce). Le mineur a modifié le nonce_value 72847 jusqu’à ce que l’identifiant atteigne l’objectif. Un vérificateur hache l’événement sérialisé et confirme que l’identifiant comporte au moins 28 bits zéro en tête, puis vérifie la signature. NIP-13 n’ajoute aucun nouveau champ ; il ajoute la balise nonce et limite le nombre de bits zéro de l’identifiant.

Où il est utilisé

La version 1.5.4 de Bitchat utilise un PoW 8 bits sur 20 000 messages de canal Geohash : les messages sortants m’envoient la balise avant la publication et les événements entrants avec PoW validé assouplissent la limite de taux d’admission par expéditeur. TAO et Wired utilisent PoW 21 bits comme seuil post-signal par défaut et les racines d’alimentation en surface provenant d’une nouvelle activité PoW, traitant PoW comme un signal de classement chronologique. cagliostr applique NIP-13 au niveau de la couche relays, rejetant les événements inférieurs à un seuil. NoStrudel expose un paramètre d’exploration de données PoW côté client pour les auteurs qui souhaitent signaler les clients de filtrage. Damus et Amethyst calculent les bits zéro non significatifs lors de l’affichage des événements, permettant à un utilisateur de voir l’engagement PoW sur les notes. Coracle expose PoW à la fois pour l’exploitation minière et le filtrage. NDK et nostr-tools exposent les assistants de minage PoW aux consommateurs de bibliothèques.

La propriété de conception qui façonne le déploiement de NIP-13 est que PoW est infalsifiable : une revendication de target_bits ne compte comme preuve que lorsque l’identifiant comporte autant de zéros non significatifs, et une contrefaçon nécessite de refaire le travail. Cette propriété permet à Bitchat d’utiliser le PoW entrant comme assouplisseur de limite de débit, même lorsqu’un spammeur revendique une difficulté élevée ; le contrôle est un décompte de hachage, pas une décision de confiance. La propriété complémentaire est que PoW n’engage pas le mineur sur une clé publique ou un contenu spécifique ; un spammeur peut toujours choisir d’exploiter à 8 bits et de graver le calcul, mais le calcul représente un coût réel. NIP-13 fait passer le problème du spam de « impossible » à « quantifiable » et permet aux clients de fixer leur propre prix.

NIP Deep Dive : NIP-40 (horodatage d’expiration)

NIP-40 définit une balise expiration qui indique à un relay et à un client qu’un événement doit être considéré comme expiré après un horodatage Unix donné. Il existe parce que les événements Nostr sont par ailleurs permanents : une fois qu’un événement signé arrive sur un relay, la seule façon de le supprimer est un événement de suppression NIP-09, et même dans ce cas, un relay peut conserver l’original. NIP-40 permet à un auteur de déclarer au moment de la publication qu’un événement est de courte durée, et demande aux relays de cesser de le servir et aux clients de cesser de l’afficher après l’horodatage.

Le mécanisme

Un auteur ajoute une balise expiration à un événement :

["expiration", "<unix_timestamp>"]

L’horodatage est en secondes Unix. Un relay PEUT rejeter les événements dont l’expiration est déjà passée lors de l’ingestion, PEUT arrêter de servir les événements dont l’expiration est passée, et DEVRAIT respecter l’expiration déclarée par l’auteur. Un client DEVRAIT cacher les événements expirés à l’utilisateur. NIP-40 n’exige pas que le relay supprime l’événement et n’annule pas la sémantique des événements protégés NIP-70 ; c’est un indice plus un contrat souple.

La balise réside sur l’événement lui-même (ou dans le cas d’une messagerie encapsulée, sur l’enveloppe extérieure). NIP-40 ne définit pas la sémantique de suppression ; l’événement reste un événement signé que toute personne qui le possède peut toujours lire. Ce que NIP-40 donne, c’est une attente coordonnée selon laquelle le relay et le client cesseront de faire surface sur l’événement après la date limite. Cela rend NIP-40 utile pour les publications éphémères, les annonces chronométrées, les notes d’événements en direct qui devraient cesser d’être diffusées après l’événement et les messages directs NIP-17 qui ne devraient pas s’attarder au-delà d’un horizon indiqué.

Interaction avec le papier cadeau

Le PR rust-nostr qui a atterri cette semaine (PR #1384) est une étude de cas sur la façon dont NIP-40 interagit avec le gift wrap NIP-59. NIP-59 définit une enveloppe à deux couches : un événement kind:13 « sceau » signé par la vraie clé de l’expéditeur, et un événement kind:1059 « gift wrap » signé par une clé éphémère. Les deux couches ont des valeurs created_at randomisées, jusqu’à 48 heures avant l’heure d’envoi réelle, de sorte qu’un observateur de relays ne peut pas récupérer le véritable horodatage d’envoi. NIP-59 exige que le sceau ait des étiquettes vides.

Ce mandat explique pourquoi l’étiquette d’expiration doit figurer sur le gift wrap et rester hors du sceau, et pourquoi ancrer l’étiquette à l’heure d’envoi réelle irait à l’encontre de la confidentialité temporelle de le gift wrap : si un appelant passe un horodatage d’expiration absolu, un observateur soustrait la durée de vie prévue de l’appelant et récupère l’heure d’envoi réelle. La décision de conception de rust-nostr est d’exposer l’API en tant que Duration de l’appelant, puis de calculer expiration = wrap.created_at + duration à l’intérieur de la bibliothèque. Le created_at du wrap est déjà randomisé dans la bibliothèque, donc l’horodatage d’expiration hérite de la même randomisation et ne divulgue pas l’heure d’envoi réelle.

Exemple d’événement

Un exemple minimal de NIP-40 sur une note de type 1 :

{
  "id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
  "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
  "created_at": 1720368000,
  "kind": 1,
  "tags": [
    ["expiration", "1720454400"]
  ],
  "content": "this note expires in 24 hours",
  "sig": "d2e5b8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1"
}

created_at est l’horodatage Unix de publication ; l’étiquette d’expiration indique que l’événement devrait cesser d’être diffusé 86 400 secondes (24 heures) plus tard. Un relay qui respecte NIP-40 arrête de renvoyer cet événement aux REQ après 1720454400, et un client qui respecte NIP-40 le cache à l’utilisateur après ce délai.

Où il est utilisé

Les constructeurs de rust-nostr (GiftWrapBuilder, PrivateDirectMessageBuilder) exposent désormais l’expiration en tant que paramètre Duration de première classe. NDK expose un assistant d’expiration pour les constructeurs kind-1 et DM. nostr-tools dispose d’une paire getExpiration et isExpired pour lire et appliquer la balise. strfry, nostr-rs-relay, khatru et d’autres implémentations de relays respectent NIP-40 dans la gestion REQ (rejetant ou omettant les événements expirés en fonction de la politique de l’opérateur). Damus, Amethyst, noStrudel, Coracle et Primal filtrent tous les événements expirés à partir de leur rendu chronologique. Les clients d’activité en direct comme zap.stream utilisent NIP-40 sur les événements de discussion kind-1311 associés afin qu’une discussion en direct cesse de persister après la fin du flux.

La propriété de conception qui permet à NIP-40 de fonctionner proprement dans la plupart des implémentations est qu’il est opt-in par événement et ne nécessite pas de déploiement coordonné. Un auteur peut ajouter la balise aujourd’hui ; un relay qui l’honore obtient un ensemble de travail plus propre ; un relay qui l’ignore ne fait pas pire qu’avant ; et un client qui cache les événements expirés donne à l’auteur ce qu’il a demandé. Le changement Rust-Nostr de cette semaine renforce le fait que l’emplacement de la balise est autant important que sa présence : dans une enveloppe préservant la confidentialité comme le papier cadeau NIP-59, la balise se trouve sur la couche dont l’horodatage est déjà aléatoire, et la surface de l’API empêche un appelant de divulguer accidentellement un horodatage réel dans l’emballage.

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