Amethyst v1.11.0 apporte une implémentation complète du calendrier NIP-52 avec rappels, splits de zap Bitcoin on-chain et support des réponses de groupe Marmot. White Noise v2026.5.22 livre les notifications push iOS via une Notification Service Extension, aux côtés de l’UX de blocage et d’un bouton d’ajout de membres. Vector v0.4.0 apporte une réécriture depuis zéro de vector-core, Tor en un clic avec des ponts, les signataires distants NIP-46, la synchronisation de groupe MLS en negentropy complet, et un serveur MCP de 21 outils pour agents IA. Applesauce v6.1.0 introduit les listes de relais de lookup NIP-51 (kind 10086) et un ensemble complet d’usines de git-cast NIP-34. MDK ajoute les messages éphémères NIP-40 sur iOS et Android via une surface UniFFI unifiée, et Mostro v0.17.4 ferme la boucle de caution anti-abus avec les paiements de caution slashée Phase 3 au gagnant. Notedeck fusionne la réconciliation negentropy NIP-77 complète pour les giftwraps et le backfill de fils, Cordn fait surface comme messager MLS médié par coordinateur qui échange une dépendance de disponibilité unique contre un ordonnancement d’époque plus serré et un modèle opérationnel plus simple, une implémentation de référence NIP-B0 appelée deepmarks livre un client de signets monétisé par curateurs, et l’équipe Formstr ouvre quatre propositions coordonnées de NIP de calendrier couvrant l’auto-retrait de participants, les événements privés, la récurrence et la planification de rendez-vous décentralisée.

Articles principaux

Amethyst v1.11.0 : calendriers, splits de zap on-chain, et réponses Marmot

Amethyst, le client Nostr pour Android maintenu par Vitor Pamplona, a livré v1.11.0. PR #2994 ajoute une implémentation d’événement de calendrier NIP-52 avec une UI dédiée et un système de rappels, afin que les événements de calendrier soient maintenant rendus dans leur propre catégorie de timeline, séparée de la vue générique long-form kind-30023. PR #3018 étend les zaps Bitcoin on-chain avec le support de split, distribuant une seule transaction Bitcoin à travers plusieurs destinataires selon la balise de zap-split existante, afin qu’un paiement on-chain se comporte de la même façon qu’un split Lightning. PR #2974 ajoute un écran d’historique de transactions on-chain paginé qui fait surface chaque zap réglé avec le statut de confirmation de bloc.

La messagerie de groupe gagne la parité avec le chat un-à-un : PR #2995 ajoute le support des réponses pour les messages de groupe Marmot/MLS, afin que les fils à l’intérieur des groupes chiffrés soient maintenant rendus avec la même UI de référence parent que les notes publiques. PR #2984 durcit la validation des reçus de zap NIP-57 en vérifiant que le fournisseur LNURL correspond au lud16 déclaré du destinataire, fermant une classe de contrefaçon où un LNURL tiers pourrait forger un reçu pour un paiement qui n’a jamais atterri. PR #2968 accepte les dimensions à virgule flottante dans les balises imeta NIP-92, alignant Amethyst avec les clients qui publient des valeurs de densité de pixels fractionnaires depuis des appareils comme l’écran Retina iPhone. La sortie câble également les Payment Targets, un nouveau tip jar multi-rails d’événement remplaçable couvert dans la section protocole ci-dessous.

White Noise v2026.5.22 : push iOS, UX de blocage, et ajout de membres

White Noise, le messager de groupe du protocole Marmot, a livré v2026.5.22 avec les notifications push iOS comme fonctionnalité vedette. PR #673 implémente une Notification Service Extension (NSE) iOS qui déchiffre les messages MLS à l’intérieur du processus d’extension et les fait apparaître comme notifications système, afin que les utilisateurs iPhone n’aient plus besoin que l’app soit au premier plan pour recevoir des messages. La plomberie de token push Android route par le même pipeline backend, avec la NSE par plateforme gardant le chiffré hors du broker.

PR #676 ajoute une UX complète de blocage et de déblocage avec des flux de confirmation et le filtrage de liste de contacts. PR #679 ajoute le bouton « Ajouter des membres » longuement demandé à l’écran d’informations de groupe, fermant une lacune UX où les admins de groupe devaient se rabattre sur les liens de partage. PR #688 introduit un écran de paramètres de notification iOS dédié, et PR #687 câble le partage-via-appui-long pour les médias et messages.

MDK ajoute les messages éphémères NIP-40 à travers les plateformes

Le Marmot Development Kit, le noyau Rust partagé utilisé par White Noise iOS, White Noise Android, et tout futur client Marmot, a fusionné PR #306 pour exposer la validation de messages éphémères et la gestion d’expiration NIP-40 via le pont UniFFI. La PR est la deuxième d’une série en trois parties. iOS et Android partagent maintenant une implémentation Rust de la logique d’expiration ; les règles de timing vivent dans un seul chemin de code audité consommé par les deux plateformes via UniFFI. PR #307 plafonne la longueur stockée des raisons d’échec de welcome et les assainit avant persistance, une passe de durcissement séparée qui complète la gestion d’événement welcome livrée la semaine dernière.

