Nostr Compass #16 | Nostr Compass

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Amethyst livre v1.07.0 avec notes épinglées, gestion des relays via NIP-86, et support NIP-62 Request to Vanish. NIP-5A (Static Websites) fusionne dans le dépôt NIPs, définissant la manière d’héberger des sites web sous des paires de clés Nostr en utilisant le stockage Blossom. Flotilla livre v1.7.0 avec salons vocaux, connexion email/mot de passe et DMs proof-of-work. White Noise corrige le churn relay dans v2026.3.23, nospeak lance sa 1.0.0 comme messagerie chiffrée sans inscription. Nymchat adopte Marmot pour les groupes MLS chiffrés avec repli NIP-17. Calendar by Form* atteint v1.0.0 avec listes de calendriers privées et import ICS, Amber ajoute la récupération par phrase mnémonique et une liste blanche d’auth relay NIP-42, et la spécification Marmot déplace les KeyPackages vers des événements adressables tout en resserrant le formatage des notifications push MIP-05.

Actualités

Amethyst ships pinned notes, relay management, and Request to Vanish

Amethyst, le client Android maintenu par vitorpamplona, a livré six versions en trois jours, de v1.07.0 à v1.07.5. L’ensemble principal de fonctionnalités couvre six surfaces protocolaires : notes épinglées, écran dédié aux sondages, support NIP-62 (Request to Vanish) pour demander la suppression complète d’événements aux relays, NIP-86 (Relay Management API) depuis le client, évaluations NIP-66 (Relay Discovery and Liveness Monitoring) sur l’écran d’information relay, et affichage des informations de membres NIP-43 (Relay Access Metadata and Requests).

NIP-86 définit une interface JSON-RPC pour les opérateurs de relays, permettant aux clients d’envoyer des commandes d’administration comme bannir des pubkeys, autoriser des pubkeys et lister les utilisateurs bannis via une API standardisée. Amethyst expose désormais cela directement dans son interface de gestion relay, de sorte que les utilisateurs qui exploitent leurs propres relays peuvent les administrer depuis le même client qu’ils utilisent pour publier. PR #2039 remplace l’ancien dialogue d’entrée hexadécimale pour les pubkeys bannies et autorisées par un dialogue interactif de recherche d’utilisateurs.