Les messages éphémères dans MLS ne sont pas simplement une affordance UI. La balise d’expiration est publiée avec l’enveloppe de message chiffré, afin qu’un destinataire qui n’ouvre jamais le message ait toujours le chiffré sous-jacent expirer à la couche relais aux côtés de toute copie en cache dans le client récepteur. Avec MDK possédant le chemin de validation, le comportement reste cohérent à travers les clients : toute implémentation Marmot conforme applique la même sémantique d’expiration, donc un client honorant l’expiration tandis qu’un autre met en cache pour toujours cesse d’être un risque de portabilité.

Mostro v0.17.4 : Phase 3 ferme la boucle de caution slashée

Mostro, le protocole d’échange Bitcoin peer-to-peer construit sur Nostr, a livré la Phase 3 de son déploiement de caution anti-abus dans v0.17.4. PR #738 atterrit le flux de paiement pour les cautions slashées, prenant le collatéral confisqué du perdant et le distribuant au gagnant du litige. PR #743 ajoute la Phase 3.5, un message de confirmation de paiement explicite au gagnant afin qu’il sache que les sats slashés se sont réglés, avec l’événement de confirmation arrivant sur la même session Nostr que la résolution du litige. Phase 2, couverte la semaine dernière, a introduit le slashing comme action admin ; Phase 3 est la différence entre menacer d’une pénalité et en appliquer une.

PR #746 permet au démon de finaliser les litiges qui manquent d’une ligne de solveur, un cas limite qui bloquait auparavant la résolution des litiges legacy. PR #748 tolère les taux null dans la réponse /exrates/BTC de Yadio afin qu’une brève panne de Yadio ne casse plus le chemin de conversion fiat de Mostro. PR #745 documente la spécification pour les fournisseurs de prix multi-sources, le travail préparatoire pour supprimer Yadio en tant que point unique de défaillance. Le client mobile Mostro a câblé le chemin de réclamation Phase 3 correspondant dans PR #596.

Applesauce v6.1.0 : relais de lookup et git casts NIP-34

Applesauce, la boîte à outils Nostr modulaire qui alimente Coracle, noStrudel, et la pile de Pablo F7z, a publié v6.1.0 à travers ses packages. La sortie ajoute le support de liste de relais de lookup NIP-51 de première classe : les événements kind 10086 permettent à un utilisateur de signaler « demandez à ces relais si vous voulez me trouver », se situant aux côtés des listes d’outbox NIP-65 comme primitive de découverte. Les applications construites sur applesauce-core reçoivent un observable réactif User.lookupRelays$ et un chargeur correspondant dans applesauce-relay.

Les usines de git-cast NIP-34 arrivent dans applesauce-factory, donnant à chaque client construit avec Applesauce un chemin en une ligne pour publier des annonces de dépôt (kind 30617), des patchs (kind 1617), et des issues (kind 1621). Les propriétés réactives User.favoriteGitRepos$, User.gitAuthors$, et User.graspServers$ permettent aux applications de lister les dépôts suivis d’un utilisateur, les mainteneurs de dépôts, et les serveurs GRASP configurés directement depuis le même objet User. La sortie corrige également les méthodes manuelles du pool qui abandonnaient silencieusement les relais hors ligne dans PR #73.

Notedeck fusionne la negentropy NIP-77 pour les giftwraps et le backfill de fils

Notedeck, le client de bureau multi-colonnes natif de Damus, a fusionné PR #1459 le 25 mai pour câbler la réconciliation negentropy NIP-77 complète dans le chemin d’outbox partagé. La PR ajoute les trames client et relais NIP-77, les sessions negentropy locales au relais, et un traqueur d’historique complet d’outbox qui pilote la réconciliation d’ensemble local et les récupérations d’événements manquants. Les giftwraps de messages obtiennent la réconciliation negentropy afin que les enveloppes de messages privés puissent être récupérées depuis les relais de lecture du compte sélectionné. Les vues de fils ne sont plus plafonnées par la limite de réponse d’abonnement en direct. Dave PNS remplace son implémentation de negentropy locale à Dave par le chemin d’outbox partagé tout en préservant son comportement existant d’historique borné.

Les abonnements en direct et la negentropy utilisent maintenant des filtres séparés. Un flux peut garder une petite requête en direct tout en émettant un filtre negentropy plus large pour réconcilier ce que le relais a déjà. La PR n’active intentionnellement pas la synchronisation negentropy large pour les timelines d’accueil ou de profil, ce qui changerait les caractéristiques de coût au démarrage à froid. La couverture de tests a été ajoutée pour la réconciliation, la livraison de giftwrap, le backfill de fils, la restauration Dave PNS, la commutation de compte, le re-ciblage de relais, les nouvelles tentatives de fetch, et le comportement du relais NIP-77.

Vector v0.4.0 : réécriture vector-core, Tor, NIP-46, MLS negentropy complet, et une surface d’agent MCP

Vector, le messager multiplateforme axé sur la vie privée construit sur les DMs NIP-17 et les groupes Marmot, a livré v0.4.0 comme sa plus grande sortie à ce jour. Le titre est une réécriture de moteur depuis zéro : toute la logique de Vector vit maintenant dans un seul crate découplé, vector-core, partagé entre le bureau, Android, et tout futur client, avec plus de 440 tests dans le noyau lui-même et la coque d’application débarrassée de milliers de lignes. La réécriture est un travail préparatoire pour une CLI Vector, des bots, et des SDKs qui pilotent le même code de protocole que la GUI.

L’intégration Tor livre le routage de trafic en un clic et le support des ponts pour le contournement de censure. Le support multi-comptes atterrit avec un basculeur dans l’app. La connexion par signataire distant arrive via NIP-46 avec l’appairage bunker par QR ou URI collée, afin que les utilisateurs puissent se connecter sans jamais exposer leur nsec. Supprimer-pour-tous fonctionne à la fois dans les DMs NIP-17 et les chats de groupe Marmot, avec Vector gardant la clé de signature éphémère comme une divergence de spécification délibérée que les notes de sortie appellent explicitement : « une déviation des spécifications NIP-17/Marmot traditionnelles pour des contrôles de vie privée utilisateur améliorés ». La clé éphémère retenue donne aux clients Vector une preuve locale qu’une suppression a été sanctionnée par l’expéditeur original, mais cela signifie aussi que tout autre client touchant Vector voit une surface de vérifiabilité de suppression différente de celle des clients NIP-17/Marmot de base.

La synchronisation de groupe MLS est maintenant entièrement réconciliée sur la negentropy NIP-77, la même direction que Notedeck a prise pour les giftwraps et fils cette semaine. L’uploader Blossom bascule à travers plusieurs serveurs, apprend les capacités de chaque serveur, et synchronise la liste de serveurs entre les appareils. Les packs d’emoji personnalisés sont créables par l’utilisateur, partageables, et compatibles entre clients avec d’autres clients Nostr. La mémoire SQLite est passée d’environ 308MB à 5MB. Le panneau emoji s’ouvre depuis le cache disque et les shortcodes de style Discord (:smile:) plus le classement de fréquence Unicode font surface le bon glyphe en premier.

L’ajout le plus novateur est vector-agent, un serveur MCP (Model Context Protocol) qui expose 21 outils afin que les agents IA puissent piloter Vector : envoyer des DMs, gérer des groupes, uploader des fichiers, éditer des profils. C’est le deuxième projet Nostr cette semaine (aux côtés de Shopstr) à livrer une surface MCP, et la première application de classe messager à le faire. Combiné avec AgentNoise (couvert la semaine dernière), le modèle de clients Nostr contrôlés par agent passe d’expériences ponctuelles à une direction de plateforme délibérée.

Cordn fait surface comme messager MLS médié par coordinateur

Cordn (client web à cordn.net, dépôts à Cordn-msg/cordn et Cordn-msg/cordn-web) est un nouveau messager MLS qui prend un tack architectural différent de Marmot. Là où Marmot est entièrement basé sur les relais sans coordinateur privilégié (chaque membre du groupe écrit directement sur les relais et tout relais conforme peut porter le trafic), Cordn introduit un rôle de coordinateur par groupe implémenté comme service ContextVM. Le coordinateur ordonne les commits MLS et gère la distribution des welcomes.

L’argument de Cordn, énoncé sur sa page /why, est que MLS tel que déployé dans les messagers de production « n’est pas sans coordination » et que la « dissémination publique faiblement ordonnée » rend la convergence d’état de groupe « beaucoup plus difficile » sans un point de coordination fort. Une conception médiée par coordinateur fournit un avancement d’époque prévisible et une résolution simplifiée des commits concurrents. Les participants se connectent au coordinateur en utilisant des clés éphémères, donc le coordinateur apprend l’ID du groupe et le timing du trafic de commit mais pas quels pubkeys à long terme sont membres. Toute partie interrogeant les relais pour un groupe Marmot peut déjà voir la même surface : l’activité de groupe par ID de groupe, avec le timing inférable de l’arrivée d’événement. Cordn reconnaît également que « la confiance de disponibilité demeure » avec l’auto-hébergement : un coordinateur auto-hébergé évite la préoccupation de centralisation au niveau opérateur mais introduit un point unique de défaillance pour la vivacité du groupe. Marmot évite ce point unique en laissant l’ordonnancement à MLS lui-même (les époques et messages Commit gèrent l’ordonnancement à l’intérieur du protocole) et en distribuant les événements Welcome via un gift wrap NIP-59, au coût de discipline côté admin : les admins doivent attendre l’accusé de réception du relais d’un Commit avant d’envoyer le Welcome correspondant, et les clients doivent réconcilier les commits concurrents quand la livraison du relais court avec une transition d’état.