v1.07.2 a ajouté les téléversements du clavier GIF et corrigé une régression de signature où les réponses de rejet d’Amber étaient mal interprétées parce que les anciennes versions d’Amber renvoyaient une chaîne vide pour le champ rejected (PR #2042). v1.07.5 corrige un crash de téléversement d’images. Les versions v1.06.2 et v1.06.3 plus tôt dans la semaine ont ajouté un sélecteur de type de sondage pour simple ou choix multiples, le drag-to-seek sur les barres de progression vidéo, et des améliorations pour la publication anonyme.

NIP-5A merges, bringing static websites to Nostr

NIP-5A (Static Websites) a fusionné via PR #1538, définissant la manière d’héberger des sites web statiques sous des paires de clés Nostr. La spécification utilise deux kinds d’événements : le kind 15128 pour un site racine, un par pubkey, et le kind 35128 pour des sites nommés identifiés par un tag d. Chaque manifeste associe des chemins d’URL à des hachages SHA256, avec des tags server optionnels pointant vers des hôtes de stockage Blossom où vivent les fichiers réels.

Le modèle d’hébergement fonctionne ainsi : un auteur de site construit un site statique, téléverse les fichiers sur un ou plusieurs serveurs Blossom, puis publie un événement de manifeste signé qui associe les chemins à des hachages de contenu. Un serveur hôte reçoit les requêtes web, résout la pubkey de l’auteur depuis le sous-domaine, récupère le manifeste depuis la liste de relays NIP-65 de l’auteur, puis sert les fichiers en téléchargeant les blobs correspondants depuis Blossom. Le site reste sous le contrôle de l’auteur parce que seule cette clé peut signer un manifeste mis à jour. Le serveur hôte est remplaçable car tout serveur qui comprend NIP-5A peut servir le même site à partir du même manifeste.

La spécification s’appuie sur une infrastructure déjà existante. nsite, l’implémentation de référence de serveur hôte NIP-5A construite par lez, et nsite-manager, l’interface de gestion de hzrd149, fonctionnaient déjà avant la fusion du NIP. La fusion rend officiels les kinds d’événements et les règles de résolution d’URL, donnant ainsi aux deuxièmes et troisièmes implémentations une cible stable.

White Noise fixes relay churn and expands client controls

White Noise, la messagerie privée construite sur le protocole Marmot, a livré v2026.3.23 le 25 mars. Le travail principal concerne la stabilité relay. La connexion n’attend plus la publication de chaque liste de relays avant d’avancer, parce que la publication des listes utilise maintenant une logique de quorum et retente le reste en arrière-plan. Les fetches et publications ponctuels utilisent des sessions relay éphémères ciblées au lieu de rester dans le pool longue durée, les sessions restaurées récupèrent leur chemin de refresh de groupe après le démarrage, et l’application expose désormais des diagnostics relay et l’inspection d’état relay via PR #495 et PR #502.

La même version change aussi le comportement des conversations. PR #468 ajoute le threading de réponses NIP-C7 avec tags q et références nostr:nevent, PR #471 et PR #512 laissent les messages supprimés visibles comme placeholders supprimés au lieu de les retirer silencieusement, PR #478 ajoute un flux de signalement de bug in-app utilisant des rapports anonymes NIP-44 (Encrypted Payloads), et PR #486 ajoute un chat de support directement dans le client. Les contrôles de messages côté utilisateur ont aussi atterri dans la même fenêtre : PR #532 archive les chats, PR #541 ajoute mute et unmute avec durées configurables, et PR #535 ajoute les paramètres de notification. PR #539 est un travail préparatoire sur l’enregistrement push, connectant l’inscription APNs sur iOS et la détection Play Services sur Android pour que l’enregistrement puisse être construit par-dessus. Côté backend, le MDK (Marmot Development Kit) a ajouté les primitives de notifications push MIP-05 et un constructeur de requêtes de notification (PR #235, PR #238), tandis que whitenoise-rs a ajouté la persistance de l’enregistrement des notifications push (PR #688), des correctifs d’annulation de tâches en arrière-plan (PR #696), et la récupération des key packages au démarrage (PR #693).

Nostr VPN reaches v0.3.0 with roster sync and invite v2

Suite à la couverture du lancement la semaine dernière, nostr-vpn, le VPN pair à pair qui utilise les relays Nostr pour le signalement et WireGuard pour les tunnels chiffrés, a continué son rythme rapide de versions jusqu’à v0.3.3. Ce changement de version apporte deux breaking changes : le format d’invitation passe en v2 (0.3.0 peut toujours importer les invitations v1, mais les anciennes builds ne peuvent pas importer les invitations v2), et une synchronisation de roster signée par administrateur a été ajoutée au protocole de signalement. Les pairs de versions mixtes peuvent encore se connecter au niveau du mesh, mais les plus anciens ne participeront pas à la synchronisation du roster.

L’ajout de la synchronisation du roster amorce le passage vers un réseau géré. Un nœud administrateur peut maintenant pousser les changements d’appartenance à tous les pairs, de sorte qu’ajouter ou retirer un appareil du mesh n’exige plus que chaque pair mette à jour sa configuration manuellement. Les versions v0.2.x durant la même semaine ont traité des problèmes de déploiement précis : v0.2.22 à v0.2.28 ont corrigé la gestion des services Windows, ajouté les scripts de build Android, et affiné le flux d’appairage LAN.

nospeak launches as a 1.0 private messenger

nospeak, une messagerie privée construite sur Nostr, a livré sa version 1.0.0 le 27 mars. Le projet inclut des conversations individuelles et de groupe, la gestion des contacts, et une architecture auto-hébergeable. Les chats individuels utilisent NIP-17 (Private Direct Messages), qui combine NIP-59 (Gift Wrap) avec NIP-44 (Encrypted Payloads) pour masquer l’expéditeur aux relays. Pour les médias, les fichiers sont chiffrés côté client avec AES-256-GCM avant téléversement vers des serveurs Blossom. La version est également livrée sous forme d’image conteneur pour l’auto-hébergement.

Flotilla, le client de type Discord de hodlbod pour NIP-29 (Relay-based Groups) construit autour du modèle « relays as groups », a livré v1.7.0 et v1.7.1 les 30 et 31 mars. La fonctionnalité phare est l’ajout de salons vocaux, contribuée par mplorentz. Les utilisateurs peuvent maintenant rejoindre des appels vocaux à l’intérieur des canaux de groupe, avec un dialogue d’entrée (PR #109) qui leur permet de sélectionner un périphérique d’entrée audio et de choisir s’ils veulent rejoindre l’appel vocal ou seulement voir le chat texte. Le dialogue résout un problème UX de l’itération précédente : entrer dans un salon vocal activait auparavant le microphone de force, même si l’utilisateur voulait seulement lire les messages ou vérifier les paramètres du salon.

La même version ajoute la connexion email/mot de passe comme alternative à l’authentification par clés Nostr, le proof-of-work sur les DMs, l’édition des DMs, la refonte de l’onboarding relay et des paramètres, la détection du support Blossom via supported_nips, de meilleurs badges de notification, un fallback de notifications push Android, et des correctifs de téléversement de fichiers sur Android. v1.7.1 suit avec un correctif du fallback d’enregistrement pomade lors de l’utilisation d’un signataire hors ligne.

Hodlbod construit aussi Caravel, un gestionnaire d’hébergement et tableau de bord pour les relays zooid, qui a enregistré 40 commits cette semaine en début de développement.

Nymchat ships Marmot-powered group chats

Nymchat (également connu sous le nom de NYM, Nostr Ynstant Messenger), le client de chat éphémère ponté avec Bitchat, a annoncé que tous les nouveaux chats de groupe utilisent désormais le protocole Marmot pour la messagerie MLS chiffrée. L’intégration utilise les kinds 443, 444 et 445 pour les key packages, les welcome messages et les messages de groupe, apportant forward secrecy, sécurité post-compromission et fuite de métadonnées nulle. Si un destinataire ne peut pas utiliser MLS, Nymchat se replie sur son ancien chemin de chat de groupe NIP-17 (Private Direct Messages), toujours chiffré de bout en bout mais dépourvu des propriétés d’arbre à cliquet de MLS.

Les séries v3.55 et v3.56 de cette semaine se sont concentrées sur les cas limites des chats de groupe : chargement sur de nouveaux appareils, comportement de départ, routage des notifications et compteurs de non-lu. Le même cycle a aussi corrigé une vulnérabilité XSS due à du HTML non échappé et ajouté le blocage de mots-clés et phrases étendu aux surnoms d’utilisateurs. Nymchat devient ainsi un client Marmot de plus rejoignant White Noise et OpenChat, élargissant l’ensemble des applications capables d’échanger des messages de groupe MLS chiffrés sur le même protocole.

Versions

Calendar by Form* v1.0.0

Calendar by Form*, l’application de calendrier décentralisée construite sur NIP-52 (Calendar Events), a atteint v1.0.0 le 29 mars. La version ajoute des listes de calendriers privées utilisant des événements Nostr chiffrés (kind 32123) avec auto-chiffrement NIP-44 (Encrypted Payloads), de sorte que les utilisateurs puissent organiser leurs événements en collections privées sans exposer le regroupement aux relays. La même version ajoute la gestion des intentions ICS pour importer des données de calendrier depuis d’autres applications et des demandes d’invitation pour partager des événements entre utilisateurs.

Amber v5.0.2 through v5.0.4

Amber, l’application signataire NIP-55 (Android Signer Application), a livré trois point releases : v5.0.2, v5.0.3, et v5.0.4. L’ajout le plus visible est la connexion par phrase mnémonique de récupération (PR #358), qui permet aux utilisateurs de restaurer leur signataire depuis une seed phrase BIP39 au lieu d’exiger la chaîne brute nsec ou ncryptsec. PR #357 ajoute une liste blanche d’auth relay NIP-42, afin que les utilisateurs puissent restreindre les relays autorisés à demander une authentification client. PR #353 ajoute la sélection du périmètre de chiffrement pour les permissions de déchiffrement, permettant d’accorder un accès de déchiffrement NIP-04-only ou NIP-44-only au lieu d’une permission globale. v5.0.4 corrige un bug où le rejet ne respectait pas les permissions chiffrées et déchiffrées scopées et améliore les performances lors de la réception de multiples demandes bunker.

Aegis v0.4.0

Aegis, le signataire cross-platform, a livré v0.4.0 le 26 mars. La version ajoute des modes d’autorisation Full et Selective dans les Settings et corrige plusieurs problèmes de scan QR. Les commits suivants d4f799f, 3313af9, 3b214e4, et e4f40b6 prolongent le même travail avec des contrôles de sélection par lots, des statistiques réutilisables de sélection en lot, des APIs de sélection set-all-groups, et des statistiques d’utilisation par permission sur la page des permissions applicatives.

Schemata v0.2.7 through v0.3.0

Schemata, l’ensemble de définitions JSON Schema pour valider les kinds d’événements Nostr, a livré quatre versions de v0.2.7 à v0.3.0 avec 21 PRs fusionnées. La version v0.3.0 apporte des correctifs de cohérence de patterns à travers les URLs relay, les hex IDs, les types MIME et les chaînes BOLT-11 (PR #126), une centralisation des patterns d’URLs relay (PR #117), des schémas de types de base bech32 NIP-19 (PR #118), et la validation des événements spell kind 777 (PR #125). Le pipeline de version publie désormais une note kind 1 sur Nostr à chaque release (PR #120), de sorte que le projet s’annonce via le protocole qu’il valide. Schemata supporte maintenant une douzaine de langages au-delà du paquet canonique JS/TS : Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby et C.

Aux côtés de Schemata, l’équipe a publié schemata-codegen, un générateur de code expérimental qui prend une autre approche du même problème de validation. Là où les paquets validateurs de Schemata exigent une dépendance runtime à JSON Schema, schemata-codegen convertit directement les schémas en constructions natives typées selon le langage ciblé (tuples de tags typés, interfaces de kind, validateurs runtime), supprimant le besoin d’une bibliothèque de validation à l’exécution. Le document codegen-vs-validators comparison expose dans quels cas chaque approche convient.

BigBrotr v6.5.0 through v6.5.4

BigBrotr, la plateforme d’analytique de relays, a livré cinq versions de v6.5.0 à v6.5.4. La version v6.5.0 centralise la validation des URLs relay avec une fonction factory parse_relay_url() et ajoute une vérification de longueur d’URL et une sanitation des chemins. L’infrastructure de monitoring a aussi reçu des correctifs : les événements d’annonce incluent maintenant des tags de localisation geohash (en suivant NIP-52), et une protection par timeout a été ajoutée aux tests de métadonnées Geo/Net NIP-66 qui n’avaient aucune échéance et pouvaient se bloquer indéfiniment. PR #410 met PostgreSQL à niveau de 16 vers 18, ce qui apporte le sous-système d’I/O asynchrone et un meilleur débit WAL au pipeline d’analytique relay.

Vertex Lab relay adds NIP-50 profile search

Vertex Lab, l’équipe derrière npub.world et le moteur Web of Trust Vertex, a annoncé que wss://relay.vertexlab.io supporte maintenant NIP-50 (Search) pour les requêtes de profils. NIP-50 étend le filtre standard REQ de Nostr avec un champ search, permettant aux clients d’envoyer des requêtes de recherche plein texte à des relays qui supportent l’indexation. Ajouter la recherche de profils à un relay qui sert déjà des données Web of Trust signifie que les clients connectés à relay.vertexlab.io peuvent découvrir des utilisateurs par nom ou description sans service de recherche séparé.

Hashtree v0.2.17 and v0.2.18 ship WebRTC mesh and Iris Desktop

Hashtree, le système de stockage de blobs adressé par contenu de mmalmi qui publie des racines Merkle sur Nostr, a livré v0.2.17 et v0.2.18 le 31 mars. Ces deux versions concluent un sprint de 30 commits ajoutant trois capacités distinctes. D’abord, la crate hashtree-webrtc (renommée hashtree-network dans v0.2.18) ajoute la distribution P2P de blobs basée sur WebRTC avec signalement mesh unifié à travers le CLI Rust, le harnais de simulation et le client TypeScript. Ensuite, le pipeline de release construit désormais des artefacts Windows (zip CLI et installeur Iris), apportant une couverture cross-platform à macOS, Linux et Windows. Enfin, les deux versions embarquent Iris Desktop 0.1.0, le client social Nostr de mmalmi, sous forme d’assets AppImage, .deb et installeur Windows aux côtés du CLI hashtree. Hashtree a été couvert pour la première fois dans la Newsletter #10 lors de son lancement comme magasin compatible Blossom basé sur le système de fichiers. La couche WebRTC est la première étape vers une distribution de contenu pair à pair sans dépendre de serveurs Blossom centralisés.

Nostr Mail Client v0.7.0 through v0.7.2

Nostr Mail Client, le client de style mail en Flutter construit sur des identités Nostr, a livré v0.7.0, v0.7.1, et v0.7.2 en trois jours. Le travail produit visible était centré sur l’onboarding (PR #9) et l’édition de profil (PR #10), deux briques de base pour tout client essayant de présenter Nostr comme une boîte mail. Les point releases suivantes ont empaqueté ce travail dans de nouvelles builds Android et Linux.

Wisp v0.14.0 through v0.16.1

Wisp, le client Nostr Android, a livré 13 versions supplémentaires de v0.14.0-beta à v0.16.3-beta. Le travail de cette semaine inclut des correctifs JSON rumor NIP-17 (PR #385), des badges de repost sur les cartes galerie (PR #383), des détails de réactions extensibles (PR #382), des ensembles d’emojis persistants (PR #381), et des contrôles d’autoplay vidéo (PR #380). La plus récente v0.16.3-beta corrige aussi les shortcodes d’emojis personnalisés avec tirets et les tags emoji manquants.

Primal Android 3.0.17

Primal Android a livré 3.0.17 le 24 mars. PR #1000 mappe les types de WalletException vers des codes d’erreur dans les réponses NWC, donnant aux clients NIP-47 une information d’échec structurée au lieu d’erreurs génériques. PR #995 corrige l’affichage des votes zap de sondages comme Top Zaps, et PR #998 masque le solde portefeuille et les boutons d’action quand aucun portefeuille n’est configuré.

OpenChat v0.2.4 through v0.3.0

OpenChat, le client de chat basé sur Avalonia construit sur la pile Marmot, a livré six versions de v0.2.4 à v0.3.0 en quatre jours. L’historique de commits raconte l’histoire d’un client qui comble l’écart entre « Marmot fonctionne » et « quelqu’un peut réellement l’utiliser tous les jours ». L’auth relay NIP-42 a atterri, suivie d’une interface de sélection de relays avec filtrage des événements dupliqués. Les messages vocaux ont gagné pause, reprise, seek et affichage du temps. Le chemin de signature a été durci : les connexions Amber ont été corrigées avec un format d’URI NIP-46 mis à jour, le WebSocket se reconnecte automatiquement avant l’envoi des requêtes, et les requêtes Amber dupliquées sont maintenant détectées par vérification des réponses rejouées. Côté stockage, Linux et macOS ont reçu un stockage sécurisé AES-256-GCM avec clés adossées à des fichiers, et la récupération des métadonnées utilisateur utilise désormais la découverte relay NIP-65 et met les résultats en cache dans une base locale.

Igloo Signer 1.1

Igloo, le signataire à seuil FROST iOS du projet FROSTR, a livré v1.1 le 28 mars. Les signatures FROST (Flexible Round-Optimized Schnorr Threshold) permettent à un groupe de signataires de contrôler collectivement une paire de clés Nostr, où n’importe quels t-of-n participants peuvent signer un événement sans qu’aucune partie ne détienne à elle seule la clé privée complète. Igloo est l’une des premières implémentations mobiles de cette approche pour Nostr.

nak v0.19.3 and v0.19.4

nak, la boîte à outils Nostr en ligne de commande de fiatjaf, a livré v0.19.3 et v0.19.4 les 26 et 30 mars. Les deux versions corrigent des conditions de panic : PR #118 remplace strings.Split par strings.Cut pour prévenir un accès potentiel hors limites, et PR #119 empêche la même classe de panic dans le parsing des flags curl.

Flora v0.3.0

Flora, une extension Chrome pour l’enregistrement d’écran décentralisé et le partage sur Nostr, a livré v0.3.0. La version ajoute le partage privé chiffré de vidéos avec modes public, non listé et privé. Les enregistrements privés sont chiffrés avec AES-256-GCM et livrés aux destinataires via NIP-17 (Private Direct Messages), de sorte que l’enregistrement ne touche jamais un serveur en clair.

YakiHonne Mobile 2.0.3

YakiHonne, le client Nostr mobile, a livré 2.0.3 avec des avis sur les relays et des demandes d’adhésion, des réponses imbriquées étendues, la traduction automatique des notes, et le support multi-relays NWC.

Mises à jour des projets

Zap Cooking adds zap polls and Branta payment verification

Zap Cooking, la plateforme de recettes et de contenu, a fusionné 11 PRs cette semaine centrées sur le contenu interactif et les flux de paiement. PR #277 ajoute les zap polls (kind 6969), où les utilisateurs votent en envoyant des sats et peuvent voir les listes de votants avec leurs photos de profil. PR #274 repense l’UX des sondages pour que l’interface de vote s’insère plus naturellement dans le flux.

PR #276 ajoute le scan QR par caméra au flux Send Payment et intègre Branta, un service de vérification qui contrôle la légitimité d’une destination de paiement avant l’envoi. Branta vérifie les destinations de paiement contre le phishing, les échanges d’adresses et l’interception man-in-the-middle avant l’envoi. Dans l’implémentation de Zap Cooking, un nom de plateforme et un logo vérifiés par Branta apparaissent directement dans le flux de paiement, et les QR codes compatibles Branta peuvent transporter des paramètres branta_id et branta_secret pour que le portefeuille vérifie la destination à partir du code scanné lui-même.

diVine lays groundwork for unified search and hardens video delivery

diVine, le client vidéo short-form, a passé la semaine à resserrer la recherche, la navigation de flux, la récupération de lecture et le comportement de téléversement. PR #2540 pose les bases d’un écran de recherche unifié, avec des sections groupées pour Videos, People et Tags. PR #2623 durcit la pagination à travers les flux de profils, la boîte de réception, les notifications, les listes discover, les classic vines et les flux de recherche et de grille composable en les faisant passer sur un contrôleur de pagination partagé.

La livraison vidéo a aussi reçu plusieurs correctifs concrets. PR #2643 retente les sources dérivées hébergées par Divine dans l’ordre et se replie sur le blob brut avant d’afficher une erreur de lecture, pour que des échecs transitoires sur une source ne cassent pas immédiatement la lecture. PR #2634 maintient les téléversements repris sur le chemin propriétaire Divine lorsque le capability probing échoue temporairement, réduisant les téléversements cassés causés par de courtes pannes réseau. PR #2637 modifie aussi la porte de contenu sensible pour que les vidéos ne soient strictement bloquées que pour les vrais labels d’avertissement, et non simplement pour les avertissements de contenu fournis par les créateurs.

Shopstr adds custom storefronts and Milk Market keeps shipping marketplace work

Shopstr, la marketplace basée sur Nostr, a fusionné PR #245 ajoutant des vitrines personnalisées. Cela donne aux vendeurs une surface d’accueil plus distincte au lieu de forcer chaque annonce dans la même présentation générique.

Milk Market, une marketplace dédiée au lait, a poursuivi avec des optimisations de vitrines (PR #18), la récupération de compte (PR #17), les beef splits (PR #15), et des correctifs de typage d’outils MCP (PR #16).

Notedeck adds sound effects and extends its updater path toward Android

Notedeck, le client desktop de l’équipe Damus, a fusionné PR #1412 ajoutant un sous-système d’effets sonores avec sons d’interaction UI via rodio, et PR #1399 avec des mises à jour Agentium incluant un flag de titre CLI et des dossiers de sessions repliables. Une PR #1417 ouverte propose l’auto-update APK via Nostr/Zapstore sur Android, construisant sur le travail d’updater natif Nostr de Notedeck depuis la Newsletter #14.

Nostria adds repost relay hints and NIP-98 alignment

Nostria a fusionné PR #583 ajoutant des indices de relay NIP-18 (Reposts) aux tags e de repost pour les événements kind 6 et kind 16, PR #582 alignant l’auth HTTP Brainstorm (kind 27235) avec les tags requis NIP-98 (HTTP Auth), et PR #576 ajoutant des tests de validation de schémas Schemata. Le changement NIP-98 signifie que Nostria peut s’authentifier auprès de services externes en utilisant le même format d’auth HTTP que les autres clients.

Nostr-Doc adds desktop packaging and offline-first work

Nostr-Doc, l’éditeur collaboratif de Form*, a connu une semaine chargée côté packaging et éditeur. commit fcdc00a ajoute une application desktop, commit 3977a8e démarre le travail applicatif natif, et commit 413a030 pousse l’application vers un comportement offline-first. Côté éditeur, commit 1855ce8 ajoute l’enregistrement Ctrl+S, des avertissements de sauvegarde, des correctifs d’aperçu de liens et un rendu barré corrigé.

rust-nostr optimizes NIP-21 parsing and adds relay-side NIP-62 support

rust-nostr a fusionné huit PRs. La plus notable est PR #1308, qui optimise le parsing des URI NIP-21 dans PublicKey::parse en l’alignant sur les performances du parsing bech32 standard. Auparavant, les URI NIP-21 prenaient environ deux fois plus de temps à parser que les clés bech32 brutes. Le projet a aussi quatre PRs ouvertes ajoutant un support NIP-62 (Request to Vanish) spécifique aux relays sur les backends mémoire, LMDB, SQLite et tests base de données (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools adds bunker relay control and fixes NIP-47 multi-relay parsing

nostr-tools a fusionné PR #530 ajoutant skipSwitchRelays à BunkerSignerParams pour une gestion manuelle des relays, et PR #529 corrigeant le parsing des chaînes de connexion NIP-47 (Nostr Wallet Connect) pour supporter plusieurs relays comme la spécification l’autorise.

Nostrability integrates Sherlock audit data and publishes Schemata overview

Nostrability, le tracker d’interopérabilité des clients Nostr, a fusionné 14 PRs. PR #306 intègre les statistiques de scan Sherlock au tableau de bord. Sherlock est l’outil d’audit automatisé de Nostrability qui se connecte aux clients Nostr, capture les événements qu’ils publient, et valide chaque événement contre les définitions JSON Schema de Schemata pour détecter des violations de spécification. Le tableau de bord affiche désormais les taux d’échec de schémas par client (PR #315) afin que les développeurs voient quels kinds d’événements leur client produit incorrectement. PR #323 revoit le workflow de publication sur Nostr pour que les annonces de release tournent comme un job séparé qui ne peut pas être annulé par des étapes CI précédentes.

elsat a aussi publié Schemata for nostr devs le 30 mars, décrivant comment schemata, schemata-codegen et Sherlock s’articulent, et donnant les chiffres actuels de couverture : 179 schémas de kinds d’événements à travers 65 NIPs, 154 schémas de tags, 13 messages protocole et 310 événements exemples.

Nalgorithm adds digest generation and local score caching

Nalgorithm, un nouveau projet de flux Nostr classé par pertinence, a commencé son développement public cette semaine. commit cf6c501 pose l’application web initiale qui récupère des posts depuis les follows et les note selon un prompt de préférences défini par l’utilisateur. commit 8e931b6 ajoute un outil CLI de digest qui transforme les posts les mieux classés en résumé parlé, tandis que commit 4cb9c63 ajoute un cache de score basé sur fichier et une évolution incrémentale du prompt appris à partir des likes récents. commit c2edfb8 arrête aussi la mise en cache des scores de repli issus de batchs échoués, pour qu’un échec de scoring transitoire n’aplatisse pas définitivement le rang d’un post.

TENEX adds RAG vector store and targeted MCP startup

TENEX, le framework d’agents natif Nostr qui relie des agents IA à des canaux Nostr via Telegram, a fusionné sept PRs cette semaine. PR #101 ajoute une abstraction de vector store enfichable avec SQLite-vec, LanceDB et Qdrant, donnant aux agents de la retrieval-augmented generation sans verrouillage sur une seule base vectorielle. PR #102 rend le démarrage MCP ciblé : seuls les serveurs MCP dont les outils sont réellement utilisés par un agent sont lancés, au lieu de démarrer tous les serveurs au premier run. PR #100 ajoute un outil send_message pour que les agents liés à des canaux Telegram puissent pousser des messages de manière proactive au lieu de seulement répondre aux messages entrants. PR #106 évite un spawn de sous-processus qui déclenchait une pré-allocation mémoire Bun/JSC de 9 Go en lisant .git/HEAD directement au lieu d’exécuter git branch.

Dart NDK moves Amber signer and adds Alby Go 1-click

Dart NDK, le kit de développement Flutter pour Nostr, a livré 11 PRs fusionnées. PR #525 déplace le support du signataire Amber dans le paquet ndk_flutter, et PR #552 ajoute une connexion portefeuille Alby Go en un clic à l’application exemple. PR #502 ajoute un script install.sh pour le CLI, et PR #523 retire la dépendance au vérifieur Rust au profit d’une gestion native des assets.

Protocol and Spec Work

Marmot moves KeyPackages to addressable events and tightens push notifications

La spécification Marmot a fusionné quatre PRs qui changent la manière dont le protocole gère le matériel de clé et l’appartenance de groupe. PR #54 migre les événements KeyPackage du kind:443 régulier vers le kind:30443 adressable avec tag d, supprimant le besoin de suppression d’événements NIP-09 lors de la rotation des clés. Les événements adressables s’écrasent sur place, ce qui rend la rotation auto-contenue. PR #57 permet aux utilisateurs non-admin de commit des propositions SelfRemove (départ volontaire du groupe), et PR #62 exige des admins qu’ils abandonnent leur statut d’admin avant d’utiliser SelfRemove, empêchant un admin de disparaître tout en conservant des privilèges élevés.

PR #61 resserre le format des notifications push MIP-05, rendant explicites l’encodage base64 en blob unique, le versionnage, le format filaire des tokens et l’usage de clés x-only. L’effet est une représentation filaire définie pour les blobs de tokens et les clés x-only à travers la spécification, les bibliothèques clientes et les backends applicatifs. L’implémentation de ces changements de spécification a atterri dans la pile White Noise cette semaine et est couverte dans la section White Noise v2026.3.23 ci-dessus.

NIP Updates

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

Fusionnés :

NIP-5A: Static Websites (PR #1538) : Définit les événements manifeste kind 15128 (site racine) et kind 35128 (site nommé) pour héberger des sites web statiques sous des paires de clés Nostr en utilisant le stockage Blossom. Voir la deep dive plus bas.
NIP-30 (Custom Emoji) : autoriser les tirets dans les shortcodes (PR #2297) : Met à jour la description des shortcodes pour inclure les tirets. Les shortcodes avec tirets sont utilisés en pratique depuis l’introduction du NIP, la spécification documente donc maintenant l’usage réel.

PRs ouvertes et discussions :

NIP-C1: Agent TUI Messages (PR #2295) : Propose un format de messages structuré pour que les agents envoient des éléments d’interface interactifs via des DMs chiffrés, incluant des payloads typés text, buttons, card, et table. Le brouillon garde tout à l’intérieur du contenu JSON des messages directs NIP-17 et NIP-04. Il ne définit pas de nouveau kind d’événement et utilise un format simple de callback string pour les réponses aux boutons.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293) : Propose un modèle relay hybride où les relays restent autoritaires mais peuvent aussi coordonner la distribution pair à pair des événements récents sur WebRTC. Le brouillon introduit des messages relay tels que PEER_REGISTER, PEER_REQUEST, et PEER_OFFER, avec des clients stables agissant comme Super Peers et le relay comme nœud seed et repli.
NIP-B9: Zap Poll Events (PR #2284) : Rouvre l’ancienne idée de zap-poll de NIP-69 maintenant que NIP-88 (Polls) couvre les sondages gratuits. Le brouillon utilise les définitions de sondages kind 6969 et les zaps kind 9734 comme votes, ce qui en fait un système de sondage payant avec résistance économique aux Sybils. Il complète les sondages gratuits one-key-one-vote.
NIP-AD: Super Zap (PR #2289) : Propose une convention où les zaps envoyés à la pubkey d’un relay ou d’un client sont affichés comme des notes promotionnelles spécialisées, transformant de fait les reçus de zap en surface publicitaire. Les opérateurs de relays et clients publieraient des profils avec lud16, récupéreraient ces reçus, extrairaient le contenu embarqué dans les descriptions de zaps, et pourraient fixer des seuils minimum en sats pour réduire le spam.
NIP-XX: Agent Reputation Attestations (PR #2285) : Propose le kind 30085 comme événement remplaçable paramétré pour des attestations structurées de réputation sur des agents Nostr. Le brouillon évite un score global unique en rendant la réputation dépendante de l’observateur, ajoute une décroissance temporelle pour que les anciennes attestations s’effacent, supporte les notes négatives avec exigence de preuves, et esquisse des modèles de scoring pondéré simple et de diversité de graphe pour une meilleure résistance Sybil.
NIP-XX: Paid API Service Announcements (PR #2291) : Propose des événements adressables kind 31402 pour annoncer des API HTTP payantes, avec Nostr gérant la découverte et HTTP 402 gérant le paiement. Le brouillon est tags-first afin que les relays puissent filtrer par méthodes de paiement, prix et capacités sans parser du JSON, et il autorise des schémas optionnels de requête et réponse pour que les clients ou agents puissent auto-générer les appels.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294) : Propose de dériver une paire de clés Nostr à partir d’une signature ECDSA LNURL-auth combinée à un nonce aléatoire côté client. La formule de dérivation est nsec = SHA256(ecdsa_signature || nonce). Le serveur voit la signature ECDSA (inhérente au handshake LNURL-auth) mais ne voit jamais le nonce, et le navigateur génère le nonce mais ne contrôle pas la signature. Aucun des deux morceaux ne suffit seul à dériver le nsec. Le résultat visé est que le même portefeuille Lightning produise la même clé Nostr sur plusieurs appareils, avec le portefeuille comme ancre de récupération et sans qu’aucun serveur ne puisse reconstruire la clé privée.
NIP-55 : documenter le champ rejected (PR #2290) : Documente le champ rejected pour les réponses de signataire basées sur intents, formalisant le comportement auquel le correctif v1.07.x d’Amethyst a dû s’adapter.

NIP Deep Dive: NIP-5A (Static Websites)

NIP-5A définit la manière d’héberger des sites web statiques sous des paires de clés Nostr, en utilisant deux kinds d’événements et l’infrastructure de stockage de blobs existante pour transformer des événements signés en pages web servies. La spécification a été fusionnée le 25 mars via PR #1538.

Le modèle utilise le kind 15128 pour un site racine, un par pubkey, et le kind 35128 pour des sites nommés identifiés par un tag d. Chaque manifeste associe des chemins d’URL absolus à des hachages SHA256. Voici un manifeste de site racine :

{
  "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
  "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
  "created_at": 1743465600,
  "kind": 15128,
  "tags": [
    ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
    ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
    ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
    ["server", "https://blossom.primal.net"],
    ["title", "My Nostr Site"],
    ["description", "A static website hosted on Nostr"],
    ["source", "https://github.com/lez/nsite"]
  ],
  "content": "",
  "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

Le flux de service fonctionne en trois étapes. Un serveur hôte reçoit une requête HTTP, extrait la pubkey de l’auteur depuis le sous-domaine (soit un npub pour les sites racines, soit une pubkey encodée en base36 pour les sites nommés), récupère la liste de relays de l’auteur via NIP-65, puis interroge le manifeste du site. Une fois le manifeste trouvé, le serveur résout le chemin demandé vers un hachage de contenu, télécharge le blob correspondant depuis le ou les serveurs Blossom listés dans les tags server, puis le renvoie.

Le format du sous-domaine DNS est fortement spécifié. Les sites racines utilisent le npub standard comme sous-domaine. Les sites nommés utilisent un encodage base36 de 50 caractères de la pubkey brute suivi de la valeur du tag d, le tout dans un seul label DNS. Comme les labels DNS sont limités à 63 caractères et que l’encodage base36 prend toujours 50 caractères, le tag d est limité à 13 caractères. La spécification exige aussi que les tags d correspondent à ^[a-z0-9-]{1,13}$ et ne se terminent pas par un tiret, pour éviter les ambiguïtés de résolution DNS.

L’utilisation de hachages de contenu signifie qu’un même site peut être servi par différents serveurs hôtes, et que l’intégrité des fichiers est vérifiable sans faire confiance au serveur. Un serveur hôte n’a pas besoin de stocker lui-même les fichiers. Il les récupère à la demande depuis Blossom à partir des hachages présents dans le manifeste. Cela signifie que l’auteur contrôle ce qui est servi, le serveur Blossom stocke les fichiers bruts, et le serveur hôte se contente de relier les deux. Chacun de ces trois composants peut être remplacé indépendamment.

Les implémentations existantes incluent nsite, le serveur hôte qui résout les manifestes et sert les fichiers, et nsite-manager, une interface pour construire et publier les manifestes. La spécification a aussi ajouté un tag source pour lier le dépôt du code source du site, et la mise à jour du README fusionnée séparément dans PR #2286 a enregistré les kinds 15128 et 35128 dans l’index des kinds NIP.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 définit le kind 62 comme une demande faite aux relays de supprimer tous les événements de la pubkey requérante. La spécification est motivée juridiquement : dans les juridictions avec un droit à l’oubli, disposer d’une demande de suppression standardisée et signée donne aux opérateurs de relays un signal clair sur lequel agir.

{
  "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
  "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
  "created_at": 1743465600,
  "kind": 62,
  "tags": [
    ["relay", "wss://relay.example.com"]
  ],
  "content": "Requesting deletion of all events from this relay.",
  "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

La spécification sépare les demandes de vanish ciblées des demandes globales. Une demande ciblée inclut des tags relay spécifiques identifiant quels relays doivent agir. Une demande globale utilise la chaîne littérale ALL_RELAYS comme valeur du tag relay, demandant à tous les relays qui voient l’événement de supprimer tous les événements de cette pubkey. Les relays qui se conforment doivent aussi s’assurer que les événements supprimés ne puissent pas être re-diffusés dans le relay, rendant la suppression persistante.

NIP-62 va au-delà de NIP-09 (Event Deletion) à la fois par sa portée et par son intention. NIP-09 permet de supprimer des événements individuels, et les relays MAY s’y conformer. NIP-62 demande la suppression de tout, et la spécification dit que les relays MUST s’y conformer si leur URL est taguée. Elle demande aussi aux relays de supprimer les événements NIP-59 (Gift Wrap) qui avaient p-tagué la pubkey requérante, ce qui signifie que les DMs entrants sont nettoyés en même temps que les propres événements de l’utilisateur. Publier une suppression NIP-09 contre une demande vanish NIP-62 n’a aucun effet : une fois qu’on vanish, on ne peut pas « dé-vanish » en supprimant la demande de vanish.

Cette semaine, Amethyst v1.07.0 a livré le support NIP-62 côté client, permettant aux utilisateurs d’initier des demandes de vanish depuis l’application. Côté relay, rust-nostr a quatre PRs ouvertes ajoutant le support NIP-62 aux backends mémoire, LMDB, SQLite et tests base de données (PR #1315, PR #1316, PR #1317, PR #1318). Le support côté client et côté relay avancent donc la même semaine.

La conception du protocole soulève une tension pratique. La proposition de valeur de Nostr inclut la résistance à la censure, ce qui signifie que les relays ne devraient pas pouvoir empêcher la publication. NIP-62 introduit un cas où un relay MUST empêcher la re-publication depuis une pubkey spécifique. Les deux propriétés coexistent parce que la demande est auto-dirigée : on demande la suppression de ses propres événements, pas de ceux d’un tiers. La propriété de résistance à la censure reste intacte pour tout le monde sauf pour la personne qui a explicitement choisi de se retirer.

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