Le contraste vaut la peine d’être développé pour toute équipe choisissant une pile de messagerie privée. Marmot échange une certaine complexité d’implémentation pour un déploiement indépendant du relais sans acteur privilégié dans le chemin. Cordn échange une dépendance de disponibilité unique contre un ordonnancement plus serré et un modèle opérationnel plus simple. Les deux projets construisent sur MLS et utilisent Nostr comme couche d’identité et de transport. Le désaccord porte sur où vit le coût de coordination. Les dépôts cordn-msg montrent une cadence de commits régulière avec le service coordinateur implémenté sur ContextVM et la couche MLS construite sur ts-mls.

deepmarks : signets NIP-B0 avec publication monétisée par curateurs

deepmarks-public est un client de référence pour la spécification de signets NIP-B0 proposée (kind 39701), avec une architecture à trois boîtes (curateur, indexeur, visualiseur) et un système de paliers financé par des zaps NIP-57 direct-au-curateur. Le client implémente NIP-B0, NIP-07, NIP-46, NIP-57, NIP-44, NIP-98, NIP-65, et Blossom BUD-01 et BUD-04 pour le stockage de fichiers. Un palier à vie de 21 000 sats convertit les lecteurs payants en destinataires récurrents de zap pour le curateur. Le curateur publie les événements de signets, l’indexeur les enrichit avec des métadonnées lisibles par machine, et le visualiseur rend le fil ; chaque rôle est un service déployable séparé.

Sorties

Amber v6.1.0 GA : sauvegarde chiffrée par compte

Amber est passée de v6.1.0-pre3 à la GA v6.1.0 cette semaine. PR #444 livre la sauvegarde et restauration chiffrées pour la base de données de permissions d’application, et PR #446 sépare la sauvegarde par compte, afin que les utilisateurs avec plusieurs identités Nostr puissent sauvegarder et restaurer chaque ensemble d’octrois d’app indépendamment. Le travail de signature PSBT couvert la semaine dernière est dans la coupe GA.

Citrine : abonnements par relais et prévention de fuite d’URL onion

Citrine, le relais personnel sur appareil qui accompagne Amethyst, a livré deux correctifs ce cycle. PR #157 passe d’un abonnement global unique à des abonnements étiquetés par relais, afin que deux relais sources partageant un filtre kinds: [1] n’entrent plus en collision côté agrégateur. PR #162 filtre les URLs de relais onion quand le proxy Tor sortant est désactivé, empêchant les adresses onion de fuir sur le chemin de routage clearnet.

Angor v0.2.27 et v0.2.28 : fiabilité de relais et reconnexion Boltz

Angor a livré v0.2.27 et v0.2.28. PR #874 corrige un bug de déduplication de relais où un seul relais était connecté à la fois, une régression qui dégradait silencieusement la fiabilité pour les projets avec plusieurs points de terminaison de relais. PR #876 ajoute la logique de reconnexion WebSocket pour la surveillance de submarine-swap Boltz, afin qu’une brève déconnexion ne laisse plus un swap dans un état inconnu.

Nostrord v1.1.0 : zaps NIP-57 et distinction de rôle NIP-29

Nostrord a publié v1.1.0 avec le support des zaps Lightning NIP-57 pour les messages et profils (PR #98) et une distinction appropriée dans le fil d’activité entre les changements de rôle NIP-29 et les ajouts de membres (PR #92), qui se rendaient auparavant de manière identique et obscurcissaient qui avait été promu par rapport à qui avait été invité.

ぬるぬる v1.5.x : keystore MLS SQLCipher et rattrapage d’époque

ぬるぬる (nurunuru, par tami1A84), un client Nostr en langue japonaise qui implémente la messagerie de groupe MLS (kind 443) aux côtés de NIP-44, la recherche avancée NIP-50, NIP-55, et NIP-70, a livré cinq sorties cette semaine. PR #184 introduit le chiffrement SQLCipher pour le keystore MLS dans la couche rust-engine. PR #187 et PR #188 étendent SQLCipher à Android et iOS respectivement, avec une étape de purge du texte-clair legacy et des gardes CI. PR #189 et PR #191 ajoutent le rattrapage d’époque de pair MLS avec un cache de replay et une bannière de récupération sur les deux plateformes, afin qu’un client qui prend du retard sur les commits de groupe puisse récupérer sans perdre la conversation. ぬるぬる est un client Marmot construit sur mdk-core, mdk-sqlite-storage, et mdk-storage-traits de marmot-protocol/mdk, donc le travail SQLCipher et de rattrapage d’époque atterrit à l’intérieur du même runtime MDK que White Noise utilise.

Bitcredit Core v0.5.10 : correctif de propagation de bloc ancré à Nostr

Bitcredit Core a publié v0.5.10 avec un correctif pour un champ Nostr-node-id manquant pendant la propagation de bloc, qui cassait les flux de création d’entreprise qui incluaient l’upload d’identité. Bitcredit est un protocole e-bill qui utilise les identités Nostr comme racine de confiance pour les événements de propagation d’entreprise et de facture.

Changements non publiés

Jumble a ouvert PR #797 pour la connexion Google via le signataire à seuil Pomegranate, permettant à un utilisateur de diviser sa clé Nostr entre plusieurs parties afin qu’aucun signataire unique ne détienne le secret complet. C’est un pas significatif au-delà des flux de bunker ou d’import de nsec : un utilisateur peut récupérer son compte même si une partie signataire est compromise, sans que cette partie ne détienne jamais la clé privée complète.

Shopstr a ouvert PR #492 initialisant un serveur MCP (Model Context Protocol), avec PR #494 construisant l’infrastructure de support (fetch de relais, analyseurs, validation, erreurs, déduplication, journalisation d’audit) et PR #472 ajoutant une liste blanche de relais pour le gestionnaire de relais MCP. Cela fait de Shopstr le premier marketplace Nostr à s’exposer comme serveur MCP, afin que les agents IA puissent parcourir et agir sur les annonces NIP-99 comme un outil structuré.

Keydex, le coffre de partage de secret Shamir, a ouvert une migration substantielle dans PR #226 déplaçant les kinds personnalisés 1337-1345 vers la plage 713-721, aux côtés de PR #239 ajoutant AEAD sur les parts Shamir et PR #234 migrant vers l’arithmétique GF256. La migration de plage de kinds aligne Keydex avec la façon dont le dépôt NIPs alloue les kinds personnalisés, s’éloignant d’une plage auto-revendiquée.

Mill (nostr-mill) est une nouvelle UI de signataire Nostr drop-in de OceanSlim (mainteneur du relais Go grain), livrée comme Web Component en une seule balise script sur npm et jsDelivr. Une seule balise <script> donne à une app web les six points d’entrée de signataire communs derrière une UI unifiée : extension de navigateur NIP-07, bunker NIP-46 (URL collée ou appairage QR avec relais spécifiables par l’utilisateur, inhabituel parmi les intégrations bunker in-page), Amber NIP-55 via les intents Android, nsec chiffrée stockée dans sessionStorage via AES-256-GCM avec PBKDF2, npub en lecture seule, et génération de paire de clés dans le navigateur. Le composant est thémable via 29 propriétés CSS personnalisées portées au Shadow DOM et expose une petite API suivie en SemVer (MILL.open, événements mill:connected / mill:disconnected, exports thème nommés). La motivation du mainteneur est que les flux de connexion bunker ont été réimplémentés une app web à la fois à travers Nostr. Consolider sur un composant partagé permet aux clients de converger sur la façon dont l’UX du signataire devrait se comporter, et transforme les flux optionnels (comme la connexion par clé déléguée via signataires à seuil, reflétant la connexion Google basée sur Pomegranate de Wisp couverte ci-dessus) en une surface réutilisable que toute app peut déposer. Mill est à npm v1.5.0, mainteneur unique, stade alpha, avec grain comme premier intégrateur planifié.

moStard, un fork Monero-first de noStrudel par roguehashrate, a atteint v1.0.1 cette semaine avec un ensemble de fonctionnalités réduit et une identité à thème Monero superposée sur la même pile Applesauce + worker-relay. Le travail de cette semaine a atterri le rendu pour les événements d’application logicielle kind 32267 de Zapstore (cartes d’incorporation dans la timeline montrant nom d’app, icône, captures d’écran, plateforme, licence, et un lien de lancement vers zapstore.dev/apps/<d-tag>), les sondages via kind 20 et kind 21, les pourboires basés sur les Payment Targets NIP-A3 avec codes QR par méthode, le rendu markdown dans les notes, le support du sélecteur de GIF pour les claviers GIF externes, et les correctifs d’appairage de signataire Amber. Le cadrage Monero s’étend au flux de pourboire : les entrées NIP-A3 payto pour les adresses monero obtiennent des boutons de première classe dans la même UI aux côtés de lightning et bitcoin. Le client est mono-mainteneur et en stade alpha, mais le travail du 27 mai montre un constructeur tirant NIP-A3 des annonces de spécification de protocole de cette semaine directement dans un fork livrable en quelques jours.

Mises à jour NIP et travail de spécification de protocole

Pile NIP de calendrier : quatre propositions de l’équipe Formstr

Ix2 (@geralt-debugs) a ouvert quatre PRs NIP coordonnées le 17 mai, toutes référençant l’implémentation calendar.formstr.app livrée déjà sous le même auteur. PR #2350 propose kind 84 comme événement généralisé « auto-retrait de participant » : un participant balisé sur tout événement peut publier un kind 84 référençant l’original via des balises e, a, et k pour signaler l’opt-out. Les relais doivent valider que le signataire du kind 84 apparaît dans une balise p de l’événement référencé avant d’honorer le retrait, et une suppression kind 5 a toujours priorité. La PR généralise un modèle qui n’était auparavant décrit qu’à l’intérieur du contexte du calendrier NIP-52, donc kind 84 devient la façon standard pour les non-auteurs de se retirer de tout événement participant.

PR #2351 est la fondation de la pile de calendrier : NIP-52E pour les événements de calendrier privés (kinds 32678 basé sur le temps, 32681 événement de jour, 32123 liste de calendrier privée, 31926 liste occupée, 1052 gift wrap, 52 rumeur) et NIP-52R pour les événements récurrents. Au cœur architectural se trouve le modèle de clé de visualisation : une paire de clés générée aléatoirement chiffre le contenu de l’événement avec NIP-44, et la moitié secrète (encodée bech32 comme nsec) est gift-wrapped à chaque participant. Le signataire ne détient que la balise d publique ; tout le reste vit dans le content chiffré. Découpler le chiffrement de contenu de l’identité de cette manière signifie qu’éditer un événement ne nécessite pas de re-clé des destinataires. NIP-52R définit deux balises optionnelles sur les kinds 31923 et 31922 existants pour déclarer la récurrence en utilisant des valeurs RRULE RFC 5545 brutes, avec D index de jour devenant optionnel quand RRULE est présent. La forward secrecy est explicitement absente : une clé de visualisation fuite révèle toutes les versions passées et futures de l’événement sous la même balise d.

PR #2352 construit sur NIP-52E avec une spécification de planification de rendez-vous décentralisée que la description de la PR appelle « une alternative drop-in à Calendly/Cal.com sans intermédiaire central. » Kind 31927 annonce une page de planification avec des fenêtres de disponibilité chiffrées ; kind 32680 est un enregistrement de récupération auto-chiffré côté hôte pour la clé de visualisation ; kinds 1057 et 1058 sont la demande et réponse de réservation gift-wrapped. Le mécanisme astucieux : le réservateur génère à la fois la balise d et la clé de visualisation pour le futur événement privé avant d’envoyer la demande, afin que le réservateur puisse ajouter le rendez-vous à son propre calendrier immédiatement avec la bonne clé, et l’hôte n’a jamais à faire l’aller-retour d’une clé. Les réponses de réservation portent une balise status non chiffrée sur l’enveloppe externe afin que les relais puissent filtrer sans déchiffrer.

Une implémentation de référence est déjà en direct sur calendar.formstr.app et comme l’application Android Calendar sur Zapstore. PR #2351 ferme PR #2027 en sa faveur, consolidant une proposition antérieure de calendrier privé qui était ouverte depuis le début de l’année.

Payment Targets et Silent Payments

Deux propositions NIP supplémentaires ont circulé cette semaine dans des documents long-form kind:30023.

Une proposition Payment Targets (NIP-A3 / payto) définit un événement remplaçable kind 10133 portant une ou plusieurs balises ["payto", "<type>", "<authority>"] qui correspondent aux URIs RFC 8905 payto:. Les types supportés incluent bitcoin, lightning, ethereum, monero, nano, cashme, revolut, et venmo. L’intention est de standardiser un tip jar multi-rails qui complète (ne remplace pas) les zaps NIP-57 basés sur lud16. Amethyst v1.11.0 est le premier implémenteur ; les PRs fusionnées #2953 et #3009 livrent la surface d’abonnement et d’observation, et PR #3011 câble l’UI pour PaymentTargetsEvent.

Deux propositions Silent Payments concurrentes sont tombées de différents auteurs. La première variante dérive les clés de scan et de dépense de silent-payment BIP-352 de nsec via des tweaks additifs publics, afin que tout expéditeur puisse construire une adresse sp1q... depuis un npub sans configuration. L’avertissement de l’auteur est explicite dans la spécification : « bscan et bspend DOIVENT être traités avec exactement le même soin que nsec », car la clé de scan révèle la nsec. Une deuxième variante prend l’approche inverse, ajoutant un champ sp_address aux métadonnées de profil kind 0 contenant une adresse de silent-payment BIP-352 standard dont les clés sont gardées indépendantes de l’identité Nostr. La variante deux est structurellement plus sûre. Les deux propositions ont attiré un fil de revue réfléchi ; erskingardner (lead Marmot) a posté un commentaire détaillé sur le gist trbouma suivant la proposition. Sa préoccupation centrale est que la variante 1 dérive la clé privée de scan de nsec plus un tweak calculable publiquement, ce qui signifie que quiconque détient la clé de scan (y compris un service de scan tiers auquel l’utilisateur doit déléguer en pratique) peut récupérer la nsec complète en soustrayant ce tweak. La même clé qui vous permet de scanner les paiements entrants vous permet aussi de voler votre identité et tous les fonds qui en dérivent.

Côté git-over-Nostr NIP-34, hzrd149 a publié 2 patchs à schemata. gitworkshop.dev lui-même a attiré deux rapports d’issue : l’un signalant que les sessions de connexion sont perdues au rafraîchissement de page lors de l’utilisation d’un signataire à distance NIP-46, l’autre demandant un style de lien distinct dans les aperçus README.

Six ans de mais Nostr

La dernière newsletter de mai 2026 prend du recul par rapport aux sorties de la semaine pour parcourir le mois de mai à travers l’histoire de Nostr. Chaque année avait un centre de gravité différent : 2021 était un seul commit, 2022 était la formation du dépôt NIPs lui-même, 2023 était l’explosion de la spécification de protocole, 2024 était le cycle de consolidation, 2025 était quand negentropy a été fusionné et le Notedeck de Damus est passé en Bêta, et 2026 est le mois couvert dans ce numéro et les trois précédents.

Mai 2021

Nostr avait six mois. Le seul code Nostr vivait dans fiatjaf/nostr et le mois entier a produit exactement un commit, mais ce commit est devenu l’une des parties les plus utilisées du protocole. Le 22 mai, fiatjaf a réutilisé NIP-02 comme NIP de liste de contacts. Le message de commit se lit : « repurpose NIP-02 and add NIP authorship », et le crédit explicite va à PR #16 par arcbtc (Ben Arc de LNbits), ouverte le 9 février et fermée la veille du jour où fiatjaf a intégré l’idée dans NIP-02. Le pitch d’arcbtc était petit : un kind pour « envoyer la liste des followers aux relais » qui serait « utile pour restaurer les comptes et recommander des clés publiques à suivre ». fiatjaf l’a généralisé en un seul événement kind:3 dont les balises servent à trois fins à la fois. Elles sont une liste de suivis (le graphe social), un stockage de petnames (surnoms locaux pour les amis), et une source de recommandation de relais (quels relais un suivi utilise). Le même événement, remplaçable par auteur, est devenu la réponse canonique à « qui suit cette personne », « comment les appellent-ils », et « où lisent-ils ». Chaque client construit dans les cinq années suivantes lit kind:3. La convention ajoutée dans le même commit, que chaque NIP nomme son auteur, est la raison pour laquelle chaque spécification a maintenant des mentions.

Mai 2022

Le mois où le dépôt NIPs est devenu un projet communautaire. Le 1er mai, fiatjaf a migré les spécifications de fiatjaf/nostr dans un dépôt dédié nostr-protocol/nips et le 2 mai a ajouté des critères d’acceptation formels. Deux jours plus tard, Robert C. Martin (Uncle Bob) a ouvert PR #1, la première pull request externe, proposant des conventions de fil pour les balises e et p. La PR était originellement numérotée NIP-13, puis renommée NIP-10 pour faire place à la preuve de travail. Trois des six premiers NIPs sont d’Uncle Bob : NIP-10 (marqueurs de fil), NIP-14 (la balise Subject), et le commit du 21 mai qui a fixé kind:1 comme kind canonique de note de texte court. Le 5 mai, William Casarin a fait ses premiers commits NIP : NIP-13 Proof of Work et l’événement recommend-relay kind:2. Le lendemain, fiatjaf a publié NIP-07 window.nostr, vingt lignes de markdown qui définissaient l’interface de signataire d’extension de navigateur encore utilisée aujourd’hui. L’avertissement CORS de NIP-05 par David A. Harding et le filter.limit de NIP-01 ont atterri la même semaine. nostr-tools a livré son premier build ESM importable dans le navigateur le 8 mai. Semisol a rédigé NIP-15 (End Of Stored Events) et NIP-16 (plages de kinds d’événements) en fin de mois, les documents qui gouvernent encore le comportement des relais aujourd’hui.

Mai 2023

L’explosion de la spécification de protocole. Soixante-quatre PRs NIP ont été ouvertes ce mois-là, avec plusieurs des propositions qui ont défini la surface de Nostr pour les deux années suivantes atterrissant toutes en 31 jours, et la plus grande annonce de financement que Nostr ait jamais reçue a atterri le 4 mai avec la subvention OpenSats de 10 millions de dollars de #startsmall de Jack Dorsey, l’argent qui a soutenu chaque vague de subvention Nostr depuis. NIP-47 (Nostr Wallet Connect) a été fusionné le 2 mai, amenant la spécification wallet-connect d’Alby dans le protocole principal. Deux jours plus tard, Vitor Pamplona a proposé NIP-53 Live Activities avec des salles kind:30311 et messages de chat kind:1311, la fondation pour chaque surface de livestream Nostr qui a suivi. Pablo Fernandez a ouvert NIP-84 Highlights le 5 mai et NIP-89 Recommended Application Handlers le 14 mai. v0l (Kieran Babich, auteur de Snort) a proposé NIP-98 HTTP Auth le 8 mai, la primitive d’authentification dont NIP-96 et Blossom ont tous deux dépendu plus tard. Jonathan Staab a proposé NIP-32 Labels le 15 mai, et NIP-30 Custom Emoji a été fusionné le même jour. Arthur Franca a proposé NIP-96 HTTP File Storage Integration le 21 mai. Deux jours plus tard, Vitor a ajouté les splits de zap à NIP-57 et verbiricha a ajouté les brouillons long-form kind:30024 à NIP-23, la spécification qui est devenue la fondation pour les workflows modernes de rédaction long-form Nostr dans Habla, YakiHonne, et Highlighter. fiatjaf a proposé NIP-29 Simple Groups le 25 mai.

Mai 2024

Le cycle de consolidation. Moins de propositions tape-à-l’œil, plus de livraison. NIP-54 Decentralized Wikis a fusionné le 2 mai avec des articles kind:30818 et des balises d normalisées en casse. Trois jours plus tard, NIP-56 a été étendu afin que les rapports d’abus puissent signaler des menaces numériques (malware, phishing) aux côtés des catégories de contenu uniquement. Le 6 mai, les réactions NIP-25 ont été simplifiées pour cesser d’inclure le fil de réponse entier comme balises e. Arthur Franca a proposé NIP-22 Comment le 12 mai, introduisant kind:1111 afin que les réponses à des événements non-kind:1 (articles, fichiers, produits) obtiennent un moyen structuré de faire des fils. Le 19 mai, fiatjaf a refondu NIP-46 pour abandonner NIP-04 entièrement et faire passer tout le trafic bunker au chiffrement NIP-44, le mouvement de dépréciation qui a façonné chaque implémentation bunker depuis. Le 20 mai, NIP-71 Video Events a fusionné avec kind:21 et kind:22, et NIP-10 a ajouté l’argument pubkey optionnel sur les balises e afin que les clients puissent résoudre les auteurs de fil sans d’abord récupérer l’événement référencé. NIP-35 Torrents de Kieran Walsh a fusionné le 22 mai, et le 24 mai le README des NIPs a référencé pour la première fois CIP-01 comme proposition hors dépôt, signalant le début du modèle « NIPs comme l’un de plusieurs lieux de proposition ». Le 25 mai, une PR de nettoyage a supprimé la balise aes-256-gcm de NIP-71 avant que les implémentations en aval ne la figent. NIP-96 a ajouté list files et abandonné l’exigence de transformation le 27 mai. Le 28 mai, Jonathan Staab a proposé de relever la barre d’acceptation des NIP.

Mai 2025

Le mois où NIP-77 (Negentropy Syncing) a fusionné le 27 mai, la spécification de fiatjaf et Doug Hoyte pour le protocole câble qui remplace les filtres REQ à force brute par un calcul de différence à coût logarithmique. C’était la même negentropy que strfry avait livrée deux ans plus tôt comme fonctionnalité côté relais, maintenant formalisée comme protocole client-relais, et l’entrée README a atterri le même jour. La semaine précédente, NIP-23 long-form a défini comment les documents HTML s’associent aux entités Nostr via une balise <link> le 24 mai, la primitive canonical-web-copy. NIP-25 a ajouté les indices de relais cibles de réaction le 22 mai et a abandonné la recommandation emoji-vers-like/dislike, traitant les emojis comme des unités sémantiques distinctes. NIP-52 a été simplifié le 14 mai pour se concentrer sur les kinds que les clients livraient en production, le trim qui a rendu les extensions de calendrier Formstr d’un an plus tard plus propres à greffer. Le 9 mai, les Follow Packs (kind 39089 listes de suivi curatées) et les Favorite Relays (une nouvelle liste remplaçable sous NIP-51) sont entrés dans le README le même jour. L’arc du Protocole Marmot n’avait pas encore commencé : seul le dépôt whitenoise-rs existait (premier commit 9 septembre 2024), et mai 2025 était sa phase de prototype Svelte+Tauri, avec le commit du 14 mai supprimant le code spécifique à Tauri alors que le projet pivotait vers son architecture actuelle. Le noyau Rust MDK dédié (12 septembre 2025), le dépôt de spécification Marmot (19 septembre 2025), et l’UI Flutter (2 décembre 2025) ont tous suivi cette année-là.

Mai 2026

Le mois couvert dans Newsletter #21, #22, #23, et ce numéro. Le fil déterminant est que MLS-on-Nostr atteint la production multi-client : MDK 0.8.0 a livré les primitives leaf-index MIP-05 et les key packages adressables, suivi par PR #306 ajoutant la validation de messages éphémères NIP-40 sur iOS et Android via une surface UniFFI partagée. White Noise v2026.5.22+25 a livré le push iOS via une Notification Service Extension qui déchiffre le chiffré MLS à l’intérieur du processus d’extension afin que le broker ne voie jamais le texte-clair, et deux nouveaux clients Marmot sont apparus : Scramble (un client .NET/Avalonia de bureau et Android avec slots KeyPackage multi-appareils) et Cordn (une architecture MLS alternative utilisant un coordinateur par groupe sur ContextVM). Angor a migré sa messagerie chiffrée de NIP-04 à NIP-44 dans PR #860, fermant l’arc de dépréciation qui s’est ouvert avec la proposition NIP-44 de Paul Miller en mai 2023. L’équipe Formstr a ouvert la plus grande soumission NIP coordonnée en mémoire récente le 17 mai, avec PR #2350 pour l’auto-retrait de participants, PR #2351 pour les événements de calendrier privés et la récurrence (NIP-52E et NIP-52R), et PR #2352 pour la planification de rendez-vous décentralisée, tous avec calendar.formstr.app livrant déjà l’implémentation de référence. Amethyst v1.11.0 a rendu les événements de calendrier NIP-52 dans leur propre catégorie de timeline et a livré les splits de zap Bitcoin on-chain.

Si vous voulez discuter, DM-nous sur Nostr.