Bulletins on Nostr Compass

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

L’organisation Marmot Protocol ouvre trois nouveaux dépôts pour un projet de protocole v2 et une lignée de client native : un workspace Rust nommé darkmatter, une app iOS SwiftUI darkmatter-ios, et une app Android Kotlin/Compose darkmatter-android. Le Whitenoise Flutter original est archivé. Chama compresse dix-sept versions en une seule semaine et franchit la ligne d’app autonome à v3.0.0 avant d’atterrir une refonte complète de l’UI de salle de trade et des vitrines par vendeur dans v3.1.0, en plus des parts Shamir uniquement pour les détenteurs, la substitution d’arbitre, le routage de communauté mondiale, et les notifications de trade de bout en bout. Coracle lance un service de relais hébergé payant soutenu par la pile open source Caravel et zooid, avec une intégration Flotilla profonde planifiée. Angor bascule sur mainnet par défaut dans v0.2.30 et atterrit un test de financement UAT à 3 utilisateurs dans v0.2.29. Amethyst atterrit 41 PRs non publiées poursuivant le travail NIP-32 / NIP-F4 / Tor de la semaine dernière. NIP-67 (indice de complétude EOSE) et l’autocomplétion NIP-50 fusionnent, fermant deux lacunes de correction de longue date dans le protocole de relais principal. NIP-GART propose un format de câble préservant la vie privée pour les alertes d’urgence, et NIP-46 gagne une méthode de déconnexion.

Articles principaux

Marmot v2 (Dark Matter) : refonte du protocole, clients natifs, app Flutter archivée

Trois nouveaux dépôts ont fait surface sous l’organisation GitHub marmot-protocol cette semaine, formant ensemble la forme précoce d’un projet de protocole Marmot v2 et d’une lignée de client native qui remplace la ligne d’app Flutter. darkmatter (Rust, créé le 13 mai, trente-quatre commits dans les sept derniers jours) contient le projet de protocole v2 dans spec/, un moteur CGKA basé sur OpenMLS dans crates/cgka-engine, un simulateur de conformité avec des tests de propriété, et un modèle formel Tamarin pour les preuves de convergence. darkmatter-ios (Swift, créé le 25 mai) est un client SwiftUI soutenu par un xcframework UniFFI MarmotKit vendu généré à partir du workspace Rust. darkmatter-android (Kotlin/Jetpack Compose, créé le 25 mai) repose sur les mêmes bindings Rust. Le Whitenoise Flutter original a été marqué whitenoise-archive (« ARCHIVED: This was the original White Noise Flutter app ») ; un nouveau dépôt Dart whitenoise porte la ligne Flutter active en parallèle.

Lisez cela comme des progrès précoces vers un Marmot plus fiable, pas comme un pivot terminé. Le README de darkmatter s’étiquette « Projet candidat de protocole Marmot v2, moteur CGKA, et workspace de conformité » et dit directement : « MDK reste l’implémentation de protocole Rust déployée jusqu’à ce que ce projet et ce moteur soient adoptés. » À l’intérieur du workspace, le crate cgka-engine est étiqueté 0.1.0, « consommateur interne unique, non-stable-semver ». Chaque page de spécification porte « Statut : projet pour revue interne ». Trois étoiles sur le dépôt workspace et zéro sur les apps iOS et Android confirment que le travail est pré-annonce. Direction, portée et discipline sont le signal ici ; la préparation à la production n’est pas la revendication.

Le projet de protocole rend les deltas v1-à-v2 concrets. L’extension MLS marmot_group_data monolithique de MIP-01, qui a porté le nom, la description, les pubkeys d’admin, l’id de routage de groupe Nostr, la liste de relais, les données d’image de groupe, et les paramètres de messages éphémères sous un seul parapluie depuis le début de Marmot, est divisée en composants d’app versionnés : marmot.group.profile.v1 pour le nom et la description, marmot.group.admin-policy.v1 pour les pubkeys d’admin, marmot.transport.nostr.routing.v1 pour le nostr_group_id aléatoire et la liste de relais canonique, marmot.group.blossom.image.v1 pour le hash d’image, la clé de chiffrement, le nonce, et la clé d’upload, et marmot.group.message-retention.v1 pour les secondes de messages éphémères. Chaque composant possède ses octets exacts et son propre chemin de versionnement, afin qu’une future fonctionnalité puisse rev un composant sans forcer le reste de l’état de groupe à repasser sur le consensus d’extension MLS. Les identifiants MIP-00 gagnent également un nouveau document de fondation account-identity-proof-v1.md, appelé « nouveau dans v2 et cassant ». La preuve d’identité vit maintenant sur sa propre surface, séparée de la construction de KeyPackage.

Les deltas de bibliothèque soutiennent la refonte de la spécification. cgka-engine est la nouvelle machine d’état de groupe locale : elle enveloppe OpenMLS, possède les états d’époque Stable, PendingPublish, Merging, et Recovering, traduit les intents en commits MLS, retourne des valeurs IngestOutcome et GroupEvent typées pour chaque enveloppe de transport entrante, et ne livre explicitement aucun transport et aucune persistance. Un trait TransportPeeler sépare Nostr du moteur, et un trait StorageProvider sépare SQLite (via storage-sqlite, soutenu par SQLCipher) du moteur. Aujourd’hui, MDK emballe tout cela ensemble ; diviser les couches permet à un moteur de siéger sous un transport de relais Nostr maintenant et les transports flux QUIC et broker également livrés plus tard, sans réécriture du modèle de convergence. La convergence elle-même est documentée comme distributed-convergence.md et prouvée dans un modèle Tamarin qui couvre la sélection de branche déterministe, l’éligibilité gate par politique, la relecture d’ancre retenue, le rejet de branche périmée, la réorganisation de livraison, la duplication, l’invalidation de sortie d’app, le passage welcome/commit, la consommation de proposition, et le gating sortant pendant la synchronisation. Les tests de propriété Rust vérifient ensuite que le moteur suit les mêmes règles avec de vrais objets OpenMLS et le harnais de simulateur. Le travail de fiabilité par méthodes formelles de cette portée est absent de la pile Marmot actuelle.

Les deux clients natifs abandonnent Flutter pour des boîtes à outils UI natives de plateforme. darkmatter-ios est du SwiftUI pur avec une Notification Service Extension qui déchiffre les réveils push MIP-05 sur l’appareil, vend un paquet Swift MarmotKit généré construit à partir du workspace Rust, et s’enregistre sous l’ID de bundle dev.ipf.darkmatter et le groupe d’app. darkmatter-android est Kotlin et Jetpack Compose, avec un build piloté par just qui produit un APK arm64-v8a signé et lit les endpoints de télémétrie depuis local.properties. Le README Android énonce le principe architectural directement : « Dark Matter possède les données de protocole et les stocke dans SQLite. L’app Android devrait rendre ces données, gérer le comportement de plateforme Android, et garder l’état de cycle de vie UI. L’app Android ne devrait pas devenir une seconde base de données pour les données Dark Matter. » Cela reflète la discipline de frontière que le README cgka-engine applique dans la couche Rust, appliquée à la couche UI.

Les clients natifs comptent pour Marmot parce que la faiblesse la plus citée du protocole a été la fiabilité mobile sous des conditions de livraison inégales : réveils de notification à échéance manquée, courses de commits MLS pendant les fluctuations réseau, limites de récupération en arrière-plan qui bloquent les avancements d’époque. SwiftUI et Compose donnent aux clients un accès direct aux primitives de traitement en arrière-plan de plateforme que Flutter atteint via un pont de plugin, et le chemin de binding UniFFI garde la logique de protocole dans un workspace Rust unique livré comme bibliothèque statique sur les deux plateformes. La ligne Whitenoise Flutter continue dans le dépôt whitenoise non archivé, donc l’annonce est additive : une nouvelle lignée de client native fonctionne aux côtés de l’app Flutter pendant que la spécification v2 converge. Le passage de production depuis MDK ou le Whitenoise actuel attend que le projet, le moteur et les clients atteignent des sorties prêtes pour la production.

Chama v2.0.0 à v3.1.0 : entiercement P2P autonome en une semaine

Le client d’entiercement P2P Nostr-natif introduit dans Newsletter #25 à v1.3.0 a livré dix-sept versions étiquetées sur les sept derniers jours, se terminant à v3.1.0 le 9 juin avec une refonte de l’UI de salle de trade et des vitrines par vendeur. La piste de versions raconte l’histoire : v2.0.0 est la base BREAKING, puis v2.0.1, v2.0.2, et v2.0.3 ferment les lacunes de rail de financement Fedi WebView ; v2.1.0, v2.2.0, v2.3.0, et v2.3.1 durcissent la couche d’arbitre ; v2.4.0, v2.5.0, et v2.6.0 ajoutent des surfaces de self-custody et le routage de communauté mondial ; v2.7.0, v2.8.0, v2.9.0, et v2.10.0 superposent des textes clés en anglais simple, les demandes de groupe, l’arbitrage de délai de litige, et la réputation. v3.0.0 lie le paquet ensemble avec des notifications de trade de bout en bout, et v3.1.0 le 9 juin redessine l’écran de trade autour d’une épine dorsale de progression Reserved → Locked → Settled, des cartes d’action colorées par rôle, et une classe d’annonce de vitrine par vendeur (swaps curatés, carnets de prêt, et factures).

Le pivot architectural vit dans v2.0.0. Le format LOCK d’entiercement a changé pour que chaque part d’un split Shamir 2-de-3 soit chiffrée uniquement pour son détenteur (sharePolicy holder-only-v1). L’ecash porteur de la fédération ne se reconstruit plus à partir d’un seul participant seul, fermant un chemin où une partie malveillante avec sa propre part et une part détenue par la fédération pouvait compléter le trade sans consentement. Les clients pré-2.0 échouent bruyamment avec « impossible de trouver votre part » ; le trade ne peut pas se compléter sur un client périmé, et aucun fonds n’est perdu dans le processus. Un verrou v2.0 nécessite chaque partie sur v2.x pour se régler. v2.0.0 a également ajouté les vitrines multi-unités et une vue Market en sats uniquement.

v2.1.0 a introduit la substitution d’arbitre : la part d’arbitre à l’index Shamir 2 est maintenant chiffrée à un ordre de priorité déterministe sur le pool d’arbitres communautaires, afin qu’un arbitre absent puisse être remplacé sans échouer le trade. v2.2.0 a prouvé que la substitution fonctionnait en pratique sur un trade de ₿121 et a ajouté des sauvegardes de substitution de guérison. v2.3.0 a fermé la dernière lacune de front-running d’arbitre en vérifiant l’appartenance communautaire de l’arbitre de l’annonce au moment du verrouillage, et v2.3.1 a fermé la course frère où un slot d’arbitre auto-assigné était un aperçu jusqu’à ce que le verrou les installe.

Les surfaces de self-custody sont arrivées dans v2.4.0 (phrase de récupération BIP-39 pour le portefeuille ecash Fedimint, stockée chiffrée sur Nostr) et v2.5.0 (sauvegarde nsec maître qui possède l’identité Nostr et la graine du portefeuille). v2.6.0 a retravaillé l’onboarding autour d’un sélecteur de communauté global afin que les utilisateurs dans les pays sans Chama locale soient routés vers la fédération la plus proche ; les builds antérieurs faisaient rebondir l’utilisateur sans fallback. v2.7.0 a réécrit l’écran de clé de récupération en anglais simple (« la seule clé de votre compte et de l’argent qui s’y trouve ; Chama ne la voit jamais et ne peut pas la réinitialiser ; si vous la perdez, personne ne peut récupérer votre compte »). v2.8.0 a ajouté les demandes de groupe, le thème sombre/clair, et a ajouté deux nouveaux kinds d’événements (38120 roster, 38121 application). v2.9.0 a changé la résolution de litige à échéance : les trades contestés qui atteignent leur expiration se résolvent maintenant par jugement d’arbitre ; le comportement précédent auto-remboursait. La sortie est marquée COORDINATED afin que toutes les parties en litige doivent mettre à jour. v2.10.0 a ajouté des évaluations pouce-en-haut/pouce-en-bas par trade comme nouveau kind d’événement 38123.

v3.0.0 est le jalon où l’app cesse d’avoir besoin d’une communauté coordinatrice pour fonctionner. Les notifications de trade de bout en bout pingent l’utilisateur uniquement sur les transitions d’état actionnables : la contrepartie a verrouillé les sats, paiement prêt à réclamer, litige nécessite le jugement de l’utilisateur en tant qu’arbitre, ou trade réglé ou expiré. Un toggle dans l’écran Me active ou désactive les notifications, et l’invite de permission ne se déclenche que lorsque le toggle est activé. La déduplication tir-unique empêche un rechargement d’état de déclencher une tempête d’alertes. Un bug de garde-fou wrong-chama a également été fermé dans PR #103, où les versions antérieures pouvaient étiqueter une annonce avec l’étiquette d’une chama mais la fédération d’une autre chama. Les paquets desktop Windows et Linux sont livrés avec la version ; le dmg macOS est retenu jusqu’à ce que la signature et la notarisation atterrissent.

Chama rejoint maintenant Mostro et Shopstr en tant que marketplace Nostr-native, distinguée par une architecture sans serveur, un entiercement Shamir 2-de-3 soutenu par Fedimint, le chiffrement de part uniquement pour le détenteur, et la seule des trois à livrer un client desktop et mobile autonome sans communauté coordinatrice.

Coracle Hosting : service de relais payant plus pile Caravel open source

Le 3 juin, Hodlbod a annoncé Coracle Hosting à hosting.coracle.social, un service de relais communautaire hébergé qui accepte les paiements Lightning récurrents via NWC ou carte. Le service est alimenté par Caravel, le frontend de facturation et de provisionnement de Coracle, et zooid, un runtime de relais qui héberge de nombreux relais virtuels sur une seule machine. Les deux sont open source sur le gitea auto-hébergé de Coracle. Caravel est livré avec une intégration optionnelle livekit et Blossom que les opérateurs peuvent basculer par relais. Un palier gratuit avec des limites de compte de membres permet aux opérateurs d’évaluer le service avant de s’engager sur des détails de paiement.

Hodlbod est franc sur le modèle d’affaires : monétiser l’open source en vendant une version hébergée d’une pile que n’importe qui d’autre peut aussi exécuter. La barrière compétitive est l’intégration Flotilla, qui est la prochaine étape planifiée. Flotilla possède la surface utilisateur, donc l’option hébergée servie depuis l’intérieur de Flotilla devient le chemin par défaut pour tout utilisateur qui préfère l’infrastructure gérée. Hodlbod a offert d’ajouter d’autres opérateurs Caravel au sélecteur d’hébergement alternatif de Flotilla s’ils le contactent, gardant la porte ouverte à un marché d’hébergement fédéré.

Caravel rejoint relay.tools comme plateforme publique de provisionnement de relais Nostr avec des paliers de membres payants. relay.tools précède Caravel et livre en tant que service dominant de création de relais aujourd’hui, avec son propre répertoire de relais communautaires et des flux de jonction de membre payant ou modérateur. La caractéristique distinctive de Caravel est la pile coordonnée : le runtime de relais (zooid), le frontend de facturation et de provisionnement (Caravel lui-même), et le sélecteur côté client (intégration Flotilla, encore en vol) sont livrés comme une seule conception. L’autre caractéristique distinctive est la densité multi-relais-par-processus de zooid, où les relais clients partagent un seul processus hôte afin que l’opérateur amortisse les coûts d’hébergement sur de nombreuses petites communautés. C’est le même argument de densité qui a rendu l’hébergement web partagé viable au début des années 2000, appliqué à la couche de relais de Nostr.

Sorties

Angor v0.2.29 et v0.2.30 : mainnet par défaut et test de financement UAT à 3 utilisateurs

Angor v0.2.29 le 4 juin et v0.2.30 le 8 juin sont les deux sorties de cette semaine pour le protocole de financement Bitcoin-et-Nostr décentralisé. Le changement titre de v0.2.30 est PR #893, qui bascule le réseau par défaut sur mainnet. Angor est toujours livré comme version alpha instable, mais le passage mainnet-par-défaut signale que le protocole a dépassé la phase testnet-uniquement pour les clients desktop et mobile. v0.2.30 atterrit également un flux de création de projet mobile à un seul tap avec upload d’image et réinitialisation de défilement (PR #889) et résout une condition de course où le spinner de facture Lightning pouvait se bloquer (PR #890).

v0.2.29 a ajouté un test UAT de bout en bout dans PR #881 couvrant l’envoi de fonds à 3 utilisateurs sur 10 tours avec dépenses non confirmées, le premier test de flux de financement multi-utilisateur dans la suite de tests Angor. La sortie a également ajouté un plan d’implémentation pour une CLI Angor et un serveur MCP (PR #792), avec des améliorations de CLI pour le workflow de test MCP dans PR #880. PR #885 par DavidGershony a corrigé une facture Lightning Boltz qui utilisait le mauvais réseau après un changement de réseau à l’exécution, un bug qui serait apparu en production après le défaut mainnet v0.2.30. Les paramètres offrent maintenant une purge optionnelle du fichier de portefeuille de récupération pendant l’effacement de données (PR #883).

Sprout v0.3.6 : rafraîchissement TTL de canal éphémère et commandes slash ACP

Sprout v0.3.6, publié le 10 juin, est la huitième version d’une série qui a commencé avec v0.3.7 le 2 juin. Newsletter #25 a couvert la série v0.3.1 à v0.3.6 avec l’intégration mesh-llm et le travail sur les sections de canal ; v0.3.7 à v0.3.15 sont en aval de cela, axés sur le polissage et quelques ajouts visibles par l’utilisateur. Le changement le plus visible par l’utilisateur est un rafraîchissement TTL pour les canaux éphémères dans PR #902 : quand un utilisateur désarchive un canal éphémère, Sprout étend le time-to-live du canal afin que le désarchivage ne le réarchive pas immédiatement sous le minuteur d’expiration original. Les emojis personnalisés mobiles arrivent dans PR #906 aux côtés d’une refonte des paramètres, et les comptes de réactions s’animent maintenant au changement (PR #904).

PR #905 corrige une lacune de longue date où les noms d’affichage à plusieurs mots se cassaient et l’extraction de mention nostr:npub NIP-27 tombait silencieusement. Une UI d’équipe soutenue par répertoire pour desktop est livrée dans PR #912 avec des commandes install, sync et reveal. Les commandes slash passent maintenant à travers les connecteurs ACP dans PR #919, permettant à Sprout de transférer les commandes de style /help directement aux runtimes d’agents tout en gardant l’UI Sprout hors du chemin.

Wisp v1.1.1 : intégration wallet Spark et garde de collage nsec

Wisp v1.1.1, publié le 5 juin, atterrit un écran Connect wallet à deux niveaux avec sous-écran Spark dans PR #548 et parité de tableau de bord avec l’UI du portefeuille iOS dans PR #549. La sortie inclut une garde de collage nsec à l’échelle du système qui détecte un collage préfixé nsec1 n’importe où dans l’app et empêche le champ de l’accepter, fermant l’un des pièges les plus cités dans l’UX Nostr. La connexion par scan QR plus un mode watch-only pour npub et nprofile est livrée dans PR #552, permettant à un utilisateur de parcourir un profil en lecture seule. Les messages de zap se rendent maintenant comme mini-posts dans le tiroir d’engagement (PR #559) afin que les notes de zap portent leur texte aux côtés du montant en sats. Un filtre de web of trust sur les réponses de fil atterrit dans PR #583, permettant aux utilisateurs de masquer le spam de réponse des comptes en dehors de leur graphe de suivi.

Nostria v3.1.46 et nospeak 1.1.3 : refonte des notifications et redémarrage ICE

Nostria v3.1.46 le 7 juin termine une série de trois versions qui a retravaillé le compteur de notifications pour compter uniquement les nouvelles notifications depuis la dernière vue, éliminant une inflation de longue date où le chargement d’anciennes notifications par défilement augmentait le compte du badge. Nostria v3.1.45 a corrigé un bug de paiement partagé affectant les paiements Lightning et code QR et a abandonné une UI translucide précédemment prévue comme non viable sur le compositeur Android.

nospeak v1.1.3 le 4 juin ajoute le redémarrage ICE en état FAILED pour les appels vocaux 1-sur-1. Le comportement WebRTC standard abandonne un appel quand les candidats ICE expirent sans chemin alternatif ; le chemin de redémarrage ICE renégocie les candidats afin que l’appel récupère des changements de NAT ou de réseau transitoires. Les appels Android gardent maintenant l’écran allumé pendant les appels vidéo.

Changements non publiés

Amethyst : 41 PRs poursuivant la voie NIP-32 / NIP-F4 / Tor

Amethyst a fusionné 41 PRs cette semaine sans couper une balise de version, en plus des 52 PRs de la semaine dernière et du travail sur l’étiquetage de hashtag NIP-32 et l’écran de podcast NIP-F4 couverts dans Newsletter #25. La branche active continue à accumuler des fonctionnalités pour la prochaine sortie étiquetée, superposant du polissage sur les ajouts titres de la semaine dernière : découverte d’étiqueteurs de hashtag, écran de podcast, pistes musicales et playlists, watchdog d’auto-guérison Tor, signataires éphémères pour uploads anonymes, et zaps on-chain avec filtrage NIP-05. Le débit de PRs d’Amethyst reste le plus élevé de tout client Nostr, et la file d’attente non publiée est la feuille de route de facto pour ce que les autres clients Android Nostr devront égaler.

Damus : suivi de relais depuis les messages OK et changelog v1.17

Damus PR #3786, fusionnée le 3 juin, ajoute les messages OK réussis d’un relais à la liste de relais post. Les builds Damus antérieurs peuplaient la liste seen-relays uniquement lors de la réception d’un message générique du relais, ce qui signifiait qu’un relais qui accusait le post mais ne livrait aucun événement en retour était invisible pour l’utilisateur. Le changement importe pour les utilisateurs qui veulent confirmer que leur post a atterri sur leur relais d’outbox préféré. PR #3796 corrige un cycle AttributeGraph sur Profile View, et PR #3725 atterrit le changelog v1.17 avant la prochaine sortie étiquetée.

Shopstr : publication double NIP-34

Le dépôt shopstr sur ngit a été annoncé sur Nostr cette semaine comme dépôt git NIP-34, rejoignant les dépôts suivis de ngit. Le dépôt GitHub du client shop reste la surface de développement principale ; l’annonce NIP-34 rend disponible un chemin parallèle de collaboration git-over-Nostr. C’est le deuxième grand projet marketplace Nostr à publier en double sur NIP-34 après Mostro, et continue la migration progressive des métadonnées de projet sur le transport git de Nostr.

Hermes-Marmot : passerelle d’agent IA sur MLS

hermes-marmot, un plugin pour l’Hermes Agent, connecte la surface de messagerie d’un agent IA à des groupes Marmot (MLS-over-Nostr) en utilisant mdk-python, les bindings Python au Rust Marmot Development Kit. Le plugin permet à un utilisateur de DM un agent IA depuis n’importe quel client Nostr qui parle les messages MLS kind 445, y compris Whitenoise. Les DMs entrants utilisent le déballage gift-wrap NIP-59 via les bindings Python nostr-sdk, et les welcomes entrants passent à travers UnwrappedGift.from_gift_wrap à mdk.process_welcome et mdk.accept_welcome. Le contrôle d’accès passe par MARMOT_ALLOWED_USERS (une liste blanche de npubs séparée par des virgules) ou MARMOT_ALLOW_ALL_USERS=true pour un accès dev ouvert.

Le dépôt est nouveau (dernière mise à jour le 27 mai) et petit. Son importance est architecturale : c’est le premier pont public entre un runtime d’agent LLM et un canal de messagerie Nostr chiffré par MLS, et la première utilisation en production de mdk-python au-delà de Whitenoise lui-même. Le modèle pointe vers une communication agent-à-agent où les deux endpoints détiennent des clés MLS et le relais ne voit que le chiffré.

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

NIP-67 indice de complétude EOSE (PR #2317) fusionné

PR #2317 par mattn a fusionné le 6 juin, ajoutant NIP-67 au protocole. Le NIP étend le message relais EOSE avec un troisième élément optionnel : ["EOSE", <subscription_id>, "finish"] signale que chaque événement stocké correspondant au filtre a été livré, tandis qu’un simple ["EOSE", <subscription_id>] ne porte aucune revendication de complétude. Un relais qui omet l’indice dit au client qu’il pourrait y en avoir plus ; un relais qui omet l’annonce NIP-67 dans NIP-11 conserve le comportement d’aujourd’hui sous l’heuristique legacy existante. Le changement est rétrocompatible dans les deux directions : les clients legacy ignorent l’élément final du tableau, et les relais legacy l’omettent.

La motivation dans la spécification fusionnée est double. Premièrement, la perte silencieuse de données : un client demande les 500 dernières notes contre un relais avec un plafond interne de 300 événements, le relais retourne 300 événements, et le client (utilisant l’heuristique standard received < limit) conclut que le résultat est complet. Les 201e à Ne notes correspondantes les plus anciennes restent sur le relais non lues, avec le client aveugle à ce fait. Deuxièmement, les allers-retours obligatoirement gaspillés : quand un relais plafonne les réponses à 300 événements, tout abonnement qui épuise le plafond nécessite un second REQ avec until=<oldest_created_at> purement pour confirmer la complétude, même quand le filtre correspond exactement à 300 événements. Les deux modes de défaillance sont payés par chaque client sur chaque abonnement à plafond épuisé. L’indice "finish" est une chaîne optionnelle sur un message existant et élimine les deux coûts.

Extension d’autocomplétion NIP-50 (PR #2357) fusionnée

PR #2357 par Alex Gleason a fusionné le 6 juin, ajoutant un token autocomplete:true/false à la recherche NIP-50. L’extension permet à un client de marquer une requête comme recherche typeahead afin que le relais utilise la correspondance de préfixe, avec la recherche full-text comme défaut pour les requêtes sans le token. Le relais de Ditto l’implémente pour les follow packs, les listes, et tout événement avec une balise title, retournant les correspondances contre le préfixe du titre ; le chemin de recherche par défaut exécute le scoring full-text. Sans ce token, les UIs de style autocomplétion n’avaient aucun moyen de communiquer l’intention de recherche par préfixe et les relais devaient deviner à partir de la forme de la requête. Le token est un indice par recherche, pas une capacité à l’échelle du relais, donc un relais peut l’implémenter pour une classe d’événement (titres) sans revendiquer un support d’autocomplétion général.

Alertes d’urgence et diffusions de localisation NIP-GART (PR #2374)

PR #2374 par disinqa, ouverte le 9 juin, définit un format de câble préservant la vie privée sur Nostr pour les alertes d’urgence et les diffusions de localisation adressées à un groupe de destinataires de confiance. Le but de conception déclaré est de cacher l’identité de l’expéditeur, l’appartenance au groupe, et la charge utile aux opérateurs de relais tout en gardant les événements sûrs contre le replay et vérifiables par signature de bout en bout. Le numéro NIP est encore TBD, la proposition est un projet précoce. Le cas d’usage est le modèle standard d’alerte d’urgence : un utilisateur sous menace diffuse un ping de localisation que seul un groupe pré-partagé de contacts de confiance peut déchiffrer, avec le relais aveugle à l’expéditeur, l’ensemble des destinataires, et la charge utile. Les détails du format de câble vivent dans la PR et évolueront probablement à mesure que les mainteneurs révisent.

Méthode de déconnexion NIP-46 (PR #2373)

PR #2373 par hzrd149, ouverte le 8 juin, ajoute une méthode logout à NIP-46 afin qu’un client puisse dire à un bunker explicitement que la session est terminée. Jusqu’à maintenant, la seule façon de terminer une session bunker était d’attendre le timeout de session ou d’arrêter d’utiliser la connexion, les deux laissant le bunker tenant l’état de session pour un client qui est parti. La proposition est courte (une nouvelle méthode) et est le genre de changement de nettoyage qui rend les intégrations bunker de longue durée plus propres.

Proposition hybride relay-P2P NIP-95 circulée en tant que long-form

Une spécification NIP-95 long-form a circulé comme post kind:30023 de npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c le 4 juin sous le titre Protocolo Híbrido Relay-P2P via WebRTC. Le document en portugais définit un protocole hybride pair-à-pair de relais où les clients Nostr se connectent directement les uns aux autres via WebRTC pour la messagerie en direct tout en continuant à utiliser les relais pour la récupération d’événements stockés et la livraison hors ligne. L’auteur a explicitement cadré la spécification comme « LLM-ready », fournissant des définitions de messages, des flux logiques, des schémas de données, et des règles d’état à un niveau de détail qui permet à un modèle IA de générer du code client ou serveur fonctionnel. La proposition n’a pas encore atterri comme PR NIP ; la circulation via kind:30023 est le précurseur habituel d’une pull request formelle nostr-protocol/nips.

NIP-44 v3 gagne un second signataire : Clave porte la spécification

Le déploiement NIP-44 v3 d’Amber v6.2.0 de la semaine dernière a été livré avant toute PR NIPs fusionnée, laissant v3 comme extension spécifique à Amber que d’autres clients devaient refléter pour interopérer. Ce cadrage d’implémentation unique a changé cette semaine. Clave, le signataire iOS remote NIP-46 basé sur push, a atterri un port NIP-44 v3 indépendant les 3 et 4 juin à travers huit commits. Les primitives cryptographiques sont livrées dans trois commits : couche HKDF + clés ECDH, l’algorithme de padding v3, et une API publique de haut niveau plus un Context de chiffrement. En plus de ceux-ci, la surface NIP-46 suit dans le câblage de dispatch RPC à l’intérieur de LightSigner et un schéma PendingRequest qui porte le contexte v3 (kind plus portée), afin que le signataire puisse enregistrer pour quel kind d’événement et cas d’usage la charge utile v3 a été approuvée.

Clave diverge d’Amber sur la surface orientée utilisateur. Un schéma d’octroi de permission avec paliers de sensibilité permet aux utilisateurs d’octroyer le chiffrement v3 pour un kind d’événement et une portée particuliers à un niveau de sensibilité choisi. Lors de la première rencontre, des invites d’approbation conscientes du contexte v3 avec une carte explicative unique introduisent v3 aux utilisateurs. Le travail est dans main et est câblé dans le projet Xcode mais n’est pas publié ; le build étiqueté le plus récent est v0.2.0-build79 du 12 mai.

Deux implémentations indépendantes atterrissent NIP-44 v3 dans les chemins de production avant que la PR NIPs ne fusionne, ce qui renforce le cas pour le format de câble sous-jacent que la PR de protocole formalisera. Les tests d’interop inter-implémentations deviennent maintenant le chemin vers la convergence de spécification, avec la surface d’approbation Android d’Amber et le modèle de palier de sensibilité iOS de Clave comme les deux points de référence. D’autres signataires remote câblant v3 (noauth de nsec.app est dormant depuis mai 2025, et d’autres bunkers n’ont pas annoncé de travail v3) resserreraient encore le consensus.

Activité NIP-34 : Iris adopte la pile avec un nouveau transport hashtree

Iris a publié des annonces de dépôt NIP-34 pour hashtree le 8 juin et iris-apps, iris-drive, et iris-chat-rs le 9 juin, annonçant des URLs de clone sous un nouveau schéma htree:// servi depuis wss://temp.iris.to. Le transport hashtree est une alternative adressée par contenu aux clones routés GRASP, et ces quatre annonces sont ses premières utilisations publiques. Les dépôts portent des descriptions vides et les détails architecturaux émergent encore, mais le choix de publier via annonce NIP-34 (plutôt qu’un manifeste interne Iris personnalisé) signale qu’Iris s’engage envers la pile plus large NIP-34 git-over-Nostr.

NIP deep dive : NIP-67 (Indice de complétude EOSE)

NIP-67 ferme l’une des lacunes de correction les plus anciennes dans NIP-01. La spécification originale définit EOSE comme la frontière entre les événements stockés et les événements d’abonnement en direct pour un REQ, mais elle n’a jamais spécifié si le relais avait fini de livrer toutes les correspondances stockées ou s’était arrêté en cours de route à cause d’un plafond interne. Chaque relais applique un plafond par abonnement (communément 300 à 1000 événements) indépendant du limit du client, et les clients n’ont eu aucun moyen d’observer ce plafond.

La solution de contournement standard était de comparer le compte reçu contre le limit demandé. Si received < limit, traiter le résultat comme complet ; sinon paginer avec until=<oldest_created_at>. Les deux branches sont cassées. La branche received < limit tronque silencieusement : un client demandant 500 notes contre un relais plafonné à 300 voit 300 événements, conclut que le résultat est complet parce que 300 < 500, et ne récupère jamais le reste. Les événements retenus sur le relais ne peuvent pas signaler « plus disponible » à travers un message existant. La pagination comme seconde branche est gaspilleuse : un filtre qui correspond exactement au plafond nécessite un second REQ pour confirmer la complétude, retournant zéro événement tout en consommant un scan de filtre complet sur le relais.

Le correctif de NIP-67 est une chaîne optionnelle sur le message EOSE :

["EOSE", "<sub_id>", "finish"] // explicite : tous les événements stockés livrés
["EOSE", "<sub_id>"] // aucune revendication de complétude

Un relais qui annonce NIP-67 dans les supported_nips NIP-11 et émet un EOSE simple dit au client qu’il y en a plus. Un relais qui omet l’annonce conserve le comportement d’aujourd’hui, et le client revient à l’heuristique existante. Les clients legacy ignorent l’élément final du tableau. La rétrocompatibilité tient dans les deux directions, sans nouveaux verbes ou kinds d’événements.

Ce qui rend NIP-67 digne d’examen est la portée qu’il restreint délibérément. La spécification ne définit aucun curseur ou token de pagination, donc la pagination basée sur until reste le mécanisme. Les plafonds de relais restent là où ils sont, et le NIP ne nécessite aucune exposition de ceux-ci. NIP-67 préserve le sens de EOSE comme frontière stocké-vers-live et ajoute seulement un signal oui-ou-non à la frontière : « J’en ai plus pour vous » versus « c’est tout ». Cette surface minimale est pourquoi la PR a fusionné après une période de revue relativement courte pour une extension NIP-01, et pourquoi mattn note explicitement dans la PR que la traduction IA a été utilisée pour le texte anglais. Le changement est assez petit pour que l’incertitude de traduction n’importe pas.

Exemple d’échange conscient de NIP-67 entre un client et un relais appliquant un plafond. Annonce NIP-11 du relais :

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

L’échange au niveau du câble qui suit :

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 messages EVENT...]
← ["EOSE", "abc"] // pas de "finish" : plafond atteint, plus disponible
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 messages EVENT...]
← ["EOSE", "def", "finish"] // complète explicite

La réponse de 178 événements aurait précédemment déclenché un troisième REQ pour confirmer la complétude. Avec NIP-67, le client s’y arrête.

NIP-67 est également notable comme amendement NIP-01 atterrissant avec un consensus rare. La plupart des changements NIP-01 attirent de longs fils de débat parce que la petite surface du protocole est porteuse pour chaque implémentation. NIP-67 a fusionné après une période de revue prolongée (environ sept semaines de l’ouverture à la fusion), suggérant que quand un changement NIP-01 est assez petit et le mode de défaillance assez concret (perte silencieuse de données, aller-retour gaspillé obligatoire), les mainteneurs du protocole sont disposés à étendre le vocabulaire des messages centraux.

NIP deep dive : NIP-50 (Recherche)

NIP-50 définit le champ de filtre search dans les messages REQ, permettant aux clients de demander à un relais de filtrer les événements par correspondance full-text contre une chaîne de requête. La spécification de base fusionnée est délibérément minimale : le champ search est une chaîne, chaque relais décide de sa propre sémantique de recherche (quels champs sont indexés, comment fonctionne le scoring, si le stemming s’applique), et les relais annoncent le support NIP-50 dans leur document NIP-11. Les clients contrôlent l’algorithme de recherche uniquement à travers la chaîne de requête elle-même.

Ce minimalisme est à la fois la force et la contrainte de NIP-50. La force est que n’importe quel relais peut implémenter la recherche à n’importe quel niveau de qualité : un scan de sous-chaîne de base satisfait la spécification, et un relais exécutant Elasticsearch ou Meilisearch la satisfait également. La contrainte est que les clients manquent d’un moyen d’exprimer l’intention de recherche. Une UI de typeahead de mention de profil veut la correspondance de préfixe contre les noms d’affichage ; une recherche de contenu full-text veut le scoring full-text tokenisé à travers le corps de la note. Le même champ search porte les deux, et le relais doit deviner à partir de la forme de la requête.

PR #2357 ajoute le premier token d’extension NIP-50 : autocomplete:true ou autocomplete:false intégré dans la requête de recherche signale quel mode le client veut. Le relais de Ditto implémente le token pour les follow packs, les listes, et tout événement avec une balise title, passant à la correspondance de préfixe quand autocomplete:true est présent. Le token vit inline dans la requête (les champs de filtre séparés restent intacts), donc il voyage avec la chaîne de recherche et ne nécessite aucun bump de protocole de câble :

search: "fiat autocomplete:true"

Les indices en forme de token comme celui-ci sont la façon dont NIP-50 a toujours géré les dialectes spécifiques au relais. Les relais supportaient déjà des tokens comme language:en et domain:example.com. Chacun reste spécifique au relais, chaque relais documentant son propre dialecte. La PR #2357 de NIP-50 élève autocomplete d’un token privé au relais à un béni par la spécification, ouvrant la voie à une recherche consciente du typeahead à travers les relais.

Exemple REQ NIP-50 avec le token autocomplete, ciblant un relais qui indexe les titres de profil kind 0 :

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

Le REQ réel au niveau du câble :

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

Un relais qui ne reconnaît pas le token traite autocomplete:true comme faisant partie de la chaîne de recherche littérale et revient à la correspondance full-text, retournant des résultats corrects (bien que classés différemment). La dégradation gracieuse rend le token sûr à inclure inconditionnellement pour les clients qui préfèrent la correspondance de préfixe quand disponible.

La prochaine extension NIP-50 probable est le contrôle de classement par kind : un indice qui dit « classer par created_at descendant » versus le score de pertinence par défaut. Plusieurs relais acceptent déjà sort:newest comme token privé au relais, et le même chemin d’élévation qui a amené autocomplete dans la spécification s’applique. La recherche reste l’une des rares primitives Nostr où les relais rivalisent sur la qualité des résultats ; la fiabilité de la livraison est la même à travers tous les relais conformes. Les tokens incrémentaux permettent aux clients d’exploiter cette compétition de qualité sans forcer les relais à livrer une nouvelle spécification lourde.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 livre le chiffrement NIP-44 v3 avant la spécification. Mostro pose la fondation pour l’entiercement réglé en Cashu à travers huit PRs, enveloppant le Cashu Development Kit existant comme deuxième backend de règlement aux côtés de Lightning. Les podcasts NIP-F4 fusionnent après 27 mois de débat. fiatjaf ouvre une proposition contestée de découplage de clé NIP-17 qui rouvre l’argument architectural bunker-contre-Marmot. Amethyst livre l’étiquetage de hashtag NIP-32, un écran de podcast dédié et les zaps on-chain à travers 52 PRs non publiées.

Articles principaux

Amber 6.2.0 : chiffrement NIP-44 v3 livré

Amber v6.2.0, publié le 1er juin, ajoute le support de chiffrement NIP-44 v3 avec un écran d’approbation dédié, un aperçu d’intent, un aperçu bunker, la journalisation d’historique, et l’auto-rejet pour les demandes invalides. La sortie enregistre également les autorités ContentProvider NIP-44 v3 afin que d’autres apps Android puissent demander le chiffrement v3 aux côtés du chemin v2 existant. NIP-44 lui-même est la spécification de charge utile chiffrée versionnée utilisée par les DMs privés NIP-17, le trafic bunker NIP-46, et d’autres primitives Nostr ; v3 dans Amber est un opt-in aux côtés de v2, signalé par une méthode de signataire séparée afin que les clients côté récepteur puissent négocier l’algorithme explicitement. La PR NIPs correspondante n’a pas encore atterri, donc Amber déploie v3 avant le consensus de protocole, avec le format de câble et l’autorité ContentProvider enregistrés pour l’intégration client en aval.

Les sessions NIP-46 acceptent maintenant automatiquement les demandes de ping à la connexion, supprimant l’invite au premier aller-retour après l’appairage. La méthode de signataire sign_message a été entièrement supprimée après avoir été dépréciée et inutilisée.

Parce qu’Amber est le signataire Android dominant, chaque client en aval qui veut v3 doit cibler le format de câble d’Amber jusqu’à ce que la PR NIPs atterrisse. Cela donne à Amber un mot implicite sur la spécification v3 finale jusqu’à ce que le protocole rattrape. L’échange est réel : v3 en production permet à Amber de rassembler des retours d’implémentation pour le NIP éventuel, au coût d’un point de référence à implémentation unique temporaire que d’autres clients doivent maintenant égaler.

Mostro : intégration d’entiercement Cashu via CDK

grunch a atterri huit PRs à travers MostroP2P cette semaine intégrant les primitives multisig P2PK existantes de Cashu (NUT-10 et NUT-11) comme deuxième backend de règlement aux côtés de Lightning sur l’échange Bitcoin P2P coordonné par Nostr. Les primitives cryptographiques sont celles de Cashu ; le travail est un échafaudage d’intégration et un nouveau trait de backend d’entiercement. Mostro core v0.12.0, publié le 30 mai, ajoute les types de protocole pour l’entiercement multisig 2-de-3, les signatures P_M par preuve, et permet les événements d’entiercement via la validation de réponse. L’architecture est documentée dans PR #756 et utilise des clés de trade par commande clarifiées dans PR #757.

L’implémentation s’est déployée à travers six PRs de suivi sur une seule journée. F2 (PR #758) a ajouté la config, le mode d’entiercement, et le démarrage conditionnel. La tranche suivante, F3 (PR #760), a défini un trait EscrowBackend avec une implémentation Lightning et un stub Cashu, permettant à Mostro de commuter les backends de règlement sans changer la machine d’état de commande. F4 (PR #759) a enveloppé CDK (le Cashu Development Kit) pour les opérations de mint et de portefeuille. Le travail de base de données dans F5 (PR #761) a ajouté des verrous d’entiercement compare-and-swap et des requêtes de verrous actifs. F6 (PR #762) a construit un mint conteneurisé dans une tâche CI dédiée pour les tests d’entiercement de bout en bout. Le flux Mostro utilise déjà les DMs gift-wrapped NIP-59 pour la coordination de commandes sur le relais, donc l’entiercement Cashu s’insère comme deuxième option de règlement aux côtés de Lightning sans toucher au protocole de câble.

Sorties

ngit v2.5.0 : fallback GRASP et fetches git paresseux

ngit v2.5.0 change le comportement par défaut de git push pr/<branch> et ngit send pour produire un kind PR pour les nouvelles propositions quand le dépôt a au moins un serveur GRASP enregistré. Auparavant, cela ne se déclenchait que pour les commits surdimensionnés de plus de 60 KB ou les commits contenant des submodules. Quand une PR ne peut pas être poussée vers les serveurs GRASP du dépôt, ngit revient maintenant au routage GRASP-06 via les serveurs déclarés. Le drapeau ngit send --git-server ou git push -o git-server=<url> permet aux contributeurs de cibler une URL git personnalisée ou un serveur GRASP explicitement.

Les republications ngit init préservent maintenant les balises inconnues des annonces existantes, afin que les balises ajoutées par une future version de ngit ou un outil tiers survivent à la republication. Un avertissement jaune liste les balises reportées, et --clean les supprime à la demande. ngit pr apply, ngit pr checkout, et ngit pr list consultent les serveurs git paresseusement et partagent un helper de fetch unique, afin que le checkout ne fetch plus inconditionnellement quand le commit est déjà local. ngit pr checkout essaie également les URLs de clone fournies par le soumetteur depuis l’événement PR comme fallback quand les serveurs git déclarés du dépôt ne portent pas le tip de la PR, correspondant au comportement existant dans ngit pr apply. ngit est l’implémentation de référence NIP-34 pour la collaboration git sur Nostr, et v2.5.0 fait de GRASP le chemin de première classe pour les nouveaux contributeurs.

Jumble v26.5.7 : stripping EXIF et compteurs de zap validés

Jumble v26.5.7 ajoute deux changements qui affectent directement la vie privée de l’utilisateur et l’intégrité des données. Les identifiants de localisation et de caméra EXIF sont maintenant supprimés des uploads d’images avant qu’ils ne quittent le client, fermant une surface de fuite de métadonnées de longue date qui affectait chaque image postée depuis Jumble. Les compteurs de zap sont maintenant calculés uniquement à partir de reçus cryptographiquement validés, corrigeant les compteurs gonflés provenant d’événements de zap malformés qui permettaient aux attaquants d’exagérer les totaux de zap sur les notes. La sortie ajoute également la vérification d’identité d’expéditeur pour les DMs NIP-17, fermant une surface d’usurpation où un expéditeur pouvait forger sa pubkey dans le seal.

nostr-calendar v1.6.0 : RSVP et gestion des participants en double

nostr-calendar v1.6.0 atterrit le flux RSVP de Formstr (PR #169) et empêche les participants en double dans les invitations à un événement (PR #168). L’option waitForAll dans la fonction de publication par défaut est maintenant à false pour que l’UI ne se bloque pas sur les relais lents (PR #170). PR #157 a livré les deux brouillons de proposition NIP de Formstr pour la planification de rendez-vous et les réservations.

Sprout 0.3.6 : Sprout × mesh-llm et sections de canal

Sprout v0.3.6 est le titre d’une série de six sorties de v0.3.1 à v0.3.6 cette semaine. L’intégration in-process de Sprout × mesh-llm atterrit dans PR #798, permettant à Sprout de servir et consommer des nœuds mesh-llm via l’admission de relais. Les sections de canal définies par l’utilisateur se synchronisent entre les appareils via Nostr dans PR #792, et les sections de canal arrivent sur mobile avec la synchronisation relais dans PR #800. Les notifications conscientes des fils avec des contrôles mute et follow mutables arrivent dans PR #761.

Les pièces jointes de type de fichier arbitraire avec cartes de téléchargement sont arrivées dans PR #810, étendant Sprout au-delà des pièces jointes image uniquement. Mobile a gagné un onglet de fil social Pulse (PR #772) et le polissage Pulse à travers les surfaces de fil, composition et filtre (PR #796).

NostrBotKit v0.5.0 : chat de groupe Marmot dans un framework de bot Rust

NostrBotKit v0.5.0, publié le 24 mai sur Codeberg, ajoute le support Marmot (MLS-over-Nostr, NIP-104) au framework de bot Rust auto-hébergé. Quand marmot: true est défini, le bot publie ses key packages MLS (kind 443, 30443, 10051), accepte les invitations de groupe automatiquement, et écoute les messages dans les groupes rejoints. Deux nouveaux types de commande, dm_marmot et dm_marmot_npub, permettent aux bots d’envoyer des messages dans des groupes Marmot nommés ou des chats Marmot 1:1 via des tâches cron ou des webhooks. Pour prévenir les boucles de rétroaction avec d’autres bots, les bots NostrBotKit ne répondent qu’aux messages explicitement adressés à eux via /command ou @botname/command. Les pièces jointes chiffrées utilisant MIP-04 sont automatiquement déchiffrées et re-uploadées via Blossom ou NIP-96, et la base de données d’état MLS est chiffrée avec une clé dérivée de la clé privée du bot. NostrBotKit est le premier framework Rust à livrer un support de bot NIP-104, ouvrant le déploiement de bots chiffrés par Marmot à un profil d’opérateur différent du chemin TypeScript existant.

noscrypt v0.1.14 : sortie de bibliothèque cryptographique signée

noscrypt v0.1.14 est une sortie de sécurité de la bibliothèque cryptographique C utilisée par plusieurs clients Nostr pour les primitives secp256k1, NIP-04 et NIP-44. La sortie livre des téléchargements signés PGP vérifiables contre la clé publique du mainteneur. Les clients en aval qui empaquettent noscrypt devraient valider la signature avant l’intégration.

Chama v1.3.0 : nouvel entiercement P2P Nostr-natif avec Fedimint

Chama v1.3.0, publié le 1er juin, est le titre d’une série de quatre sorties pour un nouveau client d’entiercement P2P Nostr-natif qui utilise l’ecash Fedimint et le partage de secret Shamir 2-de-3 pour le règlement. Le projet est livré sur getchama.app et fonctionne sans serveur. v1.3.0 introduit « heal that sticks » (rediffusion réussie et guérison de trade qui survivent aux redémarrages de session) et l’appariement de rails de paiement, où les Chamas orientées US font surface les rails de paiement US en premier. Le travail préparatoire pour les vitrines multi-unités a atterri à travers v1.2.11 (schéma multi-unités) et v1.2.12 (comptable de stock de vitrine + durcissement de récupération de pont Fedimint natif). Chama rejoint Mostro et Shopstr dans la catégorie marketplace Nostr, distinguée par son architecture sans serveur et son règlement d’entiercement basé sur Fedimint.

Changements non publiés

Amethyst : étiquetage de hashtag NIP-32, écran de podcast, pistes musicales

Amethyst a fusionné 52 PRs et 411 commits cette semaine sans couper une balise de sortie. Le plus grand ajout fonctionnel est PR #3111, qui implémente l’étiquetage de hashtag NIP-32 et un fil de hashtag basé sur les étiquettes utilisant des événements kind 1985 avec des balises L de namespace et l d’étiquette. Cela remplace le mécanisme fragile de correspondance de texte #tag par un modèle de découverte basé sur les étiqueteurs où les utilisateurs peuvent suivre des npubs d’étiqueteurs spécifiques comme ils suivent des créateurs de contenu. PR #3105 ajoute un écran de podcast dédié avec liste d’épisodes et lecteur en ligne, atterrissant dans les jours suivant la fusion de la spécification podcast NIP-F4. PR #3071 ajoute un fil d’applications logicielles avec filtrage de liste de suivis, et PR #3067 ajoute le support des pistes musicales et playlists via les ensembles NIP-51.

Les signataires éphémères pour les uploads de posts anonymes atterrissent dans PR #3123, permettant aux utilisateurs de poster anonymement sans exposer leur clé d’identité aux services d’upload. Un watchdog d’auto-guérison Tor avec des tests d’intégration contre Arti v2.3.0 arrive dans PR #3053, renforçant le routage Tor d’Amethyst pendant les pannes réseau transitoires. Les zaps on-chain et un filtre NIP-05 pour les utilisateurs revenant de Gemini atterrissent dans PR #3052, élargissant la surface de zap au-delà de Lightning aux paiements Bitcoin on-chain.

Shopstr : validation d’URL d’aperçu OpenGraph

PR #504 valide les URLs d’aperçu OpenGraph avant de les rendre dans les annonces de marketplace, fermant une surface XSS potentielle où des vendeurs malveillants pourraient intégrer du contenu scripté via des métadonnées OG conçues. Les boutiques hébergées par Shopstr affichent des aperçus OG pour les liens externes, et les URLs non validées permettent à un attaquant d’injecter du contenu arbitraire dans l’UI de la boutique.

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

NIP-F4 (Podcasts) fusionné après deux ans

PR #1093 a fusionné le 28 mai, deux ans et trois mois après que fiatjaf ait ouvert le projet original. NIP-F4 définit les épisodes de podcast comme événements kind 54 avec des balises imeta pour les métadonnées de fichier audio (URL, type mime, code de langue ISO, URLs de fallback, drapeau de service NIP-96, débit binaire, durée), une balise title, des balises optionnelles image et description, et des balises t pour les étiquettes de sujet. La spécification garde délibérément RSS comme source de vérité : les épisodes peuvent porter une balise i référençant le GUID de podcast RSS, permettant aux clients Nostr de créer des liens vers les flux de podcast existants sans dupliquer l’hébergement audio. Le long débat dans le fil de la PR (avec le co-auteur podcast-namespace Dave Jones, Alex Gleason, et Mike Terenzio) s’est stabilisé sur un modèle de coexistence où Nostr fournit la couche sociale au-dessus de RSS tandis que RSS garde la couche de distribution. PR #3105 d’Amethyst atterrit l’écran de podcast dans les jours suivant la fusion de la spécification, et le travail du sélecteur de GIF de Jumble inclut également un échafaudage précoce de pièces jointes de podcast.

Découplage de clé NIP-17 (PR #2361)

fiatjaf a ouvert PR #2361 le 1er juin, proposant que NIP-17 sépare la clé d’identité de la clé de chiffrement. Les destinataires annoncent leur clé de chiffrement dans un nouvel événement kind 10044, et les expéditeurs utilisent cette clé annoncée (quand présente) pour le seal interne gift-wrap, ne revenant à la clé d’identité du destinataire que quand l’annonce est absente. La PR ajoute également une balise n au seal portant la pubkey de chiffrement de l’expéditeur, afin que les récepteurs puissent dériver la bonne clé de conversation sans déchiffrement d’essai contre chaque clé retirée. La motivation déclarée est l’UX bunker : sous la conception actuelle, un utilisateur bunker doit faire l’aller-retour de chaque DM reçu à travers le signataire pour déchiffrer, puisque la clé de chiffrement est la clé d’identité détenue par le signataire. Le découplage permet au client de détenir la clé de chiffrement localement tout en gardant la clé d’identité dans le bunker pour les signatures.

La proposition a attiré la revue la plus contestée de la semaine. Cody Tseng (Jumble) la soutient comme le chemin le plus facile vers l’interopérabilité DM inter-clients. Vitor Pamplona (Amethyst) objecte sur deux terrains : elle ajoute un nouveau secret de déchiffrement à long terme en dehors du bunker, et les clients qui ne la livrent pas échoueront silencieusement à déchiffrer les messages des clients qui la livrent, sans chemin de dégradation parce que la rupture est à la couche seal. Pamplona soutient que le problème est déjà correctement résolu par les key packages et la rotation d’époque de Marmot, et que rétrofitter la séparation de clé dans la spécification NIP-17 de base crée le genre d’échec d’interop que Marmot a mis deux ans à concevoir. Le contre-argument de fiatjaf a trois parties : le découplage est optionnel par destinataire, le correctif de balise n aborde la préoccupation de déchiffrement d’essai, et l’alternative est de garder l’UX bunker cassée pendant que Telegram mange le cas d’usage de messagerie. Le fil reste ouvert sans décision de fusion et est la discussion NIP la plus surveillée du trimestre.

Flux de paiement NIP-Silent Payments (PR #2362)

silentius-satoshi a ouvert PR #2362 le 1er juin comme compagnon du projet NIP Nostr Silent Payments plus large (PR #2355). Le NIP de flux de paiement définit kind 8352 pour les notifications de reçu de silent payment (livrées via gift wrap NIP-59 afin que le lien de reçu ne soit pas publiquement observable) et kind 10353 pour un cache UTXO chiffré qui se synchronise entre les appareils pour le même portefeuille Silent Payments. La paire ensemble permet à un payeur de signaler un paiement à une adresse Silent Payments en utilisant des primitives Nostr-natives sans exposer le lien on-chain sur la couche relais ouverte.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan a ouvert PR #2364 le 1er juin comme brouillon. Il introduit un transport packet-tree avec trois nouveaux kinds adressables : 39078 porte le manifeste, 39079 porte les tranches individuelles, et 39080 porte les demandes de réparation. La spécification définit un format de câble où les gros fichiers sont divisés en tranches adressables, avec des manifestes décrivant l’arbre des tranches et des demandes de réparation permettant aux récepteurs de demander les tranches manquantes. Le statut d’ébauche précoce s’applique, et la proposition n’a pas encore attiré de revue de mainteneur.

Espaces live audio/vidéo NIP-29 (PR #2238)

PR #2238 a fusionné le 28 mai, étendant les groupes relais NIP-29 avec le support d’espaces live audio et vidéo. Les groupes peuvent maintenant référencer une session d’espace live active, permettant aux événements de style NIP-53 live activity de s’ancrer dans un contexte de groupe NIP-29.

Pistes audio multiples vidéo NIP-71 (PR #2255)

PR #2255 a fusionné le 28 mai, ajoutant des balises imeta de piste audio aux événements vidéo NIP-71. Le nouveau format porte l’URL, le hash, le type mime, la balise de langue (avec ISO-639-1 plus drapeau de version originale), les URLs de fallback, le signal de service NIP-96, le débit binaire, et la durée. Cela permet le streaming audio uniquement (podcasts vidéo), la commutation de résolution avec audio stable, les pistes multilingues, et un stockage réduit quand les serveurs n’intègrent pas directement l’audio dans les fichiers vidéo. Les clients devraient vérifier la disponibilité de piste audio avant d’assumer un comportement à piste unique.

Gift wrap éphémère NIP-59 (PR #2245)

PR #2245 a fusionné le 28 mai, ajoutant kind 21059 comme équivalent éphémère du gift wrap kind 1059 existant. La sémantique correspond au wrap standard NIP-59 mais suit les règles d’événement éphémère selon NIP-01 (les relais les abandonnent après la diffusion et ne les persistent pas). Cela permet aux apps de choisir la persistance selon les exigences : les indicateurs de saisie et les pings de présence bénéficient de l’éphémère, tandis que l’historique DM a besoin de persistance.

Kind spécifique à l’application NIP-78 (PR #2292)

PR #2292 a fusionné le 28 mai, reclassant les données spécifiques à l’application NIP-78 comme kind adressable normal, abandonnant la plage séparée précédente. Cela simplifie la sémantique de remplaçabilité et aligne NIP-78 avec le modèle d’événement adressable utilisé par d’autres NIPs d’état d’application.

Clarifications NIP-85 (PR #2304)

PR #2304 a fusionné le 28 mai avec de petites améliorations au langage autour de plusieurs clés et relais par fournisseur de service dans les Trusted Assertions NIP-85, clarifiant le chemin de rotation de clé d’opérateur pour les services d’assertion de relais.

Gestion de connexion de relais NIP-01 en une ligne (PR #2307)

PR #2307 a fusionné le 28 mai, ajoutant une seule phrase à NIP-01 sur la façon dont les clients devraient gérer les durées de vie de connexion aux relais. Le correctif aborde une lacune de longue date où les clients différaient sur l’opportunité de garder les connexions WebSocket ouvertes après la récupération, menant à une perte silencieuse de messages sur les relais qui abandonnent les connexions inactives.

Contrainte de chat kind 9 NIP-C7 (PR #2310)

PR #2310 a fusionné le 28 mai, restreignant les vues de chat NIP-C7 aux messages kind 9 uniquement. Cela sépare le chat éphémère des posts de timeline kind 1 dans les clients qui implémentent des surfaces de chat de style NIP-C7.

Simplification NIP-55 (PR #2363)

PR #2363 par greenart7c3, ouvert le 1er juin, simplifie la spécification d’application signataire Android. Vitor Pamplona a signé « Looks good » et fiatjaf a demandé si c’était prêt à fusionner. Le changement ouvre la voie à l’enregistrement d’autorité ContentProvider NIP-44 v3 qu’Amber a livré cette semaine.

NIP-44 v3 (implémentation Amber avant la spécification)

Amber a livré NIP-44 v3 dans v6.2.0 avec huit commits implémentant la mise à niveau de chiffrement et l’enregistrement d’autorité ContentProvider, mais la PR de spécification du dépôt NIPs n’a pas encore atterri. NIP-44 lui-même définit un format de charge utile chiffrée versionnée utilisé à l’intérieur des événements signés ; le v2 existant (en production depuis 2024) utilise ECDH secp256k1, HKDF, padding, ChaCha20, HMAC-SHA256, et base64. Le format de câble v3 ajoute un nouvel octet de version (0x03) avant le nonce, permettant aux clients récepteurs de négocier l’algorithme explicitement. L’implémentation d’Amber inclut l’auto-rejet pour les demandes v3 invalides, un écran d’approbation dédié distinct des approbations v2, et la journalisation de texte-clair par direction pour l’historique. Jusqu’à ce que la PR NIPs fusionne, v3 reste comme extension spécifique à Amber. Traitez-la comme un signal prospectif, pas comme une signalisation stable à l’échelle du protocole.

NIP deep dive : NIP-32 (Étiquetage)

NIP-32 définit un moyen structuré pour tout acteur Nostr d’étiqueter des événements, pubkeys, relais, URLs, ou sujets en utilisant des événements adressables kind 1985 avec un vocabulaire d’étiquettes à namespace. La spécification introduit deux nouvelles balises : L dénote un namespace d’étiquette, et l dénote une étiquette dans ce namespace. Les balises cible d’étiquette (e, p, a, r, ou t) spécifient ce qui est étiqueté. L’exigence de namespace empêche plusieurs systèmes d’étiquettes d’entrer en collision : une étiquette spam dans nip28.moderation porte une sémantique différente d’une étiquette spam dans relay-report.

Le choix de conception qui rend NIP-32 utile au-delà de la modération est que les étiquettes sont des assertions, pas une vérité au niveau du protocole. Un événement kind 1985 dit seulement qu’un pubkey particulier a étiqueté une cible particulière dans un namespace particulier. Le modèle de confiance est délégué au client : chaque client choisit quels étiqueteurs honorer, quels namespaces lire, et quelle affordance UI donner à chaque étiquette. La même primitive porte les avertissements de contenu, l’attribution de licence, les balises de langue ISO-639-1 sur les notes kind 1, les balises géographiques ISO-3166-2, la classification de contenu, les suggestions de modération distribuée, et les scores de réputation.

PR #3111 d’Amethyst cette semaine est le plus grand déploiement à ce jour. Il ajoute l’étiquetage de hashtag via NIP-32 et un fil de hashtag basé sur les étiquettes, permettant aux utilisateurs de parcourir par étiquettes assignées par des étiqueteurs de confiance. Le mécanisme de correspondance de texte #tag antérieur qui pilotait initialement la découverte de hashtag sur Nostr reste comme fallback pour les notes non étiquetées. Le modèle hashtag-comme-étiquette signifie que la même note peut être découvrable sous plusieurs étiquettes assignées par différents étiqueteurs, et les utilisateurs peuvent mute ou booster des étiqueteurs spécifiques sans affecter les notes sous-jacentes.

L’auto-étiquetage est également supporté. Un auteur peut attacher directement des balises L et l à ses propres notes kind 1 pour déclarer la langue, l’emplacement et le sujet. Une note étiquetée ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] s’auto-identifie comme anglaise et peut être filtrée par des clients conscients de la langue sans infrastructure d’étiquetage tierce.

Exemple d’événement d’étiquette NIP-32 étiquetant une note kind 1 comme anglaise et lui assignant une balise de modération :

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Le déploiement Amethyst combiné avec le récent travail sur les Trusted Relay Assertions suggère que NIP-32 devient le substrat standard pour tout modèle « assertion pilotée par l’utilisateur sur une cible » sur Nostr. Le prochain test est de savoir si les étiqueteurs eux-mêmes développeront des hiérarchies de confiance : si les utilisateurs suivront des npubs d’étiqueteurs spécifiques comme ils suivent des créateurs de contenu.

NIP deep dive : NIP-F4 (Podcasts)

NIP-F4 a fusionné cette semaine, deux ans et trois mois après que fiatjaf ait ouvert le projet original (PR #1093). Le préfixe F est un simple numérotage hex : NIP-F0 à NIP-FF utilisent le même espace hex de 1 octet que NIP-0A à NIP-0D, avec la plage hex supérieure servant de dépassement maintenant que la plage décimale 01-99 se remplit. NIP-F4 définit comment les podcasts publient des épisodes et des métadonnées comme événements Nostr tout en gardant RSS comme couche complémentaire pour le fichier audio lui-même.

Le choix architectural central est que chaque podcast est sa propre paire de clés Nostr. La spécification s’ouvre directement avec cela : « chaque podcast est sa propre paire de clés Nostr ». Cela permet aux podcasts de combiner leur présence de podcasting avec une présence normale de microblogging kind 0 / kind 1, et permet à un podcast de changer de propriété au fil du temps par transfert de clé ou signature partagée de style MuSig2. Quatre kinds d’événements portent la couche de publication :

kind:10154 : métadonnées de podcast remplaçables. Porte les balises title, image, description, website optionnelles, et des balises p optionnelles marquant les auteurs avec un role de host, cohost, ou editor.
kind:10164 : contre-revendication d’auteur. L’exemple dans la spécification utilise kind 10064 (une faute de frappe ouverte à la correction), mais le titre et le texte environnant l’identifient comme kind:10164. Les utilisateurs listent les pubkeys de podcast dont ils sont auteurs, afin que les clients puissent vérifier les balises p dans kind:10154 contre une revendication équivalente de l’auteur supposé. Sans cela, un podcast pourrait faussement étiqueter n’importe qui comme hôte.
kind:54 : événements d’épisode rédigés par la pubkey du podcast directement. Les balises incluent title, image optionnel, description, et une ou plusieurs balises audio. Chaque balise audio est ["audio", "<audio-url>", "<optional_media_type>"]. La spécification note « d’autres champs importants à spécifier ici plus tard après une découverte plus approfondie », et la forme fusionnée est délibérément minimale.
kind:10054 : une liste de podcasts favoris de style NIP-51, permettant aux utilisateurs de marquer quels podcasts ils suivent.

Le débat de fil autour de la fusion impliquait le co-auteur Podcasting 2.0 Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z, et staab. Jones a argumenté fortement contre toute tentative de remplacer RSS : « Ça a été essayé plusieurs fois et échoue toujours », citant JSONfeed, XMPP, AMP, l’API Twitter, et la migration ratée de Spotify. Terenzio a recadré la proposition comme une couche sociale au-dessus de RSS, gardant RSS lui-même comme couche de distribution. fiatjaf a accepté de reculer et de laisser la proposition mûrir : « Je suis d’accord avec tout ce que vous avez dit mais je pense toujours qu’on peut y arriver, arrêtons ici pour un moment. » Deux ans plus tard, la spécification fusionnée atterrit plus près de la coexistence que du remplacement.

Trois questions de conception restent explicites dans la spécification fusionnée :

La faute de frappe kind:10164 (l’exemple montre 10064) doit être réconciliée avant que les clients puissent interopérer en toute sécurité.
La découverte au niveau épisode sans liaison GUID RSS est laissée ouverte. La spécification fusionnée n’a pas de balise i, pas de format podcast:item:guid, et pas de mécanisme de pontage RSS. Les clients qui veulent ponter un catalogue RSS existant vers des événements kind 54 doivent définir la convention de pontage eux-mêmes.
Le stub « autres champs importants » sur la définition kind:54 laisse le débit binaire, la durée, la langue, les pointeurs de transcription, les chapitres, et les métadonnées par segment comme territoire ouvert pour des propositions de suivi.

PR #3105 d’Amethyst atterrit un écran de podcast dédié avec liste d’épisodes et lecteur en ligne dans les jours suivant la fusion, la première implémentation majeure de client. Jumble a livré un échafaudage précoce de pièces jointes de podcast aux côtés de son sélecteur de GIF. Wavlake reste la plus grande plateforme de podcast Nostr-native et devra décider s’il faut aligner ses événements de piste musicale kind 31337 existants avec le modèle d’épisode kind 54 de NIP-F4.

Exemple d’événement d’épisode kind 54 NIP-F4, correspondant à l’ensemble minimal de balises de la spécification fusionnée :

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episode 42: Why RSS Won"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones and fiatjaf on protocol coexistence and the social layer."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "In this episode we discuss the two-year journey of NIP-F4 from draft to merge, and why coexistence with RSS turned out to be the right architectural choice.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

PR #1093 est resté ouvert pendant 27 mois, bien au-dessus de la durée médiane d’ouverture pour les PRs NIPs fusionnées. Le prochain test pour NIP-F4 est de savoir si la faute de frappe kind 10164 est réconciliée, si les conventions de découverte d’épisode et de pontage RSS émergent des implémenteurs, et si les grands hôtes de podcast publient sous des paires de clés par podcast comme la spécification le recommande.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

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.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 livre une coque Android reconstruite, Amethyst ajoute les zaps Bitcoin onchain, White Noise gagne le rendu markdown et les liens profonds, Keycast passe un audit de sécurité, et AgentNoise vous permet de contrôler des agents de codage IA locaux via un chat chiffré par Marmot. Hostr lance une plateforme P2P de location d’hébergement sur Nostr avec quatre projets de NIPs couvrant les annonces, les réservations et l’entiercement basé sur EVM. Angor migre la messagerie chiffrée de NIP-04 vers NIP-44, Dart NDK ajoute NIP-77 et un signataire web, Alby js-sdk v8 livre une reconnexion multi-relais NWC native, et KeyChat corrige un trou de forward secrecy dans la suppression des préclés uniques Signal. Côté protocole, la caution anti-abus de Mostro atteint la Phase 2, Wisp livre les réponses privées et les réactions gift-wrapped, et une vague d’implémentation Namecoin NIP-05 touche une demi-douzaine de clients en une seule semaine.

Articles principaux

Primal 3.5 pour Android

Primal, le client social soutenu par sa propre infrastructure de relais de cache, a livré 3.5.9 cette semaine avec une coque d’application reconstruite. La refonte remplace la structure de navigation précédente par une nouvelle disposition et un nouvel écran Explorer, donnant à la surface de découverte principale sa propre maison dédiée. La sortie ajoute la lecture audio pour les aperçus de liens, afin que les fichiers audio intégrés dans les notes soient lus en ligne sans quitter le fil. Les badges de vérification NIP-05 s’affichent maintenant en ligne sur les profils, faisant apparaître la confirmation d’identité en un coup d’œil. Le filtrage des notifications a reçu une refonte, permettant aux utilisateurs de restreindre quels types d’événements atteignent leur liste de notifications. L’éditeur a gagné une meilleure gestion des liens d’événements, et la couche de base de données sous-jacente a reçu des correctifs de stabilité.

White Noise : markdown, liens profonds et métadonnées audio

White Noise, l’application de messagerie de groupe chiffrée par Marmot construite sur Nostr et MLS (RFC 9420), a eu l’une de ses semaines les plus occupées à ce jour à travers les dépôts frontend et backend.

Sur le frontend, PR #665 ajoute le rendu markdown complet pour les messages de chat, afin que le gras, l’italique, les blocs de code et les liens s’affichent maintenant nativement dans la vue des messages. PR #675 active le flux quitter-le-groupe qui était précédemment bloqué pour les non-derniers-admins, et PR #661 ajoute le support natif des liens profonds pour les URI whitenoise:// et whitenoise-staging:// couvrant les utilisateurs, les chats et les paramètres, sans nécessiter aucune infrastructure de redirection HTTP.

Sur le backend dans whitenoise-rs, PR #835 fait fonctionner correctement la rotation des key packages en réutilisant le slot d_tag pour les publications kind:30443, activant la sémantique d’événement remplaçable NIP-33 afin que les rotations successives de key package remplacent l’événement précédent sur les relais, ne gardant que le key package actuel. PR #833 étend FileMetadata avec des champs optionnels duration_ms et waveform pour les pièces jointes audio, coordonné avec PR #300 de MDK qui ajoute les mêmes champs aux balises média MIP-04. Un nouveau crate whitenoise-markdown (PR #836) remplace l’analyseur de token nostr-sdk précédent par une bibliothèque de rendu markdown dédiée.

La spécification Marmot elle-même a reçu un correctif de sécurité dans PR #68, qui ferme un problème de sécurité en spécifiant explicitement HKDF-SHA256 pour les dérivations de clé d’image dans MIP-01, supprimant une ambiguïté qui pourrait mener à une divergence d’implémentation. Dans MDK, PR #307 assainit les raisons d’échec de welcome et plafonne la longueur stockée, fermant une constatation de sécurité distincte.

Amethyst v1.10.0 : Zaps Bitcoin onchain

Amethyst a livré quatre sorties cette semaine, avec v1.10.0 comme titre. La sortie ajoute le support des zaps Bitcoin onchain NIP-BC, permettant aux utilisateurs d’envoyer, recevoir et afficher des zaps réglés directement onchain via des transactions Bitcoin. Les sorties précédentes dans la série ont corrigé la détection de blob Blossom pour rejeter les noms de fichiers non conformes (v1.09.2), corrigé les règles ProGuard pour les builds de bureau, et fusionné la pull request #2977 pour montrer les zappeurs Bitcoin onchain comme une ligne ₿ dédiée dans la galerie de réactions étendue. Un écran d’historique de transactions on-chain en cours avec pagination a atterri dans PR #2974.

AgentNoise : contrôler des agents de codage via White Noise

AgentNoise par nvk est un helper de bureau natif en Rust qui vous permet d’utiliser un téléphone exécutant White Noise comme surface de contrôle pour des sessions d’agents de codage Codex et Claude locales. L’outil écoute un ou plusieurs chats White Noise, authentifie les expéditeurs via un flux PIN de premier appairage, et lance des agents de codage locaux via le lanceur configuré. Envoyer /claude <prompt> depuis votre téléphone ouvre une nouvelle session de travail White Noise nommée d’après le nom d’hôte de la machine et un court résumé du prompt, puis diffuse les mises à jour de progression et la sortie finale de retour dans ce chat. Il est intentionnellement Rust-first et garde Node hors du chemin de pont de confiance. Le projet a atteint v0.1.24 cette semaine, ajoutant des réponses plus courtes lisibles par téléphone, des références de tâches par préfixe unique court, et un watcher de session local en opt-in. AgentNoise pilote les CLI wn et wnd de marmot-protocol/whitenoise-rs en tant que sous-processus, donc il partage son transport Nostr avec le client White Noise lui-même.

Audit de sécurité Keycast terminé

Keycast, le serveur de signature à distance NIP-46 orienté équipe qui stocke les clés privées Nostr chiffrées au repos dans SQLite, a terminé un audit de sécurité en mai 2026. La passe de durcissement a abordé les problèmes d’authentification, de permission, d’intégrité des données et de dépendances, et les résultats sont documentés dans AUDIT.md. Les changements incluent : l’auth HTTP NIP-98 nécessite maintenant exactement une balise u et une balise method, rejette les horodatages périmés, et valide les hashes de payload ; la liste blanche ALLOWED_PUBKEYS est analysée exactement et appliquée côté serveur ; les politiques vides refusent par défaut les demandes de sign/encrypt/decrypt ; l’application des clés étrangères est activée sur les connexions SQLite ; et les routes d’application imbriquées telles que /teams/:id sont protégées côté serveur. Une migration SQL normalise l’ancien JSON de permission allowed-kinds au démarrage. Le projet est encore en phase précoce et l’audit note des éléments résiduels avant de lui confier de vraies clés d’équipe.

Scramble : client Marmot pour bureau et Android

Scramble (anciennement OpenChat) est un client .NET/Avalonia de bureau et Android pour le protocole Marmot, implémentant les MIPs 00-04 : publication de KeyPackage (kind:30443), métadonnées de groupe avec l’extension MLS NostrGroupData, événements de welcome gift-wrapped NIP-59 (kind:444), messages chiffrés ChaCha20-Poly1305 (kind:445), et pièces jointes média chiffrées Blossom. Il est entièrement interopérable avec White Noise et tout autre client compatible Marmot.

Le projet a livré 13 sorties cette semaine, avec le support multi-appareils comme fonctionnalité principale. Chaque appareil génère un slot KeyPackage unique (une balise d sur kind:30443). Au démarrage, Scramble récupère les KeyPackages propres de l’utilisateur depuis les relais, détecte les IDs de slot des appareils pairs, et les ajoute automatiquement aux groupes MLS existants via le flux de commit en étapes. L’auto-ajout est restreint aux groupes où l’utilisateur actuel est admin ; les groupes non-admin sont sautés avec des instructions pour demander à l’admin du groupe. Une bannière de divulgation de forward secrecy informe les appareils nouvellement liés que les anciens messages ne sont pas disponibles. Une passe de réconciliation d’ID de slot (TryReconcileSlotId) gère les appareils migrés depuis les versions pré-multi-appareils en comparant les octets de KeyPackage du relais avec le matériel de clé local pour adopter la bonne balise d. La reconnexion du signataire externe pour les utilisateurs Amber et NIP-46 a également été corrigée : la garde IsConnected qui bloquait la reconnexion automatique intégrée de ExternalSignerService a été supprimée aux neuf sites d’appel dans NostrService.

Hostr : hébergement locatif P2P sur Nostr

Hostr (source) est une plateforme d’hébergement locatif peer-to-peer construite entièrement sur Nostr. Elle couvre le flux complet de style Airbnb (recherche et annonces de propriétés, négociation de réservations, et règlement des paiements) en utilisant quatre projets de NIPs que le projet développe en parallèle avec l’application.

Le NIP d’hébergement étend les annonces classées NIP-99 (kind:30402 actif, kind:30403 brouillon) avec des balises spécifiques à l’hébergement pour le type (room, house, apartment, villa, hotel, hostel, resort), les heures d’arrivée/départ, le séjour minimum, et les index de cellule géospatiale H3 pour la recherche basée sur la localisation à précision configurable. Le NIP de réservation définit un protocole complet de négociation et de cycle de vie : les événements de réservation remplaçables kind:32122 portent un ID de trade d, une balise d’ancrage d’annonce a, et des balises de participants p avec les rôles (buyer, seller, escrow) ; les rumeurs de messages structurés kind:1327 délivrent les contre-offres privées d’étape de négociation via des gift wraps NIP-59 afin que la négociation reste hors des relais publics ; les événements de transition en ajout uniquement kind:1326 créent une piste d’audit publique une fois qu’une réservation s’engage. La vie privée de l’acheteur est préservée via des clés Nostr temporaires par trade liées à l’identité réelle de l’acheteur via des balises participant_proof chiffrées. Le NIP d’entiercement définit les publicités de service d’entiercement kind:30303 et les déclarations de confiance utilisateur kind:17388 ; l’implémentation de référence utilise des smart contracts EVM sur Rootstock, avec contractBytecodeHash permettant aux clients de vérifier que le contrat déployé correspond à une implémentation auditée connue. Le NIP d’annonce de marketplace définit des balises génériques partagées entre tous les profils de marketplace NIP-99, y compris instantBook, negotiable, quantity, securityDeposit, cancellationPolicy et maxDisputePeriod. Cette semaine, le projet a préparé sa soumission à l’app store et fusionné le support d’identité de client MCP pour l’automatisation orientée agent.

Deux nouvelles entrées sont apparues sur la plateforme Shakespeare MiniApps cette semaine : InkPress, un générateur de magazine IA qui publie du contenu structuré de style magazine en tant qu’événements Nostr, et PressStr, une plateforme d’écriture et de publication pour la pile Soapbox.

Livraison cette semaine

ngit v2.4.4

ngit a livré v2.4.4, ajoutant ngit sync --trust-server (-t) pour les cas où un serveur git est en avance fast-forward sur l’état Nostr. Quand cette situation est détectée, sync signale les refs affectées et nécessite le drapeau pour signer et publier un événement d’état mis à jour ; un paramètre de configuration git nostr.trust-server-domains fournit une liste blanche séparée par des points-virgules pour les serveurs qui devraient être approuvés automatiquement sans le drapeau.

Amber v6.1.0-pre3 ajoute la signature PSBT

Amber a publié v6.1.0-pre3 avec une disposition améliorée pour les nouvelles connexions d’app, des correctifs de crash, et une option de sélection/désélection tout sur l’écran des permissions. PR #438 ajoute le support de signature PSBT à travers les chemins basé sur Intent et basé sur relais NIP-46, permettant à Amber de signer des Partially Signed Bitcoin Transactions sans exposer la nsec à l’application demandeuse.

Wisp v1.1.0 livre les réponses privées et abandonne le support Amber

Wisp a publié v1.1.0 avec les réponses privées via gift wrap NIP-17 (PR #540), les réactions gift-wrapped et zaps DIP-03 sur les réponses privées (PR #543), l’auto-traduction pour les notes (PR #523), et une saisie fiat de style registre sur le dialogue de zap. PR #541 migre les zaps privés d’un schéma texte-clair de relais DM maison vers DIP-03 avec un routage de relais DM correct. Le même cycle de sortie a supprimé le support du signataire distant NIP-55 (PR #531), abandonnant Amber et autres intégrations de signataires externes, et supprimé le relais local intégré (PR #533). Wisp est un client social Nostr pour Android.

Calendar by Formstr v1.5.4 corrige le gift wrap pour les nouveaux participants

Calendar by Formstr a livré v1.5.4 (le dernier dans une séquence v1.5.2 → v1.5.4). PR #160 corrige un bug où l’édition d’un événement de calendrier privé avec de nouveaux participants publiait l’événement mis à jour avec les nouveaux pubkeys dans les balises p mais ne créait ni ne délivrait jamais les invitations gift wrap à ces participants, cassant le flux d’invitation pour les ajouts de dernière minute. PR #156 ajoute la gestion des erreurs autour du déchiffrement d’événements privés afin que les clients ne lancent plus sur les événements indéchiffrables, et PR #138 corrige les heures d’événements récurrents qui dérivaient entre fuseaux horaires.

Applesauce v6.1.0 ajoute les git casts NIP-34 et les relais de lookup NIP-51

Applesauce a publié v6.1.0 à travers ses packages avec un support significatif de NIP-34 (git-over-Nostr) : applesauce-common ajoute de nouveaux casts GitRepository, GitGraspList et FavoriteGitRepos plus des usines correspondantes, et expose les propriétés réactives User.favoriteGitRepos$, User.gitAuthors$ et User.graspServers$ afin que les applications puissent lister les dépôts git suivis d’un utilisateur, les mainteneurs de dépôts et les serveurs GRASP configurés directement depuis le même objet User. La même sortie ajoute le support des listes de relais de lookup kind 10086 NIP-51, un ajout récent à la famille de listes de relais utilisé pour découvrir où trouver des données spécifiques. applesauce-core gagne replaceableAddress sur EventCast pour la recherche d’adresse remplaçable NIP-01, plus pointer, kind, et un helper getReplaceableAddressForEvent, et ajoute une méthode timeline$() sur le cast User de base. PR #73 corrige les méthodes manuelles du pool qui abandonnaient silencieusement les relais hors ligne.

Sprout v0.0.16 livre le binaire Sprig et le protocole huddle v2

Sprout par Block, un espace de travail d’équipe basé sur des relais Nostr auto-hébergé où les humains et les agents IA partagent les mêmes salles et journal d’événements, a livré v0.0.16 de l’application de bureau aux côtés de builds continus du nouveau binaire tout-en-un Sprig (PR #605), qui rassemble le harnais ACP, l’agent et le MCP développeur dans un seul binaire de style busybox pour un déploiement facile. Le drapeau --no-memory ajouté dans PR #611 permet aux opérateurs de désactiver l’injection de mémoire centrale NIP-AE pour le harnais ACP. Côté temps réel, PR #609 étend le protocole vocal huddle à un en-tête de trame v2 supportant jusqu’à 10 pairs simultanés.

Nostrord v1.0.3 ajoute le trousseau OS et le multi-compte

Nostrord a publié v1.0.3 avec un stockage de clés locales durci utilisant le trousseau OS et une phrase de passe de secours, le support multi-compte, et un code QR bunker cliquable qui ouvre l’application signataire sur Android.

Angor migre vers NIP-44 et livre un durcissement de sécurité

Angor, l’application de crowdfunding Bitcoin construite sur Nostr et Taproot, a livré trois versions instables cette semaine (v0.2.24, v0.2.25, et v0.2.26) avec un ensemble de changements de durcissement de sécurité et d’intégration Nostr. PR #860 migre la messagerie chiffrée Nostr de NIP-04 vers NIP-44, remplaçant le schéma XOR déprécié par le chiffrement ChaCha20-Poly1305. PR #861 permet les uploads de médias Blossom sans portefeuille sélectionné en utilisant une clé d’auth Nostr éphémère, débloquant les uploads pour les utilisateurs qui n’ont pas encore connecté de portefeuille. La série de sécurité a abordé plusieurs catégories durcies : PR #854 ajoute la sécurité de type pour AngorKey et la protection mémoire des mnémoniques, PR #856 applique une validation au niveau protocole pour les timelocks, les taux de frais, les seuils dust et les règles de pénalité, et PR #851 applique un durcissement non-cassant à travers huit catégories de sévérité moyenne et basse. PR #859 corrige la compatibilité GrapheneOS en activant la compilation AOT et en supprimant la génération de code à l’exécution, et PR #855 empêche la perte de portefeuille sur swipe-kill Android en persistant l’état du portefeuille avant que l’OS ne termine le processus.

Alby js-sdk v8.0 livre la reconnexion multi-relais NWC

Alby js-sdk a publié la ligne v8.0 (v8.0.1 à v8.0.3) avec le support d’abonnement multi-relais NWC. PR #516 met à jour la dépendance nostr-tools et active la reconnexion automatique native à travers plusieurs relais, remplaçant l’approche de polling précédente par une logique de reconnexion native au relais. PR #542 remplace tous les appels console.debug par une interface de logger injectable afin que les développeurs d’application puissent router les diagnostics SDK à travers leur propre infrastructure de journalisation. La sortie abandonne le polyfill WebSocket, nécessitant Node.js 22 ou supérieur pour les consommateurs côté serveur. v8.0.2 a ajouté un correctif pour un bug d’import crypto utils qui cassait certains bundlers.

KeyChat v1.41.1 corrige la forward secrecy

KeyChat, une application de messagerie qui combine le protocole Signal avec le transport de relais Nostr, a publié v1.41.1+6513. Le correctif principal impose la forward secrecy en supprimant les préclés uniques Signal immédiatement après un déchiffrement réussi, fermant un trou où une préclé retenue pourrait être utilisée pour déchiffrer des messages passés si l’appareil était compromis plus tard. La sortie ajoute également un aperçu d’URL pour les messages consistant en un seul lien, centralise l’auto-téléchargement de médias sous un nouveau FileDownloadManager avec un seuil automatique de 20 Mo, et refactorise la récupération d’infos de relais NIP-11 pour forcer le rafraîchissement au démarrage à froid afin que les configurations de frais de relais payants se chargent toujours correctement.

En développement

Citrine a fusionné PR #151 implémentant l’application de NIP-70 : le relais Android bloque maintenant les reposts qui intègrent du contenu d’événement protégé, comme la spécification l’exige. PR #149 ajoute des actions d’affichage et de copie pour plusieurs adresses de connexion, localhost, Wi-Fi local et Tor, depuis l’écran des paramètres du relais. PR #141 ajoute la gestion des défis AUTH NIP-42 via l’intégration d’un signataire externe avec Amber.

Mostro a atteint la Phase 2 de son déploiement de caution anti-abus. PR #737 atterrit la logique de slash de caution dirigée par le solveur : les gestionnaires admin consomment maintenant la charge utile BondResolution de mostro-core, permettant à un admin de slasher la caution de l’une ou l’autre partie lors de la résolution d’un litige. Phase 1.5, fusionnée dans PR #736, a introduit une action PayBondInvoice dédiée et un statut WaitingTakerBond, séparant le paiement de la caution anti-abus du taker du paiement de l’acheteur. Le client mobile a ajouté l’UX complète de Phase 1.5 dans PR #592. Mostro est un protocole d’échange Bitcoin peer-to-peer construit sur Nostr.

Damus a fusionné PR #3773 restaurant l’indicateur de signal de relais, et PR #3775 corrige les relais qui refusaient de se reconnecter après un échec de connexion initial.

rust-nostr a fusionné PR #1358 ajoutant des traits de finalisation d’événements et des constructeurs d’événements spécifiques à NIP, rendant plus facile la construction d’événements correctement typés pour des fonctions de protocole spécifiques. PR #1363 rétroporte un correctif garantissant que le signataire NIP-46 s’abonne aux notifications avant d’envoyer la réponse de connexion, fermant une condition de course où les messages client arrivant immédiatement après la connexion pouvaient être manqués.

dart-nostr a fusionné PR #44 ajoutant un résolveur de relais .bit Namecoin et des enregistrements de pin TLSA, permettant aux applications Flutter de résoudre les URLs de relais wss://example.bit/ via DNS Namecoin vers leurs adresses WebSocket réelles.

Dart NDK (le kit de développement Nostr Dart/Flutter, maintenant à relaystr/ndk) a fusionné PR #464 implémentant NIP-77, le protocole de signature d’événement hors ligne. Côté signataire, PR #602 et PR #601 ajoutent un signataire d’événement spécifique au web et une abstraction PlatformEventVerifier, permettant aux applications Flutter web d’utiliser le signataire de plateforme sans chemin de code séparé ; PR #604 introduit une usine de signataire d’événement pour la sélection de signataire à l’exécution. PR #608 ajoute getDmRelays() pour récupérer la liste de relais DM NIP-17 d’un utilisateur (kind:10050), et PR #600 corrige la préservation des champs signés NIP-46 afin que les signataires distants ne perdent pas de champs sur l’aller-retour.

Pages by Form* (repo), l’application de document collaboratif nostr-native de Formstr hébergée à pages.formstr.app, a fusionné quatre PRs cette semaine resserrant les flux de pièces jointes chiffrées et de gestion de documents. PR #37 corrige les images manquantes dans les exports DOCX, HTML et PDF en incorporant les pièces jointes chiffrées : il récupère les blobs <encrypted-file> depuis les serveurs Blossom, les déchiffre avec AES-GCM 256 bits en utilisant la clé et le nonce stockés, valide le type MIME de l’image, et les convertit en URLs de données base64 afin que les exports préservent les images qui n’existent sur Blossom que sous forme chiffrée. PR #39 ajoute un mécanisme de recherche de document local, PR #38 nettoie le flux de renommage, et PR #40 corrige la gestion des sauvegardes partagées.

Zap Cooking a fusionné PR #396, la première phase d’une refonte du fil qui pose les primitives de rendu de fil sans aucun changement visible par l’utilisateur pour le moment. La PR introduit un analyseur de balises imeta NIP-92 qui lit les slots url, m (MIME), dim (dimensions), blurhash, alt, x (hash de fichier) et fallback, plus un décodeur blurhash canonique porté à la main (~200 LOC) qui produit des URLs de données PNG via canvas avec un fallback null SSR-safe. Quand les balises imeta sont absentes, l’analyseur revient à extraire les URLs d’images et vidéos brutes du contenu de l’événement en utilisant les mêmes heuristiques que le fil actuel utilise déjà.

Nurunuru (ぬるぬる, tami1A84/null--nostr), un client Nostr avec des variantes natives Android, iOS et Web partageant un moteur FFI Rust, a fusionné sa synchronisation Native → Web v1.5.0 dans PR #176. La synchronisation apporte plusieurs ajouts de fonctionnalités à la version Web qui ont déjà été livrés sur Android v1.4.9 et iOS 1.0.4 : le NotificationModal fait maintenant surface les notifications d’anniversaire, la détection de zap mutuel-suivi, et les notifications de réaction emoji personnalisée ; le sélecteur de réaction abandonne la ligne rapide de réactions Unicode par défaut et centre l’UX sur les emojis personnalisés ; le moteur de recommandation dans lib/recommendation.js filtre les utilisateurs sans icônes ou noms d’affichage et priorise les entrées Following avec chargement Recommended en arrière-plan. L’entrée vocale est la seule fonctionnalité qui va dans l’autre direction : la version Web utilise déjà le streaming ElevenLabs Scribe, et v1.5.0 synchronise partiellement le côté Natif vers le SpeechRecognizer standard OS (Android) et SFSpeechRecognizer + AVAudioEngine (iOS) tandis que l’intégration Scribe Natif complète est différée à v1.6.

Travail de protocole et de spécification

PR #2251 resserre la spécification des événements protégés NIP-70 : il déclare maintenant explicitement que les reposts intégrant le contenu complet d’un événement protégé doivent être rejetés par les relais. NIP-70 définit la balise - qui signale qu’un auteur de note ne consent pas à ce que sa note soit republiée. La spécification originale couvrait le comportement de filtrage du relais, mais laissait le cas de repost ambigu. Cette PR ferme cette lacune. PR #151 de Citrine implémente l’application côté relais cette même semaine.

PR #1653 propose un NIP Drafts pour sauvegarder et synchroniser les événements brouillons privés. La proposition utilise des événements remplaçables avec un statut draft et un chiffrement NIP-44 vers la propre clé de l’auteur, permettant aux clients de sauvegarder des travaux en cours sur les relais sans que ces événements soient visibles par qui que ce soit d’autre. L’événement brouillon porte l’événement complet destiné à la publication en tant que contenu chiffré, y compris son kind et ses balises éventuels.

Snapshots (PR #2279) est une proposition ouverte pour définir un événement de snapshot immuable pour préserver une version exacte d’un événement Nostr remplaçable. L’événement de snapshot porte le contenu complet de l’événement remplaçable à un moment donné, avec une balise a le liant à l’adresse de l’événement remplaçable afin que toutes les versions historiques soient interrogeables ensemble. Cela permet aux observateurs d’inspecter l’état historique même après que les relais aient cessé de retenir les anciennes versions.

Vague Namecoin NIP-05 : Cette semaine a vu une poussée coordonnée pour ajouter la résolution NIP-05 .bit aux clients Nostr. Le fil de discussion NIP a capturé des PRs open-source contre Aegis (#14, qui ajoute la vérification au moment de la signature au signataire), nostter (#2128), et dart-nostr (#44), aux côtés d’un projet de NIP upstream (PR #2349). La PR Aegis est notable pour placer la vérification côté producteur : le signataire vérifie la chaîne Namecoin avant de signer tout événement kind:0 qui revendique une identité .bit et avertit l’utilisateur en cas de non-correspondance, attrapant le problème avant que l’événement n’atteigne un relais.

NIP Deep Dive : NIP-07 (window.nostr pour les navigateurs web)

NIP-07 définit l’interface window.nostr que les extensions de navigateur exposent aux applications web. C’est l’interface de signataire la plus largement déployée sur le web, implémentée par des extensions incluant Alby, nos2x, Flamingo et horse.

L’interface a deux méthodes requises et plusieurs optionnelles. window.nostr.getPublicKey() retourne la clé publique de l’utilisateur sous forme de chaîne hex sans jamais exposer la clé privée à la page appelante. window.nostr.signEvent(event) prend un événement partiel avec created_at, kind, tags et content, et retourne l’événement signé complet avec id, pubkey et sig ajoutés. Le point clé est que la clé privée ne quitte jamais le contexte isolé de l’extension ; l’application web soumet un événement non signé et reçoit en retour un signé.

Les méthodes optionnelles couvrent le chiffrement : window.nostr.nip04.encrypt et window.nostr.nip04.decrypt pour l’ancien schéma NIP-04 (maintenant déprécié), et window.nostr.nip44.encrypt et window.nostr.nip44.decrypt pour le schéma NIP-44 actuel. Les extensions qui supportent NIP-44 peuvent donc gérer à la fois le chiffrement de messages directs et toute autre application qui a besoin de chiffrement par clé pubkey sans que la page appelante voie la nsec.

La spécification inclut également une recommandation aux auteurs d’extension : charger les scripts avec "run_at": "document_end" dans le manifeste de l’extension afin que window.nostr soit disponible de manière synchrone au chargement de la page, évitant les conditions de course où un client vérifie window.nostr avant que l’extension ne l’ait injecté.

Un exemple clé de NIP-07 en action est le projet Keycast couvert ci-dessus. Le frontend web Keycast utilise NIP-07 pour signer les événements d’auth HTTP NIP-98 : l’application SvelteKit ne gère jamais la nsec de l’utilisateur directement. Elle appelle window.nostr.signEvent pour produire l’en-tête d’auth, puis envoie cet en-tête à l’API Keycast. Cette architecture signifie que le matériel de clé reste dans l’extension du navigateur tout au long du flux complet de gestion des clés d’équipe.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

NIP Deep Dive : NIP-39 (identités externes dans les profils)

NIP-39 définit comment un utilisateur Nostr peut déclarer le contrôle d’identités de plateformes externes dans son profil. Chaque déclaration utilise une balise i à l’intérieur d’un événement kind:10011, affirmant la propriété d’un compte spécifique sur une autre plateforme avec une preuve qui peut être vérifiée indépendamment.

Chaque balise suit le format ["i", "platform:identity", "proof"], où platform:identity combine le nom de la plateforme et le nom d’utilisateur avec un séparateur deux-points (github:semisol, twitter:semisol_public). proof pointe vers un artefact vérifiable sur la plateforme elle-même.

Pour GitHub, la preuve est un ID Gist. L’utilisateur crée un Gist public depuis son compte GitHub contenant le texte Verifying that I control the following Nostr public key: npub1.... Un client vérifiant la revendication récupère https://gist.github.com/<identity>/<proof> et vérifie que le Gist a été rédigé par le nom d’utilisateur GitHub revendiqué et contient le pubkey attendu. Pour Twitter, la preuve est un ID de tweet, pour Mastodon un ID de post, et pour Telegram une référence de message dans un groupe public.

Le nom du fournisseur d’identité ne doit contenir que a-z, 0-9 et les caractères ._-/, et ne doit pas contenir :. Les noms d’identité doivent être normalisés en minuscules, avec l’alias principal utilisé quand plusieurs existent.

La discussion Namecoin .bit NIP-05 qui se déroule cette semaine montre le rôle de NIP-39 dans la pile d’identité plus large : elle fournit un moyen standardisé, indépendant du relais, de croiser une clé Nostr avec une identité établie ailleurs, sans nécessiter d’autorité de vérification centrale. Un client peut vérifier indépendamment la preuve en récupérant un artefact public sur la plateforme nommée, et la preuve est liée au pubkey Nostr spécifique dans le texte du Gist ou du tweet, pas à un identifiant de plateforme générique.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

C’est tout pour cette semaine. Si vous construisez quelque chose ou avez des nouvelles à partager, DM-nous sur Nostr ou trouvez-nous à nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire du développement du protocole Nostr.

Cette semaine : Nostr VPN livre huit versions en sept jours, d’un flux de jumelage d’appareils repensé à un échange AEAD FIPS qui double environ le débit TCP. Marmot Protocol (la fondation de White Noise) livre une version frontend complétant la fonctionnalité de blocage des utilisateurs et 31 PR fusionnées dans MDK et le backend. Grain livre v0.6.0 avec quatre nouvelles implémentations NIP en un seul jalon. Citrine livre v3.0.0-pre1 avec Tor intégré et agrégation de relais. Amber livre v6.1.0-pre2 avec des améliorations du flux de connexion et de la signature. Alby Hub livre v1.22.2 avec une page IA et Agents et l’intégration Core Lightning. Mostro livre des cautions de preneur concurrentes et mostro-core v0.11.0. Jumble livre cinq versions avec l’historique de recherche récent et des corrections de persistance des données de compte. Nostrord livre trois versions avec des modales de partage de groupe et des paquets Arch Linux. Flotilla livre 1.8.0 avec des appels vidéo, le rendu d’e-mails et les mentions de salles. Calendar by Formstr livre v1.5.1 avec la planification de rendez-vous et la synchronisation du calendrier Android. Tamagostrich lance un Tamagotchi NIP-78 décentralisé avec des récompenses en sats.

Actualités principales

Nostr VPN livre huit versions culminant en v4.0.10

Nostr VPN, le VPN mesh décentralisé basé sur Rust utilisant Nostr pour la découverte de pairs, a livré huit versions de v4.0.1 à v4.0.10 sur macOS, Linux, Windows et Android. Le changement phare dans v4.0.8 : l’AEAD est passé du backend logiciel RustCrypto chacha20poly1305 au ChaCha20-Poly1305 de BoringSSL dans ring 0.17, qui utilise NEON optimisé à la main sur aarch64 et AVX2/AVX-512 sur x86_64. Les benchmarks Docker sur matériel identique ont montré le débit TCP direct à 2 nœuds passer de 437 à 1097 Mbps. v4.0.9 a ajouté le batching sendmmsg(2) sur le chemin d’envoi UDP, poussant le TCP single-stream de 1066 à 1548 Mbps (1,45×). v4.0.10 a livré une refonte complète de l’interface utilisateur pour le jumelage d’appareils.

Marmot / White Noise livre une version frontend complétant le blocage d’utilisateurs et 31 PR fusionnées dans MDK et le backend

White Noise a livré v2026.5.7+24 le 7 mai complétant l’ensemble de fonctionnalités de blocage. Un utilisateur bloqué est désormais masqué des invitations, des aperçus de chat, des fils de messages, des résultats de recherche et des notifications, et ses messages ne comptent plus dans les badges non lus. MDK a intégré la PR #258 avec le format wire de l’extension v3 et le schéma disappearing_message_secs, posant les bases des messages éphémères.

Grain v0.6.0 ajoute NIP-40, NIP-50, NIP-70 et NIP-45

Grain a livré v0.6.0 le 6 mai avec quatre nouvelles implémentations NIP. L’expiration d’événements NIP-40 permet aux éditeurs de définir un horodatage d’expiration pour que le relais supprime les événements après leur expiration. La recherche plein texte NIP-50 permet aux clients d’émettre des filtres de recherche dans les messages REQ. Les événements protégés NIP-70 empêchent les relais de repartager des événements sans la permission explicite de l’auteur. Les requêtes de comptage NIP-45 permettent aux clients de demander à un relais de renvoyer un décompte des événements correspondants.

Publications de la semaine

Citrine v3.0.0-pre1 intègre Tor et l’agrégation de relais

Citrine a livré v3.0.0-pre1 avec le support Tor intégré pour un accès aux relais préservant la confidentialité et l’agrégation de relais, où Citrine peut récupérer des événements depuis plusieurs relais amont et les servir aux clients locaux. La PR #139 ajoute le support NIP-77 (Negentropy Reconciliation) pour la synchronisation d’événements efficace basée sur la réconciliation d’ensembles.

Amber v6.1.0-pre2 améliore le flux de connexion des nouvelles applications

Amber a livré v6.1.0-pre2. Les principaux correctifs : la boîte de dialogue de signature se ferme maintenant correctement après avoir accepté une demande bunker, les demandes bunker malformées affichent un écran de demande invalide, et une limitation de débit est ajoutée pour les demandes de signature basées sur les intentions.

Alby Hub v1.22.2 ajoute la page IA et Agents et le support Core Lightning

Alby Hub a livré v1.22.2. La nouvelle page IA et Agents expose les capacités Lightning et NWC d’Alby Hub aux agents IA et aux outils compatibles MCP. Core Lightning (CLN) est désormais un backend pris en charge aux côtés de LND et LDK.

Mostro livre des cautions de preneur concurrentes et mostro-core v0.11.0

Mostro a fusionné 11 PR faisant avancer la fonctionnalité de caution de preneur. La PR #733 implémente des cautions de preneur concurrentes où plusieurs preneurs peuvent soumettre des factures de caution simultanément et le premier à verrouiller gagne. mostro-core a livré v0.11.0 avec la PR #144 ajoutant Action::PayBondInvoice et Status::WaitingTakerBond. mostro-cli a livré v0.15.0.

Jumble livre cinq versions avec la recherche récente et la persistance des comptes

Jumble a livré v26.5.2 à v26.5.6. v26.5.5 ajoute l’historique de recherche récent. Un bug de persistance critique est corrigé dans v26.5.6 : les comptes et les données en cache survivent désormais à un redémarrage complet de l’application.

Nostrord livre des modales de partage de groupe, le téléversement de médias et des paquets Arch Linux

Nostrord a livré v1.0.0, v1.0.1 et v1.0.2. v1.0.1 livre des paquets Arch Linux via AUR sous le nom nostrord-bin avec des artefacts signés PGP, un bouton de saut au dernier message, et le collage d’images/médias dans le chat. v1.0.2 ajoute le partage de groupe via la PR #49 avec une modale de partage générant à la fois un URI nostr:naddr et un lien nostrord.com/open/.

FIPS v0.3.0 livre une portée multiplateforme, la découverte de pairs Nostr et une passerelle pour les LAN non modifiés

FIPS a livré v0.3.0, un jalon majeur passant de Linux uniquement à Linux, macOS, Windows et OpenWrt. Les nœuds publient désormais des annonces d’overlay signées en tant qu’événements remplaçables paramétrés kind:37195 sur des relais Nostr publics. Le même échange ring 0.17 ChaCha20-Poly1305 qui a alimenté le gain de débit de Nostr VPN arrive également dans FIPS v0.3.0.

Camelus v1.10.1 livre des versions bureau

Camelus a livré v1.10.1 avec des versions bureau Windows et Linux, élargissant sa distribution au-delà du mobile uniquement.

Flotilla 1.8.0 livre des appels vidéo, le rendu d’e-mails et les mentions de salles

Flotilla a livré 1.8.0. Les salles vocales prennent désormais en charge la vidéo : les participants peuvent activer leurs caméras ou partager leur écran en cours d’appel. Le rendu d’e-mails arrive via une mise à jour de la bibliothèque welshman. Les mentions de salles permettent aux utilisateurs de référencer d’autres salles et relais avec des liens inline cliquables.

Calendar by Formstr livre v1.5.1 avec la planification de rendez-vous et la synchronisation du calendrier Android

Calendar by Formstr a livré v1.5.0 le 10 mai et v1.5.1 le 11 mai. La planification de rendez-vous permet aux utilisateurs de créer des créneaux réservables. L’intégration du calendrier Android en lecture seule synchronise les événements Nostr avec le calendrier de l’appareil.

En développement

Amethyst ajoute les publications programmées, les règles de communauté NIP-9A et un relay local bureau

Amethyst a fusionné 78 PR cette semaine. Les publications programmées arrivent dans la PR #2765. Une version bureau gagne un relay local intégré avec persistance des événements SQLite dans la PR #2841. Trois PR implémentent les règles de communauté NIP-9A : la PR #2798 valide les publications par rapport aux règles de communauté avant l’envoi, la PR #2799 ajoute un éditeur de règles NIP-9A structuré, et la PR #2800 ajoute un filtre de fil NIP-9A optionnel.

Shopstr ajoute la journalisation d’audit MCP et la sécurité des sessions

Shopstr a fusionné cinq PR. La journalisation d’audit pour la couche d’outils MCP arrive dans la PR #456. La sécurité des sessions se renforce dans la PR #477 avec l’épinglage de session à la clé API d’origine et l’éviction TTL.

Dart NDK ajoute le support web et la vérification des signatures de sceau

Dart NDK a fusionné six PR. Le support web arrive dans SembastCacheManager via la PR #571. La vérification des signatures de sceau arrive dans la PR #595 pour le flux NIP-59 Gift Wrap.

Nouveaux projets

Tamagostrich lance un Tamagotchi NIP-78 décentralisé avec des récompenses en sats

Tamagostrich est un jeu d’animal de compagnie virtuel basé sur le navigateur lancé à l’IDENTITY Hackathon 2026 où un bébé autruche, Nori, évolue grâce à votre activité sociale Nostr. L’état de l’animal vit dans un événement NIP-78 kind:30078 pour la synchronisation multi-appareils. Les récompenses de jalons sont versées en sats via NIP-47 : 50 sats au niveau 5, 210 sats au niveau 10, et 420 sats au niveau maximum 21, envoyés à l’adresse lud16 de l’utilisateur.

Travaux sur le protocole et les spécifications

Cinq nouvelles propositions ont été ouvertes cette semaine :

La PR #2331 propose NIP-9A : Verifiable Community Rules, introduisant kind:34551 pour des documents de règles de communauté cryptographiquement signés et lisibles par machine.

La PR #2335 propose des Reservation Events pour les marchés Nostr, définissant kind:32122 (événements de réservation remplaçables paramétrés), kind:1326 (enregistrements d’audit de transition en ajout uniquement), et kind:32124 (avis post-transaction). La négociation est privée via des messages enveloppés NIP-59 Gift Wrap.

La PR #2334 propose des Escrow Services pour les marchés Nostr utilisant kind:30303 pour que les opérateurs d’entiercement déclarent leur adresse de contrat EVM et leur grille tarifaire.

La PR #2333 propose des Accommodation Listing Profiles pour NIP-99 Marketplace Listings, étendant NIP-99 avec des balises g d’index géospatial H3 pour les annonces de location courte durée.

La PR #2332 propose NIP-BC : Onchain Zaps (kind 8333), exploitant l’identité directe entre les clés Nostr et les adresses Bitcoin Taproot. Le numéro de kind reflète NIP-57 : 9735 est le port P2P Lightning ; 8333 est le port P2P du mainnet Bitcoin.

NIP Deep Dive : NIP-78 (données spécifiques aux applications)

NIP-78 définit une façon standard pour les applications de stocker des données privées ou publiques arbitraires pour le compte d’un utilisateur en utilisant des événements Nostr. Le type d’événement principal est 30078, un événement remplaçable paramétré où le tag d est une chaîne d’identifiant définie par l’application. Une application donne à son emplacement de stockage un tag d unique et publie un événement 30078 avec le contenu JSON ou texte qu’elle doit persister. La motivation principale est la synchronisation multi-appareils sans serveur centralisé. Pour les données d’application privées, les événements NIP-78 peuvent chiffrer le champ de contenu en utilisant NIP-44 avant la publication. Les utilisateurs actuels incluent Tamagostrich (synchronisation de l’état de l’animal), Wisp (sauvegarde du portefeuille et paramètres de sécurité), NosPress (état d’orchestration CMS), et plusieurs implémentations de synchronisation des paramètres de clients Nostr.

Sources principales :

Spécification NIP-78 : https://github.com/nostr-protocol/nips/blob/master/78.md
Tamagostrich : https://github.com/Negr087/tamagostrich

Voir aussi : NIP-51 Lists, NIP-65 Relay List Metadata

NIP Deep Dive : NIP-98 (HTTP Auth)

NIP-98 définit un schéma d’authentification HTTP permettant aux paires de clés Nostr d’autoriser les requêtes aux serveurs HTTP, éliminant les noms d’utilisateur, les mots de passe ou les tokens OAuth. Un client construit un événement Nostr de courte durée de type 27235, le signe avec sa clé privée, encode le JSON en base64, et l’envoie dans un en-tête HTTP Authorization: Nostr . L’événement de type 27235 inclut la méthode HTTP dans un tag method, l’URL complète de la requête dans un tag u, et un horodatage created_at. Le serveur valide la signature, vérifie que la méthode et l’URL correspondent, et contrôle que l’horodatage est récent pour prévenir les attaques par rejeu. NIP-98 est utilisé dans Blossom (BUD-01) pour l’authentification des téléversements de blobs, Routstr pour le contrôle d’accès API par requête, Sprout pour l’authentification du transport git, et Alby Hub pour l’authentification de l’API d’administration.

Sources principales :

Spécification NIP-98 : https://github.com/nostr-protocol/nips/blob/master/98.md
BUD-01 : https://github.com/hzrd149/blossom/blob/master/buds/01.md

Voir aussi : NIP-96 HTTP File Storage Integration

C’est tout pour cette semaine. Si vous construisez quelque chose ou avez des nouvelles à partager, envoyez-nous un DM sur Nostr ou retrouvez-nous sur nostrcompass.org.

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire de Nostr.

Cette semaine : Marmot Protocol livre MDK 0.8.0 avec les premiers primitives de notification MIP-05, des paquets de clés NIP-51 adressables et une revue de sécurité renforcée. LaWallet NWC livre v0.10.0, la plus grande version depuis le financement OpenSats, apportant un tableau de bord administrateur complet, un portefeuille utilisateur, un journal d’activité de bout en bout, et le nouveau schéma LightningAddress 1→N et NWCConnection. Amethyst effectue un sprint de stabilisation de Nests avec élimination des coupures audio lors du renouvellement JWT, des abonnements aux données de clés tenant compte du cycle de vie, une reconnexion relay keep-alive, et un indicateur animé du participant en train de parler. ngit livre v2.4.2 et v2.4.3 corrigeant la détection des serveurs GRASP pour les soumissions de PR et le filtrage des événements d’état multi-remote. GRAIN livre v0.5.4 avec un durcissement de production et une correction silencieuse de perte de données. Mostro Core livre v0.10.1 avec des artefacts de version signés PGP. Clave lance v0.2.0 avec la gestion multi-comptes sur iOS.

Actualités principales

MDK 0.8.0 ajoute les primitives de notification MIP-05 et les paquets de clés adressables

MDK, la bibliothèque Rust principale du protocole Marmot, a livré v0.8.0 le 4 mai. Cette version embarque les premiers blocs de construction de notification MIP-05, fait passer les paquets de clés MIP-00 en événements adressables pour qu’un paquet de clés utilisateur puisse être remplacé sur place, améliore la compatibilité des groupes à versions mixtes, élargit la couverture UniFFI pour les bindings mobiles, et resserre les chemins de validation autour des actions d’administration, des commits, du stockage, des bornes de chiffrement et de la gestion des replays. Les primitives MIP-05 incluent des helpers d’index de feuille ajoutés dans la PR #235, qui donnent aux clients aval suffisamment d’informations pour livrer des notifications push par destinataire sans révéler la structure du groupe. La PR #273 restaure la publication de crates.io de mdk-core, et la PR #269 expose le module test_util derrière une fonctionnalité Cargo test-utils pour que les suites de tests clients externes puissent partager le harnais de test de Marmot.

LaWallet NWC v0.10.0 livre le monorepo complet et le portefeuille utilisateur

LaWallet NWC, l’implémentation NIP-47 Nostr Wallet Connect de l’équipe LaWallet, a livré v0.10.0 le 30 avril. C’est la plus grande version depuis que le projet a reçu un financement OpenSats. Elle embarque le monorepo complet, le tableau de bord administrateur intégral, un portefeuille utilisateur, un journal d’activité de bout en bout, une marque dynamique, et le nouveau schéma LightningAddress 1→N et NWCConnection. Le portefeuille utilisateur livré dans la PR #191 couvre l’intégration, l’accueil, l’envoi/réception, le scan, les devises, un fil d’activité et un cache hors ligne.

Amethyst stabilise Nests avec keep-alive, résilience JWT et abonnements de cycle de vie

Amethyst, le client Android riche en fonctionnalités, a poursuivi les travaux sur les salles audio NIP-53 Nests avec un sprint de stabilisation axé sur les modes de défaillance qui cassaient les appels en production. Le correctif de coupure audio dans la PR #2733 chevauche l’acquisition de nouveaux identifiants avec le flux actif lors du renouvellement JWT. Un nouveau mécanisme keep-alive dans la PR #2730 reconnecte les relais déconnectés sans nécessiter d’action manuelle de l’utilisateur, et la PR #2728 remplace l’ancien KeyDataSourceSubscription par LifecycleAwareKeyDataSourceSubscription. La PR #2724 ajoute un indicateur animé en anneau externe qui met en surbrillance le participant en train de parler lors des sessions multi-intervenants.

ngit v2.4.2 et v2.4.3 corrigent la détection des serveurs GRASP et les événements d’état multi-remote

ngit, l’outil en ligne de commande et le plugin git pour la collaboration NIP-34, a livré v2.4.2 le 28 avril et v2.4.3 le 1er mai. v2.4.2 corrige une discordance de normalisation d’URL où repo_grasps contenait des noms d’hôtes normalisés mais la comparaison était effectuée par rapport aux URL de clone complètes. v2.4.3 corrige une ambiguïté d’événement d’état qui apparaissait lorsqu’un dépôt possède plusieurs remotes nostr:// partageant le même identifiant.

GRAIN v0.5.4 apporte un durcissement de production et corrige une perte de données silencieuse

GRAIN, le relais Nostr et la bibliothèque client basés sur Go, a livré v0.5.4 le 30 avril. La version regroupe six correctifs accumulés depuis v0.5.3, dont un bug de perte de données silencieuse dans le démarrage rapide Docker qui supprimait auparavant des événements lors du redémarrage du conteneur, et un bug de correction de la couche de stockage dans les lectures d’événements adressables.

Mostro Core v0.10.1 ajoute des artefacts de version signés PGP

Mostro Core, la bibliothèque Rust fournissant des fonctionnalités pair à pair pour le démon Mostro, a livré v0.10.1 le 28 avril. Cette version ajoute des artefacts de version signés PGP et un flux de vérification de version pour que les empaqueteurs aval puissent confirmer la provenance des artefacts.

Versions publiées

Clave v0.2.0 lance la gestion multi-comptes sur iOS avec la signature NIP-46 (Nostr Connect)

Clave, l’application iOS de signature distante NIP-46, a livré v0.2.0 le 5 mai. La principale nouveauté introduit la gestion multi-comptes : Clave peut désormais gérer jusqu’à quatre comptes sur un seul appareil, avec un sélecteur en un appui et une isolation par compte. La PR #23 ajoute la plomberie iOS pour le multi-comptes, et la PR #22 ajoute un champ signer_pubkey à la charge utile APNs pour que l’appareil sache à quel compte appartient une demande de signature distante.

Wisp livre des travaux de stabilité v1.0.3 → v1.0.5

Wisp, le client Android, a livré v1.0.3, v1.0.4 et v1.0.5 le 4 mai avec des travaux de stabilité. La PR #506 ajoute Thumbhash pour les aperçus d’images floutées pendant le chargement des médias complets, et la PR #514 réduit les saccades lors du changement d’onglets inférieurs.

Amber 6.1.0-pre1 livre des corrections de mise en page et de stabilité

Amber, l’application de signature Android pour NIP-55 et NIP-46, a livré v6.1.0-pre1 avec une passe de mise en page sur le flux de connexion des nouvelles applications et plusieurs corrections de plantage. La PR #416 corrige la mise en page d’ActivityStatsBar et les problèmes de débordement de texte.

Routstr Core v0.4.3 améliore le paiement, les remboursements et le reporting d’utilisation

Routstr Core a livré v0.4.3 en pré-version le 1er mai avec des améliorations du traitement des paiements et remboursements, du suivi des coûts et du reporting d’utilisation.

Nostria v3.1.37 à v3.1.41 ajoutent les signets Web et un thème automatique

Nostria, le client Nostr multi-plateforme, a livré v3.1.37 à v3.1.41 avec la prise en charge des signets Web NIP-B0, un thème automatique suivant les paramètres de l’appareil, et la consultation de PDF dans l’application.

NoorNote v0.8.9 corrige l’écran vide au premier lancement sur bureau

NoorNote a livré v0.8.9 le 28 avril corrigeant un bug d’écran vide au premier lancement de l’application de bureau.

Kubo v0.3.4 à v0.4.1 lancent une plateforme vidéo Nostr sécurisée pour les enfants avec contrôles parentaux et curation Web of Trust

Kubo, une plateforme vidéo sécurisée pour enfants sur Nostr, a livré v0.3.4 à v0.4.1 les 4 et 5 mai. Chaque enfant dispose d’une paire de clés Nostr distincte et d’un fil centré sur la vidéo où les parents contrôlent les limites de temps (15 à 180 minutes par jour), les plages horaires autorisées et la visibilité des actions de publication.

Changements non publiés

Sprout livre Desktop v0.0.4 et v0.0.5 avec l’authentification d’agent NIP-OA et le sidecar relay de jumelage

Sprout, le client Nostr de Block avec un relay intégré, a livré Desktop v0.0.4 le 5 mai et v0.0.5 le 6 mai. La PR #471 intègre l’authentification d’agent NIP-OA dans le flux d’adhésion NIP-43 du relay afin qu’un agent autonome puisse prouver qu’une clé publique humaine spécifique a autorisé ses actions. Un nouveau relay sidecar éphémère pour le jumelage d’appareils NIP-AB arrive dans la PR #467 sous la forme de sprout-pair-relay.

nostream ajoute la prise en charge du relay Marmot et les réactions NIP-25

nostream, l’implémentation de relay Node.js, a fusionné la prise en charge du relay Marmot Protocol couvrant les MIPs 00 à 03 dans la PR #602, la prise en charge des réactions NIP-25 dans la PR #589, et la correspondance de préfixe geohash pour les filtres #g dans la PR #586.

strfry ajoute l’observabilité par connexion et réduit le plafond nofiles

strfry, le relay Nostr en C++, a fusionné 14 PR ciblant l’observabilité. La PR #218 ajoute l’observabilité des sorties en attente par connexion et un plafond de contre-pression configurable. La PR #224 supprime les allocations de tas std::function du fanout du moniteur par événement.

Damus remplace les GIF Tenor par un proxy Purple et livre une interface de compaction

Damus a fusionné la PR #3737 remplaçant l’intégration GIF Tenor par un proxy Damus Purple.

Primal Android peaufine Explore, les alertes et le badge vérifié NIP-05

Primal Android a fusionné la PR #1043 corrigeant un badge vérifié NIP-05 qui clignotait pour les utilisateurs avec des identifiants _@domaine.

Alby Hub ajoute les paiements NWC depuis les connexions d’applications

Alby Hub a fusionné la PR #2267 permettant les paiements depuis les connexions d’applications.

routstrd-auth : un Routstrd Dockerisé pour les équipes avec authentification NIP-98 et RBAC npub

routstrd-auth, créé le 27 avril, est une variante Dockerisée de Routstrd pour les déploiements en équipe multi-utilisateurs avec contrôle d’accès basé sur les rôles via npub et authentification HTTP NIP-98.

Routstrd intègre Hermes pour les clients démons et le mode distant

Routstrd a fusionné la PR #22 ajoutant l’intégration avec Hermes Agent afin que le fichier de configuration de l’agent soit peuplé des fournisseurs de modèles et des clés API que Routstrd découvre via Nostr.

whitenoise-rs livre l’isolation de base de données par compte et les mises à niveau de propositions

whitenoise-rs a fusionné la PR #796 déplaçant les tables de projection de messages dans des bases de données par compte, et la PR #791 ajoute des mises à niveau de propositions pour que les groupes puissent étendre les fonctionnalités avec de nouveaux types de propositions.

Angor 0.2.21 livre des flux d’application compacts et un durcissement du fournisseur de clés et du changement de réseau

Angor a livré 0.2.21 le 6 mai avec des améliorations de performances de conception mobile, des flux d’application compacts et un fournisseur de clés sécurisé.

Nouvellement suivis et découverts

BitMacro Signer : un bunker NIP-46 auto-hébergeable avec chiffrement de clé côté client

BitMacro Signer est un outil de signature Nostr auto-hébergeable utilisant le modèle bunker NIP-46. Les clés sont chiffrées côté client avant stockage, de sorte que le serveur ne détient jamais le texte en clair.

La découverte de dépôts NIP-34 a fait apparaître 26 nouvelles annonces de dépôts cette semaine, dont quatre se distinguent :

gnostr : une implémentation git construite directement sur Nostr

gnostr est une implémentation git construite directement sur Nostr, livrant ses propres commandes d’arbre de travail en tant que client de contrôle de version natif Nostr construit de zéro.

nostr-archive : une spécification d’archive adressée par le contenu sur Nostr et Blossom

nostr-archive est une spécification provisoire et une implémentation de référence pour les archives adressées par le contenu sur Nostr et Blossom.

flower-cache : un serveur de cache Blossom local

flower-cache est un serveur de cache Blossom local, utile pour les clients qui souhaitent un miroir local chaud de l’ensemble de blobs d’un serveur Blossom distant.

micro-vpn-ansible : des playbooks Ansible pour le déploiement VPN via NIP-34

micro-vpn-ansible est une petite collection de playbooks Ansible pour déployer un micro VPN, hébergé en tant que dépôt NIP-34.

Travaux sur le protocole

Mises à jour NIP

Un marché de hashrate sans courtier sur Nostr (proposition provisoire) : Un brouillon NIP anonyme arguant que les acteurs actuels du marché de hashrate sont des courtiers dépositaires qui vérifient l’identité des utilisateurs. Propose un marché de hashrate P2P sur des événements Nostr.
Curated Feeds : une alternative plus simple aux flux DVM (proposition provisoire) : Argumente que les DVMs NIP-90 sont trop lourds pour la curation de flux simple ; propose des événements adressables minces avec des listes ordonnées d’identifiants d’événements à la place.
Profile Colors : identité visuelle déterministe (proposition provisoire) : Nouveau brouillon NIP pour dériver des couleurs lisibles déterministes à partir d’une clé publique Nostr pour une identité visuelle cohérente entre les clients.
NIPs Namecoin-Track : ancrage de l’identité, des relais, du TLS et de la réputation (cluster provisoire) : Un cluster de NIP provisoires déplaçant les pièces de la pile Nostr dans des enregistrements ancrés Namecoin.

NIP Deep Dive : NIP-34 (git stuff)

NIP-34 définit des types d’événements pour héberger des dépôts git, des patches, des pull requests, des issues et des statuts de fusion sur des relais Nostr. Un dépôt est annoncé comme un événement adressable de type 30617. Les patches utilisent le type 1617 transportant la sortie git format-patch. Les pull requests utilisent le type 1618. Les issues utilisent le type 1621 avec du contenu markdown. Les événements de statut font passer un fil entre Open (1630), Applied/Merged ou Resolved (1631), Closed (1632) et Draft (1633). L’actualité NIP-34 cette semaine est la même que le lancement GitWorkshop v2 de la semaine dernière : le bouton de fusion de PR dans le navigateur fonctionne parce que les serveurs GRASP, ngit et le schéma d’URL clone nostr:// ferment ensemble la boucle sur une forge entièrement décentralisée.

NIP Deep Dive : NIP-53 (Live Activities)

NIP-53 définit la surface d’événements standard pour les activités en direct sur Nostr : diffusions en direct, espaces de réunion persistants, événements de conférence programmés, présence des auditeurs et chat en direct. Une diffusion en direct est annoncée comme un événement adressable de type 30311. NIP-53 sépare la salle persistante de l’événement programmé qui s’y déroule : un Meeting Space de type 30312 définit une salle, et un Conference Event de type 30313 représente une réunion programmée ou en cours dans cette salle. La surface des activités en direct sur Nostr est intentionnellement légère : NIP-53 annonce l’activité, tandis que d’autres NIPs gèrent les préoccupations adjacentes comme les zaps (NIP-57), les objectifs de zap (NIP-75) et les enregistrements vidéo (NIP-71).

C’est tout pour cette semaine. Si vous construisez quelque chose ou avez des nouvelles à partager, envoyez-nous un DM sur Nostr ou retrouvez-nous sur nostrcompass.org.

Nostr Compass #20

Wed, 29 Apr 2026 00:00:00 +0000

Bienvenue à nouveau sur Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : GitWorkshop transforme git-over-Nostr en une surface de revue de code plus complète avec un bouton de fusion de PR dans le navigateur, les Étoiles et le suivi de dépôts, un explorateur git économe en bande passante, des commentaires de revue en ligne de kind 1111, et un état de notifications multi-appareils chiffré. Routstrd lance un démon local qui découvre les fournisseurs de modèles via des annonces Nostr de kind 38421 et les paie avec Cashu. Les sorties étiquetées incluent ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 et v0.5.3, Mostro Core v0.10.0 et Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet et plus. Les changements non publiés couvrent Amethyst Nests, nostream NIP-65 et NWC, le bootstrap udp:nat basé sur Nostr de FIPS, l’observabilité de strfry, les attestations de propriétaire de Sprout et les packs de recettes de Zap Cooking. Les nouveaux projets suivis incluent Nostrord, Clave, Treasures, smesh, Surveil, et des ajouts plus petits. La rétrospective de fin de mois couvre les avrils de Nostr de 2021 à 2026.

Articles principaux

GitWorkshop livre la fusion de PR dans le navigateur, le suivi de dépôts et un explorateur git économe en bande passante

GitWorkshop, la couche de collaboration web de Dan Conway pour NIP-34 git-over-Nostr, a livré une sortie majeure cette semaine qui rapproche beaucoup le workflow de ce que les développeurs attendent de GitHub ou GitLab, tout en gardant les commentaires, les listes de dépôts et les notifications à l’intérieur d’événements Nostr signés.

L’ajout phare est un bouton de fusion de PR dans le navigateur attendu depuis longtemps pour les dépôts utilisant des relais GRASP. La sortie ajoute également les Étoiles et le suivi de dépôts construits sur les réactions et les listes NIP-51, avec des ensembles de dépôts épinglés publiés en tant qu’événements de kind 10617 qui pointent vers des annonces de dépôts de kind 30617 via des balises a ordonnées. Les pages de profil peuvent maintenant présenter une liste portable de dépôts.

Un explorateur git économe en bande passante remplace le clone superficiel précédent dans le navigateur. Le nouvel explorateur s’appuie sur le protocole client/serveur git sous-jacent sur lequel GRASP se construit, il peut donc gérer de grands dépôts sans forcer le navigateur à récupérer un pack complet. La recherche couvre maintenant les noms d’utilisateur et les métadonnées de dépôt, alimentée par NIP-50 et une implémentation de relais ngit-indexer qui découvre et synchronise les annonces de dépôts à travers le réseau. Un workflow de création de dépôt dans le navigateur complète le chemin de découverte et d’onboarding.

L’outillage de revue est reconstruit autour d’un onglet Fichiers modifiés, d’un visualiseur de diff par patch, et d’un ensemble de nouvelles primitives expérimentales. Les commentaires de revue de code en ligne utilisent le kind 1111, construit sur NIP-22 : chaque commentaire pointe vers un chemin de fichier (balise f), un SHA de commit (balise c), et une plage de lignes sélectionnées (balise line) afin qu’un client puisse rendre le commentaire à la bonne position dans un diff. Un deuxième niveau de primitives expérimentales est autorisé par l’auteur et les mainteneurs du dépôt et utilise les étiquettes NIP-32 : renommer un sujet d’Issue ou de PR après soumission, ajouter des hashtags après soumission, épingler une CoverNote versionnée en haut d’une PR ou d’une Issue pour un résumé modifiable, et marquer les sous-fils de discussion de code en ligne comme résolus. Les événements Verdict et les blocs suggestion restent en projet et n’ont pas encore été livrés.

L’état des notifications entre appareils est également synchronisé via Nostr, mais avec une touche préservant la vie privée. GitWorkshop génère une paire de clés dédiée aux notifications, chiffre cette nsec et la stocke à l’intérieur d’un événement de kind 30078. La nsec des notifications signe ensuite les événements d’état de notification réels. L’indirection empêche le signataire principal de l’utilisateur d’être spammé avec des demandes fréquentes de chiffrement et déchiffrement pour chaque action de lecture ou d’archivage, et elle empêche les observateurs extérieurs de voir facilement quand un utilisateur touche à son état de notification. Un utilisateur peut synchroniser l’état de lecture et d’archivage entre les appareils ; les relais ne voient que des blobs chiffrés.

Routstrd lance un routeur local pour l’inférence sur Nostr

Routstrd est un nouveau démon TypeScript qui donne aux outils locaux un point de terminaison compatible OpenAI et route chaque requête vers un fournisseur Routstr concurrent. Le démon découvre les fournisseurs via des annonces Nostr de kind 38421 définies dans la spécification RIP-02 de Routstr. Il note ensuite les fournisseurs selon le prix, la confiance et les performances récentes sous RIP-06 et envoie chaque requête à la meilleure option actuelle.

Le paiement passe par un portefeuille Cashu local géré par cocod et alimenté avec Lightning. Cela donne au client un chemin de règlement dénommé en sats tout en gardant la découverte des fournisseurs publique et sans permission via les relais Nostr. Si un fournisseur échoue pendant une session, Routstrd peut se rabattre sur le nœud classé suivant. Le chemin d’installation est bun install -g routstrd, suivi de routstrd onboard pour la configuration du portefeuille et des relais.

L’organisation Routstr plus large maintient le démon, le logiciel de nœud Python (routstr-core), une UI de chat et les spécifications de protocole. Pour les utilisateurs, le port local devient l’interface stable : les outils compatibles OpenAI existants pointent vers Routstrd, tandis que le démon gère la découverte des fournisseurs, le routage et le paiement.

Sorties étiquetées

ngit v2.4.2 corrige la détection du relais GRASP pour les soumissions de PR

ngit a livré v2.4.2 avec un correctif pour la détection du serveur GRASP du dépôt, gardant la soumission de PR sur le chemin heureux lorsqu’une proposition utilise le kind PR. Notez que ngit utilise actuellement par défaut le kind Patch pour la plupart des changements sauf s’ils sont volumineux ; le mainteneur travaille à changer le défaut. v2.4.1, livré plus tôt dans la semaine, a corrigé les erreurs fatal lors du clone et du fetch quand les données git d’une PR ouverte n’étaient pas disponibles sur les serveurs git spécifiés par le dépôt.

Wisp v1.0.0 sort de la bêta

Wisp, un client Android Kotlin et Jetpack Compose axé sur le routage des relais, la vie privée et une petite UI native, a livré v1.0.0 et enchaîné avec v1.0.2. Le jalon 1.0.0 rassemble le bascule de dénomination fiat Normie Mode, le fil Pour Vous, la configuration de groupe basée sur les relais NIP-29 et la diffusion de listes de relais NIP-65 couvertes dans Newsletter #19. v1.0.2 ajoute le support de taille de page 16 Ko d’Android 15, un onglet de scan QR dans le tiroir, un bouton de téléchargement pour les contrôles vidéo en ligne et des correctifs de performance de la liste de notifications.

grain v0.5.2 corrige le blocage WebSocket, v0.5.3 poursuit le polissage

grain, le relais Go de 0ceanSlim, a coupé v0.5.2 comme correctif critique pour un blocage WebSocket introduit dans v0.5.0, puis a enchaîné avec v0.5.3. Le blocage causait le figeage des connexions sous certains chemins de filtre et WebSocket, les opérateurs sur v0.5.1 ou v0.5.0 devraient donc mettre à niveau. grain suit toutes les catégories majeures d’événements Nostr, expose les informations de relais NIP-11, prend en charge le contrôle d’accès par liste blanche/noire, les limites de taux par kind, un tableau de bord web et une bibliothèque cliente Go ajoutée dans la ligne v0.5.x.

Mostro Core v0.10.0 et Mostro Mobile v1.2.5 adoptent la double clé gift wrap NIP-59

Mostro Core v0.10.0 ajoute le nouveau module gift-wrap NIP-59 avec identité séparée et clés de trade. Le code de transport précédent utilisait une clé d’identité unique à la fois pour l’identité de trade et pour le gift wrapping. v0.10.0 sépare l’identité de trade stable de la clé de wrapping éphémère, afin que chaque trade puisse utiliser une nouvelle clé de transport tout en préservant l’identité nécessaire au protocole de trade. L’intégration du démon arrive via Mostro PR #718, et mostro-cli PR #165 apporte la même migration au client en ligne de commande.

Mostro Mobile v1.2.5 est livré aux côtés du travail de protocole. PR #581 permet aux preneurs de filtrer les offres selon l’âge du compte du maker, donnant aux utilisateurs un moyen d’éviter les comptes maker nouvellement créés dans le carnet d’ordres. PR #580 corrige les étiquettes de rôle sur les détails des commandes annulées, et PR #576 nettoie les boutons d’annulation coopérative.

marmot-ts v0.5.0 livre des KeyPackages adressables

marmot-ts a coupé @internet-privacy/marmot-ts@0.5.0, la première sortie planifiée avec changements incompatibles pour le client TypeScript Marmot. PR #68 ajoute le support des KeyPackages adressables : KeyPackageManager peut maintenant gérer à la fois les événements KeyPackage legacy de kind 443 et les nouveaux de kind 30443. La sortie supprime KeyPackageStore et les classes de stockage d’état de groupe, en les remplaçant par des stockages clé-valeur génériques passés à KeyPackageManager et MarmotGroup. Elle déplace également la gestion des invitations et des groupes sur MarmotClient.invites et MarmotClient.groups, donc les intégrateurs directs ont besoin de changements de constructeur et de stockage avant la mise à niveau.

CruxCoach v0.1.3 livre une sauvegarde chiffrée des données d’escalade avec Nostr et Blossom

CruxCoach est une nouvelle application Android open source pour les grimpeurs de Kilter Board. La Kilter Board est un mur d’entraînement interactif dont les prises s’allument via Bluetooth pour afficher les voies. L’application a été lancée le 14 avril et a atteint v0.1.3 le 26 avril.

v0.1.3 ajoute la sauvegarde cloud chiffrée en opt-in. Le compte CruxCoach d’un utilisateur est une paire de clés Nostr, et la clé privée sert aussi d’entrée à la clé de chiffrement de sauvegarde locale. L’application chiffre les données d’escalade sur l’appareil et miroite le chiffré sur les serveurs de stockage Blossom (blossom.primal.net et nostr.download). Les actions de suppression distante appellent le chemin de nettoyage Blossom. Au-delà de la sauvegarde, CruxCoach utilise la signature à distance NIP-46 pour le support d’Amber, les DM privés NIP-17 pour le contact avec le développeur dans l’application, les listes de relais NIP-65 pour la découverte des relais, et la bibliothèque Quartz de Vitor Pamplona pour la plomberie Nostr. Les utilisateurs peuvent l’installer via Zapstore ou les APKs Codeberg directs.

Meiso v1.3.0 ajoute les sous-tâches, les pièces jointes Blossom et l’étiquetage NIP-89

Meiso est un gestionnaire de tâches Flutter minimaliste pour Android qui stocke les tâches en tant que données d’application chiffrées NIP-44 de kind 30078 sur les relais Nostr. v1.3.0, publié le 6 avril, ajoute les sous-tâches avec des relations parent/enfant, des liens de tâches pour bloque/bloqué-par/lié-à/dupliqué-de, les pièces jointes image via les points de terminaison d’upload de fichier HTTP Blossom et NIP-96, une balise client d’application recommandée NIP-89 sur les événements publiés, et un outil de synchronisation en ligne de commande Go. v1.3.0 corrige aussi le comportement des relais au démarrage à froid et la réutilisation du client Amber.

NoorNote, Nostria, Nostr Calendar, nos2x-fox, et sorties de bibliothèques

NoorNote a publié v0.8.7, v0.8.8, et v0.8.9. Ces sorties corrigent la gestion des clics sur les images et vidéos dans les reposts cités, ajoutent le support lightbox pour les images d’articles long-form, et corrigent l’écran de démarrage vide sur bureau. Nostria a coupé v3.1.29, v3.1.30, et v3.1.31, ajoutant la compression d’image dans l’éditeur d’article, un bascule USD du portefeuille, des contrôles de carte promotionnelle, le support PDF et le polissage de la disposition mobile.

Nostr Calendar v1.4.1 découple la publication d’événements de calendrier de la gestion de la liste de calendriers et corrige le suivi des invitations. nos2x-fox v1.19.0 ajoute des délais d’autorisation personnalisés pour les octrois de signature de navigateur Firefox NIP-07. nostr-double-ratchet v0.0.97 livre de nouveaux binaires. nostr-wot-sdk 0.9.0 monte NostrSessionProvider par défaut, et nostr-tools PR #535 ajoute le support de l’analyse multi-relais pour les chaînes de wallet-connect NIP-47.

Tard dans la semaine, Amber v6.1.0-pre1 a livré une pré-version avec une meilleure disposition connect-new-app, des correctifs du dialogue de signataire, une gestion améliorée des permissions de notification, et une sélection de compte refactorisée. nostr-vpn v0.3.14 a coupé une nouvelle version avec des artefacts macOS Apple Silicon, Linux et Windows. Bitcredit Core v0.5.7-hotfix-1 et v0.5.8 ont livré des correctifs consécutifs pour un problème de validation de bloc orphelin. Surveil v0.1.6 a apporté un polissage de l’UI mobile et une page À propos revue ; le projet lui-même est présenté ci-dessous.

applesauce 6.0.0 supprime les usines d’événements legacy et ajoute l’analyse d’URI Blossom

applesauce, la boîte à outils Nostr TypeScript de hzrd149, a livré un train de sortie 6.0.0 à travers le monorepo. applesauce-core@6.0.0 supprime la classe legacy EventFactory et les anciens helpers buildEvent, modifyEvent et createEvent, poussant les appelants vers les nouvelles classes d’usine dans applesauce-core/factories et applesauce-common. Elle ajoute aussi la gestion des adresses IP et localhost à l’analyse de liens, les expressions régulières d’URI Blossom BUD-10, et de nouveaux helpers observables tels que timeoutWithIgnore, combineLatestBy, combineLatestByIndex et combineLatestByKey.

Les sorties au niveau des packages complètent les pièces spécifiques à Nostr. applesauce-content@6.0.0 ajoute des nœuds URI Blossom BUD-10 pour le texte et le Markdown, donnant aux moteurs de rendu un moyen de première classe d’analyser les références Blossom dans le contenu. applesauce-actions@6.0.0 ajoute des classes d’usine de base pour les listes NIP-51 couvrant les relais, les utilisateurs et les éléments, rendant la construction de listes moins ad hoc. applesauce-wallet-connect@6.0.0 expose WalletConnect.connectURI, afin que les applications puissent accéder directement à un URI wallet-connect NIP-47 existant.

Changements non publiés

Amethyst fait progresser les salles audio Nests avec des tests d’interopérabilité MoQ

Amethyst a fusionné plusieurs PRs axées sur Nests cette semaine, en s’appuyant sur la pile de salle audio Media over QUIC de la semaine dernière. PR #2622 ajoute un harnais d’interopérabilité inter-clients qui exerce le client MoQ Amethyst contre l’implémentation web de référence. L’objectif est d’attraper les divergences au niveau du fil entre Android/navigateur avant que les utilisateurs ne les rencontrent. PR #2625 améliore le focus sur l’orateur en picture-in-picture et le statut de connexion, tandis que PR #2620 clarifie les avatars, l’état de mise en sourdine et l’état de parole dans la grille des participants. Tard dans la semaine, PR #2634 corrige le rembourrage IME et les encarts de fenêtre dans la vue Nest en plein écran et PR #2635 ajoute un filtrage de fraîcheur basé sur la présence au fil Nests. Séparément, PR #2627 supprime l’implémentation C secp256k1 personnalisée d’Amethyst et migre vers libschnorr256k1.

nostream ajoute le support de la liste de relais NIP-65 et les paiements NWC

nostream a fusionné trois PRs notables après le sprint de relais de 53 PRs de la semaine dernière. Le support des métadonnées de liste de relais NIP-65 arrive dans PR #585, afin que le relais puisse indexer et servir les événements de liste de relais de kind 10002. Un processeur de paiements Nostr Wallet Connect suit dans PR #539, ajoutant un chemin de paiement au relais. Le nettoyage des connexions s’améliore dans PR #438, qui ferme un bug de connexion morte où les sockets avec des abonnements actifs n’étaient pas récupérés, causant une dérive des comptages d’abonnements sur les instances de longue durée.

FIPS ajoute le bootstrap udp:nat basé sur Nostr

FIPS, le Free Internetworking Peering System précédemment couvert dans Newsletter #6 et Newsletter #10, a fusionné PR #53 avec le bootstrap udp:nat basé sur Nostr. Le changement permet aux nœuds de publier des annonces Nostr, d’échanger une signalisation offer/answer chiffrée, de découvrir les adresses publiques via STUN, d’effectuer un UDP hole punching, et de passer le socket poinçonné dans la pile de transport FIPS normale. L’implémentation lie les identités de charge utile de signal à l’expéditeur Nostr réel, interroge les relais DM et d’annonce configurés pour la recherche d’inbox, et annule les transferts de traversée adoptés en échec afin que les transports UDP orphelins ne restent pas actifs. C’est le travail d’annonce Nostr et de traversée NAT à suivre dans le dépôt canonique, jmcorgan/fips.

strfry ajoute une observabilité par connexion

strfry a fusionné PR #214, ajoutant une observabilité par connexion et des métriques au niveau de la connexion exportables via Prometheus. PR #204 normalise les étiquettes Prometheus, et PR #215 ajoute une section Intégrations Communautaires à la documentation couvrant les projets d’identité Namecoin construits sur strfry.

Sprout ajoute l’attestation de propriétaire et le support multi-espaces de travail

Sprout, le client Nostr de Block, a fusionné PR #406 implémentant NIP-OA (Owner Attestation). La fonctionnalité donne à un agent autonome une preuve cryptographique qu’un pubkey humain spécifique a autorisé ses actions. PR #409 ajoute le support multi-espaces de travail à l’application de bureau, PR #411 ajoute l’autocomplétion #channel à la composition mobile, et PR #410 ferme une fenêtre de course qui pouvait laisser tomber les messages de canal actif. PR #413 introduit NIP-RS pour la synchronisation d’état de lecture entre appareils, et les suivi PR #420 et PR #422 câblent cet état de lecture dans les badges non lus mobiles.

Zap Cooking ajoute les packs de recettes, les demandes de suppression et la connexion bunker

Zap Cooking a fusionné une semaine productive de travail de publication de recettes. Les demandes de suppression NIP-09 pour les propres Recipe Packs d’un utilisateur arrivent dans PR #367. La fiabilité de publication s’améliore via PR #366, qui force chaque nouvelle recette sur le relais garden et ajoute une file d’attente de retry pour l’ensemble de recettes partagé. La publication en un clic de packs d’auteur arrive dans PR #365, et PR #331 ajoute le support de connexion bunker NIP-46.

Whitenoise-rs chiffre sa base de données locale

whitenoise-rs a fusionné PR #758, ajoutant le chiffrement SQLCipher pour la base de données Whitenoise sur disque. Cela ferme une lacune de sécurité au repos de longue date pour la pile de démons Marmot. PR #775 expose les capacités requises du groupe, PR #772 migre les opérations média de groupe vers des MediaOps détenus par session, et PR #773 extrait un support SharedServices dans le cadre du refactor des opérations de session. Côté mobile, whitenoise PR #577 active le redémarrage automatique au démarrage pour le service Android en premier plan, corrigeant le cas où le démon ne revenait pas après un redémarrage de l’appareil.

Nouvellement suivis et découverts

Nostrord : un client NIP-29 construit avec Kotlin Multiplatform et WASM

Nostrord est un nouveau client de chat de groupe NIP-29 ciblant le cas d’usage de remplacement de Discord. Les groupes vivent sur les relais Nostr avec l’adhésion, les rôles, la modération et le contrôle d’accès appliqués par le relais, donc l’état du groupe est hébergé par le relais NIP-29 sélectionné. Le développeur du client ne contrôle pas de base de données d’application séparée pour ces groupes. L’application web fonctionne sur web.nostrord.com et est construite avec Kotlin Multiplatform compilant vers WebAssembly, avec des builds natifs Android, iOS et desktop en développement. Nostrord est bénéficiaire d’une subvention OpenSats et interopère avec les mêmes relais NIP-29 utilisés par Flotilla, Chachi et 0xChat.

Clave apporte la signature à distance NIP-46 sur iOS via APNs

Clave est un signataire à distance iOS en bêta qui signe les événements Nostr quand l’application n’est pas ouverte. La clé privée reste dans le trousseau iPhone. Quand un client envoie une demande de signature à distance NIP-46, un proxy côté serveur délivre une Apple Push Notification, réveillant une Notification Service Extension pendant jusqu’à 30 secondes. Cette extension déchiffre la requête avec le chiffrement NIP-44, signe avec la clé du trousseau et publie la réponse. L’enregistrement du token de l’appareil utilise l’auth HTTP NIP-98 pour empêcher le détournement de token. Clave prend en charge l’appairage bunker:// et nostrconnect://, les niveaux de confiance par client, les remplacements par kind, et a été testé avec Nostur et noStrudel.

Treasures : géocaching décentralisé sur Nostr

Treasures est une plateforme de géocaching où les caches et découvertes sont des événements Nostr signés. Les créateurs de cache publient des événements adressables de kind 37516 avec les coordonnées GPS. Les découvreurs enregistrent la découverte en scannant un code QR attaché à la cache physique ; le code encode le pubkey du créateur, la balise d de la cache et une clé privée de vérification utilisée comme preuve de la visite physique. Les zaps NIP-57 peuvent circuler des découvreurs aux créateurs de caches, et l’application en direct est sur treasures.to.

smesh v0.5.1 : relais Nostr, client et signataire auto-hébergés en un seul stack

smesh est une pile Nostr auto-hébergée écrite en Moxie, un langage personnalisé dérivé de Go et TinyGo par mleku. La pile livre un binaire de relais natif avec support HTTP, WebSocket, AUTH, recherche et Blossom ; sm3sh, un client web compilé en modules ES ; et une extension de signature de navigateur avec signature de navigateur NIP-07 plus support de chiffrement NIP-04 et NIP-44. Le travail récent inclut la messagerie de groupe MLS (RFC 9420) dans v0.5.0, la réconciliation d’ensembles negentropy pour la synchronisation de relais, et un moteur de graphe Web of Trust. Le code vit sur la forge auto-hébergée de mleku à git.smesh.lol, construite avec son propre outil git-web. Le dépôt connexe gitea-nostr-auth est un pont OAuth2/OIDC pour Gitea : les utilisateurs s’authentifient avec un signataire de navigateur NIP-07, le pont découvre les relais via NIP-65, et Gitea reçoit des revendications d’identité OIDC standard.

Surveil : un constructeur de deck Magic: The Gathering sur Nostr

Surveil est un client Nostr pour les joueurs de Magic: The Gathering qui permet aux utilisateurs de rechercher des cartes, de construire des decks, de scanner des cartes papier sur Android avec l’OCR ML Kit sur l’appareil, et de partager des decks à travers le réseau. Les decks sont publiés en tant qu’événements adressables de kind 37381, et la spécification de l’événement de deck est documentée dans le NIP.md du projet. La couche sociale est construite à partir de primitives Nostr standard : commentaires en fil NIP-22 (kind 1111) portés sur chaque deck, réactions NIP-25 (kind 7), données de profil NIP-78 (kind 30078) pour les accueils de joueurs, fils de suivi de kind 3, et forks qui portent une balise a de retour au deck original. v0.1.6 a été livré cette semaine avec un polissage de l’UI mobile, des améliorations du compteur de vie, une page À propos revue, et une pastille de relais sur la bannière héros du deck. L’application web fonctionne partout où du HTML statique est servi, la version Android est livrée via Zapstore, et les événements de kind 37381 sont également indexés nativement par Ditto comme decks Magic. Le dépôt est sur GitLab à chad.curtis/surveil.

Ajouts plus petits : Fundstr, Nod City, deploy-nsite-to-pages et null–nostr

Fundstr est une plateforme de financement de créateurs sur Nostr utilisant l’ecash Cashu pour les promesses uniques et récurrentes, avec des définitions de paliers de créateurs et des DMs Nostr. Nod City est un site d’évaluation de services Bitcoin où les avis sont des événements Nostr signés et les évaluateurs peuvent recevoir des zaps ; aucun dépôt de source publique n’a été trouvé. deploy-nsite-to-pages est une GitHub Action qui miroite un nsite vers GitHub Pages en utilisant nsyte download, prenant en charge les nsites racine de kind 15128 et nommés de kind 35128. null–nostr, également découvert dans les données NIP-34 de cette semaine, est le client couvert dans la récente vague OpenSats sous le nom Nurunuru ; il prend en charge la messagerie de groupe MLS, Amber, la recherche NIP-50, les posts protégés NIP-70, les badges ProofMode et la distribution Zapstore.

FIPS n’est pas un nouveau projet pour Compass. Il a été couvert dans Newsletter #6 et Newsletter #10. La base de données pointe maintenant vers le bon dépôt canonique, jmcorgan/fips, et la découverte NIP-34 de cette semaine a également fait surface des miroirs git-over-Nostr connexes tels que fips et awesome-fips.

Travail de protocole

Mises à jour NIP

Propositions et discussions récentes dans le dépôt NIPs :

Fusionnées cette semaine :

NIP-34 dépôts git : suppression de l’extension de balise refs inutilisée (PR #2325) : Supprime une extension de balise refs de NIP-34 qui était définie mais inutilisée. Le nettoyage réduit l’ambiguïté d’implémentation pour les outils git-over-Nostr.
NIP-34 dépôts git : suppression de la revendication NIP-09 incorrecte (PR #2326) : Supprime une revendication incorrecte selon laquelle les événements de suppression NIP-09 peuvent réinitialiser l’état du dépôt. La suppression NIP-09 est une demande de suppression d’événement côté client, pas une machine d’état de dépôt. La correction empêche les implémenteurs NIP-34 de traiter les indices de suppression comme des réinitialisations de dépôt faisant autorité.

Travail ouvert et piloté par l’implémentation :

Commentaires de revue en ligne de kind 1111 de GitWorkshop : Le kind de commentaire de revue de code en ligne est documenté dans le NIP.md de GitWorkshop et est maintenant activement utilisé, mais il n’a pas encore été proposé comme NIP formel. Les événements Verdict (kind 7321) et les blocs suggestion restent en projet et n’ont pas encore été livrés. Les retours d’implémentation de GitWorkshop et ngit détermineront si les formes deviennent un NIP autonome de revue git ou restent une convention d’application superposée sur NIP-34.
Noyau Nostr mail et Nostrmon : Deux nouveaux projets de NIPs personnalisés ont circulé cette semaine. Nostr mail core propose le kind 1301 pour le contenu d’e-mail RFC 2822, enveloppé avec NIP-59 pour la livraison privée et ponté vers l’e-mail legacy via des pubkeys de pont résolues par NIP-05. Nostrmon esquisse des kinds d’événements adressables pour les régions, les cartes, les créatures, les PNJ, les sauvegardes de joueurs et les objets. Les deux restent des projets personnalisés, pas des NIPs fusionnés.
NIP-67 : Indice de complétude EOSE (PR #2317) : La proposition continue d’itérer sur l’ajout d’un marqueur de complétude positif à EOSE, permettant aux relais de distinguer « événements stockés entièrement livrés » des cas EOSE legacy où le relais ne fait aucune revendication de complétude.

Six avrils Nostr

Avril offre une coupe transversale nette du chemin de développement de Nostr : le document de protocole en 2021, les premiers travaux clients en 2022, la vague d’applications post-Damus en 2023, la messagerie privée et le travail git-over-Nostr en 2024, Blossom et le nettoyage des listes de relais en 2025, et les subventions clientes axées sur l’adoption en 2026.

Avril 2021 : le document de protocole avant le dépôt NIPs

Fiatjaf a publié l’article Nostr original, « Notes and Other Stuff Transmitted by Relays », le 20 novembre 2020. Ce premier texte contenait déjà la forme centrale qui définit encore le protocole : les utilisateurs signent des événements avec des clés, les publient sur des relais, et lisent depuis les relais qu’ils choisissent. Le journal de commits nostr-protocol/nostr ne montre aucun commit entre le 1er et le 30 avril. L’activité se trouve de chaque côté : les commits de mars 2021 ont ajouté les premiers liens « nostwitter » et un filtre kind, tandis que mai 2021 a réutilisé NIP-02 et ajouté la paternité des NIP.

En avril 2021, il n’y avait pas de marché client public, pas de réseau de relais visible, et pas de dépôt NIPs. Le protocole vivait encore comme un petit document et quelques expériences. Nostr n’était pas encore devenu un réseau social ou une plateforme de développement. C’était encore un modèle relais/clé/événement attendant sa première vague de contributeurs soutenue.

Avril 2022 : les NIPs vivaient encore dans le dépôt principal

Avril 2022 fut le dernier mois avant que les NIPs ne sortent du dépôt principal nostr-protocol/nostr. Comme la scission n’avait pas encore eu lieu, le dépôt dédié nostr-protocol/nips n’avait pas d’historique de pull requests en avril. Dans le dépôt principal, trois commits d’avril ont atterri : « Update readme to add nip12 » le 8 avril par goswami1999, « add kinds list » le 25 avril par jb55, et « add js formatting to sample code » le 28 avril par steliosrammos.

Le travail client commençait aussi à prendre forme. Les commits Damus d’avril 2022 ont ajouté le comportement précoce des salles de chat, la gestion des profils et les icônes d’application, tandis que nostr-tools devenait le chemin de bibliothèque JavaScript pour les premiers clients et expériences. Côté protocole, les requêtes de balise génériques NIP-12 ont donné à la recherche de balise une place documentée, la liste des kinds a fait progresser Nostr vers un modèle de registre, et de meilleurs exemples JavaScript ont rendu la spécification plus facile à implémenter pour les auteurs de clients et de bibliothèques. Le 1er mai, fiatjaf a déplacé les NIPs dans le dépôt dédié. Avril 2022 fut le dernier mois de l’ère originale mono-dépôt.

Avril 2023 : expansion des applications post-Damus

Avril 2023 est arrivé trois mois après que Damus a lancé sur l’App Store iOS le 31 janvier 2023, et après que Jack Dorsey ait publié sa clé publique Nostr. Le réseau venait d’absorber sa première grande vague de croissance publique. Les clients tels que Damus, Snort, Iris, Coracle et Amethyst étaient actifs, tandis que les opérateurs de relais apprenaient ce qu’un graphe social plus grand faisait aux hypothèses de bande passante, spam, recherche et modération.

Avril 2023 a eu une PR NIPs fusionnée : PR #456, fusionnée le 17 avril, ajoutant des liens d’entités bech32 NIP-19 à la gestion d’URI NIP-21. Les commits environnants montrent la pression d’application derrière le travail de protocole. Avril 2023 a vu des travaux sur NIP-45 COUNT, les marqueurs de zap spécifiques à l’événement, NIP-15 marketplace, la sémantique de délégation de suppression NIP-26, les métadonnées de fichier NIP-94, la gestion des erreurs de wallet-connect NIP-47, et NIP-30 emoji personnalisé. La liste des contributeurs s’était élargie pour inclure fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt et arkin0x.

Damus, Snort, Iris, Coracle et Amethyst n’étaient plus des démos autour d’une spécification ; c’étaient des clients de production traitant l’onboarding, les fils, le spam, les zaps, les médias et la sélection de relais. Le travail de protocole d’avril 2023 se lit comme le backlog que ces clients ont créé : zaps, marketplaces, métadonnées de fichier, comptage, emoji et liens d’identité ont tous poussé la spécification au-delà des simples notes et suivis.

Avril 2024 : messagerie privée, git-over-Nostr et support des mainteneurs

Avril 2024 a eu deux fusions de PR NIP. PR #1167, fusionnée le 10 avril, a corrigé une terminologie confuse dans la signature à distance NIP-46, où les clients et les signataires ont besoin d’un langage exact pour les actions demandées et autorisées. PR #1108, fusionnée le 17 avril, a étendu les dépôts git NIP-34 avec des événements de statut, des clarifications, des mainteneurs optionnels, des identifiants de dépôt et des balises de découvrabilité. Cette étape a rendu git-over-Nostr plus pratique pour ngit et plus tard GitWorkshop.

NIP-17, anciennement NIP-24, a atterri le 24 avril en tant que messages gift-wrapped scellés pour les DMs privés et les petits chats de groupe. Le travail sur les clients et bibliothèques a suivi : Amethyst, Primal, Gossip, nostr-tools, NDK et rust-nostr étaient tous actifs dans la même période.

OpenSats a également annoncé un support à long terme pour les développeurs Nostr en avril 2024 : PabloF7z le 9 avril, Stuart Bowman le 12 avril, et hzrd149 le 15 avril. Ces subventions ont déplacé le financement des subventions de projets isolés vers la maintenance soutenue des relais, bibliothèques et infrastructure client.

Avril 2025 : nettoyage dense des NIPs et formalisation de Blossom

Avril 2025 fut le mois de protocole le plus dense de cette rétrospective, avec seize PRs NIPs fusionnées. Le mois a commencé avec PR #1846, ajoutant les transactions et adresses blockchain à NIP-73, et PR #1865, ajoutant les balises NIP-C0 à la table des balises standardisées. Il a continué avec PR #1801 et PR #1889, améliorant tous deux les directives de republication de liste de relais de kind 10002, et PR #1879, qui a rétréci et clarifié NIP-65.

PR #1822 a ajouté NIP-B7 pour l’interaction Blossom, donnant aux clients Nostr et aux serveurs Blossom une couche de coordination canonique après plus d’un an de pratique informelle. PR #1051 a déprécié NIP-26, la spécification de signature d’événement déléguée. NIP-26 avait été difficile à implémenter en toute sécurité et était devenu moins attractif à mesure que NIP-46 et d’autres modèles de signataire mûrissaient.

Le reste du mois a combiné nettoyage et expansion d’application : PR #1882 a ajouté des champs politique de confidentialité et conditions d’utilisation à NIP-11, PR #1849 a étendu les signets web de kind 39701 sous NIP-B0, PR #1891 a ajouté ce kind de signet au README, et PR #1895 a ajouté les balises standardisées NIP-B0. OpenSats a annoncé sa Onzième Vague de Subventions Nostr le 16 avril, finançant Swae, HAMSTR, Vertex, Nostr Double Ratchet et Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK et rust-nostr livraient aussi pendant cette période, donc le nettoyage du protocole se situait à côté du travail actif sur les clients et bibliothèques.

Avril 2026 : durcissement de NIP-34, badges et subventions axées sur l’adoption

Avril 2026, le mois où ce numéro se termine, a eu quatre PRs NIPs fusionnées. La première fut PR #2276, fusionnée le 1er avril, qui a changé les badges de profil NIP-58 au kind 10008 et ajouté les ensembles de badges de kind 30008, rendant l’attribution de badges et les collections de badges plus composables. Un deuxième changement de convivialité git-over-Nostr est arrivé dans PR #2312, fusionnée le 10 avril, ajoutant la sémantique d’URL de clone nostr:// à NIP-34. Les nettoyages du 25 avril, PR #2325 et PR #2326, ont supprimé un langage inutilisé et incorrect de NIP-34.

Les commits connexes affinent les mêmes surfaces. Le 22 avril, fiatjaf a ajouté une liste de serveurs Blossom à NIP-51 et ajusté l’édition des métadonnées NIP-29 pour correspondre au comportement de style PUT de Flotilla. Le 26 avril, il a renommé NIP-5A pour plus de clarté. Avril 2026 s’est concentré sur rendre les surfaces de protocole déjà utilisées plus faciles à implémenter et plus difficiles à mal interpréter.

OpenSats a annoncé sa Seizième Vague de Subventions Nostr le 8 avril, soutenant Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr) et un renouvellement HAMSTR : clients de bureau, messagerie de type e-mail, UX de groupe, onboarding japonais et connectivité hors réseau.

Merci d’avoir lu Nostr Compass #20. DM-nous sur Nostr avec des conseils, corrections ou nouveaux projets à couvrir.

Nostr Compass #19

Wed, 22 Apr 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Amethyst livre une grosse vague de travail autour de Marmot, des communautés NIP-72, des objectifs de zap NIP-75 et des salons audio sur Media over QUIC. TollGate stabilise l’accès internet pay-per-use sur Nostr et Cashu avec v0.1.0. nostream clôt une grosse semaine de travail relay autour de NIP-45, NIP-62, de la compression et du durcissement des requêtes. Forgesworn publie une pile complète de signature, d’identité et d’API payante pour Nostr. ShockWallet poursuit la synchronisation native à Nostr de wallet Lightning, et les suites Formstr, StableKraft, Keep, topaz, WoT Relay et Flotilla complètent les sorties notables. Les deep dives de la semaine couvrent NIP-72 et NIP-57.

Actualités

Amethyst livre la conformité MIP de Marmot, les communautés NIP-72, les objectifs de zap et les salons audio MoQ

Amethyst a fusionné 57 PRs cette semaine. Les thèmes dominants sont la conformité des groupes chiffrés Marmot, la prise en charge native des communautés modérées NIP-72, les objectifs de zap NIP-75 sur les live streams NIP-53 et une nouvelle pile de salons audio reposant sur Media over QUIC.

Sur Marmot, les PR #2462, #2435, #2436, #2466, #2471, #2477 et #2493 ferment progressivement les écarts d’interop, de framing MLS, de KeyPackage Relay List et de validation cryptographique. PR #2488 ajoute aussi amy, un CLI piloté depuis l’implémentation d’Amethyst pour les opérations de groupe Marmot et MLS. Côté communautés, PR #2468 ajoute la création et la modération de communautés NIP-72. Côté live streaming, PR #2469 branche les objectifs de zap NIP-75 dans l’UI NIP-53, et PR #2494 ajoute le transport MoQ et les salons audio en temps réel.

TollGate v0.1.0 stabilise l’accès internet pay-per-use sur Nostr et Cashu

TollGate a publié v0.1.0 le 21 avril, premier snapshot tagué de ses spécifications d’accès réseau pay-per-use. Le protocole permet à un routeur WiFi, un switch Ethernet ou un partage Bluetooth de publier ses tarifs, d’accepter des tokens ecash Cashu et de gérer des sessions prépayées sans comptes, sans abonnements et sans KYC.

La release fixe trois couches : TIP-01 pour les événements de base (Advertisement, Session, Notice), TIP-02 pour les paiements Cashu, HTTP-01 à HTTP-03 pour l’interface HTTP, NOSTR-01 pour le transport via relays Nostr et WIFI-01 pour le medium WiFi captive portal. Le nouvel article de sujet TollGate couvre toute cette pile plus en détail.

nostream fusionne 53 PRs pour NIP-45, NIP-62, la compression et le durcissement des requêtes

nostream, l’implémentation relay TypeScript de Cameri, a fusionné 53 PRs en une semaine. PR #522 ajoute le support COUNT NIP-45, PR #544 ajoute NIP-62 à la liste de fonctionnalités annoncées, PR #548 étend le schéma de filtre aux tags majuscules #A à #Z, et PR #514 ajoute gzip et xz pour l’import/export d’événements.

PR #534 ajoute un harness de benchmarks et optimise la traduction filtre-vers-SQL, PR #524 corrige un bug de matching pubkey sur whitelist/blacklist, PR #553 durcit upsertMany en cas d’égalité de created_at, PR #493 limite la confiance dans X-Forwarded-For aux proxies déclarés, et PR #557 amène le relay à une parité complète avec NIP-11.

Sorties

Primal Android livre un onglet Explore, la vérification NIP-05 et un lecteur audio

Primal Android a poussé 11 PRs fusionnées après la refonte du flux de la semaine dernière. PR #1021 ajoute un onglet Explore construit autour des utilisateurs populaires, des follow packs et de flux curés, PR #1015 ajoute un éditeur de flux alimenté par le DSL Advanced Search de Primal, PR #994 ajoute l’UI de vérification NIP-05, et PR #997 embarque un lecteur audio in-feed. PR #1018 ajoute aussi le pairing nostr-connect NIP-46 depuis le scanner QR du wallet.

strfry ajoute des métriques Prometheus sur le chemin d’écriture et corrige l’enveloppe AUTH NIP-42

strfry a livré une série d’améliorations destinées aux opérateurs. PR #194 ajoute un exporter dédié de métriques Prometheus sur le chemin d’écriture et PR #197 journalise les bytes échangés par connexion ainsi que les ratios de compression. PR #192 rend configurable à l’exécution la limite de tags de filtre. PR #201 corrige enfin les réponses d’échec AUTH NIP-42 pour utiliser l’enveloppe OK prévue par la spécification au lieu de NOTICE.

Shopstr durcit la sécurité de ses vitrines à travers 13 PRs

Shopstr a fusionné 13 PRs dominées par des correctifs de sécurité. PR #434 ferme un trou de JavaScript stocké dans les liens de vitrines, PR #417 échappe le rendu HTML des policies de boutique, PR #418 corrige une API de suppression d’événements en cache accessible sans auth, PR #433 exige une authentification pour lire les messages en cache, et plusieurs autres PRs corrigent SSRF, revalidation de remises et robustesse de file de publication.

Nostria v3.1.26 à v3.1.28 ajoutent la lecture de musique en arrière-plan sur Android

Nostria a livré six versions cette semaine, de v3.1.22 à v3.1.28. La nouveauté principale de v3.1.26 est la lecture musicale en arrière-plan sur Android avec contrôles média dans la barre de notifications et sur l’écran verrouillé. v3.1.27 et v3.1.28 durcissent cette nouvelle surface de service média.

Wisp v0.18.0-beta ajoute le mode Normie, le flux For You et la configuration de groupe NIP-29

Wisp a livré v0.18.0-beta le 16 avril. PR #462 ajoute un mode Normie qui affiche les montants en fiat dans toute l’application, PR #464 revoit l’onboarding, PR #469 ajoute un flux For You, PR #471 ajoute la configuration de groupes NIP-29 et PR #478 corrige la séquence AUTH NIP-42 avant les événements de groupe.

NoorNote v0.8.4 ajoute les posts programmés et les zaps sur live stream

NoorNote a livré v0.8.4 et v0.8.5. La nouveauté principale est un add-on de posts programmés : l’application remet un événement déjà signé à un relay opéré par NoorNote, qui le publie à l’heure prévue sans que la clé privée quitte l’appareil. La même release ajoute les zaps en un geste depuis les cartes de live streams NIP-53.

topaz v0.0.2 livre un relay Nostr pour Android

topaz, nouveau relay Nostr de fiatjaf qui tourne directement sur téléphone Android, a publié v0.0.2 le 17 avril. Le projet est encore très étroit en surface mais livre déjà l’essentiel : un relay fonctionnel dans un package Android installable.

StableKraft v1.0.0 livre sa première release PWA stable musique-et-podcast

StableKraft est une PWA Next.js pour découvrir, organiser et streamer de la musique récupérée depuis des flux de podcasts, avec Nostr pour l’auth et les fonctions sociales, et Lightning pour le V4V. L’application atteint v1.0.0 le 18 avril. La même semaine, l’ingestion des feeds a été durcie avec un cache OPML de 15 minutes et une suppression de XML illégal, puis la fenêtre de reparse nocturne a été réduite de 720 heures à 24 heures.

NipLock livre un gestionnaire de mots de passe basé sur NIP-17

NipLock est un gestionnaire de mots de passe qui stocke et synchronise les identifiants entre appareils via des messages directs gift-wrapped NIP-17. Chaque entrée est un DM NIP-17 envoyé de la clé de l’utilisateur à elle-même, ce qui permet la réplication vers n’importe quel appareil authentifié avec la même clé. La signature fonctionne avec un nsec brut, des extensions navigateur comme nos2x ou Amber via NIP-46.

flotilla-budabit polit sa surface de dépôt NIP-34

Le fork communautaire Budabit de Flotilla, flotilla-budabit, a livré plusieurs correctifs de son workflow git-over-nostr NIP-34. Les changements restaurent les contrôles de discussion de dépôt, gardent les onglets épinglés visibles sur les pages de détail, chargent les annonces de dépôts depuis les relays GRASP enregistrés et maintiennent le statut des patchs appliqués par les mainteneurs synchronisé.

rx-nostr 3.7.2 à 3.7.4 ajoutent un vérificateur par défaut et des arguments constructeur optionnels

rx-nostr a livré 3.7.2, 3.7.3 et 3.7.4. PR #192 ajoute un vérificateur Schnorr par défaut, et PR #195 rend optionnels les arguments de createRxNostr() pour des intégrations plus rapides.

Keep Android v1.0.0 livre des builds reproductibles et zéro tracker

Keep, gestionnaire natif Nostr de mots de passe et de secrets, a livré v1.0.0 le 21 avril. PR #241 ajoute une recette de build reproductible, PR #248 remplace Google ML Kit par ZXing, PR #252 publie un scan Exodus Privacy montrant zéro tracker, et PR #256 ajoute un manifeste zapstore.yaml.

Flotilla 1.7.3 et 1.7.4 ajoutent l’enveloppement kind-9 pour des salons NIP-29 plus riches

Flotilla, client de groupes NIP-29 de hodlbod, a livré 1.7.3 et 1.7.4. Le changement protocolaire principal est l’enveloppement kind 9 de contenus non orientés chat, annoncé dans la note de release de hodlbod et aligné avec PR #2310. Le même cycle ajoute aussi sondages, connexion NIP-46 via Aegis, partages natifs, mentions de salon, brouillons et vidéo dans les appels.

WoT Relay v0.2.1 migre son eventstore vers LMDB

WoT Relay a livré v0.2.1 le 22 avril. PR #97 migre l’eventstore vers LMDB et retune les fetches bootstrap du web of trust, PR #99 met à jour golang.org/x/crypto, et PR #100 ajuste l’URL logicielle et la version annoncées via NIP-11.

Suite Formstr : passe sécurité Pollerama, i18n de Forms, support RRULE de Calendar

La suite Formstr a fusionné 26 PRs réparties entre Pollerama, Formstr Forms et Nostr Calendar. Pollerama durcit la gestion des clés, expire les DMs en cache à la déconnexion, déplace la clé locale dans un stockage navigateur sécurisé et protège le parsing JSON des profils kind 0. Formstr ajoute le support des URLs audio et vidéo, introduit l’i18n web et livre un importeur Google Forms. Nostr Calendar by Formstr a livré v1.3.0 et v1.4.0 avec le support de RRULE multiples et personnalisés, l’interprétation UTC des dates flottantes et plusieurs améliorations de partage et de notifications sur NIP-52.

Aussi livré : notedeck, nostr.blue, cliprelay, Captain’s Log

Quelques clients ont livré des releases incrémentales sans fonctionnalité phare unique. notedeck a publié v0.10.0-beta.4 avec des correctifs de rendu en colonnes et de pool de relays. nostr.blue v0.8.6 met à jour Dioxus et débloque Android. cliprelay a livré des builds desktop et Android pour le partage de presse-papiers entre appareils via Nostr, et Captain’s Log ajoute notamment la détection de liveness des relays de sync.

En développement

whitenoise-rs se refactorise autour de vues de compte à portée de session

whitenoise-rs a fusionné 15 PRs faisant progresser un refactor multi-phase depuis des singletons globaux vers des vues AccountSession par compte. Le but est de casser un monolithe partagé en surfaces par compte plus simples à raisonner, tester et faire évoluer. Les phases récentes ont migré handles relay, brouillons et paramètres, opérations de messages, lecture et écriture de groupes, appartenance, notifications push, lectures de KeyPackage, création de groupes et, depuis PR #770, le dispatch d’événements côté session.

White Noise ajoute l’UI de blocage/déblocage, le départ de groupe et les notices hors ligne

White Noise a ajouté les contrôles manquants de cycle de vie des groupes. PR #578 ajoute l’UI de block/unblock au-dessus du hook livré dans PR #573, PR #571 et PR #572 branchent clear_chat, delete_chat et leave_and_delete_group côté Rust, PR #569 et PR #576 ajoutent des notices hors ligne, et PR #585 restreint la suppression aux anciens KeyPackages hérités.

MDK ajoute le support des invitations entre versions mixtes et la convergence du format wire SelfUpdate

MDK a fusionné sept PRs autour de la compatibilité. PR #261 calcule RequiredCapabilities comme le LCD des capacités des invités, débloquant les invitations entre Amethyst et White Noise. PR #264 fait converger le format wire de SelfUpdate, tandis que PR #262, PR #256, PR #259 et PR #265 durcissent le parsing, la validation et l’exposition d’état.

nostter ajoute le chiffrement NIP-44 aux listes de personnes, bookmarks et mutes

nostter a fusionné 10 PRs. PR #2088, PR #2089 et PR #2090 migrent respectivement mutes, bookmarks et listes de personnes vers le chiffrement NIP-44, en s’éloignant de NIP-04. PR #2087 supprime un ancien chemin de migration kind-30000 devenu inutile.

zap.cooking livre le scoring Nourish et un fil de commentaires réutilisable

zap.cooking a fusionné 20 PRs. Les plus visibles ajoutent le module de scoring de recettes Nourish, refactorisent le module de commentaires vers un CommentThread réutilisable, et améliorent l’upload média, l’onglet Replies du profil et la mise à l’échelle des recettes.

ridestr extrait un coordinateur partagé pour les riders

ridestr a fusionné 10 PRs, refactorisant ses écrans Compose et extrayant la logique protocolaire riders/drivers dans un module partagé :common (PR #70). PR #60 ajoute aussi un récepteur de ping de conducteur kind 3189 pour le versant Roadflare de l’application.

Blossom ébauche un header BUD-01 Sunset pour l’expiration des blobs

Blossom a ouvert PR #99 pour ajouter un header Sunset à BUD-01. L’idée est qu’un serveur puisse annoncer à l’avance le moment où il cessera de servir un blob, en s’appuyant sur la sémantique standard RFC 8594.

Nouveaux projets

Forgesworn publie une boîte à outils cryptographique de 29 dépôts pour Nostr

Forgesworn a publié 29 dépôts open source en cinq jours couvrant la signature, l’identité, les attestations, le web of trust et la découverte d’API payantes sur Nostr. La pile de signature s’ancre sur nsec-tree, Heartwood, Sapwood et heartwood-esp32. Côté identité, Signet atteint v1.6.0, nostr-attestations définit un kind 31000 pour les credentials et endorsements, et nostr-veil construit un web of trust privé avec signatures de groupe LSAG.

La partie monétisation couvre aussi les API payantes sur Lightning et Nostr avec toll-booth, toll-booth-dvm, toll-booth-announce, 402-announce et 402-indexer. L’ensemble est écrit en TypeScript et publié via anvil, un outil bash-only de supply chain durcie.

ShockWallet livre une synchronisation Lightning native à Nostr et des connexions multi-node

ShockWallet est un wallet Lightning qui utilise Nostr comme transport pour se connecter à des nœuds Lightning auto-custodial. L’application se paire avec un ou plusieurs nœuds Lightning.Pub via un nprofile, puis signe de bout en bout les autorisations de paiement entre le wallet et le nœud. PR #608 ajoute une nouvelle vue dashboard pour les canaux, accompagnée de PR #606 et PR #607.

ShockWallet utilise des événements de données spécifiques à l’application NIP-78 pour synchroniser l’état du wallet entre appareils, ce qui le place une couche en dessous de NIP-47. En parallèle, l’équipe pousse aussi CLINK, un protocole de pairage de sessions basé sur Nostr.

Les issues Nostrability migrent vers git over Nostr après la censure GitHub

Nostrability, le tracker d’interop d’elsat pour les clients et relays Nostr, déplace son workflow d’issues vers git over Nostr après la fermeture de l’organisation Nostrability sur GitHub et deux semaines sans réponse du support GitHub. Le tracker vit désormais sur GitWorkshop/ngit.

nowhere encode des sites web complets dans des fragments d’URL et route les commandes via Nostr

nowhere est un nouveau projet AGPL-3.0 de 5t34k qui sérialise un site entier dans le fragment d’URL après #, le compresse puis l’encode en base64url. Comme les fragments ne sont pas envoyés au serveur, l’hôte qui livre la page ne voit jamais le contenu, et le site lui-même n’est jamais stocké sur un serveur. Les types nécessitant de la communication live utilisent des clés éphémères avec chiffrement NIP-44 sur des relays Nostr.

Petites nouvelles surfaces : relayk.it et Brainstorm Search

Deux petits projets méritent une mention rapide. relayk.it, construit par sam de l’équipe Soapbox, est un client de découverte de relays généré avec Shakespeare et entièrement exécuté dans le navigateur. Brainstorm Search se lance comme interface de recherche Nostr en page unique.

Travail sur le protocole et les spécifications

Mises à jour des NIP

Propositions et discussions récentes dans le dépôt NIPs :

PRs ouvertes et discussions :

NIP-67 : EOSE Completeness Hint (PR #2317) : ajoute un troisième élément optionnel à EOSE pour permettre à un relay d’indiquer qu’il a réellement livré tous les événements stockés correspondant au filtre.
NIP-5D : Nostr Applets (PR #2303) : propose un nouveau kind pour distribuer des applets interactives sur Nostr, à mi-chemin entre NIP-5A et NIP-5C.
NIP-29 : spécification des sous-groupes (PR #2319) : étend NIP-29 avec une hiérarchie de sous-groupes.
NIP-29 : permissions explicites sur le kind 39003 (PR #2316) : définit un schéma explicite de permissions par rôle.
NIP-11 : champ access_control pour la découverte de relays fermés (PR #2318) : permet d’annoncer le mode d’accès du relay et l’endpoint où demander l’autorisation.
NIP-63a : Minimal Payment Gateway Descriptor (PR #2315) : poursuit son itération sur le shape kind 10164.
NIP-XX : Agent Reputation Attestations (kind 30085) (PR #2320) : propose des attestations signées sur des agents et services autonomes sur Nostr, en particulier dans le contexte NIP-90.
NIP-TPLD : Transient Private Location Data (PR #2309) : poursuit l’itération sur le kind 20411, le chiffrement NIP-44 par destinataire et la sémantique du tag ttl.
PR de release marmot-ts 0.5.0 (PR #70) : regroupe les premiers changements cassants du client Marmot TypeScript, notamment le support conjoint des KeyPackages kinds 443 et 30443.

Deep Dive NIP : NIP-72 (communautés modérées)

NIP-72 définit un modèle de communautés thématiques dans lequel les modérateurs curent une vue de lecture au-dessus d’écritures autrement ouvertes. Une communauté est définie par un événement adressable kind 34550 contenant un slug d, des tags name, description, image, rules, des tags p marqués moderator et, éventuellement, des tags relay annotés author, requests ou approvals.

Les utilisateurs soumettent des posts en publiant un événement Nostr ordinaire et en ajoutant un tag a pointant vers la coordonnée 34550:<creator_pubkey>:<slug>. L’approbation est un événement séparé kind 4549 publié par un modérateur, qui référence la soumission par tag e, l’auteur par tag p, la communauté par tag a, et embarque une copie stringifiée de la soumission dans content. Ce modèle rend la modération transparente, forkable et révocable côté lecture, tout en gardant la publication ouverte à n’importe quel relay qui transporte les kinds nécessaires.

Deep Dive NIP : NIP-57 (Zaps)

NIP-57 définit les zaps, c’est-à-dire l’association d’un paiement Lightning à une identité ou à un contenu Nostr avec publication d’un reçu vérifiable sur les relays. Le flux implique un client expéditeur, un endpoint LNURL destinataire, le paiement Lightning lui-même et un reçu kind 9735 publié après paiement. La demande signée kind 9734 déclare le p tag du destinataire, un éventuel e ou a tag pour la cible, un tag amount, une liste relays et éventuellement un tag k.

Le point décisif est la validation. Un client sérieux doit vérifier que la signature du reçu correspond au nostrPubkey annoncé dans la réponse LNURL, que le montant de la facture bolt11 correspond au amount de la demande embarquée, que le hash de description de la facture s’engage sur cette demande et que le preimage correspond au payment_hash de la facture. Les zaps privés et anonymes ajoutent ensuite une couche de confidentialité, et NIP-75 réutilise ces reçus pour totaliser les objectifs de financement.

C’est tout pour cette semaine. Si vous construisez quelque chose ou avez des nouvelles à partager, envoyez-nous un DM sur Nostr ou retrouvez-nous sur nostrcompass.org.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Amethyst fusionne 29 PRs autour de Tor desktop, d’une implémentation C secp256k1, des appels NIP-AC et du support multi-wallet NIP-47. nstrfy lance des notifications push natives à Nostr pour Android via les relays et les événements kind 7741. HAMSTR ajoute Reticulum pour transporter des événements Nostr sur un mesh LoRa sans connexion internet. Bloom livre v0.1.0 avec un serveur Blossom auto-hébergé et un relay embarqué. WaveFunc lance une radio internet sur Nostr. Botburrow démarre comme plateforme de bots auto-hébergée pour les chats de groupe Marmot. Snort livre une série de releases avec audit de sécurité et refonte des performances, tandis que Primal Android repense sa mise en page du flux.

Actualités

Amethyst fusionne Tor desktop, C secp256k1, les appels WebRTC et le multi-wallet NWC

Amethyst, le client Android maintenu par vitorpamplona, a fusionné 29 PRs cette semaine à travers la cryptographie, le réseau, les appels et l’infrastructure wallet. La plus grande modification, PR #2381, ajoute le support de Tor sur desktop en embarquant un daemon kmp-tor avec un design fail-closed : si Tor est activé, toutes les connexions relay passent par le processus Tor embarqué, et l’application refuse de se connecter si Tor ne démarre pas.

PR #2374 ajoute une implémentation secp256k1 en C avec bindings JNI pour la vérification de signature, avec GLV decomposition, encodage de point wNAF et SHA-256 accéléré matériellement sur x86_64 et ARM64. Le résultat annoncé est un gain de 2x à 3x sur la vérification des signatures Schnorr. La PR #2202 aligne l’implémentation MLS en pur Kotlin sur RFC 9420 pour l’intégration Marmot, tandis que la série PR #2203 à PR #2211 construit un système complet d’appels voix et vidéo pour NIP-AC. Enfin, PR #1988 ajoute le support multi-wallet NIP-47, et PR #2189 ajoute la conversion GIF-vers-MP4 avec réglage de qualité.

nstrfy lance des notifications push natives à Nostr pour Android

nstrfy a été lancé le 13 avril avec trois releases de v1.0.0 à v1.2.0. L’application est un fork de ntfy-android dans lequel le transport HTTP est remplacé par Nostr : au lieu de sonder un serveur, nstrfy s’abonne à des événements kind 7741 sur des relays configurables et les affiche comme notifications Android natives.

Le modèle de notification supporte à la fois les payloads en clair et les payloads chiffrés NIP-44. Quand le chiffrement est activé, nstrfy utilise Amber pour la signature via NIP-55 ou un nsec local. L’application importe les listes de relays depuis le profil utilisateur via NIP-65 et respecte l’expiration d’événements NIP-40. Le projet compagnon nstrfy.sh fournit en plus un CLI bash et un client web hébergé sur nstrfy.sh.

HAMSTR ajoute Reticulum pour Nostr sur mesh LoRa

HAMSTR, le projet qui envoie des événements Nostr et des zaps Lightning sur la radio amateur, a fusionné PR #10 le 12 avril pour ajouter Reticulum comme backend de transport mesh. Reticulum est un protocole mesh cryptographique qui fonctionne sur LoRa, HF, VHF/UHF, liaisons série et TCP/IP. Avec cet ajout, HAMSTR peut relayer des événements Nostr à travers un mesh de matériels RNode sans infrastructure internet.

Les transports AX.25 Packet Radio et VARA HF restent disponibles. L’architecture zero-knowledge de HAMSTR signifie que le serveur relay ne voit jamais les clés privées, et sa conformité NIP-57 garantit que les zaps Lightning hors ligne apparaissent correctement dans des clients comme Amethyst et Primal. La même semaine, PR #11 a migré le frontend vers Svelte 5 et TailwindCSS v4.

Sorties

Bloom v0.1.0 livre un serveur Blossom auto-hébergé et un relay

Bloom a livré sa première release, v0.1.0, le 9 avril. Construit avec Tauri v2 et React 19, Bloom embarque un serveur média complet Blossom et un relay Nostr dans une seule application desktop pour macOS, Windows et Linux. Les utilisateurs obtiennent un stockage de fichiers souverain avec adressage de contenu SHA-256, support des métadonnées de fichier NIP-94 et résolution du schéma d’URI blossom:// sans gérer eux-mêmes une infrastructure serveur.

WaveFunc v0.1.0 et v0.1.1 lancent une radio internet Nostr

WaveFunc a livré v0.1.0 et v0.1.1 le 13 avril, se lançant comme annuaire et lecteur de radio internet basé sur Nostr. Le modèle de données s’appuie sur des kinds personnalisés : kind 31237 pour les stations, kind 30078 pour les favoris, kind 1311 pour le live chat et kind 1111 pour les commentaires de station. Le backend relay Khatru fournit le stockage SQLite et la recherche full-text Bluge avec support NIP-50.

WaveFunc embarque aussi un wallet Cashu NIP-60 et le support nutzap. La release v0.1.1 ajoute des carrousels de genres, un popover de dons Lightning, la gestion des stations pour les utilisateurs authentifiés et une fiche Zapstore. Les builds sont disponibles sur macOS, Windows, Linux et Android via wavefunc.live.

Snort livre v0.5.0 à v0.5.3 avec durcissement sécurité et refonte des performances

Snort, le client web Nostr basé sur React, a livré trois releases de v0.5.0 à v0.5.3. La version v0.5.0 est la plus importante : audit de sécurité, vraie vérification des signatures Schnorr, protection NIP-46 contre les messages relay falsifiés, améliorations du chiffrement PIN et suppression de la confiance implicite dans la délégation NIP-26.

Les gains de performance incluent une vérification batchée des signatures en WASM, des routes chargées paresseusement, un chargeur de profils prioritaire réécrit et des optimisations worker-relay. La release ajoute aussi l’affichage des factures kind 7000 requises pour paiement pour les DVM NIP-90. PR #620 retravaille en parallèle le système de messagerie pour réduire le coût du calcul de listes de chat.

Primal Android livre 3.0.21 et repense la mise en page du flux

Primal Android a livré v3.0.21 avec des correctifs pour les votes zap de sondages, le partage multi-comptes du wallet et l’auto-reconnexion du signataire distant et du service wallet. Sept PRs fusionnées ont suivi : PR #1008 unifie la mise en page de l’écran principal, PR #1010 introduit un nouveau design de cartes de flux, PR #1009 ajoute le support vidéo dans les cartes média, PR #1012 ajoute un champ compact pour les réponses rapides, et PR #1013 repense les barres d’application.

Nostria v3.1.19 à v3.1.21 ajoutent la génération locale d’images

Nostria a livré trois releases de v3.1.19 à v3.1.21 avec plus de 80 commits. La nouveauté principale est la génération locale d’images avec Janus Pro accéléré par WebGPU, de sorte que les utilisateurs puissent générer des images sur l’appareil sans API externe. Les releases ajoutent aussi la génération d’images cloud, le chat multimodal, le support ONNX runtime, une bibliothèque de prompts et la gestion du cache AI.

TubeStr v1.0.3 livre des mises à jour du flux et du studio

TubeStr, application privée de partage vidéo familial construite sur Nostr, a livré v1.0.3 le 13 avril. La release apporte des améliorations du flux et du studio. PR #3 revoit les écrans d’onboarding et PR #2 corrige une erreur d’export vidéo. L’application utilise NDK et MDK pour le partage média chiffré entre membres d’une famille.

En développement

Botburrow commence comme plateforme de bots Marmot

Botburrow est un nouveau projet de l’équipe Marmot, démarré le 3 avril. Il s’agit d’une plateforme auto-hébergée de gestion de bots où chaque bot reçoit sa propre identité Nostr, rejoint des chats de groupe Marmot via des messages Welcome et envoie ou reçoit des messages chiffrés de bout en bout. Le tableau de bord, construit avec Rails 8.1, communique avec un unique daemon whitenoise-rs (wnd) via un socket Unix.

Le projet expose déjà une couche importante de scripts et d’opérations : commandes, triggers et actions planifiées exécutent du code Ruby personnalisé, les scripts peuvent inspecter profils, appartenance aux groupes et invitations en attente via wnd, et l’interface inclut une vue de chat live. Une image Docker cible l’auto-hébergement sans configuration sur Umbrel et Start9.

Nostr Archives ajoute un relay de flux tendances et la résolution d’entités

Nostr Archives, la plateforme d’archivage et d’analytics à nostrarchives.com, poursuit son développement côté API en Rust et côté frontend en Next.js 16. PR #118 ajoute le filtrage par plage de temps au leaderboard client, PR #117 ajoute des compteurs d’engagement sur les réponses, PR #85 résout directement les entités Nostr depuis les chemins d’URL, et PR #86 ajoute une page de documentation API.

Damus corrige la timeline des favoris

Damus, le client iOS, a fusionné PR #3708 qui réécrit subscribe_to_favorites() avec filtrage sur place, reconstruction de la déduplication et persistance de l’onglet sélectionné.

Nostur ajoute les zaps privés et l’affichage des emoji personnalisés

Nostur, le client iOS, a poussé 10 commits cette semaine ajoutant le support des zaps privés, l’affichage des emoji personnalisés, un correctif de rendu .webp animé et la détection du format audio des messages vocaux.

Amber livre v6.0.1 à v6.0.3 avec sauvegarde WebDAV et correctifs de reconnexion relay

Amber, l’application signataire Android NIP-55, a livré trois versions. v6.0.1 ajoute WebDAV et le partage vers Google Drive comme nouvelles options de sauvegarde, implémente un backoff exponentiel pour les reconnexions relay et met à jour Quartz. v6.0.2 ajoute une option d’index de compte lors de l’usage des seed words, et v6.0.3 corrige un problème d’ID de requête vide lors de la réception d’intents.

Plektos v0.6.0 se repense avec des thèmes Ditto

Plektos, la plateforme décentralisée de meetups et d’événements construite sur NIP-52, a livré v0.6.0 et v0.6.1. La mise à jour ajoute des thèmes communautaires de style Ditto avec upload d’images d’arrière-plan, configuration de la forme des avatars et refonte de l’UI. PR #6 traite une revue de code complète couvrant sécurité, architecture et UX.

Shadow ajoute une API Nostr OS et une app wallet Cashu

Shadow, la plateforme runtime d’apps de Justin Moon, a poussé plus de 30 commits en deux jours. Commit 88cbda5 ajoute une application wallet Cashu tournant dans le runtime Shadow, et Commit 865c415 ajoute une démo de lecteur de podcast. Le runtime expose Shadow.os.nostr et Shadow.os.audio comme API système de premier plan.

Lief corrige la connexion Amber et ajoute Zapstore

Lief, application Nostr d’écriture de lettres longues, a livré le build v2026.04.12. La mise à jour corrige un problème de connexion au signataire Amber sur Android, simplifie le flux de nudge du signataire, met à jour la dépendance nostrify et ajoute l’intégration Zapstore.

Espy revoit complètement le sélecteur de couleurs et corrige la connexion Amber

Espy, application sociale Nostr où les utilisateurs partagent des « moments couleur », a livré le build v2026.04.12. La mise à jour remanie le sélecteur de couleurs avec un arc de saturation courbe, corrige des bugs de scintillement sur l’anneau de teinte et ajoute des personnages cachés. La release corrige aussi un problème de connexion Amber, simplifie le flux de nudge du signataire, met à jour nostrify et ajoute Zapstore.

Jumble ajoute des filtres de kind par flux et un onglet Articles

Jumble a poussé 13 commits ajoutant le filtrage par kind dans chaque flux, un onglet Articles, la synchronisation du statut lu des notifications avec une option préservant la vie privée, un mode de masquage d’avatar et un correctif de race condition lors du changement de compte.

Primal Web livre 8 montées de version

Primal Web a livré les versions 3.0.93 à 3.0.101 en une semaine avec 21 commits. Le travail s’est concentré sur l’amélioration du chat de live stream, des correctifs sur les frontières de mentions, la pagination des bookmarks, la prévention des likes dupliqués et des correctifs du relay proxy.

Travail sur le protocole et les spécifications

Mises à jour des NIP

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

Fusionnés :

NIP-34 (Git Stuff) : ajout des URL de clone nostr:// (PR #2312) : la spécification définit désormais trois formes d’URL nostr:// pour référencer des dépôts NIP-34 de manière lisible ou directement par naddr. Cela permet à des helpers git-remote-nostr de résoudre un npub ou une adresse NIP-05, de découvrir les relays du dépôt puis de récupérer les données git. La PR resserre aussi le format du tag d des identifiants de dépôt afin que ces URL produisent des URI valides.

PRs ouvertes et discussions :

NIP-63a : Minimal Payment Gateway Descriptor (PR #2315) : propose un événement remplaçable kind 10164 permettant aux créateurs de déclarer des passerelles de paiement, des modèles tarifaires et des règles d’abonnement pour l’accès à du contenu payant.
NIP-XX : Relay Self-Declaration Manifest and Retention Horizon (PR #2314) : propose un manifeste gossipable kind 10100 pour la transparence relay et un nouveau message relay-vers-client HORIZON qui annonce la borne temporelle la plus ancienne que le relay conserve.
NIP-TPLD : Transient Private Location Data (PR #2309) : propose le kind 20411 pour partager des données de géolocalisation chiffrées NIP-44 avec des destinataires spécifiques.
NIP-5C (Scrolls) : mise à jour des programmes WASM (PR #2281) : poursuit le travail sur la publication et l’exécution de binaires WASM distribués comme événements Nostr.
Support des gros payloads NIP-44 (PR #1907) : propose d’étendre NIP-44 au-delà de la limite actuelle de 65 535 bytes, en particulier pour les usages comme la signature distante NIP-46 de grosses contact lists kind 3.
NIP-C7 : restreindre le kind 9 aux vues de chat (PR #2310) : ajoute une exigence selon laquelle les clients qui rendent une « vue chat » comme flux d’événements ordonnés ne doivent récupérer que des événements kind 9.

Deep Dive NIP : NIP-29 (groupes basés sur les relays)

NIP-29 définit un modèle de messagerie de groupe où le relay lui-même gère l’appartenance et la modération. Les groupes vivent sur un relay spécifique, identifié par une chaîne aléatoire, et le relay fait autorité pour décider qui peut écrire dans le groupe. C’est une architecture différente de Marmot ou des chats de groupe NIP-17 : ici, le relay peut lire les messages et la modération se fait au niveau du relay.

Un groupe est identifié par le format <host>'<group-id>, par exemple groups.nostr.com'abcdef. Les événements envoyés dans le groupe portent un tag h avec l’identifiant du groupe, et un tag previous peut référencer les premiers 8 caractères hexadécimaux d’événements récents vus sur le même relay pour détecter les rediffusions hors contexte. L’appartenance se gère via des événements de modération dans la plage 9000-9020, comme les demandes d’adhésion kind 9021, les suppressions kind 9001, les changements de métadonnées kind 9002 et les événements de rôles kind 39003.

Les groupes peuvent être publics, fermés ou totalement ouverts, et la lecture comme l’écriture peuvent être contrôlées indépendamment. La spécification accepte aussi d’autres kinds que le chat : articles NIP-23, événements calendrier NIP-52 ou lives NIP-53 peuvent tous participer au même espace de groupe. Pour des communautés publiques, ce modèle de confiance assumée côté relay est souvent suffisant ; pour la confidentialité de groupe, Marmot ou NIP-17 restent mieux adaptés.

Deep Dive NIP : NIP-90 (Data Vending Machines)

NIP-90 définit un protocole de calcul à la demande sur Nostr. Un client publie une demande de travail, des fournisseurs peuvent y répondre, et les résultats reviennent eux aussi comme événements Nostr. Les kinds 5000-5999 sont réservés aux demandes de jobs, les kinds 6000-6999 aux résultats et le kind 7000 au feedback d’état.

Une demande peut inclure des tags i pour les entrées, param pour les paramètres, output pour le format de sortie attendu, bid pour le plafond de paiement et des hints de relays pour le retour. Les fournisseurs peuvent demander un paiement avant exécution, publier des états processing ou payment-required, puis renvoyer un résultat du kind correspondant, toujours 1000 au-dessus du kind de la demande. Le protocole supporte aussi le chaînage de jobs, ce qui permet d’enchaîner transcription, résumé et traduction sans couche d’orchestration séparée.

C’est tout pour cette semaine. Vous construisez quelque chose ou vous avez des nouvelles à partager ? Envoyez-nous un DM sur Nostr ou retrouvez-nous sur nostrcompass.org.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Amethyst livre v1.08.0 avec l’intégration d’Arti Tor et une interface Shorts repensée, tout en fusionnant des implémentations en pur Kotlin de MLS et Marmot dans sa bibliothèque Quartz. Nostur livre v1.27.0 avec enregistrement vidéo, profils GIF animés et réponses privées. Shosho lance v0.15.0 avec Shows (informations de live personnalisées connectées à OBS) et un carrousel vidéo vertical de style TikTok. Nymchat abandonne Marmot et livre des chats de groupe NIP-17 renforcés avec des clés éphémères rotatives. Nostr VPN livre le support des exit nodes et le packaging Umbrel à travers six versions. Amber passe à v6.0.0-pre1 avec des clés de signature NIP-46 par connexion et des mises à jour in-app via Zapstore. Notedeck atteint v0.10.0-beta avec l’auto-update APK via Zapstore, et NIP-58 (Badges) reçoit une migration de kind. Deux deep dives NIP couvrent NIP-17 (Private Direct Messages) et NIP-46 (Nostr Remote Signing).

Actualités

Amethyst livre Arti Tor, intègre MLS et Marmot en pur Kotlin

Amethyst, le client Android maintenu par vitorpamplona, a livré quatre versions de v1.07.3 à v1.08.0 et a fusionné un gros lot de travail non encore publié dans sa bibliothèque Quartz (le module Nostr Kotlin Multiplatform partagé). La version phare est v1.08.0 « Arti Tor », qui migre la connectivité Tor de l’application depuis la bibliothèque Tor en C vers Arti, l’implémentation Rust du Tor Project. La migration corrige des crashes aléatoires qui survenaient avec les anciens bindings Tor en C. Arti est le remplaçant de long terme du Tor Project pour le codebase en C, réécrit depuis zéro en Rust pour la sûreté mémoire et les async I/O.

La version v1.07.3 a repensé l’interface Shorts, en remplaçant le design paginé par des flux bord à bord pour les images, les shorts et les vidéos longues. La même version a migré les badges vers le kind 10008 et les bookmarks vers le kind 10003, en s’alignant sur la migration de kind NIP-58 fusionnée cette semaine. v1.07.4 a corrigé un problème de gestion de secret Nostr Wallet Connect, et v1.07.5 a corrigé un crash lors du téléversement d’images.

Sur main mais pas encore dans une release taguée, l’équipe a écrit une implémentation complète en Kotlin de MLS et du protocole Marmot, supprimant le besoin de bindings natifs vers des bibliothèques C/Rust. PR #2147 ajoute la couche centrale de messagerie de groupe MLS de Marmot, PR #2149 ajoute l’interface de chat de groupe, PR #2146 ajoute les processeurs de messages entrants et sortants avec un gestionnaire d’abonnements, PR #2141 ajoute la persistance d’état de groupe MLS et la gestion de rotation des KeyPackage, PR #2150 ajoute une suite de tests MLS complète avec une signature GroupInfo améliorée, et PR #2158 ajoute le suivi du statut de publication des KeyPackage. PR #2166 ajoute une implémentation secp256k1 en pur Kotlin pour les opérations cryptographiques Nostr, remplaçant la dépendance à la bibliothèque C native. Combiné à l’implémentation MLS en Kotlin, Quartz peut exécuter la signature Nostr et la messagerie de groupe Marmot sans aucun binding natif, ce qui ouvre la voie à des cibles Kotlin Multiplatform, y compris iOS.

L’équipe construit aussi le support de NIP-AC (P2P Voice and Video Calls) : PR #2143 ajoute une suite de tests complète pour la machine d’état d’appel NIP-AC, et PR #2164 empêche d’anciennes offres d’appel de se redéclencher après un redémarrage de l’application.

Nostur v1.27.0 ajoute l’enregistrement vidéo et les réponses privées

Nostur, le client Nostr iOS, a livré v1.27.0 le 2 avril. La version ajoute l’enregistrement vidéo in-app avec découpe avant téléversement, de sorte que les utilisateurs puissent capturer de courts clips, les raccourcir et les publier sans quitter le client. Le support des GIFs animés s’étend aux photos de profil et de bannière, avec aussi l’ajout du rendu WebP animé. Une nouvelle intégration Shortcuts permet aux utilisateurs d’envoyer des posts Nostr depuis les automatisations Apple Shortcuts. La version ajoute aussi les réponses privées et corrige des problèmes de compatibilité DM qui affectaient la livraison des messages entre Nostur et d’autres clients.

Shosho v0.15.0 lance Shows et un carrousel vidéo vertical

Shosho, l’application de live streaming Nostr, a livré v0.15.0 et v0.15.1 le 7 avril. La fonctionnalité phare est Shows : les streamers peuvent préparer des informations d’émission personnalisées avant de passer en direct et connecter leur show à OBS ou à n’importe quel encodeur externe. Cela sépare les métadonnées « qu’est-ce que je diffuse » de l’acte de passer en direct, de sorte que les streamers puissent préparer titres, descriptions et produits avant de commencer la diffusion. La même version ajoute un carrousel vidéo vertical de style TikTok pour parcourir lives, clips et replays dans un flux plein écran, ainsi que Quick Add pour publier des clips vidéo et ajouter des produits directement depuis une page de profil. v0.15.1 corrige un bug où le clavier masquait le champ de saisie du chat de live.

Versions

Notedeck v0.10.0-beta livre l’auto-update via Zapstore

Notedeck, le client desktop et mobile de l’équipe Damus, a livré v0.10.0-beta.1 et v0.10.0-beta.2 comme préreleases de test pour l’auto-update APK. PR #1417 ajoute l’auto-update APK via l’updater Nostr/Zapstore sur Android, en prolongeant le travail de découverte de mises à jour natif à Nostr de la Newsletter #14. Le flux de mise à jour découvre les nouvelles releases via des événements Nostr publiés sur des relays, puis télécharge l’APK depuis l’endroit où le développeur l’héberge (GitHub releases, Blossom CDN ou autres sources), vérifie le hash SHA-256 contre l’événement Nostr signé, puis l’installe. PR #1438 corrige un bug d’écran d’accueil où les boutons Login et CreateAccount revenaient immédiatement en arrière, et PR #1424 corrige un débordement de texte dans la vue de session Agentium AI.

Amber v6.0.0-pre1 ajoute des clés de signature NIP-46 par connexion

Amber, l’application signataire NIP-55 (Android Signer Application), a livré v6.0.0-pre1 le 4 avril. Le changement le plus important est l’ajout de clés de signature par connexion pour le protocole bunker NIP-46 (Nostr Remote Signing). Au lieu d’utiliser une seule paire de clés pour toutes les connexions bunker, Amber génère désormais une clé distincte pour chaque client connecté. Si la connexion d’un client est compromise, l’attaquant ne peut pas usurper le signataire auprès des autres clients.

PR #377 ajoute la vérification et l’installation de mises à jour in-app via Zapstore, rejoignant Notedeck dans l’adoption d’une distribution d’apps native à Nostr. PR #375 gère les échecs AndroidKeyStore proprement en affichant un avertissement aux utilisateurs au lieu de crasher, et PR #371 ajoute un nettoyage de base de données avec limites de taille et troncature de contenu pour empêcher une croissance de stockage non bornée. La prérelease reprend aussi la liste blanche d’auth relay NIP-42 et la connexion par phrase mnémonique de récupération du cycle v5.0.x couvert la semaine dernière.

Nostria livre une application mobile native

Nostria, le client Nostr cross-platform maintenu par SondreB, a publié une application mobile native pour Android avec huit versions de v3.1.11 à v3.1.18. La nouveauté la plus importante est le support natif d’un signataire local pour des signataires comme Amber et Aegis. Des installeurs desktop pour Linux, macOS et Windows sont aussi disponibles. PR #610 réduit la pression mémoire du flux avec des limites runtime adaptatives et un nettoyage des URLs d’aperçu. v3.1.14 corrige l’intégration avec Brainstorm, un fournisseur Web of Trust. v3.1.15 se concentre sur des améliorations musicales. La nouvelle application Android est disponible sur Zapstore.

diVine 1.0.8 livre des téléversements reprenables et des DMs

diVine, le client vidéo short-form, a livré 1.0.8 avec 87 PRs fusionnées. Les téléversements reprenables permettent aux créateurs de reprendre des téléversements interrompus morceau par morceau au lieu de repartir de zéro sur une connexion instable. La version ajoute des réglages de qualité vidéo et de bitrate, le double tap pour liker, et des améliorations des DMs. PR #2722 ajoute un plugin caméra macOS pour la capture vidéo desktop, et PR #2820 migre le système de notifications vers une architecture BLoC avec enrichissement et regroupement. L’équipe a aussi remplacé les stickers et illustrations de catégories générés par AI par des SVG OpenMoji (PR #2844, PR #2842).

Manent v1.3.0 ajoute le floutage des notes sensibles et l’auth NIP-42

Manent, l’application privée de notes chiffrées et de stockage de fichiers, a livré v1.3.0 le 2 avril. Les utilisateurs peuvent maintenant marquer des notes comme sensibles afin de les flouter dans la vue liste, ce qui garde le contenu privé caché lors d’un défilement occasionnel. La version ajoute aussi le support NIP-42 (Authentication of Clients to Relays), permettant à Manent de s’authentifier auprès des relays qui l’exigent avant d’accepter les événements. Manent stocke toutes les données chiffrées sur les relays Nostr à l’aide de la paire de clés de l’utilisateur, donc le support NIP-42 élargit l’ensemble des relays qu’il peut utiliser pour le stockage.

Wisp v0.17.0 à v0.17.3 ajoutent les zaps sur live stream et la sauvegarde du portefeuille

Wisp, le client Nostr Android, a livré six versions de v0.16.2-beta à v0.17.3-beta avec 44 PRs fusionnées. La version v0.17.0 ajoute des invites de sécurité pour la sauvegarde du portefeuille et des améliorations UX pour les zaps. v0.17.1 ajoute la visibilité du chat de live stream à travers les plateformes et la fonctionnalité de zap sur live stream. PR #423 ajoute l’auto-search des profils, une animation de succès de zap et des améliorations du statut utilisateur. PR #426 corrige un crash out-of-memory dans computeId pour des événements avec de grandes listes de tags. Les versions v0.16.x avaient ajouté l’autocomplétion des shortcodes emoji, des améliorations de l’interface de chat de groupe et le filtrage des utilisateurs bloqués sur tous les chemins de notification.

Mostro livre des deep links, des taux de change Nostr et un correctif de paiement en double

Mostro, l’échange Bitcoin pair à pair construit sur Nostr, a connu cette semaine des mises à jour à la fois sur son daemon serveur et son client mobile. Côté serveur, PR #692 empêche que des écritures d’ordres obsolètes causent des paiements en double, un bug qui pouvait conduire à payer deux fois un vendeur pour la même transaction. PR #693 utilise des mises à jour ciblées pour les écritures dev_fee au lieu d’écrasements complets d’ordres.

Mostro Mobile, le client Flutter, a livré v1.2.3 le 3 avril. La version gère les deep links provenant de différentes instances Mostro, de sorte que les utilisateurs puissent toucher des liens qui routent vers le bon serveur d’échange. PR #498 détecte les DMs admin et de litige dans le pipeline de notifications en arrière-plan, et l’application récupère désormais les taux de change depuis Nostr avec un fallback HTTP/cache. PR #560 corrige un bug bloquant la connexion relay qui empêchait l’application d’atteindre les relays dans certaines conditions réseau.

Unfiltered v1.0.12 ajoute les hashtags et les commentaires

Unfiltered, un client Nostr centré sur le contenu image-first, a livré v1.0.12. PR #69 ajoute le support des hashtags et PR #72 ajoute la possibilité d’écrire et d’afficher des commentaires sur les posts. PR #71 corrige des problèmes de navigation avec plusieurs images par post.

Primal Android livre le partage multi-comptes du portefeuille et l’auto-reconnexion du signataire distant

Primal, le client Nostr Android, a livré une version le 7 avril. La mise à jour ajoute le partage multi-comptes du portefeuille et un menu overflow avec suppression du portefeuille dans Dev Tools. Le signataire distant se reconnecte désormais automatiquement lors des pertes de connexion, et le service portefeuille a gagné sa propre logique d’auto-reconnexion. Les correctifs incluent le fait que les votes zap de sondage n’apparaissent plus comme Top Zaps, la prévention des crashes sur option de sondage vide, le masquage du solde du portefeuille quand aucun portefeuille n’existe, et le mapping des types de WalletException vers des codes d’erreur dans les réponses NWC.

Titan v0.1.0 lance un navigateur natif `nsite://` avec enregistrement de noms sur Bitcoin

Titan, un navigateur desktop natif pour le web Nostr, a livré v0.1.0 le 7 avril. Titan résout les URLs nsite:// en recherchant des noms lisibles par l’humain enregistrés sur Bitcoin, en interrogeant les relays Nostr pour les événements de contenu du site, puis en rendant les pages récupérées depuis des serveurs Blossom. Le résultat est une expérience de navigation web sans DNS, sans certificats TLS et sans hébergeurs. Les noms sont enregistrés via une interface web liée à des transactions Bitcoin. La version initiale est livrée sous forme de .dmg macOS (ARM, avec support Rosetta 2 pour Intel) et inclut le support d’un environnement de développement Nix.

Bikel v1.5.0 livre un service d’avant-plan natif pour les téléphones de-Googlés

Bikel, un tracker cycliste décentralisé qui transforme les trajets en données d’infrastructure publique via Nostr, a livré v1.5.0 le 4 avril. La version migre depuis Expo TaskManager dépendant de GMS vers un service d’avant-plan natif personnalisé, garantissant un suivi fiable des trajets en arrière-plan sur LineageOS, GrapheneOS et d’autres variantes Android de-Googlées. Le Bikel Bot a reçu une architecture dual-pocket avec collecte eCash autonome via des Cashu nutzaps. v1.4.3 et v1.4.2 corrigent la synchronisation du suivi en arrière-plan pour les environnements Android non standard, et l’application ajoute des bascules de points de carte pour les racks à vélos OSM.

Sprout ajoute le support de NIP-01, NIP-23 et NIP-33

Sprout, une plateforme de communication de Block avec relay Nostr intégré, a livré desktop/v0.1.0-rc7 le 6 avril. Cette semaine, l’équipe a ajouté le support des articles kind 30023 NIP-23 (Long-form Content), des événements remplaçables paramétrés NIP-33 avec remplacement indexé par tag d, et des text notes kind 1 et follow lists kind 3 NIP-01/NIP-02. La version ajoute aussi un système de thèmes IDE adaptatifs avec 54 thèmes, des améliorations UX de workflow et d’historique d’exécution d’agents, ainsi qu’un nettoyage de la sidebar membres.

mesh-llm v0.56.0 livre un protocole de configuration distribué

mesh-llm, un système d’inférence LLM distribué qui utilise des paires de clés Nostr pour l’identité des nœuds, a livré v0.56.0 le 7 avril. La version ajoute un protocole de configuration distribué avec une sémantique de propriété, une quantification asymétrique du cache KV (clés Q8_0 avec valeurs Q4) pour réduire l’usage mémoire, le stockage dans l’OS keychain pour les keystores d’identité, un streaming de chat fluide avec mise en file des messages, et des correctifs pour la mise en page fullscreen et le découpage du cache KV avec flash attention.

Nostr VPN livre le support des exit nodes et le packaging Umbrel

Nostr VPN, un VPN pair à pair qui utilise les relays Nostr pour le signalement et WireGuard pour les tunnels chiffrés, a livré six versions de v0.3.0 à v0.3.6 cette semaine. Le cycle v0.3.x ajoute le support des exit nodes sur Windows et macOS, permettant à des pairs de router le trafic internet via d’autres nœuds du réseau. La propagation des invitations et des alias se synchronise désormais sur Nostr, de sorte que les utilisateurs puissent partager l’accès réseau sans coordination hors bande. Les versions ajoutent le packaging Umbrel pour un déploiement auto-hébergé, le NAT punch-through en utilisant des endpoints publics mémorisés, le nettoyage automatique des exit nodes obsolètes, et une spécification de protocole publiée. Le projet a aussi stabilisé la gestion des routes macOS avec des routes par défaut auto-réparatrices et une réparation de l’underlay, et a ajouté une build Android via Tauri. Des builds sont disponibles pour macOS (Apple Silicon et Intel), Linux (AppImage et .deb), Windows et Android.

Nymchat abandonne Marmot et livre des chats de groupe NIP-17 renforcés

Nymchat, le client de chat capable de MLS, a livré 14 versions de v3.56.261 à v3.58.274. Le changement le plus significatif est un pivot protocolaire : v3.57.261 a ajouté des chats de groupe MLS Marmot, mais v3.58.268 est revenu à NIP-17 parce que le support multi-appareils de Marmot n’est pas encore terminé, ce qui causait des problèmes de synchronisation de l’état des chats de groupe entre appareils. v3.58.271 introduit des chats de groupe NIP-17 renforcés avec des clés éphémères rotatives pour tous les messages, conçues pour prévenir les attaques de timing et de corrélation. La semaine a aussi apporté un système d’amis avec contrôle granulaire des paramètres (v3.58.262), la synchronisation des messages de groupe MLS dans les paramètres applicatifs chiffrés, et plusieurs correctifs de connectivité relay.

nak v0.19.5 ajoute Blossom multi-serveur et la publication outbox

nak, la boîte à outils Nostr en ligne de commande de fiatjaf, a livré v0.19.5. La commande blossom accepte désormais plusieurs flags --server pour téléverser vers plusieurs serveurs Blossom en un seul appel. Une nouvelle commande key complète les clés partielles en les left-padding avec des zéros. La commande event gagne un flag --outbox pour publier des événements via le modèle outbox, et fetch sort maintenant avec un code d’erreur quand aucun événement n’est renvoyé.

En développement

White Noise ajoute des aperçus thumbhash et un pont d’enregistrement push

White Noise, la messagerie privée construite sur le protocole Marmot, a fusionné cinq PRs. PR #549 remplace les aperçus d’images blurhash par thumbhash, un algorithme plus récent qui produit des images placeholder plus nettes avec une charge utile plus petite (généralement moins de 30 bytes contre environ 50-100 bytes pour blurhash) tout en conservant le ratio d’aspect et la distribution de couleurs de l’image d’origine. Blurhash est conservé comme fallback pour les anciens contenus. PR #548 met à jour whitenoise-rs et ajoute le pont d’enregistrement push MIP-05, connectant le travail sur la spécification des notifications push de la semaine dernière au client. PR #493 ajoute une pagination à curseur pour les messages de chat, remplaçant l’ancienne stratégie de chargement par une approche pilotée par le scroll.

Route96 ajoute une configuration dynamique des labels et un nettoyage zéro-egress

Route96, le serveur média Blossom de v0l, a fusionné trois PRs. PR #80 ajoute la configuration dynamique des modèles de labels via l’API d’administration, permettant aux opérateurs de changer de modèles de classification de contenu sans redémarrer le serveur. PR #82 ajoute les champs de configuration de labels à l’interface d’administration. PR #79 ajoute une politique de nettoyage de fichiers zéro-egress qui supprime automatiquement les fichiers qui n’ont jamais été téléchargés, afin de réduire les coûts de stockage pour les opérateurs.

Snort livre du durcissement de sécurité et des factures de paiement DVM

Snort, le client web, a livré deux versions cette semaine avec un audit de sécurité complet. Les correctifs incluent la vérification des signatures Schnorr, la protection NIP-46 contre la falsification de messages relay (empêchant des attaquants d’injecter des requêtes de signature via des relays compromis), des améliorations du chiffrement du PIN, et la suppression de la confiance de délégation NIP-26. Les gains de performances viennent d’une vérification Schnorr batchée en WASM, de routes chargées paresseusement, de traductions précompilées et de l’élimination d’une double vérification par événement. PR #618 ajoute l’affichage de factures kind 7000 NIP-90 (Data Vending Machine) requérant paiement, de sorte que lorsqu’un DVM répond avec une exigence de paiement, Snort rend la facture Lightning directement dans le flux.

Damus améliore la compaction LMDB

Damus, le client iOS, a fusionné PR #3719 ajoutant une compaction LMDB automatique planifiée, empêchant la base de données locale de croître sans borne au fil du temps. PR #3663 améliore BlurOverlayView pour lui donner un aspect protecteur plutôt que cassé.

Captain’s Log ajoute l’indexation des tags et la synchronisation des notes

Captain’s Log (Comet), l’outil d’écriture long-form natif à Nostr de Nodetec, a fusionné quatre PRs cette semaine. PR #156 ajoute l’indexation des tags et le support de synchronisation entre les notes, PR #157 refactorise la synchronisation des notes et la gestion des tags, et PR #159 corrige la synchronisation des notes mises à la corbeille afin que les notes supprimées restent supprimées sur tous les appareils.

Relatr v0.2.x repense le système de plugins avec une marketplace de validateurs native à Nostr

Relatr, un moteur de scoring Web of Trust qui calcule des classements de confiance à partir de la distance dans le graphe social et de validateurs configurables, a livré la famille v0.2.x avec une refonte complète de son système de plugins. Les validateurs sont désormais écrits en Elo, un langage d’expressions fonctionnelles portable forké pour supporter des capacités multi-étapes orchestrées par l’hôte (requêtes Nostr, lookups de graphe social, résolution NIP-05). Les plugins sont publiés comme événements Nostr kind 765, rendant leur distribution native au réseau relay. Une nouvelle plugin marketplace permet aux opérateurs de découvrir, installer et pondérer des validateurs depuis le navigateur, avec un CLI (relo) pour l’écriture et la publication locales. L’architecture est sandboxée : les plugins ne peuvent invoquer que les capacités que l’hôte fournit explicitement, de sorte qu’un validateur malveillant ne peut pas sortir de son périmètre défini. Les instances Relatr peuvent maintenant être gérées depuis le site web, avec une visibilité complète sur les plugins qui composent l’algorithme de scoring et sur leurs pondérations individuelles.

Shopstr, la marketplace native à Nostr pour acheter et vendre avec Bitcoin, a poussé 158 commits cette semaine à travers son application principale et le projet compagnon Milk Market. Les correctifs incluent des améliorations de mise en page mobile pour les communautés, la fermeture des menus à la navigation et la fermeture automatique des menus déroulants. Les routes protégées ne peuvent plus être atteintes par URL directe sans connexion, et la logique de matching des slugs gère désormais correctement plusieurs correspondances exactes.

Pollerama ajoute des notifications, la recherche de films et une nouvelle interface de notation

Pollerama, une application de sondages, enquêtes et notation sociale construite sur Nostr, a ajouté des notifications de fil, une fonctionnalité de recherche de films et une refonte de l’interface de notation. La version corrige aussi des problèmes de chargement du flux et augmente les versions de dépendances.

Purser construit un daemon de paiement natif à Nostr avec chiffrement Marmot

Purser, un daemon de paiement natif à Nostr conçu comme remplaçant de Zaprite, a fusionné neuf PRs cette semaine pour construire son architecture centrale. Le projet utilise Marmot MLS via MDK pour la messagerie chiffrée entre commerçants et clients, avec Strike et Square comme fournisseurs de paiement. Cette semaine ont atterri le chargement de configuration et de catalogue, la validation du schéma des messages, la couche de communication MDK, les implémentations des fournisseurs Strike et Square, un moteur de polling, une limitation anti-spam, la persistance des paiements en attente et le pipeline de traitement des commandes. Les 99 tests exercent maintenant de vraies opérations MLS mdk-core après que l’équipe a retiré le mock MLS au profit d’un chiffrement réel en mode local.

Vector refactorise les pièces jointes DM et ajoute l’édition de profil

Vector, la messagerie Nostr centrée sur la confidentialité construite avec Tauri, a fusionné PR #55 refactorisant le frontend. Le déchiffrement et la sauvegarde des pièces jointes DM ont été déplacés vers la bibliothèque vector-core, et l’application supporte maintenant l’édition de profil. Le flag d’annulation d’upload est correctement câblé via TauriSendCallback, et les callbacks inutilisés d’aperçu de pièces jointes ont été nettoyés.

Travail sur le protocole et les spécifications

Mises à jour des NIP

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

Fusionnés :

NIP-58 (Badges) : les Profile Badges passent au kind 10008, les Badge Sets au kind 30008 (PR #2276) : migre les Profile Badges du kind 30008 vers le kind 10008 (un événement remplaçable, un par pubkey) et introduit le kind 30008 pour les Badge Sets. Auparavant, les Profile Badges utilisaient le même kind (30008) que les définitions de badges, ce qui en faisait des événements remplaçables paramétrés indexés par un tag d. Le nouveau kind 10008 est un événement remplaçable simple : un par pubkey, sans besoin de tag d. Les clients interrogent un seul événement remplaçable par utilisateur au lieu de scanner des événements remplaçables paramétrés. Amethyst v1.07.3 embarque déjà cette migration.
NIP-34 (Git Stuff) : ajout de follow lists liées à git (PR #2130) : ajoute des conventions de follow lists pour le suivi des dépôts et des issues NIP-34. Les utilisateurs publient des ensembles de follow kind 30000 avec des tags d comme git-repos ou git-issues contenant des références de tag a vers les dépôts (kind 30617) qu’ils veulent suivre. Les clients peuvent s’abonner à ces follow sets pour afficher l’activité des dépôts dans le flux d’un utilisateur, de manière similaire au fonctionnement des contact lists kind 3 pour les pubkeys.

PRs ouvertes et discussions :

NIP-AC : P2P Voice and Video Calls over WebRTC (PR #2301) : étend le NIP-100 original (implémenté par 0xChat) avec trois changements : migration vers le chiffrement NIP-44 enveloppé dans des gift wraps NIP-59 pour éliminer les fuites de métadonnées, workflow WebRTC spécifié pour l’établissement d’appels audio et vidéo (offer, answer, ICE candidates), et modèle d’appel de groupe en mesh où chaque pair établit une connexion WebRTC directe avec chaque autre pair. La spécification n’est pas rétrocompatible avec NIP-100. Amethyst construit déjà contre elle, avec une suite de tests de machine d’état d’appel (PR #2143) et la gestion des offres d’appel obsolètes (PR #2164) livrées cette semaine.
NIP-340 (FROST Quorum) (PR #2299) : propose des conventions pour la signature à seuil FROST (Flexible Round-Optimized Schnorr Threshold) sur Nostr. FROST permet à un groupe de signataires de contrôler collectivement une identité Nostr où n’importe quels membres t-of-n peuvent signer des événements sans reconstruire la clé privée complète. Le NIP définit comment coordonner les rounds de signature, distribuer les key shares et publier des événements signés à seuil, en s’appuyant sur le travail du signataire Igloo du projet FROSTR.
NIP-5D (Nostr Web Applets) (PR #2303) : définit un protocole postMessage pour des applications web sandboxées (« napplets ») tournant dans des iframes et communiquant avec une application hôte (« shell »). Le shell fournit à la napplet la signature Nostr, l’accès relay et le contexte utilisateur via une API de messages structurée, tandis que la sandbox iframe empêche l’accès direct aux clés. Cela étend le modèle d’hébergement de sites web statiques de NIP-5A vers des applications interactives capables de lire et d’écrire des événements Nostr. Le NIP est en développement actif avec une implémentation runtime fonctionnelle.
NIP-5C (Scrolls) (PR #2281) : renommé depuis l’ancienne proposition NIP-A5. Définit des conventions pour publier et découvrir des programmes WebAssembly sur Nostr. Les binaires WASM sont stockés comme événements Nostr, et les clients peuvent les télécharger puis les exécuter dans un runtime sandboxé. Une demo app montre des scrolls s’exécutant dans le navigateur, avec des programmes exemples publiés comme événements Nostr que n’importe quel client peut récupérer et exécuter.
NIP-85 (Trusted Assertions) : clarifications (PR #2304) : resserre le langage de la spécification autour de multiples clés et relays par fournisseur de services, en clarifiant comment les clients doivent gérer des assertions provenant de fournisseurs opérant à travers plusieurs pubkeys ou endpoints relay.
NIP-24 (Extra Metadata Fields) : published_at pour les événements remplaçables (PR #2300) : généralise le tag published_at depuis NIP-23 (Long-form Content) à tous les événements remplaçables et adressables. Le tag est seulement destiné à l’affichage : si published_at égale created_at, les clients affichent l’événement comme « créé » à ce moment-là ; s’ils diffèrent (parce que l’événement a été mis à jour), les clients peuvent l’afficher comme « mis à jour » à la place. Cela permet aux profils kind 0 d’afficher des dates « joined at » et à d’autres événements remplaçables de préserver leur timestamp de publication d’origine à travers les mises à jour. Une proposition complémentaire NIP-51 (PR #2302) ajoute le même tag aux événements de listes.
NIP-59 (Gift Wrap) : kind de gift wrap éphémère (PR #2245) : ajoute le kind 21059 comme contrepartie éphémère au gift wrap kind 1059 existant. Les événements éphémères (kinds 20000-29999) suivent la sémantique NIP-01 : les relays ne sont pas censés les stocker et peuvent les supprimer après livraison. Cela permet aux applications d’envoyer des messages gift-wrapped qui disparaissent des relays une fois livrés, réduisant les besoins de stockage pour la messagerie à fort volume tout en conservant le même modèle de chiffrement à trois couches que les DMs NIP-17 classiques.

OpenSats annonce sa seizième vague de subventions Nostr

OpenSats a annoncé sa seizième vague de subventions Nostr le 8 avril, finançant quatre premières subventions et un renouvellement. Amethyst Desktop reçoit un financement pour que le contributeur Robert Nagy construise une application desktop autonome au-dessus des modules Quartz et Commons, apportant l’ensemble des fonctionnalités du client Android à des interfaces pilotées à la souris avec connexions relay persistantes. Nostr Mail reçoit un financement pour construire un système email complet sur Nostr en utilisant des événements kind 1301 enveloppés dans des gift wraps NIP-59, avec un client Flutter et des serveurs de pont SMTP pour la compatibilité Gmail/Outlook. Nostrord reçoit un financement pour un client de groupe basé sur relay NIP-29 en Kotlin Multiplatform avec messagerie de groupe, modération et fils à la Discord. Nurunuru reçoit un financement pour construire une version iOS native du client Nostr japonais inspirée de l’interface familière de LINE, avec connexion biométrique basée sur passkey pour l’onboarding. HAMSTR a reçu un renouvellement de subvention (financé pour la première fois lors de la onzième vague).

Deep Dive NIP : NIP-17 (Private Direct Messages)

NIP-17 définit le standard actuel des messages directs privés sur Nostr. Il remplace l’ancien schéma NIP-04 (Encrypted Direct Messages), qui laissait fuiter des métadonnées (expéditeur, destinataire et timestamps étaient tous visibles sur les relays) et utilisait une construction de chiffrement plus faible. NIP-17 combine NIP-44 (Encrypted Payloads) pour le chiffrement avec NIP-59 (Gift Wrap) pour la protection des métadonnées, créant un système à trois couches où les relays ne peuvent pas voir qui parle avec qui.

Le protocole utilise trois kinds d’événements empilés les uns dans les autres. La couche la plus interne est le message réel, un événement kind 14 non signé :

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

L’événement kind 14 est volontairement non signé (sig vide). La spécification présente cela comme une forme de déni plausible, mais en pratique cette protection reste limitée. Le seal kind 13 qui enveloppe la rumor est signé avec la vraie clé de l’expéditeur. Un destinataire peut montrer ce seal signé à un tiers, prouvant que l’expéditeur a communiqué avec lui, même sans révéler le contenu du message. Avec des preuves à divulgation nulle de connaissance, un destinataire peut prouver le contenu exact du message sans révéler sa propre clé privée. La rumor non signée ressemble à une lettre non signée placée dans une enveloppe signée : la signature de l’enveloppe relie l’expéditeur au contenu. Un véritable déni exigerait une authentification symétrique (comme les HMACs de Signal), ce qui est incompatible avec le modèle relay décentralisé de Nostr où les messages doivent être auto-authentifiants. Les véritables forces de NIP-17 sont la confidentialité des métadonnées et le secret du contenu, pas le déni plausible.

Ce message non signé est ensuite enveloppé dans un seal kind 13, signé par l’expéditeur réel et chiffré avec NIP-44 pour le destinataire :

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

Le seal n’a pas de tags, donc même déchiffré il ne révélerait pas le destinataire. Le seal est signé avec la vraie clé de l’expéditeur, ce qui permet au destinataire d’authentifier le message en vérifiant que le pubkey du seal correspond au pubkey du kind 14 interne.

Le seal est ensuite enveloppé dans un gift wrap kind 1059, signé avec une clé aléatoire jetable et adressé au destinataire :

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

Le pubkey du gift wrap est une clé aléatoire générée uniquement pour ce message, et created_at est randomisé jusqu’à deux jours dans le passé. C’est la couche la plus externe que les relays voient réellement : un message provenant d’un pubkey inconnu adressé au destinataire, avec un timestamp qui ne reflète pas le moment réel d’envoi. Le timestamp randomisé protège contre les analyses a posteriori d’événements stockés, mais un adversaire activement connecté aux relays peut quand même observer quand le gift wrap apparaît pour la première fois, donc cette défense se limite aux observateurs passifs qui interrogent plus tard les données relay. Parce que le pubkey est aléatoire et que le timestamp est faux, les relays ne peuvent pas déterminer l’expéditeur réel. Pour lire le message, le destinataire déchiffre le gift wrap en utilisant sa propre clé et le pubkey aléatoire, trouve le seal à l’intérieur, déchiffre le seal en utilisant sa propre clé et le pubkey de l’expéditeur présent dans le seal, puis trouve le message kind 14 à l’intérieur.

NIP-17 ne fournit pas de forward secrecy. Tous les messages sont chiffrés à l’aide de la paire de clés Nostr statique (via la dérivation de clés de NIP-44 à partir des clés de l’expéditeur et du destinataire). Si une clé privée est compromise, chaque message passé et futur chiffré pour cette clé peut être déchiffré. C’est un compromis délibéré : comme le chiffrement dépend seulement du nsec, un utilisateur qui sauvegarde son nsec peut récupérer tout son historique de messages depuis n’importe quel relay qui stocke encore les gift wraps. Des protocoles comme MLS (utilisé par Marmot) fournissent la forward secrecy via une rotation du matériel de clé, mais au prix d’exiger une synchronisation d’état et de rendre impossible la récupération de l’historique après rotation des clés.

NIP-17 définit aussi le kind 15 pour les messages de fichiers chiffrés, qui ajoute les tags file-type, encryption-algorithm, decryption-key et decryption-nonce afin que le destinataire puisse déchiffrer un fichier joint chiffré avec AES-GCM avant téléversement vers un serveur Blossom. Le kind 10050 est utilisé pour publier la liste des relays DM préférés de l’utilisateur, afin que les expéditeurs sachent où livrer les gift wraps. L’ensemble des tags pubkey + p dans un message définit un salon de chat ; ajouter ou retirer un participant crée un nouveau salon avec un historique propre.

Les implémentations couvrent la plupart des grands clients. nospeak utilise NIP-17 pour toute la messagerie one-on-one. Flotilla utilise NIP-17 pour ses DMs proof-of-work. Amethyst, Primal, Nostur, Damus, noStrudel, et Coracle implémentent tous NIP-17 comme protocole DM principal. La spécification supporte aussi les messages éphémères en définissant un tag expiration dans le gift wrap.

Deep Dive NIP : NIP-46 (Nostr Remote Signing)

NIP-46 définit un protocole permettant de séparer la clé privée de l’utilisateur de l’application cliente. Au lieu de coller un nsec dans une web app, l’utilisateur exécute un signataire distant (aussi appelé « bunker ») qui détient la clé privée et répond aux requêtes de signature via les relays Nostr. Le client ne voit jamais la clé privée. Cela réduit la surface d’attaque : un client compromis peut demander des signatures, mais ne peut pas extraire la clé elle-même.

Le protocole utilise le kind 24133 à la fois pour les requêtes et les réponses, chiffrées avec NIP-44 (Encrypted Payloads). Un client génère une client-keypair jetable pour la session et communique avec le signataire distant via des messages chiffrés NIP-44 tagués avec les pubkeys respectifs. Voici une requête de signature d’un client vers un signataire distant :

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

Le content chiffré contient une structure de type JSON-RPC :

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

Le signataire distant déchiffre la requête, la présente à l’utilisateur pour approbation (ou l’auto-approuve selon les permissions configurées), signe l’événement avec la clé privée de l’utilisateur, puis renvoie l’événement signé dans une réponse :

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Les connexions peuvent être initiées depuis n’importe quel côté. Un signataire distant fournit une URL bunker:// contenant son pubkey et les informations relay. Un client fournit une URL nostrconnect:// avec son pubkey client, ses relays et un secret de vérification de connexion. Le paramètre secret empêche l’usurpation de connexion : seule la partie qui a reçu l’URL hors bande peut terminer le handshake.

Huit méthodes sont définies : connect pour établir la session, sign_event pour signer des événements, get_public_key pour apprendre le pubkey de l’utilisateur, ping pour le keepalive, nip04_encrypt/nip04_decrypt pour l’ancien chiffrement, nip44_encrypt/nip44_decrypt pour le chiffrement actuel, et switch_relays pour la gestion des relays. La migration relay est gérée par le signataire distant, qui peut déplacer la connexion vers de nouveaux relays au fil du temps sans casser la session.

Les clients demandent des capacités spécifiques au moment de la connexion via un système de permissions. Une chaîne de permissions comme nip44_encrypt,sign_event:1,sign_event:14 demande l’accès au chiffrement NIP-44 et l’accès à la signature pour les événements kind 1 et kind 14 seulement. Le signataire distant peut accepter, rejeter ou modifier ces permissions. Cela signifie qu’un client web pour lire et publier des notes peut n’obtenir que la permission sign_event:1, tandis qu’un client DM peut aussi obtenir sign_event:14 et nip44_encrypt.

Amber implémente NIP-46 sur Android, et sa v6.0.0-pre1 de cette semaine ajoute des clés de signature par connexion pour isoler les clients. nsec.app (anciennement Nostr Connect) fournit un bunker web. nostr-tools inclut BunkerSigner pour les clients JavaScript, et la PR #530 de la semaine dernière a ajouté skipSwitchRelays pour une gestion manuelle des relays. Le protocole supporte aussi les défis d’auth : lorsqu’un signataire distant a besoin d’une authentification supplémentaire (mot de passe, biométrie ou token matériel), il répond avec une auth_url que le client ouvre dans un navigateur pour que l’utilisateur termine l’opération.

C’est tout pour cette semaine. Vous construisez quelque chose ou avez des nouvelles à partager ? Envoyez-nous un DM sur Nostr ou retrouvez-nous sur nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

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.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Primal Android enchaîne après sa version 3.0 orientée portefeuille avec Follow Packs, enrichissement zap et liens profonds primalconnect://. BigBrotr publie une analyse de fuite de nsec portant sur 41 millions d’événements à travers 1 085 relays et trouve 16 599 clés privées valides, tandis que npub.world intègre des avertissements de fuite sur les pages de profil la même semaine. Martti Malmi lance nostr-vpn, une alternative à Tailscale qui signale via les relays Nostr et établit des tunnels WireGuard, avec 11 versions en sept jours. L’équipe Vector open source un DOOM P2P sur Nostr, FIPS livre v0.2.0, et Nostrability Schemata s’étend à six langages en une semaine.

Actualités

Primal adds Follow Packs, zap enrichment, and deep links

Suite à la couverture de la 3.0.7 la semaine dernière, Primal Android a consacré cette semaine au travail post-version autour de l’onboarding, de l’UX de composition et du contexte portefeuille. L’onboarding repensé introduit les Follow Packs (PR #949), un bouton GIF natif rejoint l’éditeur de notes, un service d’enrichissement zap (PR #979) annote les transactions du portefeuille avec leur contexte zap, et un protocole de lien profond primalconnect:// (PR #969) permet la navigation entre applications.

Primal iOS livre le même travail via TestFlight en parallèle, avec le changement de portefeuille (PR #191), l’implémentation des sondages et la refonte de l’onboarding dans la même fenêtre.

BigBrotr maps exposed private keys across the relay network

BigBrotr, la plateforme d’analytique de relays Nostr, a publié une analyse détaillée des clés privées exposées sur le réseau de relays. L’étude a parcouru 41 millions d’événements sur 1 085 relays, à la recherche de chaînes nsec valides intégrées dans le contenu des événements, et a trouvé 16 599 clés privées valides. Le chiffre paraît alarmant jusqu’à ce qu’on filtre un bot nommé « Mr.nsec », qui représente 92 % des correspondances. Après retrait du trafic du bot, seuls 38 comptes réels totalisant plus de 21 000 abonnés avaient des clés exposées, et aucun ne montrait de signe de conscience que ses clés étaient publiques.

L’équipe a construit un nsec-leak-checker comme service NIP-90 (Data Vending Machine), permettant aux utilisateurs de vérifier si leur clé privée apparaît quelque part dans l’ensemble de données scanné sans révéler la clé au vérificateur. npub.world a intégré les données de fuite la même semaine, affichant des bannières d’avertissement sur les pages de profil où des clés exposées ont été détectées. La combinaison donne au réseau à la fois une interface programmatique pour les DVMs et les agents, et un avertissement lisible par l’humain pour les utilisateurs ordinaires. L’ensemble de données sous-jacent alimente aussi BigBrotr v6.4.0, qui ajoute des vues matérialisées d’événements remplaçables et adressables ainsi qu’un correctif de délai d’inactivité du synchroniseur.

Nostr VPN launches as a Tailscale alternative

Martti Malmi (mmalmi), créateur d’Iris, a construit et livré nostr-vpn, un VPN pair à pair qui utilise les relays Nostr pour le signalement et WireGuard (via boringtun) pour les tunnels chiffrés. La motivation était directe : « Got annoyed by Tailscale requiring 3rd party accounts, so created Nostr VPN. » L’outil crée des réseaux maillés entre appareils en utilisant des paires de clés Nostr comme identité, sans serveur central de coordination.

Le projet a livré 11 versions en sept jours, de v0.2.2 à v0.2.13. Ce sprint a ajouté le support Windows, l’appairage LAN pour la découverte sur réseau local, et un sidecar Android pour les appareils mobiles. L’architecture est simple : deux appareils échangent les métadonnées de connexion via les relays Nostr, puis établissent un tunnel WireGuard direct. Nostr gère la découverte et le signalement de traversée NAT. WireGuard transporte le trafic réel. L’identité est une paire de clés Nostr.

Malmi a aussi continué à pousser nostr-double-ratchet, une bibliothèque de canal de messagerie sécurisée de type Signal, avec six versions de v0.0.86 à v0.0.93 pendant la même semaine.

Open-source DOOM runs peer-to-peer over Nostr

L’équipe Vector a open sourcé une implémentation multijoueur pair à pair de DOOM qui utilise Nostr pour la découverte de pairs, Marmot pour le chiffrement de bout en bout, et Iroh, la bibliothèque réseau QUIC de n0, pour le transport gossip. Le jeu est livré sous forme d’un fichier WebXDC de 4,2 Mo qui peut être envoyé dans des messages de chat, sans nécessiter de serveurs pour héberger ou coordonner une partie.

L’approche technique remplace le netcode lockstep original de 1993 par un modèle hybride de synchronisation en temps réel. Les joueurs se découvrent via des requêtes relay Nostr, négocient les sessions via des canaux chiffrés Marmot, puis basculent sur la couche gossip QUIC d’Iroh pour le trafic de jeu à faible latence. La pile utilise Nostr pour la découverte, Marmot pour le chiffrement et Iroh pour le transport.

Vector a aussi livré du durcissement de sécurité cette semaine. La version ajoute un coffre de clés renforcé en mémoire avec protections anti-debug et zeroize pour le matériel sensible, le blocage d’utilisateurs avec filtrage complet des DMs et messages de groupe, et des correctifs de canaux temps réel WebXDC pour les Mini Apps.

FIPS v0.2.0 ships Tor transport, reproducible builds, and sidecar examples

FIPS, le Free Internetworking Peering System et projet de réseau maillé adjacent à Nostr, a livré v0.2.0. La version ajoute le support du transport Tor pour des liens maillés anonymisés, des builds reproductibles, un exemple sidecar qui se connecte via un relay Nostr, et la publication de versions Nostr dans le workflow de paquets OpenWrt. La version corrige aussi les pics de gigue post-rekey causés par les frames de drain-window. Le format filaire a changé depuis v0.1.0, donc les nœuds v0.1.0 existants ne peuvent pas interopérer avec v0.2.0 sans mise à niveau.

Nostrability Schemata goes multilingual

Le projet Nostrability Schemata, qui maintient des définitions JSON Schema pour valider les kinds d’événements Nostr, est passé de JavaScript seul à six langages en une semaine. De nouveaux paquets ont été livrés pour Rust, Go, Dart, Swift et Python, chacun fournissant à la fois un paquet de données et un validateur. v0.2.6 a aussi ajouté 17 nouveaux schémas de kinds d’événements.

Le tracker d’interopérabilité Nostrability a reçu une refonte parallèle. Un nouvel onglet What’s New publie les mises à jour via un flux Atom et un événement Nostr, le filtrage par catégorie d’application permet aux visiteurs de cibler des types de clients précis, et le tracker détecte maintenant automatiquement les langages de programmation à partir des métadonnées des dépôts GitHub. Nostrability possède aussi désormais son propre npub, ce qui rend le projet lui-même découvrable via le protocole qu’il documente. Pour les auteurs de bibliothèques travaillant sur plusieurs langages, les paquets de schémas multi-langages signifient que les mêmes définitions de kinds d’événements sont disponibles comme imports natifs, au lieu d’obliger chaque projet à maintenir sa propre copie de schémas.

Versions

Amethyst v1.06.0 and v1.06.1

Amethyst, le client Android maintenu par vitorpamplona, a livré v1.06.0 et v1.06.1 le 23 mars. La fonctionnalité phare est le support des sondages en utilisant les données NIP-85 (Trusted Assertions) pour le vote pondéré, avec des cartes de sondages et de zap polls repensées. Le nouveau rendu donne aux sondages standard et pondérés par zap une disposition visuelle plus propre. v1.06.1 suit avec des correctifs de crash liés aux modifications concurrentes qui résolvent des régressions de stabilité introduites dans le chemin de rendu des sondages.

Amber v5.0.0 and v5.0.1

Amber, l’application signataire NIP-55 (Android Signer Application), a promu son travail de pré-version récent en 4.1.x vers la stable avec v5.0.0 le 18 mars. Cette version stable embarque les changements d’auth relay NIP-42, de Tor intégré, de permissions par type de contenu et de stockage chiffré du PIN couverts la semaine dernière. v5.0.1 retire ensuite la permission internet de la variante hors ligne, de sorte que cette build ne peut plus effectuer de requêtes réseau au niveau des permissions Android.

Mostro v0.17.0 and Mostro Mobile v1.2.2

Mostro, l’échange Bitcoin pair à pair construit sur Nostr, a livré v0.17.0 le 18 mars. La version serveur poursuit le travail sur les litiges et les évaluations du cycle v0.16.x, en ajoutant des données de réputation commerciale plus complètes pour les acheteurs et vendeurs sous forme d’événements Nostr. Mostro Mobile, le client Flutter, a suivi avec v1.2.2 le 23 mars, maintenant l’interface mobile synchronisée avec les derniers changements du protocole.

Shosho v0.14.0

Shosho, l’application de streaming live Nostr, a livré v0.14.0 le 19 mars avec le lancement de Shosho Shop. La version ajoute un onglet Shop sur les profils, Shop dans Browse, et un bouton In-Live Shop sur les lives et clips. Les notes de version indiquent que les « Nostr products » existants apparaissent automatiquement et que les acheteurs cliquent vers la page Plebeian Market du vendeur pour l’achat. Les notes de version de Shosho n’identifient pas le kind d’événement de listing, il n’est donc pas encore possible de confirmer si Shosho Shop lit les mêmes annonces NIP-99 que Shopstr prend explicitement en charge dans son README.

Applesauce v5.2.0

Applesauce, la collection de paquets utilitaires de hzrd149 pour construire des applications Nostr, a livré v5.2.0 le 22 mars. La version s’étend sur six paquets. Le paquet SQLite corrige une collision de contrainte UNIQUE sur les tags d’événements qui provoquait des insertions dupliquées. Le paquet signers ajoute AndroidNativeSigner, qui encapsule l’interface native de signataire Android NIP-55 pour que les applications basées sur webview puissent utiliser une signature adossée au matériel sans code de pont personnalisé. Le paquet relay ajoute un champ challenge aux objets d’état du relay et du pool, suivant l’état d’auth NIP-42 pour que les applications puissent détecter quand un relay demande une authentification et répondre programmatiquement. Le paquet core gagne isEventPointerSame et isAddressPointerSame pour dédupliquer les références d’événements, et le paquet common ajoute user.blossomServers$ pour résoudre les serveurs médias Blossom d’un utilisateur. Applesauce alimente noStrudel, Satellite et plusieurs autres clients web, donc ces correctifs se propagent à travers toute la couche des clients web.

Wisp ships 16 releases in one week

Wisp, le client Nostr Android, a livré 16 versions de v0.9.3-beta à v0.13.1-beta cette semaine. Les ajouts de fonctionnalités incluent le support multi-comptes, un mode zen notifications pour réduire les interruptions, les brouillons et publications planifiées, des filtres de sécurité de contenu et une nouvelle icône flamme.

Manent v1.2.0

Manent, l’application privée de notes chiffrées et de stockage de fichiers, a livré v1.2.0 le 20 mars. La version ajoute la capture caméra directement depuis l’application, le redimensionnement d’image avant téléversement pour réduire les coûts de stockage, et le pinch-to-zoom pour examiner les images stockées. Manent stocke notes et fichiers chiffrés sur les relays Nostr à l’aide de la paire de clés de l’utilisateur, ce qui fait du téléphone ou de l’application desktop un client léger capable de reconstruire tout son état à partir des données des relays.

diVine 1.0.7

diVine, le client vidéo court format, a livré 1.0.7 le 21 mars avec un watchdog de lecture vidéo qui relance automatiquement les vidéos bloquées. Après l’infrastructure de tests E2E et le chargement direct MP4 dans v1.0.6, cette version cible le chemin d’échec restant de lecture : les vidéos qui s’arrêtent en milieu de flux sans lancer d’erreur.

Alby Extension v3.14.2

Alby Extension, l’extension de navigateur NIP-07 (Browser Extension Signer), a livré v3.14.2 le 18 mars avec l’affichage de QR codes d’adresses Lightning et le support de signature Schnorr. Cet ajout Schnorr aligne l’extension de navigateur avec le schéma de signature secp256k1 que Nostr utilise nativement.

NoorNote v0.6.5 through v0.6.11

NoorNote, l’application de prise de notes, a livré sept versions de v0.6.5 à v0.6.11. L’ajout principal est Follow Packs : des ensembles curatés de comptes que les utilisateurs peuvent parcourir et suivre en masse, similaires aux Twitter Lists mais conçus pour l’onboarding. Les utilisateurs peuvent créer, modifier et partager des Follow Packs avec des titres, descriptions et images de couverture personnalisés. La série met aussi à niveau la bibliothèque Nostr sous-jacente de NDK v2 à v3, ce qui apporte une meilleure gestion des connexions relay et des abonnements. Les picture notes et une expérience de connexion relay repensée complètent le cycle.

nak v0.19.1 and v0.19.2

nak, la boîte à outils Nostr en ligne de commande de fiatjaf pour interagir avec les relays, encoder et décoder les identifiants NIP-19 (Bech32-Encoded Entities), signer des événements et interroger les données relay, a livré v0.19.1 et v0.19.2 les 17 et 20 mars. Ces deux point releases suivent l’ajout de l’interface forum de groupe de v0.19.0.

Calendar by Form* v0.2.1

Calendar by Form*, l’application de calendrier décentralisée construite sur NIP-52 (Calendar Events), a livré v0.2.1 le 20 mars. La version corrige un problème de modèle de notification qui affectait les rappels d’événements. Calendar stocke les événements sous forme d’événements Nostr kind 31922 (basés sur la date) et kind 31923 (basés sur l’heure), permettant à n’importe quel client Nostr d’afficher les données de calendrier s’il choisit de supporter ces kinds. L’application est construite par l’équipe Formstr, qui maintient aussi Formstr (formulaires décentralisés) et Pollerama (sondages).

NYM v3.50 through v3.53

NYM, le client de chat éphémère ponté avec Bitchat, a livré 28 versions de v3.50 à v3.53. La fonctionnalité la plus notable est Nymbot, un chatbot intégré qui répond aux mentions @nymbot dans les canaux et fournit des fonctions de statut et de gestion des relays. Un « hardcore mode » génère une nouvelle paire de clés pour chaque message envoyé, rendant les fils de conversation non corrélables au niveau de l’identité. Le compromis est clair : on perd une identité persistante mais on gagne en anonymat par message. La couche proxy relay a aussi reçu du travail, avec des workers proxy relay shardés pour une meilleure connectivité, le support de canaux geohash et la tolérance au décalage d’horloge pour les nœuds aux horloges système imprécises.

Mises à jour des projets

Ditto adds Bluesky bridge and Wikipedia integration

Ditto, le client social Nostr personnalisable de l’équipe Soapbox, a enregistré plus de 300 commits cette semaine à travers trois pistes fonctionnelles distinctes. La première est un pont Bluesky (19 commits) qui rend les publications Bluesky inline sous forme de fils complets de style flux, ajoute une navigation latérale vers une page de découverte Bluesky alimentée par le flux officiel Discover (whats-hot), et relie des boutons d’action pour commenter, partager, réagir et copier les liens. Lorsqu’un utilisateur répond à un post Bluesky depuis Ditto, la fenêtre de composition affiche un avertissement rappelant la nature inter-protocole de l’interaction. Les réactions de kind 17 NIP-73 (External Content IDs) alimentent ce modèle : un utilisateur Nostr réagit à un post Bluesky, et la réaction est stockée comme un événement Nostr standard référant l’identifiant de contenu externe. C’est le même motif NIP-73 qui pourrait faire le pont vers n’importe quel contenu externe, des posts Bluesky aux vidéos YouTube en passant par les pages web.

La seconde piste est une intégration Wikipedia (9 commits). Ditto rend maintenant du contenu riche d’articles Wikipedia sur les pages de détail au lieu de simples aperçus de liens, ajoute l’autocomplétion de recherche avec miniatures d’articles, et fournit une page /wikipedia qui récupère le contenu mis en avant depuis l’API Wikipedia. Les résultats Wikipedia et Archive.org apparaissent aussi dans la liste générale d’autocomplétion de recherche. La troisième piste concerne le support iOS via Capacitor, avec un script de build distant et la configuration de plateforme livrés en parallèle d’une refonte UI (55 commits) qui remplace les en-têtes flous par un nouveau design de navigation en arc à travers toute l’application. Ces 314 commits déplacent Ditto d’un client Nostr-only vers un agrégateur multi-protocole qui traite Bluesky et Wikipedia comme des sources de contenu de première classe aux côtés du flux Nostr.

Pika builds a NIP-34 forge CI pipeline

Pika, l’application de messagerie chiffrée basée sur Marmot, a fusionné 33 PRs cette semaine autour d’une forge NIP-34 auto-hébergée avec CI avant fusion. La forge est une couche d’hébergement git qui reçoit les patches comme événements NIP-34, exécute les vérifications CI avant fusion, puis renvoie un statut structuré via des événements Nostr. PR #701 ajoute une CI pré-fusion et nocturne par lanes, où chaque chemin de code (Rust, TypeScript, builds Apple) s’exécute dans sa propre lane avec un statut indépendant de réussite ou d’échec. PR #715 déplace les agents CI gérés vers des conteneurs Incus OpenClaw pour l’isolation, et PR #733 ajoute un CLI ph forge pour interagir avec la forge hébergée depuis la ligne de commande. Des PRs de support gèrent les permissions d’écriture du dépôt pour les fusions (PR #736), les métadonnées CI structurées avec badges de statut en direct (PR #722), la séparation des builds nocturnes Apple (PR #738), et des correctifs d’authentification de forge et de lookup de branches (PR #734). C’est l’un des premiers systèmes CI/CD opérationnels construits au-dessus des événements git NIP-34, amenant l’hébergement de code source basé sur Nostr au-delà du simple échange de patches vers le workflow merge-and-test que les développeurs attendent de GitHub ou GitLab.

Nostria adds communities, code snippets, and voice event handling

Nostria, le client Nostr cross-platform maintenu par sondreb, a passé cette semaine à étendre la surface de l’application au-delà du filtrage Web of Trust couvert dans le numéro 14. L’ajout principal est une implémentation complète de NIP-72 (Moderated Communities) avec création de communautés, configuration des modérateurs et relays, suivi de l’approbation des publications avec aperçus d’images, et une page dédiée aux communautés avec onglets Posts et Moderators.

La même période de travail ajoute aussi le rendu et l’édition de snippets de code avec éditeur à coloration syntaxique, le support des réponses à événements vocaux pour les conversations audio, les paramètres de relays de chat pour les messages directs, le partage de canaux via l’API Web Share, un système d’ancrage de la barre d’outils pour le lecteur multimédia, l’inscription intégrée au dernier service Brainstorm Web of Trust, les flux d’envoi et de réception d’argent dans les DMs utilisant NWC et des invoices BOLT-11, la gestion native des GIFs Nostr, et un chemin d’import RSS renforcé pour les musiciens capable de récupérer les répartitions Lightning existantes depuis les flux de podcasts.

nostr-vpn rapid iteration

Au-delà du lancement initial, l’historique de commits de nostr-vpn révèle les problèmes précis rencontrés lors du déploiement réel. v0.2.3 à v0.2.5 ont ajouté le script d’installation initial et le CLI cross-platform. v0.2.6 et v0.2.7 ont apporté le support Windows, ce qui a nécessité le quoting des chemins UAC pour les écritures de configuration et les mises à jour de configuration possédées par le daemon. v0.2.8 à v0.2.10 ont corrigé les actions du service GUI Windows, la gestion des sous-processus CLI et la configuration des services à l’échelle de la machine. v0.2.12 a remplacé la découverte LAN par un appairage LAN temporisé, un flux initié par l’utilisateur où deux appareils sur le même réseau local s’appairent sans signalement relay. Le motif est celui d’un test terrain de phase précoce : chaque version cible un échec précis de déploiement, la base d’utilisateurs est assez petite pour itérer quotidiennement, et le développeur utilise l’outil lui-même entre les versions.

Comet automated builds

Comet (anciennement Captain’s Log), l’outil long format natif Nostr de Nodetec, a produit plus de 40 builds alpha automatisés cette semaine. Comet est une application desktop pour écrire et publier des articles NIP-23 (Long-form Content), avec stockage local des brouillons, édition markdown et publication en un clic vers l’ensemble de relays de l’utilisateur. Le pipeline de build automatisé génère une version taguée pour chaque commit sur la branche main, ce qui rend le nombre brut de versions trompeur comme mesure de vitesse fonctionnelle. Ce que montrent ces 40 builds, c’est que l’application est en développement actif quotidien, chaque commit étant testé, empaqueté et rendu téléchargeable en quelques minutes.

Mises à jour des NIP

Changements récents dans le dépôt NIPs durant la fenêtre du 17 au 24 mars :

Aucune fusion NIP n’a eu lieu entre le 18 et le 24 mars.

PRs ouvertes et discussions mises à jour pendant la fenêtre :

NIP-AA: Autonomous Agents on Nostr (PR #2259) : Propose des conventions pour les agents autonomes opérant sur le réseau Nostr. La PR définit comment les agents s’identifient, découvrent des services et se coordonnent avec d’autres agents et humains via des événements Nostr.
NIP-50 (Search) : extensions de tri (PR #2283) : Ajoute des paramètres de tri aux requêtes de recherche NIP-50, notamment top, hot, zaps et new. Cela permettrait aux clients de demander des résultats classés aux relays qui supportent la recherche plein texte au lieu de trier côté client.
NIP-A5: WASM Programs (PR #2281) : Propose une convention pour publier et découvrir des programmes WebAssembly sur Nostr. Les binaires WASM pourraient être distribués comme événements Nostr, avec les relays comme couche de découverte pour du code exécutable portable.
NIP-CF: Combine Forces interoperable napps (PR #2277) : Définit une convention pour des applications Nostr interopérables (« napps ») capables de composer leurs fonctionnalités entre différents clients et services.
Snapshots NIP (PR #2279) : Propose un mécanisme de snapshots d’état relay, pour la synchronisation et la sauvegarde des relays.
Checkpoints NIP (PR #2278) : Propose des événements de checkpoints pour marquer un état relay connu comme bon, en complément de la proposition snapshots.
NIP-58 (Badges) : refonte des Badge Sets (PR #2276) : Restructure la manière dont les collections de badges sont organisées et référencées.
NIP-11 (Relay Information Document) : extensions (PR #2280) : Ajoute des champs supplémentaires au document d’information relay pour des métadonnées relay plus riches et lisibles par machine.

Cinq ans de mars Nostr

La newsletter du mois dernier retraçait la progression des mois de février de Nostr, de la réécriture de NIP-01 (Basic Protocol Flow) à la vague Damus sur l’App Store, puis au réseau maillé et aux propositions d’agents. Cette rétrospective suit ce qui s’est passé chaque mois de mars de 2021 à 2026.

March 2021: Two Commits

Quatre mois après sa création, le mois de mars de Nostr a produit exactement deux commits dans le dépôt du protocole, tous deux le 4 mars. fiatjaf a ajouté des liens vers des instances nostwitter, orientant les premiers visiteurs vers des déploiements fonctionnels, et a ajouté kind à la définition de filtre de base. Ce second commit est révélateur : en mars 2021, on ne pouvait pas encore filtrer les événements Nostr par kind. Le protocole en était à ce niveau de primitivité. Deux ou trois relays servaient le réseau. Le groupe Telegram constituait l’unique canal de coordination. Le dépôt NIPs n’existait pas encore, les propositions protocole vivaient comme fichiers dans le dépôt principal nostr. fiatjaf était l’unique committer ce mois-là. Toute la production de mars 2021 de ce qui deviendrait un protocole supportant VPNs, jeux multijoueurs et réseau maillé cinq ans plus tard tient dans un seul diff git.

March 2022: Pre-Damus Building

Le dépôt principal du protocole n’a reçu aucun commit en mars 2022. Le développement s’était entièrement déplacé vers les dépôts outils. Branle, le client web Vue.js de fiatjaf et à l’époque l’interface Nostr principale, a reçu 5 commits incluant le support de déploiement Docker et des correctifs d’affichage de noms NIP-05 (DNS-Based Verification) supprimant le préfixe _@ des badges de vérification. more-speech de Robert C. Martin, le client desktop Clojure, a enregistré 13 commits ou plus ajoutant threading, navigation clavier et fenêtre d’édition. L’auteur logiciel le plus célèbre construisant activement sur Nostr ce mois-là n’était pas un développeur crypto, mais la personne dont « Clean Code » s’est vendu à des millions d’exemplaires, écrivant un client Nostr en Clojure, un choix de langage qui dit tout sur la communauté des débuts : des programmeurs au caractère bien trempé construisant pour eux-mêmes.

Le réseau relay s’était étendu à environ 15 relays avec une base d’utilisateurs active comptée en centaines. Damus n’existait pas encore et ne serait créé qu’en avril 2022. Nostream n’était pas non plus apparu. Le travail du mois relevait de l’infrastructure : rendre les outils existants plus fiables pour la petite communauté qui les utilisait déjà au quotidien.

March 2023: Post-Explosion Infrastructure

Un mois après la vague Damus App Store et l’explosion au-delà de 300 000 clés publiques, mars 2023 a consisté à absorber la croissance. Le dépôt NIPs a fusionné 28 pull requests, le deuxième total mensuel le plus élevé de l’histoire du protocole. NIP-51 (Lists) a été fusionné, donnant aux clients des collections structurées de follow, mute et bookmarks. NIP-39 (External Identities in Profiles) a été intégré, NIP-78 (Application-Specific Data) a fourni un kind de stockage généraliste pour les applications ayant besoin d’état privé, et une réécriture de NIP-57 (Lightning Zaps) (PR #392) a consolidé le flux zap et clarifié la terminologie. La PR la plus discutée du mois était une proposition alternative de gestion des mentions (PR #381) avec plus de 50 commentaires.

Le nouveau projet le plus déterminant fut NDK (Nostr Development Kit), la bibliothèque TypeScript pour les connexions relay, la signature d’événements, le cache et la gestion des abonnements. pablof7z a fait le commit initial le 16 mars 2023, puis l’a réécrit de zéro 11 jours plus tard le 27 mars (« basically another initial commit »), et le support LNURL et zap fonctionnait au 31 mars. NDK est passé de rien à zap-capable en 15 jours. Cinq jours après la création de NDK, le 21 mars, l’équipe Alby a créé NWC (Nostr Wallet Connect), l’implémentation de référence de NIP-47 qui connecte les portefeuilles Lightning aux applications Nostr. Les deux projets qui soutiendraient les trois années suivantes de développement web Nostr sont nés dans la même fenêtre de 30 jours. OpenSats n’avait pas encore lancé son fonds Nostr ; la première vague n’arriverait qu’en juillet 2023, quatre mois après la création de NDK.

D’autres créations notables ce mois-là incluaient NostrGit, NostrChat, un projet nostr-signing-device par LNbits, et nostrmo. Gossip, le client desktop Rust centré sur la sélection intelligente de relays, a livré trois versions. Le protocole était en mode construction, et les outils créés en mars 2023 sont encore utilisés trois ans plus tard.

March 2024: Protocol Maturation

Mars 2024 a consisté à durcir le protocole pour un usage de long terme. Le dépôt NIPs a fusionné 12 pull requests. La plus significative fut NIP-34 (Git Stuff), PR #997, fusionnée le 5 mars après plus de 130 commentaires et 44 jours de revue. Le fil de discussion est une capsule temporelle montrant la communauté débattant de la manière de construire un GitHub décentralisé. jb55 a tracé des parallèles avec git send-email, Giszmo a proposé d’utiliser les hashes de commit racine pour la découverte inter-forks (« something GitHub doesn’t do and we could »), mikedilger a suggéré l’authentification signée par événements NIP-98 (HTTP Auth) au lieu des clés SSH, et fiatjaf a balayé sans détour le besoin de généralité du contrôle de version : « not for each version control system, just for git. No one uses the others. » Quelques heures après l’ouverture de la PR, fiatjaf avait déjà modifié nak, go-nostr et gitstr pour accepter des patches via Nostr. DanConwayDev, dont ngit était déjà bénéficiaire d’une subvention OpenSats, faisait partie des contributeurs les plus actifs de la discussion. Un champ bot pour les métadonnées de profil a aussi été fusionné, donnant aux clients un moyen lisible par machine de distinguer les comptes automatisés des comptes humains.

Amethyst a livré v0.85.0 avec support des événements git, articles wiki, rendu de données médicales et édition de contenu dans une seule version. Mostro a atteint v0.10.0. Nosflare, un relay Nostr serverless tournant sur Cloudflare Workers, a prouvé que la logique relay pouvait tourner à l’edge. OpenSats a accordé une subvention Long-Term Support à Bruno Garcia pour des contributions continues au client Amethyst.

March 2025: Infrastructure Expansion

Mars 2025 a produit 10 NIPs fusionnés. Le sujet central était NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, fusionnée le 3 mars après un parcours de 25 mois. dskvr avait d’abord proposé la surveillance relay en février 2023, s’était entendu dire que cela pouvait se faire côté client, avait expliqué pourquoi se connecter à des milliers de relays à la fois était impraticable pour les clients individuels, avait traversé sept brouillons complets, construit des nœuds de monitoring sur huit régions géographiques (Nord-Est US, Brésil, US-Ouest, US-Est, Australie, Inde, Corée, Afrique du Sud), et attendu que l’outillage relay rattrape son retard. Au moment de la fusion, des implémentations existaient déjà dans nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel et Jumble. Les données NIP-66 alimenteraient plus tard les benchmarks outbox de Nostrability couverts dans la Newsletter #12. NIP-C0 (Code Snippets) a aussi été fusionné (PR #1852, 63 commentaires), ajoutant les événements kind 1337 pour partager du code source.

Les premiers serveurs MCP pour Nostr sont apparus ce mois-là. nostr-mcp-server est apparu le 23 mars et nwc-mcp-server le 14 mars, seulement quatre mois après l’annonce du Model Context Protocol par Anthropic en novembre 2024. Ces premiers ponts ont précédé le SDK ContextVM complet et le travail ultérieur sur le commerce d’agents à la fin 2025 et au début 2026.

Gossip a livré v0.14.0. Coracle, le client web de hodlbod avec gestion de flux consciente des relays, a livré trois versions. OpenSats a annoncé sa dixième vague de subventions Nostr, poursuivant la chaîne de financement en place depuis mi-2023.

March 2026: Convergence

L’activité de mars 2026 est tirée des numéros Nostr Compass #12 à #15 (ce numéro).

Mars 2026 est le mois où des fils jusqu’ici séparés convergent vers des systèmes opérationnels. Le Marmot Development Kit a livré sa première version publique avec médias chiffrés, liaisons multi-langages et une migration ChaCha20-Poly1305 qui a exigé des mises à jour coordonnées à travers la spécification, Rust et TypeScript. Shopstr et Milk Market ont ajouté des surfaces de commerce MCP pour des achats pilotés par agents. L’auth relay NIP-42 a atterri simultanément dans Amber, strfry et OAuth Bunker, bouclant la boucle entre signataire, relay et logiciel bunker. Notedeck a livré des mises à jour logicielles natives Nostr via des événements de version NIP-94 (File Metadata).

Cette semaine, BigBrotr a scanné tout le réseau relay à la recherche de clés privées fuitées et a publié à la fois l’analyse et un vérificateur DVM. Nostr VPN a prouvé que le modèle de clé de Nostr fonctionne pour l’infrastructure réseau, pas seulement pour les médias sociaux. DOOM a montré que la découverte Nostr, le chiffrement Marmot et le transport QUIC peuvent faire tourner un jeu multijoueur en temps réel. Amber a bondi en v5.0.0. Wisp a livré 16 versions en sept jours. Vingt-cinq versions taguées ou plus sont venues de projets majeurs en une seule semaine.

Sept NIPs ont fusionné dans les 24 premiers jours du mois. Le protocole a ajouté le balisage Djot de NIP-54 (Wiki), des limites d’entrée pour NIP-19 (Bech32-Encoded Entities), la logique de requêtes booléennes NIP-91 (AND Operator for Filters) et les assertions Web of Trust NIP-85 (Trusted Assertions). Les propositions ouvertes allaient des agents autonomes (NIP-AA) aux programmes WASM (NIP-A5) en passant par les extensions de tri de recherche pour NIP-50.

Looking Ahead

Cinq mois de mars Nostr dessinent un arc clair. En 2021, une seule personne a fait deux commits dans un protocole qui ne pouvait pas encore filtrer les événements par kind. En 2023, NDK et NWC sont nés à cinq jours d’écart pour absorber l’explosion post-Damus. En 2024, un fil de PR de 141 commentaires débattait de la manière dont la collaboration git devait fonctionner sur un protocole social. En 2025, une spécification de monitoring relay patiemment réécrite sept fois en 25 mois a enfin été fusionnée. En 2026, quelqu’un s’est agacé de voir Tailscale exiger un compte et a construit un VPN avec des paires de clés Nostr, tandis que quelqu’un d’autre a livré un DOOM multijoueur qui découvre les pairs via des relays Nostr et chiffre la partie via Marmot. Le scan de 41 millions d’événements sur 1 085 relays par BigBrotr donne une mesure concrète de la croissance du réseau. La surface du protocole en mars 2026 aurait été méconnaissable pour le mars 2021, mais le modèle sous-jacent, des événements signés par des clés secp256k1 et distribués via des relays, n’a pas changé.

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.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Amethyst implémente le support complet des méthodes NIP-47 (Nostr Wallet Connect), Alby Hub ajoute le support multi-relays dans v1.21.6, Amber livre v4.1.3 avec Tor intégré et des permissions de signature plus fines, et Zeus supprime un chemin NWC keysend risqué dans PR #3835. Notedeck livre un updater signé dans v0.8.0-rc2 qui découvre les versions via des événements NIP-94 (File Metadata), tandis que Damus corrige l’état NIP-65 (Relay List Metadata) obsolète, Nostrability Outbox révise ses résultats de benchmark avec des données corrigées, et Primal iOS teste les abonnements directs aux relays pour les DMs. Primal Android livre 3.0.7, Route96 livre v0.6.0, OpenChat continue de renforcer l’interopérabilité Marmot dans v0.1.0-alpha.11, Pika consolide son runtime dans pika/v1.1.1, et Nostria ajoute le filtrage Web of Trust via NIP-85 (Trusted Assertions). Le dépôt NIPs fusionne le balisage Djot pour NIP-54 (Wiki) et un plafond de 5 000 caractères pour NIP-19 (Bech32-Encoded Entities), tandis que les PRs ouvertes proposent un format de fichier .nostrkey pour NIP-49 (Private Key Encryption), une clarification de la cohérence d’appartenance pour NIP-43 (Relay Access Metadata and Requests), des conseils de suppression pour NIP-17 (Private Direct Messages) et un URI d’intention de partage pour NIP-222.

Actualités

Le support Wallet Connect s’élargit, et les clients de portefeuille resserrent les chemins d’erreur

Amethyst, le client Android maintenu par vitorpamplona, a fusionné PR #1828, qui rapproche son implémentation NIP-47 d’une couverture complète du protocole. Le patch ajoute make_invoice, lookup_invoice, list_transactions, get_balance, get_info, les méthodes de hold invoices, le support keysend avec enregistrements TLV, la découverte de capacités via le kind 13194, et les événements de notification sur le kind 23197 avec NIP-44 (Encrypted Payloads). Cela donne au client une surface NWC bien plus large sans s’appuyer sur des extensions spécifiques à une application.

La pile de portefeuilles environnante a évolué dans la même direction. Alby Hub, le nœud Lightning auto-hébergé et service de portefeuille derrière de nombreux déploiements NWC, a livré v1.21.6 avec le support multi-relays et des flux de connexion et de swap simplifiés. Zeus, le portefeuille Lightning mobile, a fusionné PR #3835 supprimant le support NWC keysend après avoir identifié un chemin silencieux de drainage de fonds dans ce flux, tout en corrigeant aussi la gestion des événements en attente et de l’activité Cashu. La connectivité des portefeuilles sur Nostr s’élargit, et les implémenteurs suppriment les flux difficiles à sécuriser.

Notedeck déplace la découverte de versions sur Nostr

Suite à la couverture de Notedeck la semaine dernière, Notedeck, le client desktop natif de l’équipe Damus, a livré v0.8.0-rc2 après avoir fusionné PR #1326. Le nouvel updater s’abonne aux événements de version signés de kind 1063, identifie la plateforme locale, télécharge le binaire référencé et vérifie son hachage SHA256 avant l’installation. Les métadonnées de version n’ont plus besoin de provenir de l’API GitHub ou d’un site web de projet. Une pubkey de confiance et une connexion relay suffisent.

Le même patch ajoute un CLI notedeck-release qui publie ces événements depuis les artefacts de version GitHub, ce qui signifie que le pipeline de publication dispose maintenant d’un chemin de publication natif Nostr ainsi que d’un chemin de découverte natif Nostr. Cela rapproche aussi le modèle de mise à jour Damus et Notedeck du flux de publication signée de Zapstore via relay : l’outillage zsp de Zapstore gère déjà les artefacts logiciels comme événements kind 1063 ou 3063, donc ce chemin n’est pas verrouillé sur un seul client ou un seul éditeur. Le reste du release candidate est du travail desktop pratique : colonnes de suivi, « View As User » pour les profils, support NIP-59 (Gift Wrap), statistiques de notes en temps réel et gestion des limitations NIP-11 (Relay Information Document), mais l’updater est la partie susceptible de survivre au-delà de ce seul cycle de version.

L’état des relays se rapproche du comportement en temps réel

Damus a fusionné PR #3665, remplaçant un identifiant d’événement de liste de relays obsolète par une requête directe à la base de données pour le dernier événement kind 10002. Quand l’ancienne valeur devenait obsolète, les opérations d’ajout et de suppression de relays pouvaient se rabattre sur des listes d’amorçage ou vieilles d’un an, ce qui faisait que certains changements de relays semblaient réussir tout en laissant l’état actif inchangé. PR #3690 corrige un second chemin d’échec en supprimant l’état lock.mdb obsolète durant la compaction LMDB pour que l’application ne plante pas avec SIGBUS au prochain lancement.

Primal iOS a ouvert PR #194, qui s’abonne directement aux relays d’écriture NIP-04 (Encrypted Direct Messages) d’un partenaire de chat pendant qu’une conversation est ouverte, gardant le serveur de cache comme repli. Nostur a ouvert PR #53, qui combine le scoring aléatoire de relays, le filtrage de disponibilité NIP-66 depuis nostr.watch, et l’échantillonnage de Thompson pour passer la sélection de relays d’une heuristique fixe à une politique apprise. Les clients ont longtemps traité le choix de relay comme une donnée de configuration. De plus en plus d’applications le traitent maintenant comme un état en direct qui nécessite une logique de mesure et de réparation.

Versions

Primal Android 3.0.7

Primal Android, le client Android de Primal, a livré 3.0.7 avec un nouveau cycle de sondages et de portefeuille. PR #945 ajoute le vote par sondage basé sur les zaps, PR #948 pagine le chargement des votes pour que les sondages plus importants restent utilisables, et PR #965 récupère les reçus de zap pour toutes les transactions. La même version tague aussi les événements supportés avec les métadonnées client NIP-89 (Recommended Application Handlers) dans PR #968, ce qui aide les clients en aval à attribuer les origines des événements plus proprement.

Amber v4.1.3

Suite à la couverture d’Amber la semaine dernière, Amber, l’application de signature Android pour les flux NIP-55 (Android Signer Application), a livré v4.1.3. La version s’appuie sur son récent travail d’authentification relay NIP-42 avec plus de durcissement opérationnel : PR #327 ajoute Tor intégré aux côtés du support Orbot, PR #324 remplace les permissions de chiffrement grossières basées sur les NIP par des règles spécifiques au type de contenu, et PR #336 supprime les permissions réseau de la variante hors ligne tandis que PR #335 ajoute des vérifications CI pour le maintenir ainsi. PR #322 déplace aussi le stockage du PIN vers un DataStore chiffré.

Cette version resserre la frontière du signataire lui-même. C’est utile pour tout flux Android qui confie de vraies clés ou des décisions d’authentification relay à Amber, car la difficulté n’est pas seulement ce que le signataire peut faire. C’est aussi à quel point il peut être restreint.

Route96 v0.6.0

Suite à la couverture de Route96 la semaine dernière, Route96, le serveur de médias qui supporte Blossom et NIP-96 (HTTP File Storage), a livré v0.6.0. La version déplace la configuration et l’état de la liste blanche dans la base de données avec rechargement à chaud et ajoute des politiques de rétention pour les fichiers froids ou vieillissants. Elle ajoute aussi un endpoint GET /user/files plus riche ainsi que le suivi des statistiques de fichiers pour les téléchargements et le trafic sortant, ce qui donne aux opérateurs plus de visibilité sur l’utilisation de leur serveur de stockage.

OpenChat v0.1.0-alpha.11

Suite à la couverture d’OpenChat la semaine dernière, OpenChat, le client de chat basé sur Avalonia construit sur la pile Marmot, a livré v0.1.0-alpha.11 après une semaine de travail protocolaire rapide. Commit c33895d encapsule les événements Welcome dans un gift wrap NIP-59 et supprime les anciens shims de normalisation de tags MIP-00, commit 2738ff4 complète l’audit de conformité MIP-02, et commit 8e470cf fait de même pour le chiffrement des messages de groupe MIP-03. Commit 129ca37 consolide aussi la gestion NIP-44 sur l’implémentation partagée marmot-cs, réduisant le risque de dérive cryptographique côté client.

nak v0.19.0 et v0.19.1

nak, la boîte à outils Nostr en ligne de commande de fiatjaf, a livré v0.19.0 et v0.19.1. La série 0.19 ajoute une interface de forum de groupe dans commit 5f4efdb, passe les modifications de métadonnées de groupe à un flux de remplacement complet dans commit da0b753, et remplace l’ancien traitement no-text par supported_kinds dans commit bef67d3. Pour les implémenteurs de groupes, cela garde le CLI aligné avec la direction que prennent les spécifications et clients de groupes.

Mises à jour des projets

Amethyst

Suite à la couverture d’Amethyst la semaine dernière, Amethyst, le client Android avec l’une des surfaces protocolaires les plus larges de Nostr, a continué à développer son travail sur les portefeuilles et les relays après le patch NIP-47. PR #1853 ajoute des requêtes COUNT NIP-45 (Event Counting) à travers les écrans de gestion des relays, pour que les utilisateurs puissent voir combien d’événements chaque relay détient réellement pour le flux d’accueil, les notifications, les DMs et les données d’index. PR #1849 ajoute les téléversements de fichiers chiffrés pour les chats NIP-17 (Private Direct Messages), avec un chemin de repli pour les téléversements non chiffrés quand un hôte de stockage rejette la version chiffrée.

PR #1791 apporte aussi la connexion complète au bunker desktop NIP-46 (Nostr Connect) avec un indicateur de heartbeat, ce qui compte parce que les échecs de signature à distance ressemblent souvent à des bugs aléatoires d’interface du côté de l’utilisateur. Le client montre si le signataire est en vie et quand il a répondu pour la dernière fois, tout en rendant évident quand la session en cours utilise un bunker.

Nostria

Nostria, le client multi-plateforme construit autour d’une pile local-first, a fusionné PR #561 ajoutant le filtrage Web of Trust pour les flux et les réponses de fils. La fonctionnalité utilise les données de rang du service de confiance existant et les expose à la fois comme filtre de flux et filtre de réponses, masquant les auteurs dont le rang ne dépasse pas le seuil tout en préservant la structure du fil quand des descendants de confiance sont présents. Cela donne aux utilisateurs une couche intermédiaire entre « montrer tout le monde » et la curation basée sur des listes codées en dur.

La même semaine a aussi apporté PR #563, qui ajoute le filtrage de contenu et le support des reposts sur la page de résumé. En dehors de la liste de PRs suivies, Nostria a aussi complété davantage sa surface pour utilisateurs avancés. Il supporte maintenant le dernier service Brainstorm Web of Trust avec inscription intégrée, ainsi que des flux d’envoi et de réception d’argent dans les DMs utilisant NWC et les invoices BOLT-11. Il ajoute aussi la gestion native de GIFs Nostr via le NIP emoji et un chemin d’import RSS renforcé pour les musiciens qui peut récupérer les répartitions Lightning existantes depuis les flux de podcasts. Nostria traite le classement, les médias, les paiements et la publication comme une seule surface d’application connectée.

Nostur

Nostur, le client iOS maintenu par nostur-com, a ouvert PR #53 pour passer le routage outbox d’un plan fixe à une politique scorée. Le patch ajoute le scoring aléatoire de relays, le filtrage de disponibilité NIP-66 avec un flux nostr.watch en cache, et l’échantillonnage de Thompson pour que les données de succès et d’échec des relays modifient les sélections futures. La conception conserve une soupape de sécurité quand trop de relays seraient filtrés et préserve les relays .onion. C’est l’un des exemples actuels les plus clairs d’un client traitant la sélection de relays comme un système adaptatif.

Nostrability Outbox

Suite au précédent rapport de benchmark Outbox, Nostrability Outbox, le projet de benchmark et d’analyse centré sur le routage client NIP-65 et NIP-66, a passé la semaine à resserrer ses propres affirmations. PR #35 remplace les résultats d’échantillonnage de Thompson gonflés par un re-benchmark complet sur 1 511 exécutions et recommande la variante CG3 pour le routage de type NDK. PR #43 ajoute des comparaisons de décroissance et de cas d’usage, corrige un bug d’empoisonnement de cache 0 follows, puis relance le jeu de données Telluride après avoir fixé les TTL de cache.

Ce n’est pas du travail produit au sens habituel, mais c’est important pour les auteurs de clients car les chiffres du projet sont maintenant plus précis et moins flatteurs aux endroits où ils avaient précédemment surestimé. Le résultat corrigé reste utile. La sélection aléatoire continue de battre le routage purement déterministe dans les cas qui intéressent Outbox, l’apprentissage de type Thompson peut améliorer matériellement la couverture quand les clients persistent l’historique utile des relays, et le filtrage de disponibilité NIP-66 réduit le temps perdu sur les relays morts. Le travail se transforme aussi en propositions d’implémentation concrètes, incluant NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53, et applesauce #54 plus applesauce #55.

Backend White Noise

whitenoise-rs, le backend Rust utilisé par White Noise et d’autres outils Marmot, a fusionné deux patchs de durcissement des frontières autour de la gestion des médias Blossom. PR #637 impose HTTPS sur les URLs Blossom et ajoute un timeout de téléversement, tandis que PR #642 plafonne les téléchargements de blobs à 100 MiB pour empêcher les téléchargements de médias surdimensionnés de se transformer en chemin de déni de service. Pour un logiciel de messagerie privée, les URLs de médias sont l’une des interfaces les plus sensibles entre la logique applicative chiffrée et l’infrastructure réseau non fiable. Cette semaine, l’équipe a resserré cette frontière.

rust-nostr

rust-nostr, la bibliothèque de protocole Rust, a fusionné PR #1280 ajoutant des constructeurs de commodité pour LocalRelayBuilderNip42. Les nouveaux helpers de lecture et d’écriture donnent aux configurations de relays embarqués et de tests un moyen plus clair de transformer la politique d’authentification NIP-42 en code. C’est un petit patch de bibliothèque, mais il compte pour les équipes construisant des relays locaux ou intégrés aux applications qui ont besoin de l’authentification activée sans répéter du code standard à chaque fois.

Pika

Suite à la couverture précédente de Pika, Pika, l’application de messagerie basée sur Marmot, a livré pika/v1.1.1 et pikachat-v1.1.1 avec un cycle de versions centré sur la convergence du runtime. PR #542 introduit une façade de runtime Marmot partagée pour le CLI et le sidecar, avec l’hôte de l’application migrant sur la même surface. PR #556 resserre le cycle de vie des agents OpenClaw et l’état de provisionnement, tandis que PR #600 ajoute la restauration depuis une sauvegarde et une sécurité de récupération plus stricte pour les environnements gérés.

La surface utilisateur directe ici est plus petite que dans le dernier article sur Pika, mais le changement architectural est significatif. Regrouper la logique de groupe, média, appel et session derrière un seul runtime partagé réduit les chances que l’application et le démon divergent à mesure que la pile Marmot grandit.

Mises à jour des NIP

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

Fusionnés :

NIP-54 (Wiki) : Passage d’Asciidoc à Djot (PR #2242) : Le contenu wiki sur le kind 30818 utilise maintenant Djot comme format de balisage canonique. Le texte fusionné ajoute un comportement explicite de wikilinks, des exemples de demandes de fusion pour le kind 818, des exemples de redirection pour le kind 30819 et des exemples de normalisation non latine pour les tags d. Cela donne aux implémenteurs une cible d’analyse plus propre qu’Asciidoc et supprime un chemin de spécification supplémentaire qui dépendait d’une chaîne d’outils centrée sur Ruby.
NIP-19 (Bech32-Encoded Entities) : Ajout d’une limite d’entrée (PR #2264) : La spécification recommande maintenant de plafonner les chaînes d’entités encodées Bech32 à 5 000 caractères. C’est un petit changement avec une vraie valeur pour les parseurs, car les chaînes NIP-19 apparaissent maintenant dans les flux QR, les liens profonds, les feuilles de partage et les entrées collées par les utilisateurs dans de nombreux clients.

PRs ouvertes et discussions :

Fichier de clé Nostr pour NIP-49 (Private Key Encryption) (PR #2269) : Propose un format de fichier .nostrkey pour l’export et l’import de clés chiffrées par mot de passe. S’il est fusionné, cela donnerait aux clients un chemin de sauvegarde basé sur des fichiers plus normal que la copie de chaînes ncryptsec brutes.
Cohérence de l’état d’appartenance pour NIP-43 (Relay Access Metadata and Requests) (PR #2267) : Ajoute une section clarifiant que les relays devraient maintenir un état d’appartenance autoritaire unique par pubkey. Cela simplifierait la logique des clients de groupe autour des changements d’appartenance et de l’historique rejoué.
Conseils de suppression pour NIP-17 (Private Direct Messages) (PR #2260) : Propose un chemin concret pour l’édition et la suppression de messages privés via des événements de suppression encapsulés en gift wrap. Le travail est encore ouvert, mais les auteurs de clients ont besoin d’une réponse ici si NIP-17 doit remplacer complètement les anciens flux de DM.
URI d’intention de partage pour NIP-222 (PR #2266) : Le brouillon standardiserait la manière dont les applications mobiles et desktop transmettent du contenu partagé à un client Nostr. C’est l’un des bords d’interopérabilité les plus rugueux dans les flux actuels d’application à application.

NIP Deep Dive : NIP-94 (File Metadata)

NIP-94 définit le kind 1063 comme un événement de métadonnées de première classe pour un fichier. La spécification donne à l’événement son propre content lisible par l’humain plus des tags lisibles par machine pour l’URL de téléchargement, le type MIME, les hachages, les dimensions, les aperçus, les replis et les indications de service de stockage. C’est important car le fichier devient interrogeable sur les relays comme son propre objet. Un client n’a pas besoin d’extraire les métadonnées du contenu environnant pour comprendre ce qu’est le fichier.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

Les tags font plus de travail qu’il n’y paraît au premier abord. x identifie le fichier servi, tandis que ox identifie le fichier original avant toute transformation côté serveur. Les tags d’aperçu permettent aux clients de construire des index de fichiers navigables sans télécharger l’asset complet, et summary peut porter un court extrait à côté. fallback fournit une seconde source quand l’URL principale échoue, et service indique le protocole de stockage derrière le fichier, comme NIP-96 ou un autre hôte. NIP-94 se situe donc en dessous de la publication sociale et au-dessus du stockage brut. Il décrit le fichier, pas la conversation autour du fichier.

C’est pourquoi l’updater de Notedeck de cette semaine est intéressant. PR #1326 utilise des événements signés de kind 1063 pour la découverte de versions logicielles, puis vérifie le binaire téléchargé par rapport au SHA256 publié. La même forme d’événement peut décrire un artefact logiciel ou un téléversement de média. NIP-94 est assez ancien pour être stable, mais il a encore de la marge pour croître car de plus en plus de projets traitent les événements de métadonnées comme un transport pour les machines, pas seulement comme une décoration pour les personnes.

NIP Deep Dive : NIP-54 (Wiki)

NIP-54 définit le kind 30818 comme un événement d’article wiki. La spécification traite le tag d comme le sujet normalisé de l’article et permet à plusieurs auteurs de publier des entrées pour le même sujet. Le corps de l’article vit dans content, tandis que les tags gèrent l’identité normalisée, le titre d’affichage, les résumés et les références aux versions précédentes. Cela signifie que NIP-54 n’est pas seulement un format de contenu. C’est aussi un problème de récupération et de classement, car chaque client doit encore décider quelle version d’article afficher.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

La fusion de cette semaine change le balisage canonique d’Asciidoc à Djot dans PR #2242. C’est important pour les implémenteurs car Djot a une spécification autonome plus resserrée et une histoire de parseur plus simple à travers les langages. Le texte fusionné clarifie aussi comment les wikilinks de style référence se résolvent, comment les demandes de fusion utilisent le kind 818, comment les redirections utilisent le kind 30819, et comment la normalisation des tags d devrait se comporter pour les écritures non latines. Ce sont les parties qui font que deux clients indépendants s’accordent sur quel article un lien pointe.

NIP-54 se situe aussi dans un endroit inhabituel du protocole. Un client wiki a besoin du rendu de contenu, mais il a aussi besoin d’une politique de classement. Les réactions, les listes de relays, les listes de contacts et les signaux de déférence explicites alimentent tous la décision de quel article gagne pour un sujet donné. Le passage à Djot ne résout pas ce problème de classement, mais il supprime l’une des ambiguïtés de parseur qui se trouvaient en dessous. C’est pourquoi la fusion compte maintenant : le changement concerne moins un formatage de prose plus agréable et davantage la facilitation d’une implémentation cohérente du comportement wiki multi-client.

Vous construisez quelque chose, ou vous voulez qu’on en parle ? Contactez-nous via NIP-17 DM sur Nostr à npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Shopstr et Milk Market ajoutent des surfaces MCP pour le commerce piloté par agents, tandis que OAuth Bunker, Amber et strfry ajoutent le relay-auth NIP-42 (Authentication of Clients to Relays) et le support des protected events à travers des logiciels d’application, de signer et de relay. Route96 livre deux versions autour de l’étiquetage IA, des files de modération, du perceptual hashing et d’une documentation serveur lisible par machine. Samizdat, déjà en ligne sur le web, a publié sa première alpha Android puis a ajouté le support signer NIP-55 (Android Signer Application). Formstr ajoute l’inscription via NIP-49 (Private Key Encryption), Amethyst livre un travail de résolution NIP-05 (Domain Verification) fondé sur Namecoin, Mostro publie v0.16.4, et le dépôt des NIPs fusionne NIP-91 (AND Operator for Filters) ainsi que des recommandations défensives pour NIP-66 (Relay Discovery and Liveness Monitoring).

Actualités

Shopstr et Milk Market ouvrent des surfaces de commerce MCP

Shopstr, la marketplace pair à pair avec paiements Lightning et Cashu, a fusionné PR #234 (commit 94ef7d1), ajoutant un serveur MCP avec authentification par clé d’API pour la gestion des comptes agents. Le changement ajoute .well-known/agent.json pour la découverte d’agents, des endpoints MCP d’onboarding et de statut, des routes de création de commande et de vérification de paiement, des outils dédiés à l’achat et à la lecture, ainsi qu’un écran de réglages pour les clés d’API. PR #236 étend cela avec des actions côté vendeur pour les messages, les adresses, les mises à jour de commande et la sélection de spécifications produit. Un correctif de sécurité dans PR #235 remplace le hachage SHA-256 des clés d’API en une seule itération par du PBKDF2 salé à 100 000 itérations.

Les agents peuvent lire des listings NIP-99 (Classified Listings) et passer par le checkout en utilisant les flux de paiement existants de NIP-47 (Nostr Wallet Connect) et NIP-60 (Cashu Wallet), sans scraper des pages ni reverse-engineerer le comportement du client.

Milk Market, une marketplace alimentaire sur Nostr accessible sur milk.market, a adopté la même base MCP et clé d’API dans le commit da6c0b4. PR #10 ajoute les commandes par abonnement, la modification d’adresse de livraison après achat, et la gestion des checkouts multi-marchands et multi-devises pour Stripe et d’autres chemins de paiement fiat. Une PR #11 corrige ensuite un bug d’initialisation de base de données au démarrage, où la table des publications relay échouées n’était pas créée sur une installation neuve, ce qui provoquait des erreurs 500 au premier chargement. L’interface côté agent fonctionne avec un checkout natif Bitcoin sur Shopstr ou un checkout mixte fiat et Bitcoin sur Milk Market.

NIP-42 relay-auth à travers bunker, signer et relay

OAuth Bunker, un bunker NIP-46 (Nostr Connect) qui relie des fournisseurs OAuth à la signature Nostr, a ajouté la connexion NIP-07 (Browser Extension Signer), la sélection automatique quand une seule identité existe, et le nettoyage des identités supprimées (commit f0c7683). Lorsqu’une seule identité existe, le bunker la sélectionne maintenant automatiquement au lieu d’afficher un choix. Supprimer une identité retire aussi ses assignations et connexions orphelines. Le commit 6b8796c ajoute une voie de configuration ALWAYS_ALLOWED_KINDS pour les utilisateurs assignés, avec par défaut le kind 30078 pour les données spécifiques à une application, afin que les identités déléguées puissent écrire dans ce stockage sans approbation événement par événement.

Amber, le principal signer NIP-55 sur Android, a livré v4.1.3-pre4 dans une série de quatre pré-releases pendant la semaine. PR #317 ajoute la gestion de l’authentification relay NIP-42 pour les requêtes de kind 22242. L’implémentation ajoute une nouvelle colonne de base de données pour suivre les permissions spécifiques à un relay, avec un index unique sur (pkKey, type, kind, relay). Les utilisateurs voient un écran d’auth dédié où ils peuvent autoriser ou refuser par relay ou pour tous les relays via un scope wildcard *, puis persister ce choix. Les permissions wildcard effacent toutes les entrées spécifiques à un relay pour un kind donné. PR #318 poursuit en refactorant les écrans de requêtes multi-événements afin d’afficher les détails inline avec des cartes composables plutôt que de naviguer vers un écran séparé. La version met aussi à jour les relays de profil par défaut, ajoute un affichage des requêtes en bottom sheet et corrige un crash sur les appareils MediaTek en désactivant StrongBox keystore.

Côté relay, strfry PR #156 implémente la gestion NIP-42 pour les NIP-70 (Protected Events), et PR #176 rejette les reposts qui embarquent des protected events.

Notedeck ajoute les limites de relay NIP-11 et des fonctionnalités Agentium

Notedeck, le client desktop natif de l’équipe Damus, a fusionné 14 PRs cette semaine. PR #1316 ajoute la récupération des limitations de relay NIP-11 (Relay Information Document), de sorte que tous les relays outbox respectent maintenant max_message_length et max_subscriptions depuis le relay info document. L’implémentation inclut un traitement en background jobs, un backoff exponentiel avec jitter pour les tentatives de reconnexion, et des en-têtes HTTP Accept personnalisés. PR #1312 corrige un bug où les DMs échouaient parfois à se charger après un changement de compte, et PR #1333 ajoute un mécanisme de backoff à la communication multicast avec les relays pour éviter le spam de diffusion en cas d’erreurs.

Le sous-système Agentium, l’UI d’agent de code intégrée à Notedeck, appelée en interne « Dave », a reçu le collage d’images depuis le presse-papiers, des configurations d’exécution nommées synchronisées entre appareils via des événements de kind 31991, NIP-33 (Parameterized Replaceable Events), un créateur de git worktree et un sélecteur de modèle pour choisir les backends par session (PR #1336). PR #1338 intègre egui_kittest pour des tests UI headless, et PR #1339 ajoute une carte de tableau de bord suivant les nouvelles créations de listes de contacts par client. Une PR #1314 encore ouverte porte la résolution Namecoin NIP-05 d’Amethyst dans Notedeck avec des requêtes ElectrumX, un routage Tor SOCKS5 et une intégration à la barre de recherche.

diVine livre v1.0.6 avec une infrastructure de tests E2E et l’import NIP-49

diVine, le client vidéo court format en boucle qui restaure les archives Vine sur divine.video, a livré v1.0.6 avec 127 PRs fusionnées. La version ajoute l’import de compte NIP-49, le support NIP-05 externe, la gestion multi-comptes, des builds macOS et Linux expérimentaux, ainsi qu’une bibliothèque de brouillons et de clips repensée, adossée au stockage local.

Côté ingénierie, PR #1928 ajoute une infrastructure complète de tests d’intégration E2E utilisant Patrol pour l’automatisation UI native face à une stack backend Docker, relay, API, Blossom, Postgres, Redis et ClickHouse. Cinq tests de parcours d’auth couvrent l’inscription, la vérification, la réinitialisation de mot de passe, l’expiration de session et le rafraîchissement de token. PR #2105 remplace le chargement vidéo HLS-first par du MP4 direct avec fallback HLS automatique, ce qui réduit les temps de chargement de 30 à 60 secondes à un niveau presque instantané. PR #2076 met en cache la réponse API du flux d’accueil dans SharedPreferences pour un affichage instantané au cold start. PR #2104 impose le masquage dans les flux des labels de contenu ai-generated, et PR #2100 ajoute un réglage de sécurité pour n’afficher que les vidéos hébergées par diVine. La migration du cache de profils de Hive vers Drift continue à travers PR #1881, PR #1883 et PR #1903, en remplaçant environ 1 074 lignes de code Hive par des DAOs Drift.

Vector v0.3.2 livre la synchronisation negentropy NIP-77 et des améliorations MLS

Vector, une messagerie desktop axée sur la vie privée qui utilise le chiffrement de groupe MLS avec NIP-17 (Private Direct Messages) et NIP-44 (Encrypted Payloads), a livré v0.3.2. Le changement principal est la negentropy NIP-77 pour la synchronisation de groupes MLS (commit b06adf4), qui rattrape les messages manqués beaucoup plus vite grâce à un boot parallèle. La version ajoute aussi un moteur audio reconstruit avec support Linux complet, des spoilers d’image avec aperçus floutés, des hyperliens cliquables avec aperçus enrichis, des pings @mention avec @everyone pour les admins de groupe, l’autocomplétion des shortcodes emoji, la mise en sourdine de groupes, la réaction en un geste sur des réactions existantes, et des uploads de fichiers annulables. Vector filtre explicitement les événements de chat de groupe NIP-17 (commit 2179a51), en utilisant MLS exclusivement pour le chiffrement de groupe.

Versions

Route96 v0.5.0 et v0.5.1

Route96, un serveur média compatible Blossom et NIP-96 (HTTP File Storage), a livré v0.5.0 et v0.5.1. v0.5.0 ajoute l’étiquetage IA automatisé, le backfill rétroactif des uploads non étiquetés, des files de modération pour les fichiers signalés, le rejet basé sur EXIF pour la vie privée, et la gestion de hash interdits.

v0.5.1 ajoute des hashes perceptuels d’image, du locality-sensitive hashing pour retrouver des images similaires, des endpoints admin par lots, et un SKILL.md publié décrivant la surface API Blossom et NIP-96 du serveur pour les outils d’agents. PR #58 déplace les workers en arrière-plan vers des tâches Tokio entièrement asynchrones, et le commit 97b00a3 ajoute un backoff pour éviter des hot loops.

Samizdat v1.0.0-alpha

Samizdat, lecteur et éditeur long format disponible sur samizdat.press, a livré son premier build Android dans v1.0.0-alpha. L’application s’ouvre sur une page Press curatée d’articles Nostr long format, avec navigation par onglets entre Press, Feed, Saved et Write. Le build Android ajoute un stockage natif des clés via chiffrement Android Keystore avec déverrouillage biométrique, gère les URI nostr: et les deep links samizdat.press, et prend en charge le handoff de signer via le sélecteur d’applications Android, Amber, Primal, etc., au lieu d’exiger un import direct de clé. Le pull-to-refresh, la gestion des safe areas sur différentes tailles d’écran, et les intégrations natives de partage, presse-papiers, haptique et écran de démarrage font maintenant partie de la shell Android plutôt que du wrapper web.

Le commit d17308f ajoute la signature NIP-55 basée sur intents pour les parcours Amber et Primal, et le commit e29dab8 remplace un contournement JavaScript bridge par un plugin Capacitor natif utilisant startActivityForResult. L’application exige Android 7.0 ou plus, API 24, est distribuée sous forme d’APK debug dans cette alpha, et n’a toujours pas de notifications push. La publication dépend actuellement d’une application signer, tandis que la connexion par nsec couvre la lecture locale et l’accès au compte.

Calendar by Form* v0.2.0

Calendar by Form*, une application de calendrier décentralisée avec partage d’événements privés NIP-59 (Gift Wrap) disponible sur calendar.formstr.app, a livré v0.2.0 avec PR #38. La version étend la gestion des événements récurrents pour NIP-52 (Calendar Events), allant au-delà des fondations mono-événement de la v0.1.0. Les changements sous-jacents touchent aussi le stockage local des événements, la gestion des signers et le plumbing des notifications Android. C’est la deuxième application active de l’organisation Formstr après la migration de dépôt du mois dernier.

Mostro v0.16.4

Mostro, la plateforme d’échange Bitcoin pair à pair construite sur Nostr, a publié v0.16.4. Les correctifs de restauration de session de litige (PR #599) et de fermeture automatique (PR #606) couverts la semaine dernière sont inclus. Nouveau dans cette version : PR #625 ajoute un champ days aux événements d’évaluation utilisateur de kind 38384, PR #612 ajoute une expiration à ces événements d’évaluation, et PR #614 fait passer les événements de commande vers des réglages d’expiration configurés au lieu d’une fenêtre codée en dur de 24 heures. PR #622 ajoute une vérification d’idempotence pour empêcher les paiements en double des frais de développement.

Mostro Mobile v1.2.1

Mostro Mobile, le client Flutter pour l’échange P2P Mostro, a livré v1.2.1 avec 11 nouvelles fonctionnalités et 11 corrections de bugs. La version ajoute le rendu multimédia chiffré dans le chat de litige (PR #514), la fermeture automatique de l’UI de litige quand les commandes atteignent un état terminal (PR #503), le scan QR pour l’import wallet NWC (commit 12eaee4), des traductions françaises, et la gestion des notifications push FCM. PR #496 corrige un bug de padding de signature Schnorr en épinglant la dépendance bip340 à la v0.2.0.

0xchat v1.5.4

0xchat, le client de messagerie type Telegram avec support Cashu, a livré v1.5.4 centrée sur les correctifs Linux desktop : icônes de dock AppImage, rendu des emojis, gels des menus contextuels, et blocages UI sur répondre/copier. La version corrige aussi les problèmes d’upload d’image et l’intégration npub.cash. PR #49 élimine des rebuilds UI inutiles en supprimant un timer de polling de 3 secondes qui forçait des repaints glassmorphic sans rien faire, et débloque l’initialisation de connexion en lançant le chargement du cache d’événements en parallèle au lieu de bloquer le démarrage relay, contacts et canaux.

Keep v0.6.0

Keep, un signer à seuil FROST pour Android avec support NIP-55 et NIP-46, a livré v0.6.0 et v0.6.1. v0.6.0 ajoute une UI de coordination et gestion de descripteurs de wallet, un flux de sauvegarde/restauration avec authentification biométrique (PR #184), la récupération de nsec à partir de threshold shares (PR #187), la génération cross-platform de cadres QR animés via Rust UniFFI (PR #188), et une piste d’audit de signature avec vérification de chaîne (PR #189). v0.6.1 remplace la licence AGPL-3.0 par MIT (PR #191).

njump v0.3.0

njump, la passerelle statique pour consulter du contenu Nostr sur njump.me, a livré v0.3.0 avec un changement cassant dans le parsing des codes note1 et une mise à jour de la bibliothèque Nostr sous-jacente.

Roadstr v0.1.1

Roadstr, une application décentralisée de signalement d’événements routiers utilisant Nostr, a livré sa première version démo v0.1.1. L’application affiche les événements routiers sur une carte utilisant les vector tiles d’openfreemap.org.

Bitcredit v0.5.3

Bitcredit, une application d’e-bills avec couche de transport Nostr et relay dédié sur bit.cr, a livré v0.5.3. PR #846 ajoute les champs payment_actions et bill_state à l’API pour l’état de paiement et d’acceptation, et PR #849 corrige la gestion des adresses de signature pour les signers anonymes.

OpenChat v0.1.0-alpha.3

OpenChat, une application de chat construite sur les bibliothèques .NET MLS et C# du protocole Marmot, a livré v0.1.0-alpha.3. La version ajoute le support de signer externe pour Amber et les flux NIP-46 (commit e568d97), déplace la persistance de l’état MLS dans le service MLS pour éliminer les pertes de données dans la fenêtre de crash (commit 4720bc8), et publie des builds Windows, Linux et Android via un nouveau pipeline CI.

OpenSignal v1.0.0

OpenSignal, un copilot de trading Kotlin Multiplatform pour Nostr, a livré v1.0.0. La version assemble des modules KMP partagés pour la logique métier, le rendu de graphiques, l’authentification et la publication Nostr, le support d’upload Blossom NIP-96, et des hooks d’inférence IA fondés sur ONNX à travers les shells Desktop et Android. L’architecture publiée inclut aussi un service IA FastAPI pour l’analyse de captures d’écran de graphiques, des pipelines d’entraînement de modèles et un moteur de risque qui produit des plans de trade structurés avec sizing et avertissements. La connexion prend en charge soit des clés nsec brutes, soit des signers externes, et le flux de sortie se termine par la publication d’un événement Nostr plutôt qu’une analyse locale uniquement.

Mises à jour des projets

Formstr

Formstr, l’alternative à Google Forms sur Nostr, a fusionné PR #434 (commit e9c4fd5), ajoutant un flux d’inscription qui utilise des clés privées chiffrées NIP-49 (Private Key Encryption). Avant ce changement, les utilisateurs avaient besoin soit d’une extension de navigateur NIP-07, soit de coller un nsec brut pour utiliser Formstr. Le nouveau flux génère une paire de clés côté client, chiffre la clé privée avec un mot de passe choisi par l’utilisateur via le schéma scrypt + XChaCha20-Poly1305 de NIP-49, puis stocke la chaîne ncryptsec obtenue. Les utilisateurs peuvent ensuite se reconnecter avec leur mot de passe sans installer d’extension signer. La gestion des clés reste côté client du début à la fin.

Amethyst

Amethyst, le client Android riche en fonctionnalités, a fusionné quatre PRs qui livrent le travail de résolution NIP-05 soutenu par Namecoin, lequel était encore ouvert la semaine dernière. PR #1734 ajoute une vérification NIP-05 résistante à la censure via ElectrumX pour les identifiants .bit, d/ et id/. Quand Amethyst détecte l’un de ces suffixes dans un champ NIP-05, il interroge un serveur ElectrumX-NMC pour récupérer l’historique de transaction du nom, analyse le script NAME_UPDATE de la dernière sortie pour en extraire la pubkey Nostr, et rejette les noms plus anciens que 36 000 blocs, la fenêtre d’expiration de Namecoin. Les connexions ElectrumX passent par SOCKS5 lorsque Tor est activé, avec sélection dynamique entre des endpoints clearnet et .onion. Un cache LRU avec TTL d’une heure évite les requêtes blockchain répétées.

PR #1771 corrige des conditions de course et des erreurs de résolution dans ce flux. PR #1785 permet aux nouveaux utilisateurs d’importer une liste de suivis pendant l’inscription à partir d’identifiants NIP-05 ordinaires ou fondés sur Namecoin. PR #1786 ajoute des réglages de serveur ElectrumX personnalisés pour laisser les utilisateurs choisir le serveur chargé de leurs requêtes.

nostr-idb

nostr-idb, une bibliothèque fournissant des méthodes utilitaires pour stocker des événements Nostr dans IndexedDB, a fusionné PR #6 ajoutant le support des filtres de tags AND NIP-91. Le changement ajoute une sémantique d’intersection à la logique de matching côté client pour que les requêtes IndexedDB puissent exiger toutes les valeurs de tag listées plutôt qu’une seule. PR #8 met la bibliothèque à jour vers la dernière interface NIP-DB, puis un commit b49b3d3 corrige un deadlock sur subscribe et retire nostr-tools des dépendances de production.

Pensieve

Pensieve, un indexeur Nostr orienté archive avec analytique ClickHouse, a fusionné PR #8 ajoutant l’application de TTL de cache par entrée et la coalescence des misses par clé pour réduire les pics CPU de l’API. Les endpoints de séries temporelles les plus coûteux, statistiques d’engagement, activité horaire et activité par kind, utilisent maintenant des TTL serveur de 10 minutes au lieu de déclencher des recomputations synchronisées en tempête.

Blossom

Blossom, le protocole et la stack serveur d’hébergement média décentralisé, a fusionné deux mises à jour d’autorisation BUD-11. PR #91 déplace l’autorisation optionnelle dans son propre BUD et clarifie le rôle des tags x et server. PR #93 nettoie le comportement d’auth spécifique aux endpoints et formalise l’en-tête X-SHA-256 pour la vérification d’upload. Les deux PRs consolident la logique d’auth dans BUD-11 et suppriment les ambiguïtés autour du hachage des requêtes pour l’upload, la suppression et les flux de gestion média.

Mises à jour des NIP

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

Fusionnés :

NIP-91 (AND Operator for Filters) (PR #1365) : ajoute une sémantique d’intersection pour les filtres de tags, permettant aux relays de répondre à des requêtes qui exigent toutes les valeurs listées au lieu d’une seule. Cela réduit le post-filtrage côté client et la bande passante sur les requêtes riches en tags.
NIP-66 (Relay Discovery and Liveness Monitoring) : mesures défensives (PR #2240) : après le travail de benchmark outbox couvert la semaine dernière, la spécification ajoute maintenant des avertissements sur les chemins dégradés des données de monitoring relay. Les clients ne doivent pas exiger les événements de monitoring kind 30166 pour fonctionner. Un moniteur peut se tromper, être obsolète ou malveillant. Les clients doivent croiser les sources et éviter de couper de larges portions du graphe de relays d’un utilisateur sur la base d’un seul flux.
NIP-39 (External Identities in Profiles) : nettoyage du registre kind 10011 (PR #2256) : ajoute directement la référence au kind 10011 dans la spécification, en l’alignant sur l’implémentation d’Amethyst couverte la semaine dernière.

PRs ouvertes et discussions :

NIP-70 (Protected Events) : rejeter les reposts qui embarquent des protected events (PR #2251) : si un relay applique NIP-70 sur l’événement d’origine mais accepte les reposts qui transportent le même contenu, le tag - n’a pas d’effet pratique. Cette PR ajoute la règle selon laquelle les relays doivent aussi rejeter les reposts kind 6 et kind 16 d’événements protégés. strfry PR #176 l’implémente déjà.
NIP-71 (Video Events) : pistes audio multiples (PR #2255) : ajoute des tags imeta audio pour les pistes alternatives, variantes linguistiques et flux audio-only. Un client pourrait conserver un fichier vidéo stable tout en changeant la langue audio, ou servir l’audio comme piste séparée pour un contenu de type podcast.
NIP-11 (Relay Information Document) et attributs de relay NIP-66 (PR #2257) : ajoute un champ structuré attributes aux relay information documents, offrant aux clients et outils de découverte des métadonnées lisibles par machine au-delà de la description en texte libre actuelle.

NIP Deep Dive : NIP-49 (Private Key Encryption)

NIP-49 définit comment un client chiffre une clé privée avec un mot de passe et encode le résultat sous forme de chaîne bech32 ncryptsec. Formstr utilise NIP-49 dans son nouveau flux d’inscription.

Le format n’est pas lié à un kind d’événement dédié. Un client part de la clé privée secp256k1 brute de 32 octets, dérive une clé symétrique à partir du mot de passe utilisateur avec scrypt, chiffre la clé avec XChaCha20-Poly1305, puis encapsule le résultat dans une chaîne bech32 ncryptsec. Un flag d’un octet enregistre si la clé est connue comme ayant été manipulée de manière non sûre avant chiffrement.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

L’événement JSON ci-dessus est un exemple au niveau application, pas une exigence de NIP-49. Le NIP standardise le format de clé chiffrée. Un client peut stocker la chaîne ncryptsec localement, la synchroniser via un stockage spécifique à l’application, ou l’exporter comme chaîne de sauvegarde. Les mots de passe sont normalisés en Unicode NFKC avant la dérivation de clé afin que le même mot de passe déchiffre de manière cohérente entre clients et plateformes.

Le flag de sécurité de clé sur un octet a trois valeurs définies : 0x00 signifie que l’historique de manipulation de la clé est inconnu, 0x01 signifie que la clé est connue pour avoir été manipulée de manière non sûre, par exemple collée en clair dans un formulaire web avant chiffrement, et 0x02 signifie que la clé a été générée et chiffrée dans un contexte sûr sans jamais être exposée. Les clients peuvent utiliser cela pour afficher des avertissements lors de l’import de clés dont l’historique est connu comme non sûr.

NIP-49 protège mieux les clés qu’un export nsec en clair, mais le chiffrement n’est aussi fort que le mot de passe et le coût scrypt configuré. Des valeurs LOG_N plus élevées compliquent le brute force offline mais ralentissent aussi les opérations légitimes de déchiffrement. La spécification met en garde contre la publication de clés chiffrées sur des relays publics, puisque les attaquants bénéficient de la collecte de ciphertext pour le cracking offline. À titre de comparaison, la signature distante NIP-46 évite entièrement d’exposer les clés, tandis que la signature Android NIP-55 garde les clés dans une application signer dédiée. NIP-49 occupe un autre créneau : la sauvegarde chiffrée portable pour les utilisateurs qui gèrent eux-mêmes leurs clés.

Les implémentations incluent Formstr PR #434 pour l’inscription, Amber pour la sauvegarde et la restauration ncryptsec, diVine v1.0.6 pour l’import de compte, Keep v0.6.0 pour l’export de FROST shares, et des outils de gestion de clés comme nsec.app et Alby.

NIP Deep Dive : NIP-70 (Protected Events)

NIP-70 définit les protected events. Quand un événement porte le tag ["-"], un relay doit le rejeter sauf si le relay exige une authentification NIP-42 et que la pubkey authentifiée correspond à l’auteur de l’événement.

Le flux d’auth NIP-42 fonctionne comme suit : le relay envoie un challenge AUTH contenant une chaîne aléatoire, puis le client répond avec un événement kind 22242 signé dont les tags incluent l’URL du relay et le challenge. Le relay vérifie la signature et contrôle que la pubkey de l’événement d’auth correspond à la pubkey de l’événement protégé en cours de publication. Si les pubkeys ne correspondent pas, le relay rejette l’événement avec le préfixe de message restricted.

Le contenu de l’événement peut malgré tout rester public. Le tag - ne contrôle que qui peut publier l’événement sur un relay qui respecte ce tag. Cela couvre les flux semi-fermés de NIP-29 (Simple Groups), les espaces relay réservés aux membres, et d’autres contextes où l’auteur veut limiter la redistribution via le graphe des relays. NIP-70 est une convention à tag unique, pas un nouveau kind d’événement, donc n’importe quel kind existant peut porter le tag -.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Même si un relay bloque la publication tierce de l’événement original, quelqu’un peut toujours republier le contenu dans un repost. PR #2251 traite ce problème en imposant aux relays de rejeter aussi les reposts kind 6 et kind 16 d’événements protégés. strfry PR #156 ajoute la gestion NIP-42 pour les protected events, et strfry PR #176 bloque les reposts qui embarquent du contenu protégé.

NIP-70 contrôle le comportement des relays. Un destinataire peut toujours recopier le contenu ailleurs, et la spécification le dit explicitement. Le tag - donne aux relays un signal lisible par machine leur permettant de refuser une republication. À titre de comparaison, NIP-62 (Request to Vanish) demande aux relays de supprimer des données après coup, tandis que NIP-70 empêche une publication non autorisée dès l’ingestion. Les deux sont complémentaires : un auteur peut marquer des événements comme protégés pour limiter leur diffusion, puis demander plus tard une suppression s’il souhaite que le contenu disparaisse des relays qui l’ont accepté.

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

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Le Marmot Development Kit livre sa première version publique avec médias chiffrés et liaisons multi-langages. Nostrability publie des benchmarks du modèle outbox à travers 14 algorithmes de sélection de relays. Wisp passe de la première alpha à la bêta en huit jours avec Tor et la signature NIP-55 (Android Signer Application). NIP-91 (filtres AND) est fusionné. Vector v0.3.1 apporte la synchronisation negentropy avec des gains de performance de 15x. Ce numéro inclut également la rétrospective Cinq ans de févriers Nostr, retraçant le protocole depuis une réécriture de spécification desservant trois relays jusqu’à l’explosion de Damus sur l’App Store, en passant par le réseau maillé et les propositions d’agents IA.

Actualités

Le modèle outbox sous le microscope

Nostrability a publié une série de benchmarks du modèle outbox testant la capacité de différents algorithmes de sélection de relays à récupérer des événements depuis le réseau décentralisé de relays. Le projet a fusionné 16 PRs et 76 commits en dix jours, produisant ce qui constitue probablement l’analyse empirique la plus approfondie des stratégies d’implémentation de NIP-65 (Relay List Metadata) à ce jour.

Les benchmarks testent 14 algorithmes de sélection de relays contre des listes d’abonnements réelles à travers 15 clients et bibliothèques dans cinq langages. Une approche de base consistant à interroger uniquement les relays populaires récupère environ 26 % des événements. La couverture ensembliste gloutonne avec échantillonnage de Thompson atteint 80-90 % de rappel. L’ajout d’une variante sensible à la latence utilisant l’escompte hyperbolique et le suivi de latence EWMA des relays a fait passer la complétude de 62-80 % à 72-96 % à la marque des 2 secondes sur six profils de test.

Le filtrage des relays morts via NIP-66 (Relay Monitoring) s’est avéré déterminant. Le pré-filtrage des candidats relays contre les données de disponibilité de nostr.watch a éliminé 40-64 % des relays morts et doublé les taux de succès des relays de 30 % à 75-85 %. Les temps de chargement de flux ont chuté de 39 % (de 40 secondes à 24 secondes sur 10 profils). Une simulation de course EOSE a montré qu’attendre EOSE plus une période de grâce de 200 ms améliorait la complétude par rapport à l’arrêt au premier relay ayant terminé.

Pour les clients ne pouvant pas entièrement réécrire leur routage de relays, une approche d’« enrichissement outbox hybride » ajoute des requêtes outbox par auteur en plus des relays d’application codés en dur existants. Cette approche hybride a atteint 80 % de rappel d’événements sur un an contre les 26 % de base, offrant un chemin de migration pour les clients avec des architectures de relays héritées.

ContextVM ouvre un NIP pour MCP et livre les Gift Wraps éphémères

ContextVM, le protocole faisant le pont entre Nostr et le Model Context Protocol, a ouvert deux propositions dans le dépôt NIPs cette semaine. PR #2246 formalise CVM comme une convention pour transporter les messages MCP JSON-RPC sur Nostr en utilisant des événements éphémères de kind 25910. PR #2245 étend NIP-59 (Gift Wrap) avec un kind éphémère (21059) qui suit la sémantique éphémère de NIP-01 (Basic Protocol Flow), permettant aux relays de supprimer les messages encapsulés après livraison.

La convention de gift wrap éphémère a été livrée sous forme de CEP-19 dans la famille de versions ContextVM SDK v0.6.x. L’implémentation du SDK ajoute une énumération GiftWrapMode avec trois paramètres : OPTIONAL (accepter les deux kinds et détecter automatiquement la capacité du pair), EPHEMERAL (kind 21059 uniquement) et PERSISTENT (kind 1059 uniquement). Pour les appels d’outils IA, le mode éphémère évite de stocker le trafic intermédiaire requête-réponse sur les relays, réduisant à la fois les coûts de stockage et l’exposition de la vie privée.

De nouveaux serveurs MCP publics sont apparus sur le réseau provenant d’opérateurs indépendants, notamment un serveur de requêtes Wolfram Alpha. L’équipe ContextVM a publié CEP-15 (schéma d’outils communs) et CEP-17 (publication de liste de relays serveur) aux côtés du cycle de versions v0.6.x.

Le Marmot Development Kit livre sa première version publique

MDK (Marmot Development Kit), la bibliothèque Rust alimentant la messagerie chiffrée par Marmot à travers Pika et White Noise, a livré v0.6.0 comme première version publique. Plus de 200 PRs ont été fusionnées dans cette version, avec six nouveaux contributeurs.

La version inclut le support de médias chiffrés (MIP-04) avec dérivation de graine HKDF (MIP-01 v2), la résolution déterministe des courses de commits (MIP-03), le stockage local chiffré, la validation d’autorisation administrateur pour les commits et propositions Marmot, et le support GREASE pour l’extensibilité du protocole. Les liaisons sont fournies pour Kotlin, Python, Ruby et Windows aux côtés de la compilation croisée Android. La bibliothèque passe à OpenMLS 0.8.0 avec des correctifs d’avis de sécurité et un type Secret<T> qui met à zéro les valeurs sensibles en mémoire.

Un changement de protocole compagnon (MIP-03) a remplacé le chiffrement NIP-44 (Encrypted Payloads) par ChaCha20-Poly1305 pour les messages de kind 445. NIP-44 exigeait une entrée de chaîne UTF-8 selon sa spécification, rendant impossible le passage de bytes bruts de messages Marmot à travers les bibliothèques Nostr TypeScript standard. Le remplacement dérive les clés directement du secret exporteur Marmot. Ce changement cassant a nécessité des mises à jour coordonnées à travers la spécification de base, MDK et le SDK TypeScript.

marmot-ts, l’implémentation TypeScript maintenue par hzrd149, a fusionné quatre PRs avec des changements cassants d’API. Une mise à jour omnibus a ajouté un gestionnaire de paquets de clés pour le cycle de vie créer/publier/rotation, une méthode de commodité sendChatMessage, l’aperçu d’invitation sans rejoindre (readInviteGroupInfo), l’auto-mise à jour pour les rotations de secret de transmission, et la journalisation de débogage structurée. Les APIs de déchiffrement de groupe ont été renommées de readGroupMessage à decryptGroupMessage avec des variantes de résultats plus riches (processed/skipped/rejected/unreadable). gzuuus a contribué au nettoyage des exemples avec le support de relays NIP-65 et la gestion de paquets de clés de dernier recours selon MIP-00.

Le White Noise CLI (wn), le backend Rust alimentant à la fois l’application mobile et le nouveau TUI, a fusionné 16 PRs en dix jours. La gestion du cycle de vie du signataire a gagné en sécurité d’annulation grâce à un gardien de portée RAII (PR #538), corrigeant une classe de bugs où les opérations avortées pouvaient laisser fuir l’état du signataire. La connexion bloque maintenant lorsque les listes de relays requises (kind 10002/10050/10051) sont manquantes (PR #515), et les abonnements giftwrap se rabattent sur les relays NIP-65 lorsque les listes inbox sont absentes (PR #518). Un mode de débogage (PR #528) expose les requêtes de base de données et l’inspection de l’arbre de cliquet MLS en sortie JSON. D’autres correctifs ont traité la récupération d’abonnements après ré-enregistrement du signataire, le timing de rattrapage des messages de bienvenue, la validation des filtres de relay et les limites de rayon de recherche d’utilisateurs.

Marmot a connu une expansion significative au-delà de la pile Rust principale cette semaine. White Noise TUI, une interface en terminal pour la pile de messagerie White Noise, a été lancé le 3 mars. Il encapsule le CLI wn comme sous-processus et rend sa sortie JSON via une architecture unidirectionnelle inspirée d’Elm, fournissant la navigation multi-conversations avec indicateurs de non-lu, la création de groupes et la recherche de membres, le streaming de messages en temps réel et les réactions emoji depuis le terminal.

DavidGershony a publié une pile C# Marmot complète reflétant l’architecture en couches de la chaîne d’outils Rust. dotnet-mls implémente les primitives cryptographiques MLS RFC 9420 en C#. marmot-cs s’appuie dessus pour ajouter le transport par relays Nostr, fonctionnant comme un équivalent C# de MDK. OpenChat, une application desktop multiplateforme construite avec .NET 9 et Avalonia UI, lie les deux en un client de chat fonctionnel avec DMs NIP-44, chiffrement de groupe Marmot, signature à distance NIP-46 (Nostr Connect) et indicateurs de statut multi-relays.

MDK PWA Reference fournit un modèle Progressive Web App pour construire des applications chiffrées par Marmot, avec un support expérimental pour la participation d’agents IA dans les chats de groupe et les paiements Bitcoin via l’infrastructure de portefeuille Arkade.

Wisp passe de l’alpha à la bêta

Wisp est un nouveau client Nostr Android qui est passé de la première alpha le 24 février à v0.3.4-beta le 3 mars, produisant 19 versions, 115 PRs fusionnées et 276 commits en huit jours.

La trajectoire des fonctionnalités couvre un terrain que la plupart des clients mettent des mois à atteindre. v0.1.0 a été livré avec le support du modèle de relays outbox/inbox et des flux d’intégration. Dès v0.1.3, le client disposait de la signature basée sur les intents NIP-55 pour Amber, d’un proxy Tor SOCKS5 intégré pour la connectivité aux relays .onion, et de NIP-47 (Nostr Wallet Connect). v0.2.0 a été promu en bêta avec le filtrage par liste de silence et le support d’emoji personnalisés, tandis que v0.2.4 a ajouté les superpositions d’avertissement de contenu. La série v0.3.x a introduit la preuve de travail NIP-13 pour les notes, le minage PoW en arrière-plan avec paramètres persistants, le stockage de relays .onion et les notifications de fils silenciés.

La traduction sur appareil via Google ML Kit fonctionne localement sans accès réseau après le téléchargement initial du modèle. Une visualisation interactive du graphe social utilise une simulation physique velocity Verlet à environ 30 fps avec navigation par pincement pour zoomer et inspection de profil.

Versions

Vector v0.3.1

Vector, l’application de messagerie chiffrée par Marmot, a livré v0.3.1 avec des améliorations de gestion de groupes et un travail sur les performances. Les groupes multi-administrateurs, les invitations en masse, l’invitation par npub et les avatars de groupe étendent les fonctionnalités de collaboration. Les notifications en arrière-plan Android supportent maintenant les actions Répondre et Marquer comme lu en ligne.

La synchronisation déterministe basée sur Negentropy récupère l’historique complet des conversations, y compris les messages manqués pendant les périodes hors ligne. La voix-vers-texte a été reconstruite avec accélération GPU sur Android. La gestion des pièces jointes a été remaniée avec progression du téléchargement, états de réessai, compression et envoi de répertoire, et indicateurs de progression en direct partout. Les performances se sont améliorées de plus de 15x sur le temps de démarrage, le traitement d’images, la lecture audio et la réactivité générale de l’UI. La taille d’installation de l’application a diminué de plus d’un tiers, avec le frontend réduit d’environ la moitié. Le support Android ARM 32 bits a été ajouté.

Alby Hub v1.21.5

Alby Hub, le nœud Lightning auto-hébergé avec support Nostr Wallet Connect (NIP-47), a livré v1.21.5. Un second relay a été ajouté à la configuration NWC par défaut, améliorant la fiabilité lors des redémarrages de relays. Un correctif pour les données de zap invalides dans la liste de transactions résout un problème d’affichage avec les événements NIP-57 (Lightning Zaps) malformés. Les nouvelles entrées du magasin d’applications incluent Alby CLI et LNVPS.

nospeak v0.12.x

nospeak, le client de messagerie Nostr basé sur le texte, a livré trois versions sur la période. v0.12.0 a ajouté un verrou d’application par PIN avec clavier à 4 chiffres et plus de 15 nouvelles traductions linguistiques incluant le bengali, le thaï, le vietnamien, l’hindi, l’arabe, l’hébreu, l’ourdou, le turc, le japonais, le chinois, le coréen, le néerlandais, le polonais, le russe et le persan avec support RTL. v0.12.1 a introduit un thème Cypher avec fonds noir pur et accents cyan, plus la génération de poster vidéo Android. v0.12.2 a ajouté l’export de chat et Voir le profil dans les menus de contacts.

Citrine v2.0.0-pre2

Citrine, le relay personnel Android de greenart7c3, a livré v2.0.0-pre2 avec des améliorations de performance du relay grâce à de nouveaux index de base de données et des coroutines Kotlin restructurées. Chaque application web hébergée démarre maintenant sur son propre port. La recherche plein texte et un écran d’événements repensé avec expansion des événements complètent les changements.

NoorNote v0.5.x

NoorNote, une application de prise de notes basée sur Nostr, a livré 8 versions de v0.5.0 à v0.5.7. Le lancement v0.5.0 sur Android a ajouté le support du signataire Amber NIP-55 et la publication de notes NIP-71 (Video Events). Une page d’accueil redessinée en v0.5.1 incluait des aperçus de la timeline publique et a réduit l’APK à 15 Mo. Le Relay Browser en v0.5.2 permet aux utilisateurs de parcourir les timelines publiques des relays via des URLs partageables, aux côtés du téléchargement de médias et des réactions emoji personnalisées NIP-30. Les versions suivantes jusqu’à v0.5.7 ont traité les conditions de course de synchronisation dans le système collaboratif de partage de notes « tribes ».

NosCall v0.5.1

NosCall, l’application d’appels vocaux et vidéo Nostr, a livré v0.5.1 avec le support des messages vocaux, une expérience desktop optimisée avec entrée de groupe, les favoris de contacts sur desktop, les notes et filtrage de contacts, les options d’export et de nettoyage de données, et le support d’accessibilité des tailles de police système.

Shosho v0.13.0

Shosho, l’application de streaming en direct Nostr, a livré v0.13.0 avec les téléchargements de replays MP4 depuis les menus de cartes de stream et NIP-05 (DNS-Based Verification) pour les profils. L’éditeur RTMP a migré vers l’API Expo Modules. Les performances de streaming sur les connexions à faible bande passante se sont améliorées, et les crashs sur les anciens appareils et le streaming iOS vers Zap.Stream sont corrigés.

nostr-java v2.0.0

nostr-java a livré v2.0.0 avec des tailles de tampon WebSocket configurables, permettant aux applications de gérer des événements Nostr plus volumineux sans troncature. Le changement de version majeure reflète des changements cassants de l’API de connexion.

Prism 1.1.0

Prism a livré 1.1.0 avec le support de contenu long format (articles kind 30023) et un éditeur Markdown pour composer directement dans l’application, suivi d’une version de correction de bugs 1.1.1.

Angor v0.2.6

Angor, la plateforme de financement participatif Bitcoin, a livré v0.2.6 avec l’intégration Boltz et un flux d’investissement en 1 clic. Les types d’investissement et de financement de projet fonctionnent tous deux de bout en bout sur testnet. L’équipe note que l’UI est complète à environ 70 %.

Mises à jour des NIP

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

Fusionnés :

NIP-91 : Opérateur AND pour les filtres : Ajoute la sémantique de filtre AND pour les tableaux de tags dans les abonnements aux relays. Actuellement, spécifier plusieurs valeurs dans un filtre de tag (par exemple, plusieurs tags p) correspond aux événements contenant l’une d’entre elles. NIP-91 permet aux clients d’exiger que les événements correspondent simultanément à toutes les valeurs de tags spécifiées, réduisant la bande passante et permettant des opérations d’index plus rapides. Plusieurs implémentations de relays existent déjà, dont nostr-rs-relay, satellite-node, worker-relay et applesauce. Anciennement numéroté NIP-119.
NIP-30 : Adresse d’ensemble d’emoji dans les tags : Les tags d’emoji personnalisés dans NIP-30 peuvent maintenant inclure une adresse optionnelle d’ensemble d’emoji. Cliquer sur un emoji dans un client peut ouvrir l’ensemble auquel il appartient pour la mise en signet ou la navigation. Originaire du client Chachi.
NIP-29 : Ajout de unallowpubkey et unbanpubkey : Deux nouvelles commandes administrateur pour le chat de groupe NIP-29. unallowpubkey retire une pubkey de la liste autorisée sans la bannir. unbanpubkey lève un bannissement sans ré-ajouter la pubkey à la liste des membres. Auparavant, le seul moyen de retirer quelqu’un de la liste autorisée le bannissait également, et débannir nécessitait de ré-ajouter l’utilisateur comme membre.

PRs ouvertes et discussions :

NIP-A7 : Spells (ouvert le 27 février) : Proposés par purrgrammer, les spells sont des requêtes Nostr sauvegardées portables publiées comme événements de kind 777. Un spell encode un filtre REQ ou COUNT dans des tags structurés (k pour les kinds, authors pour les pubkeys, tag pour les filtres de tags arbitraires) avec des variables d’exécution : $me se résout en la pubkey de l’utilisateur connecté, $contacts s’étend à la liste d’abonnements kind 3 de l’utilisateur. Les horodatages relatifs (7d, 2w, 1mo) permettent aux spells de définir des fenêtres temporelles glissantes sans dates codées en dur. Déjà implémenté dans nak et Grimoire, les spells permettent aux utilisateurs de créer, partager et s’abonner à des flux curatés qui voyagent entre les clients.
NIP-59 : Gift Wrap éphémère (kind 21059) (ouvert le 27 février) : Ajoute une variante éphémère des gift wraps NIP-59. Le kind 21059 suit la sémantique éphémère NIP-01, de sorte que les relays suppriment les événements après livraison. Proposé par ContextVM pour le transport MCP où la persistance des messages n’est pas nécessaire.
ContextVM : MCP JSON-RPC sur Nostr (ouvert le 27 février) : Spécifie comment transporter les messages Model Context Protocol sur Nostr en utilisant des événements éphémères de kind 25910 avec des tags p et e pour l’adressage et la corrélation. Intentionnellement minimaliste, déférant les détails du protocole à la spécification ContextVM.
NIP-29 : Espaces audio/vidéo en direct (ouvert le 25 février, brouillon) : Brouillon de fiatjaf étendant les groupes NIP-29 avec l’audio et la vidéo en direct. La proposition ajoute des tags optionnels livekit et no-text aux événements de métadonnées de groupe. Lorsqu’un utilisateur veut rejoindre un espace vocal, le client demande un JWT au relay à /.well-known/nip29/livekit/{groupId}. Le relay vérifie l’appartenance au groupe et émet un jeton avec la pubkey hex de l’utilisateur comme claim sub, qui est transmis à LiveKit pour le transport média. L’accès au salon vocal hérite du modèle de permissions existant du groupe, de sorte que les règles d’appartenance côté relay régissent qui peut parler. En cours de test dans Pyramid et Chachi.
Propriété collaborative d’événements (ouvert le 24 février) : pablof7z propose un événement pointeur (kind 39382) qui déclare un espace collaboratif en listant les pubkeys des copropriétaires dans les tags p et un kind d’événement cible dans un tag k. Tout propriétaire listé peut publier des événements de ce kind avec le même tag d, et les clients résolvent l’état actuel en interrogeant tous les propriétaires et en prenant l’événement le plus récent. L’attribution de co-auteur ne s’affiche que lorsqu’un tag a vérifiable référence le pointeur et que l’auteur apparaît dans ses tags p, empêchant les revendications usurpées. Cela permet des pages wiki partagées et des ressources co-écrites sans attribuer le contrôle à une seule paire de clés.
NIP-09 : Suppression en cascade des reposts (ouvert le 24 février) : Lorsqu’un auteur original supprime une note, les relays devraient également supprimer tout repost de kind 6 ou kind 16 le référençant. Motivé par des préoccupations de vie privée : les reposts peuvent préserver des informations accidentellement divulguées après que l’auteur supprime la source. Le changement est uniquement côté relay, ne nécessitant aucune modification des clients.
NIP-07 : peekPublicKey (ouvert le 23 février) : Ajoute une méthode peekPublicKey() aux extensions de navigateur NIP-07. Contrairement à getPublicKey(), elle retourne la pubkey actuelle sans demander la confirmation de l’utilisateur, permettant la connexion automatique silencieuse lorsque l’utilisateur a activé la connexion automatique.
NIP-BB : Book (ouvert le 28 février, brouillon) : Définit quatre kinds d’événements adressables (30300-30303) pour la publication structurée de livres sur Nostr. Un événement Cover contient les métadonnées racines incluant le titre, l’image de couverture, la licence via les labels NIP-32 (Labeling) et le code de langue. Un événement Index associe chaque chapitre à sa position en utilisant l’indexation fractionnelle base62, permettant aux auteurs d’insérer de nouveaux chapitres entre les existants sans renumérotation. Les événements Chapter agissent comme des en-têtes structurels avec des images optionnelles, tandis que les événements Episode portent la prose elle-même plafonnée à 30 000 caractères avec des tags d’images positionnés. Les critiques utilisent les Zaps sur les événements Cover avec la description du Zap comme texte de critique.
NIP-54 : Passage d’Asciidoc à Djot (ouvert le 26 février) : Suite au correctif d’internationalisation du d-tag en décembre, cette PR propose de remplacer le format de balisage Asciidoc du wiki NIP-54 par Djot, ajoutant une section de justification et des exemples de wikilinks pour les scripts non latins.
NIP-66 : Mesures défensives (ouvert le 26 février) : Basé sur les enseignements des benchmarks nostrability/outbox, ajoute des avertissements explicites pour les cas limites de NIP-66. Une PR #2241 compagnon définit des tags de sortie pour SSL, géolocalisation, réseau et vérifications de connectivité.
NIP-C1 : Preuves d’identité cryptographiques (entrée wiki, kind 30817) : Propose des événements de kind 30509 qui lient cryptographiquement les certificats de signature APK aux profils Nostr. La preuve fonctionne en signant un message canonique contenant la pubkey Nostr avec la clé privée du certificat (supportant ECDSA, RSA PKCS1v15, Ed25519 et d’autres algorithmes standard), puis en publiant la signature dans un événement de kind 30509 signé avec la clé Nostr. Les vérificateurs peuvent confirmer que la personne contrôlant le certificat de signature d’une application Android contrôle aussi la pubkey Nostr revendiquant sa publication. Les preuves expirent après un an par défaut et peuvent être explicitement révoquées. Implémenté dans la chaîne d’outils Zapstore.
NIP-31402 : Registre SARA Revenue Share Offering (entrée wiki, kind 30817) : Définit des événements adressables de kind 31402 pour publier des offres Simple Autonomous Revenue Agreement (SARA) sur les relays Nostr. Les émetteurs annoncent des conditions de partage de revenus réglées par Lightning incluant le pourcentage de part de pool, le déclencheur de paiement, le seuil en sats, la durée du terme et la tarification par paliers. Les agents et les humains peuvent découvrir les offres à travers les relays et s’abonner de manière autonome sans plateforme centrale. Le numéro de kind reflète le kind 30402 (L402 Service Registry, publié par le même auteur comme entrée wiki compagnon) puisque SARA représente le volet retour de la relation de paiement L402.

PRs ouvertes et mises à jour de projets

Damus : NIP-89 (Recommended Application Handlers)

PR #3337 implémente le support du tag client NIP-89 pour Damus. L’application émet maintenant un tag client sur tous les chemins de publication (application principale, extension de partage, surligneur, brouillons) et affiche « via ClientName » à côté des horodatages lorsque d’autres applications incluent leurs tags. Un bouton Confidentialité dans les paramètres d’Apparence permet aux utilisateurs de désactiver l’émission du tag. PR #3652 ajoute une section Stockage dans les Paramètres avec un graphique circulaire interactif détaillant l’utilisation disque du cache NostrDB et Kingfisher avec support d’export.

Ouverte : PR #3657 ajoute le repli de relay NIP-65 pour les notes citées. Lorsqu’un nevent en ligne inclut une pubkey d’auteur mais pas d’indices de relay et que la note est absente du pool de l’utilisateur, Damus récupère la liste de relays kind 10002 de l’auteur et réessaie depuis ses relays d’écriture.

Amethyst : NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst a fusionné une vague d’implémentations NIP à travers 28 PRs. Les revendications d’identité externe se publient maintenant comme événements dédiés de kind 10011 sous NIP-39 (PR #1747), séparant l’identité sociale des métadonnées kind 0 avec repli rétrocompatible. Le support de fragments de code via NIP-C0 (PR #1744) ajoute des événements de kind 1337 avec des accesseurs pour le langage, l’extension, l’environnement d’exécution, la licence et les dépendances. L’implémentation de monitoring de relays NIP-66 (PR #1742) couvre les deux kinds d’événements avec analyse complète des tags pour les métriques RTT, le type de réseau, les NIPs supportés et le geohash.

Les DMs chiffrés sont arrivés sur Amethyst Desktop (PR #1710) avec une disposition de chat en panneau divisé supportant à la fois NIP-04 (Encrypted Direct Messages) et NIP-17 (Private Direct Messages). Un nouvel écran de flux de relay (PR #1733) permet aux utilisateurs de parcourir les publications d’un relay spécifique avec fonctionnalité d’abonnement/désabonnement. Ouverte : la vérification NIP-05 résistante à la censure (PR #1734) ajoute un chemin de vérification parallèle pour les identifiants .bit qui se résout contre la blockchain Namecoin au lieu du HTTP DNS. Lorsqu’Amethyst détecte un suffixe .bit dans un champ NIP-05, il interroge un serveur ElectrumX-NMC pour l’historique des transactions du nom, analyse le script NAME_UPDATE depuis la dernière sortie pour extraire la pubkey Nostr, et rejette les noms plus anciens que 36 000 blocs (fenêtre d’expiration de Namecoin). Les connexions ElectrumX passent par SOCKS5 lorsque Tor est activé, avec sélection dynamique de serveurs entre les points de terminaison clearnet et .onion. Un cache LRU avec un TTL d’une heure empêche les requêtes blockchain répétées.

Notedeck : architecture outbox

PR #1303 migre Notedeck de la gestion ad-hoc de pool de relays vers un modèle outbox centralisé avec abonnements scopés par compte. Le module Messages publie maintenant une liste de relays DM par défaut si aucune n’existe et route les DMs vers les relays préférés des destinataires selon le kind 10050.

Pika : profils par groupe et flux de tutoriels

Pika, l’application de messagerie chiffrée par Marmot disponible sur iOS et Android avec une version desktop, a gagné les profils par groupe (PR #368). Les utilisateurs peuvent maintenant définir un nom d’affichage et une photo distincts pour chaque chat de groupe, ainsi qu’une biographie personnalisée. Ces profils se publient comme événements kind 0 chiffrés à l’intérieur du groupe Marmot, invisibles pour quiconque en dehors, avec repli sur le profil Nostr global de l’utilisateur lorsqu’aucun profil spécifique au groupe n’est défini. Lorsque de nouveaux membres rejoignent, l’administrateur rediffuse tous les profils de groupe stockés et chaque membre republie le sien lors du commit. Les photos de profil sont chiffrées en média Marmot avant le téléversement Blossom. La PR inclut 16 nouveaux tests unitaires et expose la fonctionnalité à la fois via une commande CLI (update-group-profile) et l’UI.

Une nouvelle application web pika-news (PR #401) surveille les PRs GitHub de Pika et génère automatiquement des guides tutoriels pas à pas à partir des diffs de PR, les publiant comme pages rendues côté serveur avec authentification NIP-07. Les utilisateurs peuvent discuter de tutoriels spécifiques en temps réel via un chat authentifié par Nostr.

diVine : widgets intégrables et réponses vidéo

diVine, la plateforme de partage vidéo native Nostr, a fusionné 132 PRs en dix jours. Les widgets iframe intégrables (PR #1843) fournissent une page /embed?npub=... autonome qui affiche le profil d’un utilisateur et ses dernières vidéos. La fonctionnalité de réponse vidéo (PR #1915), contrôlée par un flag de fonctionnalité, utilise les commentaires Kind 1111 (NIP-22) avec les métadonnées imeta NIP-92 (Media Attachments). Les filtres de contenu à trois voies inspirés de Bluesky (PR #1797) offrent des contrôles Afficher/Avertir/Masquer sur 17 catégories d’avertissement de contenu NIP-32.

strfry : validation des filtres REQ

PR #163 ajoute la validation configurable des filtres REQ à strfry, le relay Nostr C++. Les opérateurs peuvent définir le nombre maximum de filtres par REQ, la présence requise d’auteurs ou de tags, les listes blanches de kinds autorisés et les limites de kinds par filtre. La fonctionnalité cible les déploiements de relays NWC nécessitant une application stricte des filtres. Ouverte : PR #173 ajoute la compression optionnelle zstd pour les charges utiles d’événements au moment de l’ingestion.

rust-nostr : NIP-62 Request to Vanish

rust-nostr, la bibliothèque Rust du protocole Nostr, a ajouté le support NIP-62 (Request to Vanish) sur les trois backends de base de données : LMDB, SQLite et en mémoire. L’implémentation LMDB inclut des options configurables pour activer ou désactiver l’application de NIP-09 et NIP-62 par déploiement.

NDK : événements collaboratifs et timeout NIP-46

NDK, le Nostr Development Kit pour JavaScript/TypeScript, a fusionné PR #380 introduisant NDKCollaborativeEvent pour les documents collaboratifs multi-auteurs utilisant un événement pointeur adressable (kind 39382) qui définit les auteurs autorisés. Un timeout configurable pour NDKNip46Signer (PR #381) empêche les opérations de signature à distance NIP-46 de rester bloquées indéfiniment lorsqu’un bunker ne répond pas.

TENEX : catégorisation d’agents et filtrage par pubkey

TENEX, la plateforme d’orchestration d’agents IA native Nostr, a fusionné deux PRs liées à la sécurité. La catégorisation d’agents basée sur les rôles TIP-01 (PR #91) associe les catégories d’agents (principal, orchestrateur, travailleur, conseiller, auditeur) à des restrictions d’outils automatisées via une carte d’outils refusés. Le filtrage de pubkey en porte d’entrée (PR #87) garantit que seuls les événements provenant de pubkeys sur liste blanche ou signés par le backend sont routés aux côtés des agents connus ; les pubkeys inconnues sont silencieusement rejetées avec des spans OpenTelemetry pour l’audit.

Zap Cooking : tableau de bord d’adhésion

Zap Cooking, la plateforme de partage de recettes basée sur Nostr, a fusionné 25 PRs et 85 commits en dix jours. Un tableau de bord d’adhésion (PR #228) affiche le statut d’abonnement avec dates d’expiration et options de gestion/mise à niveau, réactive les portes de fonctionnalités pour les paliers Sous Chef et Zappy avec vérifications côté client et côté serveur, et standardise le nommage des paliers à travers 26 fichiers. Le chargement de messages de groupe en deux phases (PR #227) fournit une récupération initiale rapide de 3 jours pour un affichage instantané suivie d’un remplissage en arrière-plan de 40 jours.

Le stockage de mnémonique de portefeuille est passé du chiffrement dérivé de la pubkey au chiffrement NIP-44 vers soi-même (PR #224), corrigeant une vulnérabilité où l’ancien schéma dérivait sa clé de SHA-256(pubkey), ce qui est effectivement non chiffré puisque les pubkeys sont publiques. Les portefeuilles existants sont silencieusement migrés au premier chargement. Le chat de groupe NIP-29 a gagné des indicateurs de non-lu avec badges à point rouge et accès sur invitation uniquement avec codes d’invitation kind 9009 (PR #213). Les aperçus de liens et les intégrations d’événements Nostr s’affichent maintenant dans les DMs et les messages de groupe (PR #218). Une section de sauvegarde Nostr dans les Paramètres (PR #210) stocke les abonnements et les listes de silence via le stockage chiffré NIP-78 (Application-specific Data) avec versionnage rotatif à 3 emplacements. Les performances au démarrage se sont améliorées grâce aux services de notification différés, au rendu DOM paresseux via IntersectionObserver (réduisant les nœuds DOM d’environ 15 000 à environ 3 000 sur un flux de 200 événements) et aux TTL de cache outbox étendus (PR #208). Un modal d’impression de recette personnalisable (PR #205) permet aux utilisateurs de basculer les sections à inclure avec un aperçu en direct. L’intégration du Branta SDK (PR #222) ajoute des garde-fous de vérification pour les requêtes POST et GET.

Keep : migration d’état pilotée par Rust

Keep, le gestionnaire de clés privées basé sur Nostr pour Android, a fusionné PR #178, supprimant quatre magasins de configuration Kotlin en faveur de l’état partagé piloté par Rust depuis la couche keep-mobile. Une boucle de polling de 10 secondes a été remplacée par un KeepStateCallback push depuis Rust. PR #179 ajoute la sauvegarde et la restauration chiffrées avec protection par phrase de passe.

Mostro Mobile : chiffrement du chat de litige

Mostro Mobile, le client mobile pour la plateforme de trading Bitcoin P2P Mostro, a livré une migration en deux phases du chiffrement du chat de litige. La première étape (PR #495) passe de l’encapsulation spécifique à mostro au chiffrement à clé partagée dérivée de la pubkey de l’administrateur. S’appuyant sur cela, PR #501 unifie le modèle de messages avec NostrEvent et stocke les événements gift wrap chiffrés sur disque, cohérent avec le modèle de chat pair-à-pair. Un correctif de signature BIP-340 (PR #496) surcharge la dépendance bip340 en 0.2.0, résolvant un bug de rembourrage bigToBytes() qui causait 1-2 % de signatures Schnorr invalides et 100 % d’échecs pour les clés dont la clé publique commence par 0x00. Les Détails de commande affichent maintenant des libellés de statut lisibles au lieu de valeurs brutes du protocole, localisés en anglais, espagnol, italien et français (PR #502). HalCash a été ajouté et SEPA retiré comme méthode de paiement (PR #493), puisque les transferts SEPA peuvent dépasser 24 heures (SEPA Instant reste).

Côté serveur, Mostro a corrigé la restauration de session de litige pour inclure le champ initiateur (PR #599) et ferme maintenant automatiquement les litiges actifs lorsqu’un vendeur libère les fonds, publiant un événement Nostr de règlement pour que les clients administrateurs voient la résolution (PR #606).

Cinq ans de févriers Nostr

La newsletter du mois dernier a retracé les jalons de janvier de Nostr depuis les premiers développements jusqu’à l’explosion de Damus, puis l’infrastructure de sécurité en 2026. Cette rétrospective couvre ce qui s’est passé chaque février de 2021 à 2026.

Février 2021 : la réécriture

Trois mois après sa création, le février de Nostr a produit le changement précoce le plus déterminant du protocole. Les 14 et 15 février, fiatjaf a réécrit NIP-01, remplaçant le format de message original par le modèle EVENT/REQ/CLOSE que le protocole utilise encore. Avant cette réécriture, les clients et relays communiquaient via une structure plus simple. La séparation de la publication d’événements (EVENT) de la gestion des abonnements (REQ/CLOSE) a permis le filtrage côté relay qui allait s’avérer essentiel pour le passage à l’échelle.

NIP-04 est arrivé le même mois, ajoutant les messages directs chiffrés utilisant des secrets partagés dérivés de l’échange de clés Diffie-Hellman sur secp256k1. Son chiffrement était basique (AES-256-CBC) et serait plus tard remplacé par la cryptographie auditée de NIP-44, mais il a donné à la poignée d’utilisateurs précoces leur premier canal de communication privée sur le protocole.

L’outillage s’est élargi avec noscl, un client en ligne de commande Go pour l’interaction avec les relays depuis le terminal, et futurepaul a démarré nostr-rs, une implémentation Rust précoce. Le réseau entier fonctionnait sur deux ou trois relays, coordonné via un groupe Telegram, avec environ sept contributeurs actifs.

Février 2022 : une dynamique croissante

Le post Hacker News du 31 décembre 2021 a continué d’attirer des développeurs en février. Le dépôt nostr-protocol/nostr (le dépôt NIPs formel n’existerait pas avant mai 2022) a reçu six pull requests en février, incluant NIP-13 (Proof of Work) de vinliao, NIP-14 (Reputation) de fiatjaf, NIP-15 (Resource Relations) de Cameri et NIP-17 (Git Updates Over Nostr) de melvincarvalho. Le numéro NIP a été ensuite réattribué à Private Direct Messages ; la collaboration git sur Nostr a continué séparément via ce qui est devenu gitworkshop.dev.

Le nostr-rs-relay de Greg Heartsfield a été le cheval de bataille du mois avec 34 commits et trois versions. La version 0.5.0 du 12 février a ajouté les limites de publication pour les utilisateurs vérifiés NIP-05. Les versions 0.5.1 et 0.5.2 ont suivi au cours des deux semaines suivantes, et le relay gérait la majeure partie du trafic du réseau à lui seul.

Robert C. Martin (Uncle Bob) construisait more-speech, un client desktop Clojure, enregistrant 69 commits entre le 18 janvier et la fin février. Son implication a attiré l’attention de la communauté élargie du génie logiciel. L’extension de navigateur nos2x de fiatjaf a livré le support de déchiffrement NIP-04 et les politiques de préférence de relay en février, implémentant l’interface window.nostr (NIP-07) que les clients web utilisent encore pour la délégation de clés.

Branle, encore le client web principal, a gagné l’enregistrement de gestionnaire de protocole web+nostr le 13 février, une tentative précoce de liens profonds entre applications Nostr. nostr-tools a renforcé la validation NIP-05. go-nostr a ajouté le support des DMs chiffrés NIP-04 et l’analyse NIP-12 (Generic Tag Queries) à travers 11 commits. Le réseau fonctionnait sur environ 7-15 relays avec une base d’utilisateurs actifs probablement dans les quelques centaines. Damus et Nostream n’existaient pas encore et n’apparaîtraient pas avant avril 2022.

Février 2023 : l’attention internationale

Février 2023 a apporté à Nostr sa plus grande vague d’attention publique. Damus, le client iOS de William Casarin, avait été approuvé sur l’App Store d’Apple le 31 janvier après des rejets répétés. Le 1er février, il a atteint le top 10 aux États-Unis dans la catégorie Réseaux sociaux. Deux jours plus tard, le 2 février, Apple a retiré Damus de l’App Store chinois apparemment à la demande de l’Administration du cyberespace de Chine.

Les grands médias incluant TechCrunch et CoinDesk ont couvert le retrait, amplifiant la notoriété de l’application et du protocole. Les clés publiques uniques avec métadonnées sur nostr.directory ont dépassé 300 000 le 3 février. Tous les relays étaient opérés par des passionnés payant de leur poche, et l’infrastructure s’est empressée de gérer la charge. Environ 289 relays étaient suivis début février, un nombre qui a continué de grimper.

Le dépôt NIPs a enregistré 29 pull requests fusionnées ce mois-là, le plus haut total mensuel de l’histoire du protocole à ce moment. NIP-57 (Lightning Zaps) et NIP-23 (Long-form Content) ont tous deux été fusionnés le 13 février, ajoutant les micropaiements Bitcoin et étendant Nostr au-delà des publications courtes en une seule journée. NIP-65 (Relay List Metadata) avait été fusionné une semaine plus tôt le 7 février, permettant le modèle outbox qui a suivi. NIP-46 (Nostr Connect) et NIP-58 (Badges) ont également été intégrés avant la fin du mois.

La Human Rights Foundation a accordé 50 000 $ à William Casarin pour le développement de Nostr et Damus le 21 février, l’une des premières subventions institutionnelles à un projet Nostr. OpenSats n’avait pas encore lancé son fonds Nostr (cela viendrait en juillet 2023).

Février 2024 : la durabilité du protocole

Février 2024 a déplacé l’attention de la croissance vers la durabilité du protocole. NIP-17 (Private Direct Messages), ouvert depuis le mois de juillet précédent, travaillait vers un remplacement du vieillissant chiffrement NIP-04 en utilisant la cryptographie auditée de NIP-44 et l’encapsulation gift wrap de NIP-59. NIP-04 fuyait les métadonnées vers les opérateurs de relays, qui pouvaient voir les paires expéditeur-destinataire. NIP-17 masque l’identité de l’expéditeur derrière des paires de clés jetables et a été fusionné au printemps après un dernier tour de revue en mars.

NIP-29 (Simple Groups) a été fusionné le 28 février après des mois de discussion, définissant comment les relays peuvent héberger des chats de groupe modérés avec rôles d’administrateur et contrôle d’accès. NIP-92 (tags imeta) a été fusionné le 1er février, standardisant comment les clients attachent les dimensions d’image et les aperçus blurhash aux événements médias.

Le 16 février, le dépôt NIPs a ajouté BREAKING.md, un fichier suivant les changements rétro-incompatibles de la spécification du protocole. Sa création a reconnu que Nostr avait atteint un niveau de maturité où les changements cassants nécessitaient une documentation formelle.

Vingt-deux pull requests ont été fusionnées ce mois-là. npub.cash a été lancé comme service d’adresse Lightning permettant à n’importe quelle npub de recevoir des paiements sans faire tourner un serveur. Un article académique publié le 8 février a constaté que 95 % des relays gratuits ne pouvaient pas couvrir les coûts opérationnels par les dons, avec 35 % des relays payants facturant des frais d’admission inférieurs à 1 000 sats (environ 0,45 $ à l’époque).

Février 2025 : la croissance de l’infrastructure

Février 2025 a produit 28 pull requests fusionnées dans le dépôt NIPs. Un NIP Right to Vanish a été fusionné le 19 février, définissant comment les utilisateurs peuvent demander la suppression de leurs données aux relays en réponse aux questions réglementaires sur la portabilité des données et le contrôle utilisateur.

NIP-60 (Cashu Wallet) et NIP-61 (Nutzaps) ont reçu des mises à jour de simplification, rationalisant le format de stockage de jetons ecash. Un déploiement de q-tag (quote tag) s’est poursuivi à travers plusieurs NIPs, standardisant comment les événements référencent d’autres événements pour la citation et le threading.

Les versions de clients ont marqué une progression régulière. Notedeck v0.3.0 alpha a été livré le dernier jour de janvier, avec une adoption se poursuivant en février. Primal v2.1 a suivi le 7 février, et GRAIN v0.3.0, une implémentation de relay en Go, est sorti le 21 février.

NOSTRLDN v5 a réuni la communauté Nostr londonienne pour son cinquième meetup. Un pont DVMCP a connecté les Data Vending Machines de Nostr (NIP-90) au Model Context Protocol, préfigurant le travail d’intégration d’agents IA arrivé le mois suivant.

Février 2026 : au-delà des réseaux sociaux

L’activité de février 2026 est tirée des numéros de Nostr Compass #8 à #11.

Février 2026 a produit la gamme la plus large de développement de couche applicative en un seul mois Nostr. Mostro a livré sa première bêta publique pour le trading Bitcoin pair-à-pair décentralisé, et Zapstore a atteint la version 1.0 stable après des mois en release candidate. White Noise v0.3.0 a livré la messagerie en temps réel chiffrée par Marmot avec le support du signataire Amber et plus de 160 améliorations fusionnées.

Des propositions concurrentes d’agents IA de pablof7z (NIP-AE pour les flux de travail d’agents, NIP-AD pour les annonces de serveurs MCP) et joelklabo (AI Agent Messages) sont arrivées aux côtés d’une proposition de coordination d’agents DVM étendant NIP-90. ContextVM a livré des améliorations du SDK connectant le Model Context Protocol au transport Nostr. Burrow a ajouté la messagerie chiffrée par Marmot pour les agents IA et les humains, étendant l’infrastructure d’identité et de relays de Nostr à la communication machine-à-machine.

FIPS a livré une implémentation Rust fonctionnelle du réseau maillé natif Nostr, utilisant les paires de clés secp256k1 comme identités de nœuds avec un routage agnostique au transport sur UDP, Ethernet, Bluetooth ou radio LoRa. Sa conception a montré que le modèle de clés de Nostr s’étend au-delà des réseaux sociaux vers l’infrastructure de réseau physique.

OpenSats a annoncé sa quinzième vague de subventions Nostr, finançant des projets incluant ContextVM et Nostube. Les changements de protocole incluaient le support des factures en attente NIP-47 pour Nostr Wallet Connect et le HyperLogLog NIP-45 (Counting Results) pour l’estimation de comptage côté relay. La découvrabilité de fournisseurs de services NIP-85 (Trusted Assertions) pour le scoring de Web of Trust a également été fusionnée. rust-nostr a commencé une refonte complète de l’API tandis que Nostria 3.0 et Frostr (iOS TestFlight) ont tous deux été livrés. La couche de cache local de Blossom a traité la disponibilité des médias à travers les relays.

Perspectives

Cinq févriers d’histoire du protocole montrent une progression constante du travail fondamental vers la diversification de la couche applicative, avec l’afflux d’utilisateurs de 2023 comme point de bascule. En 2021, sept contributeurs travaillaient sur trois relays. En 2026, le même protocole supportait le réseau maillé et des propositions d’agents autonomes fonctionnant sur une infrastructure de production.

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

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : White Noise v0.3.0 apporte la messagerie en temps réel et le support du signataire Amber avec plus de 160 améliorations fusionnées. diVine 1.0.5 corrige les problèmes de lecture vidéo et ajoute des événements de visionnage Kind 22236 pour les analyses des créateurs. Pika, Ridestr et Unfiltered livrent des mises à jour. FIPS livre une implémentation Rust fonctionnelle du réseau maillé natif Nostr. Notecrumbs reçoit des correctifs de stabilité pour les aperçus de liens damus.io. ContextVM fait le pont entre Nostr et le Model Context Protocol. Parmi les nouveaux projets : Burrow pour la messagerie chiffrée MLS entre agents IA et humains, et Nostria Signer pour le coffre-fort et la gestion d’identité dans le navigateur. Les approfondissements portent sur la signature Android NIP-55 et la synchronisation de portefeuille Cashu NIP-60.

Actualités

Améliorations de stabilité pour Notecrumbs

Notecrumbs, l’API Nostr et le serveur web qui alimente les aperçus de liens damus.io, a reçu une série de correctifs traitant des problèmes de fiabilité.

Un correctif de concurrence a remplacé le mécanisme de déduplication des requêtes en vol par des canaux watch. Deux appelants demandant la même note pouvaient tous deux devenir récupérateurs, menant à un interblocage lorsque l’un terminait avant que l’autre ne s’abonne à la notification. Grâce aux canaux watch avec opérations atomiques, un seul récupérateur s’exécute tandis que les autres attendent le résultat.

La limitation de débit implémente une défense à deux niveaux contre le martèlement des relays. Lorsque les utilisateurs accèdent de manière répétée à la même note, le système débonde maintenant les requêtes aux relays avec une fenêtre de refroidissement de 5 minutes. Cette protection s’étend à tous les types NIP-19 et aux flux de profils, empêchant le spam proportionnel vers les relays lors d’un trafic intense.

Un ensemble d’améliorations de performance a déplacé les récupérations de données secondaires vers des tâches tokio en arrière-plan. Désormais les pages se rendent instantanément avec des données en cache au lieu de bloquer sur des timeouts de relays séquentiels qui pouvaient s’additionner jusqu’à 7,5 secondes. Une mise à niveau vers nostrdb 0.10.0 a accompagné ces correctifs.

ContextVM : MCP sur Nostr

ContextVM est une suite d’outils faisant le pont entre Nostr et le Model Context Protocol (MCP). De récents commits ont introduit la nouvelle spécification CEP-8 permettant les paiements, et ont fait avancer les améliorations du SDK tout au long de février.

Le SDK fournit des transports client et serveur TypeScript pour MCP sur Nostr. Avec ce SDK, les développeurs peuvent exposer des serveurs MCP à travers le réseau Nostr et les clients peuvent s’y connecter. Agissant comme un bus de messages aveugle, les relays routent simplement les événements chiffrés de manière aveugle. Une couche proxy permet aux clients sans support Nostr natif de se connecter. La bibliothèque gère la gestion des relays et la signature cryptographique pour l’authentification des événements. Elle fonctionne dans les environnements Node.js et navigateur.

CVMI fournit une CLI pour la découverte de serveurs et l’invocation de méthodes. Relatr calcule des scores de confiance personnalisés à partir de la distance du graphe social combinée à la validation de profil.

ContextVM se positionne comme une couche de pont : les serveurs MCP existants gagnent l’interopérabilité Nostr tout en maintenant leurs transports conventionnels.

White Noise documente la recherche d’utilisateurs décentralisée

Un article de blog de jgmontoya détaille comment White Noise gère la recherche d’utilisateurs à travers le réseau de relays décentralisé.

La distribution de profils crée le défi : contrairement aux messageries centralisées avec des bases de données unifiées, les profils Nostr se dispersent sur des dizaines de relays sans index central. White Noise résout cela grâce à une architecture producteur-consommateur fonctionnant en parallèle.

Un processus producteur étend continuellement le graphe social vers l’extérieur depuis les abonnements de l’utilisateur, récupérant les listes d’abonnements à des distances croissantes et mettant en file d’attente les pubkeys découvertes pour la résolution de profil. Le consommateur résout les correspondances à travers cinq niveaux de plus en plus coûteux : table d’utilisateurs locale (plus rapide), profils en cache de recherches précédentes, relays connectés, listes de relays utilisateur selon NIP-65 et requêtes directes vers les relays déclarés par l’utilisateur (plus lent).

Prenant environ 3 secondes, les recherches à froid sont nettement plus lentes que les recherches chaudes depuis le cache qui descendent à environ 10 millisecondes. Pour les nouveaux utilisateurs sans graphes sociaux établis, le système injecte des nœuds d’amorçage bien connectés pour assurer la fonctionnalité de recherche. L’appartenance à un groupe fournit un signal social implicite aux côtés des abonnements explicites.

L’instrumentation s’est avérée critical pour l’optimisation, note l’auteur. Sans métriques, les améliorations n’étaient que des suppositions.

FIPS : réseau maillé natif Nostr

FIPS (Free Internetworking Peering System) est une implémentation Rust fonctionnelle d’un réseau maillé auto-organisé qui utilise les paires de clés Nostr (secp256k1) comme identités de nœuds. La documentation de conception accompagne le code fonctionnel.

Le protocole répond à l’indépendance d’infrastructure : les nœuds se découvrent automatiquement sans serveurs centraux ni autorités de certification. Un arbre couvrant fournit un routage basé sur les coordonnées tandis que les filtres bloom propagent les informations d’accessibilité, permettant aux nœuds de prendre des décisions de transfert avec seulement une connaissance locale. Grâce à l’agnosticisme de transport, le même protocole fonctionne sur UDP, Ethernet, Bluetooth, radio LoRa ou tout support capable de datagrammes.

Deux couches de chiffrement protègent le trafic. Pour la couche liaison, le chiffrement (pattern Noise IK) sécurise la communication saut par saut entre voisins avec authentification mutuelle et secret parfait de transmission. Au niveau session, le chiffrement (pattern Noise XK) fournit une protection de bout en bout contre les routeurs intermédiaires, où seule la destination peut déchiffrer la charge utile. Cela reflète la façon dont TLS protège le trafic HTTP même lors de la traversée de réseaux non fiables.

Utilisant un arbre couvrant greedy embedding pour le routage, l’architecture attribue à chaque nœud des coordonnées basées sur sa position par rapport à la racine de l’arbre et au parent. Routant de manière avide vers les coordonnées plus proches de la destination, les paquets bénéficient de filtres bloom annonçant les points d’accès accessibles. Lorsque le routage avide échoue (minima locaux), les nœuds peuvent se rabattre sur des chemins basés sur l’arbre.

Incluant déjà le transport UDP avec découverte par filtre bloom, l’implémentation Rust progresse rapidement. Le travail futur cible l’intégration de relays Nostr pour l’amorçage de pairs.

Versions

Cette semaine a apporté des versions à travers l’infrastructure de relays et les applications clientes, avec de nouveaux projets entrant également dans l’espace.

HAVEN v1.2.0

HAVEN, le relay personnel tout-en-un regroupant quatre fonctions de relay avec un serveur média Blossom, a livré v1.2.0. Cette version va au-delà du stade RC couvert la semaine dernière.

Le support multi-npub permet à une seule instance HAVEN de servir plusieurs identités Nostr via whitelisting, avec une nouvelle fonctionnalité de blacklisting pour le contrôle d’accès. Réécrit entièrement, un système de sauvegarde utilise le format JSONL portable, avec une commande haven restore pour importer des notes depuis des fichiers JSONL. L’intégration de stockage cloud ajoute les flags --to-cloud et --from-cloud pour la gestion des sauvegardes distantes.

Parmi les améliorations de Web of Trust : des niveaux de profondeur configurables pour les calculs de confiance et des intervalles de rafraîchissement automatique de 24 heures avec optimisation sans verrou réduisant la surcharge mémoire. Complétant la version, la configuration de user-agent pour les requêtes de relays et les paramètres de timeout Blastr configurables s’ajoutent à l’exportation de données vers JSONL compressé.

White Noise v0.3.0

White Noise, l’application de messagerie chiffrée basée sur MLS implémentant le protocole Marmot, a livré v0.3.0 avec plus de 160 améliorations fusionnées.

Cette version apporte la messagerie en temps réel via des connexions en streaming au lieu du polling, de sorte que les messages arrivent instantanément. Avec le support Amber (NIP-55), les clés privées n’ont jamais besoin de toucher l’application. Fonctionnant maintenant avec suivi de la progression du téléversement et des emplacements réservés blurhash lors du chargement, le partage d’images s’améliore grandement. L’affichage plein écran supporte le pincement pour zoomer.

Recevant des améliorations de fiabilité avec des listes de conversations montrant les noms d’expéditeur et le chiffrement MLS assurant le secret parfait de transmission, la messagerie de groupe progresse également. S’étendant vers l’extérieur depuis les abonnements jusqu’à quatre degrés de séparation avec des résultats en streaming au fur et à mesure de leur découverte, la recherche d’utilisateurs devient plus puissante.

Un changement cassant réinitialise toutes les données locales lors de la mise à niveau en raison des changements du protocole Marmot et du passage au stockage local chiffré. Avant de mettre à niveau, sauvegardez vos clés nsec.

diVine 1.0.5

diVine, le client vidéo courte en boucle construit sur les archives Vine restaurées, a livré 1.0.5 avec d’importants correctifs de lecture vidéo et un nouveau système d’analyse décentralisé.

Plusieurs problèmes de lecture vidéo ont dominé les correctifs. Pause fantôme résolue. Audio double entre vidéos éliminé. Flash noir entre miniatures et premières frames corrigé. Crashs de lecteur disposé tous résolus. Gérant maintenant le flux Home pour une lecture cohérente, un lecteur vidéo poolé remplace l’ancien système.

Permettant les analyses de créateurs et les recommandations, la version introduit des événements de visionnage éphémères Kind 22236. Suivant les sources de trafic (accueil, variantes de découverte, profil, partage, recherche) et les comptages de boucles tout en filtrant les auto-vues, le système fournit des métriques utiles. Corrigées avec des URLs Blossom canoniques construites côté client selon la spécification BUD-01, les fuites de chemins de fichiers locaux dans les tags imeta d’événements Nostr disparaissent.

Côté signataire distant NIP-46, plusieurs améliorations arrivent. Connexions de relays parallélisées implémentées. Support d’URL de rappel ajouté. Reconnectant les connexions WebSocket lors de la reprise de l’application après approbation du signataire, Android fonctionne mieux.

Coracle 0.6.30

Coracle, le client Nostr web axé sur la gestion de relays et la modération par Web of Trust, a livré 0.6.30 avec support des miniatures vidéo, améliorant la navigation média dans les flux.

Nostur v1.26.0

Nostur, le client Nostr iOS, a livré v1.26.0 avec une nouvelle section de flux Live Streams et un écran Paramètres repensé. Pouvant maintenant être hébergés sur des serveurs média Blossom, les GIFs réduisent la dépendance aux services centralisés. Fournissant une sauvegarde lorsque Tenor devient indisponible, l’intégration de GIFs Klipy aide. Complétant les changements visibles par l’utilisateur, des en-têtes d’année dans les conversations DM et l’affichage du comptage de mentions s’ajoutent.

Cette semaine a également apporté des mises à jour pour les outils de développement et les applications CLI.

nak v0.18.5

nak, le couteau suisse en ligne de commande pour Nostr de fiatjaf, a livré v0.18.5 avec une nouvelle sous-commande nak profile pour récupérer et afficher les profils utilisateur. Supportant maintenant les noms NIP-05 dans les URIs nostr://, la commande git clone permet le clonage de dépôts par identifiants lisibles par l’humain.

Pika v0.5.3

Pika, la messagerie chiffrée MLS pour iOS, Android et desktop construite sur le protocole Marmot, a livré v0.5.3. Ajoutant le téléversement de fichiers et le support de glisser-déposer de médias à l’application desktop, aux côtés des correctifs de déploiement Cloudflare Workers, les commits récents améliorent l’expérience.

Utilisant un noyau Rust qui possède toute la logique métier tandis qu’iOS (SwiftUI) et Android (Kotlin) agissent comme des couches UI fines rendant des instantanés d’état, Pika adopte une architecture claire. Fournissant l’implémentation MLS, MDK (Marmot Development Kit) sert de base. Notant un statut alpha et mettant en garde contre l’utilisation pour des charges de travail sensibles, le projet reste expérimental.

Ridestr v0.2.6

Ridestr, la plateforme de covoiturage décentralisée avec paiements Cashu, a livré v0.2.6. Corrigeant des problèmes d’accessibilité TalkBack et résolvant des bugs où les conducteurs disparaissaient de la liste à proximité lors du changement de méthodes de paiement ou où les comptages de conducteurs sélectionnés ne se mettaient pas à jour lorsque les conducteurs passaient hors ligne, cette version améliore la stabilité.

Devenant Broadcast RoadFlare avec des correctifs pour les échecs silencieux sur les installations de conducteurs fraîches, la fonctionnalité Send to All évolue. Implémentant l’escrow HTLC pour les paiements de trajet sans confiance et la synchronisation de portefeuille NIP-60 sur les appareils, Ridestr progresse techniquement.

Unfiltered v1.0.6

Unfiltered, l’application de partage de photos de type Instagram pour Android, a livré v1.0.6 avec recherche d’utilisateurs améliorée et reconnexion automatique de relay toutes les 60 secondes.

Construit avec Kotlin et Jetpack Compose, Unfiltered utilise des liaisons rust-nostr et des serveurs compatibles Blossom pour l’hébergement d’images. Gérant la gestion sécurisée des clés, l’intégration Amber (NIP-55) protège les utilisateurs. Montrant les publications des comptes suivis en ordre chronologique sans algorithmes ni publicités, l’application reste fidèle à l’esprit Nostr.

Deux nouveaux projets de messagerie et de signature ont également été lancés cette semaine.

Burrow : messagerie MLS pour agents IA

Burrow est une messagerie implémentant le protocole Marmot pour la communication chiffrée MLS sans numéros de téléphone ni serveurs centralisés. Humains et agents IA peuvent tous participer.

Gérant l’intégration avec les systèmes automatisés, un daemon CLI Rust pur avec mode de sortie JSONL sert les besoins programmatiques. Couvrant Android, iOS, Linux, macOS et Windows, une application Flutter multiplateforme sert les utilisateurs humains. Chiffrant aux côtés des messages, les pièces jointes média restent protégées, et WebRTC gère les appels audio et vidéo avec des serveurs TURN configurables.

Superposant le chiffrement MLS sur l’infrastructure Nostr, Burrow utilise des paires de clés Nostr (secp256k1) pour l’identité tandis que les KeyPackages MLS publient comme événements kind 443. Pour les messages, le chiffrement NIP-44 produit des événements kind 445. Utilisant le gift-wrapping NIP-59, les invitations de bienvenue protègent les métadonnées.

Permettant la participation d’agents IA avec accès complet aux outils, l’intégration OpenClaw ouvre de nouvelles possibilités. Gérant les permissions de contacts et de groupes avec journalisation d’audit, les listes de contrôle d’accès assurent la sécurité. Positionnant Burrow pour les scénarios de messagerie agent-à-agent et agent-à-humain nécessitant un chiffrement de niveau Signal sur une infrastructure décentralisée, cette combinaison de fonctionnalités est puissante.

Extension Nostria Signer

Nostria Signer est une extension de navigateur basée sur Chromium fournissant un coffre-fort et une gestion d’identité pour les utilisateurs Nostr.

Permettant aux utilisateurs d’organiser les identités pour différents contextes, plusieurs coffres contenant plusieurs comptes offrent de la flexibilité. Incluant le support des langues RTL, l’internationalisation est complète. Fonctionnant à la fois comme extension de navigateur et Progressive Web App, la construction avec Angular et TypeScript (79,2 % de la base de code) assure une bonne maintenabilité.

Implémentant NIP-07 pour la signature d’extension de navigateur, Nostria Signer permet aux clients Nostr web de demander des signatures d’événements sans accéder directement aux clés privées. Gérant les mises à jour distribuées via le Chrome Web Store, la migration automatique de portefeuille facilite la vie des utilisateurs. Restant également possible pour les utilisateurs avancés, le chargement depuis le dossier dist/extension offre une alternative.

Soulignant le statut expérimental, les développeurs insistent : les utilisateurs doivent gérer leurs propres phrases de récupération secrètes puisque les développeurs ne peuvent pas restaurer l’accès aux clés perdues.

Mises à jour des projets

Formstr migre vers une nouvelle organisation

Formstr, l’alternative à Google Forms sur Nostr, a migré son dépôt de abh3po/nostr-forms vers l’organisation formstr-hq. Continuant le développement au nouvel emplacement, ce bénéficiaire de subvention OpenSats progresse.

PRs ouvertes notables

Travail en cours à travers les projets Nostr :

Modèle Outbox Damus (PR #3602) : Plan d’implémentation pour le modèle de relay gossip/outbox sur iOS. Améliorant la livraison de messages en publiant vers les relays où les destinataires lisent réellement, ce changement architectural est significatif.
Notifications multiplateforme Notedeck (PR #1296) : Système de notifications natif pour le client desktop Damus couvrant Android FCM, macOS et Linux.
Mise à niveau Cashu v3 NDK (PR #370) : Met à jour l’intégration de portefeuille du Nostr Development Kit vers cashu-ts v3.
Zeus Cashu Offline (PR #3742) : Envoi et réception d’ecash hors ligne pour le portefeuille Lightning Zeus.
Livraison numérique chiffrée Shopstr (PR #231) : Ajoute la livraison chiffrée pour les biens numériques avec support de poids dynamique pour les articles physiques.

Mises à jour des NIP

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

Fusionnés cette semaine :

Découvrabilité du fournisseur de services NIP-85 : Incluant maintenant des conseils sur la façon dont les clients découvrent les fournisseurs d’assertions de confiance, la spécification NIP-85 s’améliore. Lorsqu’un client a besoin de scores de Web of Trust ou d’autres métriques calculées, il peut interroger les relays pour les annonces kind 30085 des fournisseurs que l’utilisateur suit déjà ou en qui il a confiance.
NIP-29 supprime les groupes non gérés : Abandonnant le support des groupes non gérés (où tout membre pouvait ajouter d’autres), la spécification de chat de groupe NIP-29 se simplifie. Nécessitant maintenant une gestion côté relay avec des rôles d’administrateur explicites, tous les groupes NIP-29 deviennent plus contrôlables. Simplifiant les implémentations et réduisant les vecteurs de spam, ce changement améliore la sécurité.
NIP-11 supprime les champs dépréciés : N’incluant plus les champs dépréciés software et version, les documents d’information de relay NIP-11 se nettoient. Devant retirer ceux-ci de leurs réponses, les implémentations s’alignent.
NIP-39 déplace les tags d’identité : Déplacées des profils kind 0 vers des événements dédiés kind 30382, les revendications d’identité externe (tags i NIP-39 pour GitHub, Twitter, etc.) changent d’emplacement. Séparant la vérification d’identité des métadonnées de profil, ce changement clarifie les responsabilités.

Progression des NIP d’agents IA :

Continuant un développement actif, quatre NIP axés sur l’IA progressent. Depuis la couverture de la semaine dernière :

NIP-AE : Agents (mis à jour le 19 février) : Définissant l’identité d’agent avec kind 4199 pour les définitions d’agent et kind 4201 pour le prompting (nudges), cette spec structure les agents. Pouvant référencer des métadonnées de fichier NIP-94 pour des descriptions étendues, les agents gagnent en expressivité.
NIP-XX : AI Agent Messages (mis à jour le 18 février) : Standardisant la messagerie conversationnelle avec sept kinds d’événements éphémères (25800-25806) pour le statut, les deltas en streaming, les prompts, les réponses, les appels d’outils, les erreurs et l’annulation, cette spec couvre beaucoup. Permettant aux agents d’annoncer les modèles et capacités supportés, les événements AI Info kind 31340 facilitent la découverte.
NIP-AC : DVM Agent Coordination (ouvert le 18 février) : Étendant NIP-90 pour les flux de travail d’agents autonomes, cette proposition ajoute beaucoup. Heartbeats pour la découverte d’agents. Revues de tâches pour le suivi de qualité. Escrow de données pour l’engagement de résultats. Chaînes de flux de travail pour les pipelines multi-étapes. Enchère en essaim pour la sélection de fournisseurs compétitifs. Fonctionnant sur 2020117.xyz, une implémentation de référence existe.
NIP-AD : MCP Server Announcements (ouvert le 12 février) : Standardisant l’annonce de serveurs Model Context Protocol et de compétences sur Nostr, cette spec trouve déjà un usage. Déjà utilisée sur la plateforme TENEX, l’adoption commence.

Autres PRs ouvertes :

NIP-144 : Service Authorization Protocol : Définissant comment les clients prouvent l’identité et les permissions aux fournisseurs de services sur Nostr, cette spec aborde l’autorisation.
NIP-DC : Nostr Webxdc : Proposant d’intégrer Webxdc (applications web décentralisées) avec les événements Nostr, alexgleason explore de nouvelles directions.

Approfondissement NIP : NIP-55 (Android Signer Application)

NIP-55 définit comment les clients Nostr Android demandent des opérations cryptographiques à des applications de signature dédiées. Ajoutant tous deux le support Amber cette semaine, White Noise v0.3.0 et Unfiltered v1.0.6 justifient un examen du protocole de signature Android.

Canaux de communication :

Permettant la signature inter-applications via deux mécanismes, NIP-55 offre de la flexibilité. Fournissant une approbation manuelle de l’utilisateur avec feedback visuel pour les opérations ponctuelles, les Intents conviennent aux actions explicites. Permettant la signature automatisée lorsque les utilisateurs accordent des permissions persistantes, les Content Resolvers autorisent les applications à signer en arrière-plan sans invites répétées.

Utilisant le schéma URI personnalisé nostrsigner:, la communication reste simple. Un client initie le contact avec :

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Opérations supportées :

La spec définit sept méthodes cryptographiques. Signature d’événement (sign_event). Récupération de clé publique (get_public_key). Opérations de chiffrement et déchiffrement NIP-04. Opérations de chiffrement et déchiffrement NIP-44. Déchiffrement d’événement zap (decrypt_zap_event).

Modèle de permissions :

Appelant get_public_key une fois pour établir une relation de confiance, les clients reçoivent le nom de paquet du signataire et la pubkey de l’utilisateur. Imposant que les clients sauvegardent ces valeurs et n’appellent jamais get_public_key à nouveau, la spec empêche les attaques de fingerprinting.

Pouvant approuver une fois ou accorder se souvenir de mon choix pour les opérations en arrière-plan, les utilisateurs contrôlent les permissions pour les requêtes de signature. Retournant un statut rejected et empêchant les invites répétées si les utilisateurs rejettent systématiquement les opérations, le signataire protège l’expérience utilisateur.

Implémentations :

Servant de signataire NIP-55 principal pour Android, Amber domine. Parmi les clients supportant NIP-55 : Amethyst, White Noise, Unfiltered et d’autres. Ne pouvant pas recevoir directement les réponses du signataire et devant utiliser des URLs de rappel ou des opérations de presse-papiers, les applications web ont des contraintes.

Relation avec d’autres NIP de signature :

Complétant NIP-07 (extensions de navigateur) et NIP-46 (signature à distance sur relays), NIP-55 s’intègre dans un écosystème. Là où NIP-07 gère les navigateurs de bureau et NIP-46 gère la signature inter-appareils, NIP-55 fournit une intégration Android native avec latence minimale.

Approfondissement NIP : NIP-60 (Cashu Wallet)

NIP-60 définit comment les portefeuilles ecash Cashu stockent l’état sur les relays Nostr, permettant la synchronisation de portefeuille inter-applications. Utilisant NIP-60 pour la synchronisation de portefeuille sur les appareils, Ridestr v0.2.6 justifie un examen du protocole.

Kinds d’événements :

Utilisant quatre types d’événements, NIP-60 structure l’état du portefeuille. Stockant la configuration du portefeuille incluant les URLs de mint et une clé privée dédiée pour recevoir les paiements ecash P2PK, le kind remplaçable 17375 contient les paramètres essentiels. Contenant des preuves cryptographiques non dépensées, les événements de jetons (kind 7375) gardent les fonds. Enregistrant les transactions pour la transparence de l’utilisateur, l’historique de dépenses (kind 7376) aide au suivi. Suivant les quotes de paiement de mint, un kind optionnel 7374 complète l’ensemble.

Architecture du portefeuille :

Vivant sur les relays et le rendant accessible à travers les applications, l’état du portefeuille se décentralise. Contenant des références chiffrées aux mints Cashu et une clé privée spécifique au portefeuille séparée de l’identité Nostr de l’utilisateur, l’événement de portefeuille d’un utilisateur sépare les préoccupations. Gérant les opérations ecash tandis que la clé Nostr gère les fonctions sociales, cette séparation de la clé de portefeuille compte.

{
 "kind": 17375,
 "content": "<nip44-encrypted-wallet-config>",
 "tags": [["d", "cashu-wallet"]]
}

Gestion des preuves :

Étant des instruments au porteur qui deviennent invalides une fois dépensés, les preuves Cashu nécessitent une gestion soigneuse. Gérant cela via un mécanisme de roulement, NIP-60 maintient la cohérence. Lors de la dépense, les clients créent un nouvel événement de jeton avec les preuves non dépensées restantes et suppriment l’original via NIP-09. Allant dans un champ del pour le suivi d’état, les IDs de jetons détruits restent traçables.

Devant périodiquement valider les preuves contre les mints pour détecter les credentials précédemment dépensés, les clients maintiennent la sécurité. Étant permis avec plusieurs événements de jetons par mint, la flexibilité existe. Aidant les utilisateurs à suivre les transactions même s’ils sont optionnels, les événements d’historique de dépenses améliorent l’expérience.

Modèle de sécurité :

Utilisant le chiffrement NIP-44, toutes les données sensibles restent protégées. N’apparaissant jamais en clair, la clé privée du portefeuille demeure secrète. Stockant des blobs chiffrés sans comprendre leurs contenus, les relays ne peuvent pas violer la vie privée. Restant privé même sur des relays non fiables, l’état du portefeuille bénéficie d’une architecture zero-knowledge.

Implémentations :

Supportant NIP-60, plusieurs portefeuilles adoptent le standard. Nutsack implémente. eNuts également. Utilisant NIP-60 pour la synchronisation inter-appareils et permettant aux utilisateurs de recharger sur desktop et de dépenser depuis mobile sans transferts manuels, les clients comme Ridestr démontrent la valeur.

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

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Une couche de cache local Blossom prend forme à mesure que des projets indépendants convergent vers l’accès hors ligne aux médias sur Android. Alby lance un bac à sable NWC pour développeurs permettant de construire et tester des intégrations Nostr Wallet Connect sans risquer de vrais fonds. Des propositions concurrentes pour la communication d’agents IA sur Nostr arrivent la même semaine de deux auteurs différents. fiatjaf supprime les champs inutilisés de NIP-11, retirant les politiques de rétention, codes pays, politiques de confidentialité et tags de préférence communautaire que les opérateurs de relay n’ont jamais adoptés. NIP-85 fusionne les conseils de découverte de fournisseurs de services pour les Trusted Assertions. Un nouveau tag D dans NIP-52 active l’indexation des événements de calendrier à la granularité journalière. Parmi les nouveaux projets : Mapnolia pour la distribution décentralisée de tuiles cartographiques, Pika pour la messagerie chiffrée MLS, Keep pour la signature à seuil FROST sur Android, Hashtree pour le stockage adressé par contenu avec intégration Nostr, et Prism pour partager du contenu vers Nostr depuis n’importe quelle application Android. Primal Android fusionne 11 PRs NWC ajoutant le support double portefeuille et le cycle de vie automatique du service. Mostro Mobile livre un portefeuille Lightning intégré via l’intégration NWC. Notedeck prépare sa sortie sur l’App Store Android tandis que HAVEN atteint v1.2.0-rc3 avec le support multi-npub et la sauvegarde cloud. Les approfondissements de cette semaine portent sur le système Trusted Assertions de NIP-85 pour déléguer les calculs de Web of Trust à des fournisseurs de services, et sur le protocole Événements de Calendrier de NIP-52 suite à sa mise à jour d’indexation à la granularité journalière.

Actualités

Une couche de cache local Blossom émerge

Plusieurs projets indépendants convergent vers le même problème : l’accès hors ligne aux médias Blossom sur les appareils mobiles.

Morganite, une nouvelle application Android de greenart7c3 (le développeur derrière Amber et Citrine), implémente un cache côté client pour les médias Blossom. Les utilisateurs peuvent accéder aux images et fichiers précédemment consultés sans connexion réseau.

Aerith a livré v0.2 avec l’étiquetage d’images, les opérations de miroir/tag/suppression en masse, le filtrage par étiquette et type de fichier, ainsi que le support initial du cache Blossom local. Aerith est une interface de gestion pour les utilisateurs qui stockent des médias sur plusieurs serveurs Blossom et ont besoin d’organiser et de mettre en miroir leurs blobs.

Un nouveau guide d’implémentation du cache local dans la spécification Blossom documente le stockage de blobs côté client, tandis que Prism (du même développeur qu’Aerith) ajoute l’intégration de téléversement Blossom à son flux de partage vers Nostr sur Android. Quatre projets indépendants ont convergé vers le même problème cette semaine : une application de cache dédiée, un gestionnaire de médias, une spécification de référence et un outil de partage avec intégration Blossom, tous implémentant un stockage local persistant au-delà du simple téléversement et récupération.

Bac à sable NWC d’Alby pour les développeurs

Alby a lancé un environnement bac à sable pour les développeurs qui construisent avec Nostr Wallet Connect (NIP-47). Le bac à sable fournit un service de portefeuille NWC hébergé où les développeurs peuvent créer des connexions de test et envoyer des paiements simulés sans connecter un vrai portefeuille Lightning, tout en observant le cycle complet requête/réponse des événements NWC en temps réel. Les développeurs génèrent une chaîne de connexion nostr+walletconnect:// depuis le bac à sable et la transmettent à leur client. Le bac à sable affiche alors les événements de requête kind 23194 et de réponse kind 23195 résultants au fur et à mesure qu’ils transitent entre le client et le service de portefeuille.

Cela abaisse la barrière pour les nouvelles intégrations NWC. Auparavant, les tests nécessitaient soit un portefeuille Lightning personnel, soit un service NWC auto-hébergé. Le bac à sable abstrait tout cela, donnant aux développeurs une boucle de rétroaction immédiate pour implémenter les méthodes pay_invoice, get_balance, make_invoice, lookup_invoice et list_transactions contre un point d’accès NWC en direct.

Des NIP pour les agents IA arrivent

Des propositions pour la communication d’agents IA sur Nostr sont apparues à quelques jours d’intervalle, abordant le problème sous des angles différents.

NIP-XX : AI Agent Messages de joelklabo définit un protocole complet pour l’interaction d’agents IA : kinds d’événements pour les prompts, réponses, deltas en streaming, mises à jour de statut, télémétrie d’outils, erreurs, annulations et découverte de capacités. Un événement de découverte ai.info (kind 31340, remplaçable) permet aux agents d’annoncer leurs modèles supportés, outils avec schémas, support du streaming et limites de débit. La proposition de joelklabo inclut la corrélation d’exécutions via l’ID de prompt, la gestion de sessions, la réconciliation de flux avec ordonnancement par séquence, et des conseils NIP-59 pour la confidentialité des métadonnées.

NIP-AE : Agents de pablof7z adopte une approche différente, définissant des kinds pour l’instanciation d’agents : définitions et leçons. Ce sont les types d’événements que pablof7z utilise dans TENEX, le système d’apprentissage autonome construit sur Nostr. Une proposition complémentaire, NIP-AD : MCP Server and Skill Announcements, également de pablof7z, définit des événements pour annoncer les serveurs Model Context Protocol et les compétences sur Nostr. Les commentaires NIP-22 sont supportés, permettant à la communauté de discuter et d’évaluer les serveurs MCP directement sur Nostr.

NIP-XX couvre la communication complète entre agents tandis que NIP-AE et NIP-AD traitent de l’identité et de la découverte d’outils. Ces propositions pourraient converger vers un standard unifié ou coexister comme des couches complémentaires.

Versions

HAVEN v1.2.0-rc3

HAVEN, le relay personnel tout-en-un qui regroupe quatre fonctions de relay avec un serveur média Blossom, a atteint v1.2.0-rc3. Cette version candidate ajoute le support de plusieurs npubs, permettant à une seule instance HAVEN de servir plusieurs identités Nostr. Les RC précédents ont ajouté les flags --from-cloud et --to-cloud pour la sauvegarde cloud (RC2) et corrigé un bug de double comptage dans le Web of Trust (RC1).

Mostro Mobile v1.2.0 : portefeuille Lightning intégré

Mostro Mobile, le client mobile pour la plateforme d’échange Bitcoin P2P Mostro (v1.1.0 couvert la semaine dernière), a livré v1.2.0 avec un portefeuille Lightning intégré grâce à l’intégration complète de NWC (NIP-47). Les acheteurs et vendeurs n’ont plus besoin de changer d’application pour gérer les factures. L’application détecte les hold invoices pour les vendeurs et les paie automatiquement via le portefeuille connecté, tandis que les acheteurs bénéficient de la génération automatique de factures. Cette version fait suite à v1.1.1 publiée plus tôt dans la semaine, qui a ajouté le support multi-nœud Mostro avec un registre curé d’instances de confiance, la récupération des métadonnées kind 0 pour l’affichage des nœuds, la gestion de nœuds personnalisés par pubkey, et le basculement automatique lorsqu’un nœud sélectionné est hors ligne.

Côté serveur, Mostro v0.16.2 a atterri avec des correctifs pour les paiements de frais de développement en double, la limitation de débit sur le point d’accès RPC de validation de mot de passe, et le nettoyage correct des litiges lors d’annulations coopératives.

Un nouveau projet compagnon, mostro-skill, permet aux agents d’échanger sur Mostro via Nostr.

Aerith v0.2

Aerith, le gestionnaire d’images Blossom, a livré v0.2 avec des étiquettes d’images pour organiser les médias, les opérations de miroir/tag/suppression en masse sur plusieurs serveurs, le filtrage par étiquette et type de fichier, ainsi que le support initial du cache local. Voir la section Actualités pour le contexte sur la tendance plus large du cache local.

Mapnolia : tuiles cartographiques décentralisées sur Nostr

Mapnolia est un nouveau serveur de données géospatiales qui découpe les archives de tuiles cartographiques PMTiles en régions géographiques et les annonce sur Nostr pour une découverte décentralisée. Il publie des événements remplaçables paramétrés kind 34444 vers les relays Nostr contenant un index complet des fragments de tuiles cartographiques avec les métadonnées de couches, les régions géohash, les références de fichiers et les détails du serveur Blossom.

Les clients découvrent et récupèrent les données cartographiques via le réseau Nostr plutôt que des serveurs de tuiles centralisés, les événements d’annonce portant suffisamment de métadonnées pour ne demander que les régions géographiques nécessaires aux serveurs Blossom listés. Mapnolia est le premier projet à apporter la distribution de données géospatiales sur Nostr, ouvrant des possibilités pour des applications cartographiques capables de fonctionner hors ligne.

Pika : messagerie chiffrée basée sur Marmot

Pika est une nouvelle application de messagerie chiffrée de bout en bout pour iOS et Android utilisant le protocole Marmot, qui superpose Messaging Layer Security (MLS) sur les relays Nostr. L’architecture sépare les préoccupations en un noyau Rust (pika_core) gérant l’état MLS et le chiffrement/déchiffrement des messages sur les relays Nostr, avec des interfaces utilisateur natives légères en SwiftUI (iOS) et Kotlin (Android). L’état circule de façon unidirectionnelle : l’UI envoie des actions à l’acteur Rust, qui modifie l’état et émet des instantanés avec des numéros de révision vers l’UI via les liaisons UniFFI et JNI.

Pika rejoint un champ croissant de messageries MLS-sur-Nostr aux côtés de White Noise, Vector et 0xchat. Toutes utilisent les relays Nostr comme couche de transport pour le texte chiffré MLS, empêchant les opérateurs de relay de lire le contenu des messages. Pika utilise le Marmot Development Kit (MDK) pour son implémentation MLS et nostr-sdk pour la connectivité aux relays.

Keep : signature à seuil FROST pour Android

Keep est une nouvelle application Android pour la signature à seuil FROST où aucun appareil unique ne détient la clé privée complète. Elle implémente NIP-55 (signataire Android) et NIP-46 (signature à distance), de sorte que les clients Nostr compatibles peuvent demander des signatures tandis que le matériel de clé reste distribué sur plusieurs appareils. Les configurations par défaut sont 2-sur-3 et 3-sur-5, bien que tout seuil t-sur-n soit supporté.

La cérémonie de génération de clés distribuées (DKG) de Keep s’exécute sur les relays Nostr en utilisant des kinds d’événements personnalisés : kind 21101 pour les annonces de groupe, kind 21102 pour les polynômes d’engagement du tour 1 (diffusés publiquement), et kind 21103 pour les parts secrètes du tour 2 (chiffrement point-à-point NIP-44 entre participants). Le scalaire de clé privée du groupe n’est jamais calculé ni assemblé nulle part durant le DKG. Chaque appareil ne détient que sa part d’évaluation polynomiale, et n’importe quelles t parts peuvent produire une signature Schnorr valide via un protocole en deux tours commit-puis-signer. La signature de 64 octets résultante est indiscernable d’une signature Schnorr à signataire unique. En coulisse, Keep utilise le crate frost-secp256k1-tr de la Zcash Foundation avec tweaking Taproot, de sorte que la clé publique de groupe fonctionne directement comme un npub Nostr.

Keep rejoint la famille de projets Frostr aux côtés d’Igloo Desktop, Igloo for Android, Frost2x et Igloo for iOS, élargissant les options de gestion de clés à seuil sur Nostr.

Prism : partager n’importe quoi vers Nostr depuis Android

Prism est une nouvelle application Android (Kotlin/Jetpack Compose, API 26+) qui s’enregistre comme cible de partage système, permettant aux utilisateurs de publier du texte, des URLs, des images et des vidéos vers Nostr depuis n’importe quelle application de leur téléphone. Les URLs partagées passent par un extracteur de paramètres de suivi avant d’être composées en notes. Prism récupère les métadonnées OpenGraph pour générer des aperçus de liens enrichis et rend les références Nostr natives (note1, nevent1) inline.

Le moteur de planification utilise une approche hybride AlarmManager/WorkManager pour contourner les optimisations de batterie Android : AlarmManager gère le timing précis du réveil tandis que les tâches WorkManager expéditives assurent la livraison, avec une relance à backoff exponentiel pour les scénarios hors ligne. Les téléversements de médias passent par des serveurs Blossom configurables avec génération de miniatures pour les images et les frames vidéo. Toute la signature d’événements est déléguée aux signataires externes NIP-55 comme Amber, avec un support multi-compte pour basculer entre les identités. Prism supporte également les publications NIP-84 (Highlights). Du même développeur qu’Aerith.

Hashtree : stockage adressé par contenu avec intégration Nostr

Hashtree est un système de stockage de blobs adressé par contenu basé sur le système de fichiers qui publie les racines Merkle sur Nostr pour créer des adresses mutables npub/chemin. Le système utilise un « stockage muet » fonctionnant avec tout magasin clé-valeur, découpant le contenu en blocs de 2 Mo optimisés pour les téléversements Blossom. Contrairement à BitTorrent, aucun calcul actif de preuves Merkle n’est nécessaire — il suffit de stocker et de récupérer les blobs par hash.

L’intégration Nostr permet des URLs de dépôt git comme htree://npub.../nom-depot pour cloner des dépôts, avec des commandes comme htree publish mydata <hash> pour publier des hashes de contenu vers les adresses npub.../mydata. Le CLI complet supporte les modes de stockage chiffré (par défaut) et public, l’épinglage de contenu, la publication vers les serveurs Blossom et la gestion des identités Nostr. Chaque élément stocké est soit des octets bruts soit un nœud d’arbre, fournissant une base pour la distribution de contenu décentralisée via le réseau de relays Nostr.

Espy : capture de palettes de couleurs sur Shakespeare

Espy, construit sur la plateforme Shakespeare, permet aux utilisateurs de capturer des palettes de couleurs à partir de photos et de les partager comme événements Nostr. Shakespeare est un créateur d’applications propulsé par l’IA qui authentifie les utilisateurs via les extensions de navigateur NIP-07 et fournit une connectivité relay Nostr intégrée, de sorte que les développeurs livrent des applications sans implémenter leur propre gestion de clés ou pool de relays. Espy extrait les couleurs dominantes de la prise de vue de l’appareil photo en cartes de palettes partageables, découvrables via les flux Nostr standard.

Flotilla 1.6.4

Flotilla, le client Nostr style Discord de hodlbod qui organise les relays comme des groupes, a livré 1.6.4. La famille de projets Coracle a migré de GitHub vers une instance Gitea auto-hébergée. Cette version ajoute les notifications push via NIP-9a et un flux de réception de portefeuille, ainsi que les annonces classifiées et le support d’URL d’espace. Les améliorations d’interface incluent les modales nettoyées et la gestion des notifications. La mise en sourdine des salles et les encoches de zone de sécurité sur mobile complètent les changements, avec des correctifs pour les téléversements d’images Safari et les détails d’événements de calendrier.

Shosho v0.12.0

Shosho, l’application mobile de streaming en direct avec intégration Nostr, a livré v0.12.0. Cette version ajoute des Clips vidéo avec réponses dans le lecteur et intégration d’émojis personnalisés. La protection de fil bloque le spam de mentions indirectes, et une nouvelle fonctionnalité de partage QR permet aux utilisateurs d’échanger des profils hors ligne. Un nouveau mode de lecture horizontal donne aux flux une expérience de visionnage style Twitch, et l’écran de navigation présente maintenant les clips de créateurs aux côtés des flux en direct.

Granary v10.0

Granary, une bibliothèque de traduction du web social qui convertit des données entre Nostr, Bluesky, ActivityPub et d’autres plateformes dans un format commun, a livré v10.0 avec des changements cassants. La version bascule les IDs ActivityStreams 1 par défaut de Nostr de bech32 vers hex et ajoute un support Nostr étendu incluant l’analyse des mentions NIP-27 et les tags d’articles. Une nouvelle option de sortie multiple à travers les convertisseurs permet aux développeurs de traduire entre protocoles en lot.

Nostr MCP Server v3.0.0

Nostr MCP Server, un serveur Model Context Protocol qui permet aux agents IA d’interagir avec le réseau Nostr, a livré v3.0.0. Cette version majeure ajoute les actions sociales (abonnements, réactions, reposts, réponses) et la gestion des listes de relays avec le support NIP-65 plus l’authentification optionnelle NIP-42. La messagerie directe via NIP-17 et NIP-44 est également nouvelle. La version s’associe aux propositions de NIP pour agents IA de cette semaine comme outillage pratique pour les agents opérant sur Nostr.

Aegis v0.3.8

Aegis, le signataire Nostr multiplateforme, a livré v0.3.8 avec le support multilingue de l’interface et un gestionnaire de mises à jour incrémentales pour son navigateur d’applications Nostr intégré. Le nouveau mécanisme de mise à jour effectue des diffs incrémentaux par rapport à l’état local, maintenant le répertoire d’applications web Nostr dans l’application à jour avec une utilisation de bande passante réduite. La version introduit également un cache de matériel de clés de 5 minutes pour réduire les allers-retours en base de données lors de la signature de plusieurs événements consécutifs.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), une bibliothèque TypeScript pour le protocole Nostr, a livré v0.3.1. La version ajoute des gardes de vérification de paquets s’assurant que tous les points d’entrée sont inclus dans les archives npm, avec application CI sur Node et Bun. v0.3.0 a été livré la même semaine.

Citrine v2.0.0-pre1

Citrine, le relay Nostr Android de greenart7c3, a publié v2.0.0-pre1 avec des améliorations de performance via des index de base de données optimisés et une meilleure gestion des coroutines Kotlin. La version améliore également le support pour l’hébergement d’applications web, chaque application fonctionnant désormais sur son propre port.

Mises à jour des projets

Primal Android : expansion de l’infrastructure NWC

Primal Android a fusionné 11 PRs liés à NWC cette semaine, poursuivant la construction commencée il y a deux semaines. Ce lot ajoute le support NWC double portefeuille, le démarrage/arrêt automatique du service lié aux notifications backend, le routage des connexions par type de portefeuille, et un nettoyage correct des données lors de la suppression d’un portefeuille. Le service NWC gère maintenant son propre cycle de vie en fonction de l’état de connexion du portefeuille, réduisant l’intervention manuelle de l’utilisateur.

Notedeck : préparation pour l’App Store Android

Notedeck, le client Nostr multiplateforme de l’équipe Damus, a fusionné la préparation à la sortie sur l’App Store Android cette semaine. La PR ajoute un plan de conformité UGC (User Generated Content) requis par Google Play, incluant un écran d’acceptation des Conditions d’utilisation, le blocage d’utilisateurs via les menus contextuels et les paramètres, la fonctionnalité NIP-56 (Signalement) qui publie des événements de rapport aux relays, et une section Paramètres Contenu et Sécurité. Une infrastructure de build a été ajoutée pour générer des APK de publication signés et des AAB (Android App Bundles) via de nouvelles cibles Makefile. Un document EULA établit une exigence d’âge de 17 ans et des clauses de non-responsabilité spécifiques à Nostr concernant le contenu décentralisé. Les fonctionnalités de conformité elles-mêmes seront livrées dans des PRs de suivi ; cette fusion pose les bases de documentation et de signature.

Du côté de Damus iOS, un correctif a atterri pour une régression de spinner de chargement infini où le spinner persistait indéfiniment après le chargement du contenu.

Nostria : relays de découverte et correctifs DM

Nostria, le client Nostr multiplateforme axé sur l’échelle mondiale, a fusionné 9 PRs cette semaine. La plus notable ajoute l’auto-initialisation des Discovery Relays pour la recherche de profils, donnant aux nouveaux utilisateurs une connectivité relay fonctionnelle sans configuration manuelle. D’autres correctifs traitent du retour à la ligne dans les zones de texte DM, du remplissage du viewport en plein écran pour les vidéos, de l’extraction de métadonnées d’articles dans les aperçus de reposts et de la résolution d’URI nostr: dans les notifications.

Camelus : migration vers Riverpod v3

Camelus, le client Nostr basé sur Flutter, a fusionné 5 PRs cette semaine centrées sur une migration vers l’API Riverpod v3 et une refonte du flux générique. Un cache de notes intégrées évite les récupérations redondantes depuis les relays pour les notes citées.

Mises à jour des NIP

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

Fusionnés :

NIP-85 : Découverte des fournisseurs de services : vitorpamplona a ajouté des conseils sur la découverte par les clients des fournisseurs de services Trusted Assertions NIP-85, incluant les hints de relay et les clés de service spécifiques aux algorithmes. Voir l’approfondissement ci-dessous pour une couverture complète.
NIP-11 : Nettoyage des informations relay : fiatjaf a retiré privacy_policy, le tableau retention, relay_countries et le bloc de préférences communautaires de NIP-11. Les opérateurs de relay remplissaient rarement ces champs et les clients n’agissaient pas dessus.
NIP-52 : Tag de timestamp à granularité journalière : staab a ajouté un tag D obligatoire aux événements de calendrier basés sur l’heure NIP-52 (kind 31923) représentant le timestamp Unix à granularité journalière, calculé comme floor(unix_seconds / 86400). Plusieurs tags D couvrent les événements multi-jours, permettant une indexation temporelle efficace sans analyser les timestamps complets.
NIP-47 : Simplification : La PR de simplification discutée dans le Compass #9 a fusionné cette semaine, retirant multi_pay_invoice et multi_pay_keysend de NIP-47 (Nostr Wallet Connect). Voir le Compass #8 pour l’approfondissement complet du protocole NWC.

PRs ouvertes et discussions :

NIP-74 : Podcasts : Couvert dans le Compass #8, cette proposition de spécification de podcast a suscité une discussion animée cette semaine. staab a noté qu’au moins trois standards de podcast concurrents existent déjà dans la nature, et derekross a pointé vers une implémentation existante vieille de six mois avec des applications et podcasts actifs. La voie à suivre nécessite une convergence entre les implémentations avant qu’un numéro de NIP puisse être attribué.
NIP-XX : AI Agent Messages : joelklabo propose un protocole complet de communication d’agents IA avec des kinds d’événements pour les prompts, réponses, streaming, télémétrie d’outils, erreurs et découverte de capacités. Voir la section Actualités pour la couverture de toutes les propositions IA de cette semaine.
NIP-PNS : Stockage de notes privées : Le système de notes privées de jb55 définit des événements kind 1080 pour stocker des notes personnelles chiffrées sur les relays sans révéler qui les a écrites. Le schéma dérive une paire de clés pseudonyme déterministe depuis le nsec de l’utilisateur via HKDF : pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), puis génère une paire de clés secp256k1 à partir de cette clé dérivée. Une deuxième dérivation produit une clé de chiffrement symétrique : pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). Les notes internes sont chiffrées avec NIP-44 v2 en utilisant cette clé et publiées sous la pubkey pseudonyme, de sorte que les relays voient des événements kind 1080 d’une identité non liée à la clé principale de l’utilisateur. Contrairement aux gift wraps NIP-59, PNS n’est pas spammable (la clé pseudonyme est déterministe, pas aléatoire) et ne porte aucune métadonnée publique (aucun tag p nécessaire puisqu’il n’y a pas de destinataire). Cette semaine, jb55 a publié les résultats de l’implémentation de PNS dans le backend Rust de Notedeck (module enostr::pns). Il a identifié que l’appel hkdf_extract de la spec est ambigu car RFC 5869 HKDF comporte deux phases (Extract et Expand) qui produisent des sorties différentes, et la plupart des bibliothèques s’attendent aux deux. Il a précisé que pns_nip44_key contourne l’accord de clés ECDH normal de NIP-44 et est utilisé directement comme clé de conversation — un détail que les implémenteurs doivent connaître car la plupart des bibliothèques NIP-44 utilisent ECDH par défaut. Il a également signalé une variable non définie dans l’implémentation de référence TypeScript. La PR, datant à l’origine d’avril 2025, est maintenant en cours d’implémentation active.
NIP-AE : Agents : pablof7z définit quatre kinds d’événements pour l’identité des agents sur Nostr, tirés de son travail sur TENEX. Le template de base est kind 4199 (Agent Definition), portant le titre, la description du rôle, les instructions système, les déclarations d’outils et la version. Les modificateurs comportementaux vivent dans kind 4201 (Agent Nudge), qui utilise les tags only-tool, allow-tool et deny-tool pour le contrôle des capacités en exécution. Les agents publient ce qu’ils apprennent comme événements kind 4129 (Agent Lesson), catégorisés et liés à la définition parente via des tags e, affinables via des fils de commentaires NIP-22. La vérification de propriété utilise kind 14199, un événement remplaçable où les opérateurs humains listent les pubkeys de leurs agents, établissant une chaîne bidirectionnelle lorsque correspondant au tag p du profil kind 0 de l’agent.
NIP-AD : MCP Server and Skill Announcements : pablof7z définit des événements pour annoncer les serveurs Model Context Protocol et les compétences individuelles sur Nostr. Les annonces de serveurs MCP portent l’URL du point d’accès du serveur et la version de protocole supportée aux côtés d’une liste d’outils disponibles avec leurs schémas d’entrée. Les commentaires NIP-22 sont supportés sur les annonces de serveurs, permettant à la communauté de discuter et d’évaluer les serveurs MCP directement sur Nostr.
NIP-73 : Kind OSM : DestBro propose d’ajouter les identifiants OpenStreetMap à NIP-73 (External Content IDs), qui standardise comment les événements Nostr référencent le contenu externe comme les livres (ISBN), films (ISAN), flux de podcasts (GUID), géohashes et URLs via les tags i et k. Le kind OSM proposé permettrait aux événements de référencer des entités cartographiques spécifiques (bâtiments, routes, parcs) par leur ID de nœud ou de voie OpenStreetMap, connectant le contenu Nostr à la base de données géographique ouverte.
NIP-XX : Variantes d’images adaptatives : woikos propose d’étendre les événements de métadonnées de fichier NIP-94 avec des tags pour des variantes d’images adaptatives à différentes résolutions. Les clients pourraient sélectionner la variante appropriée en fonction de la taille d’affichage et des conditions réseau, réduisant la bande passante pour les utilisateurs mobiles consultant des images haute résolution hébergées sur des serveurs Blossom.

Approfondissement NIP : NIP-85 (Trusted Assertions)

NIP-85 définit un système pour déléguer des calculs coûteux à des fournisseurs de services de confiance qui publient des résultats signés comme événements Nostr. Les scores de Web of Trust et les métriques d’engagement nécessitent le parcours de nombreux relays et le traitement de grands volumes d’événements — un travail impraticable sur les appareils mobiles. La fusion de cette semaine a ajouté des conseils sur le processus de découverte des fournisseurs par les clients.

Délégation :

Le calcul du score de Web of Trust d’un utilisateur nécessite le parcours des graphes d’abonnements sur plusieurs sauts à travers de nombreux relays, et le comptage précis des followers implique la déduplication sur l’ensemble du réseau de relays. Les appareils mobiles et les clients de navigateur ne peuvent pas effectuer ces opérations, pourtant les résultats sont essentiels pour le filtrage du spam et le classement du contenu. NIP-85 comble cet écart en permettant aux utilisateurs de désigner des fournisseurs de confiance pour effectuer les calculs et publier les résultats comme événements Nostr standard.

Conception du protocole :

NIP-85 utilise quatre kinds d’événements pour les assertions sur différents types de sujets. Les assertions utilisateur (kind 30382) portent le nombre de followers, les comptages de publications/réponses/réactions, les montants de zaps, le rang normalisé (0-100), les sujets courants et les heures d’activité :

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Les assertions d’événements (kind 30383) évaluent des notes individuelles avec le nombre de commentaires, de citations, de reposts, de réactions et les données de zaps :

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Pour les événements adressables (articles longs, pages wiki), le kind 30384 applique les mêmes métriques d’engagement sur toutes les versions collectivement. Le kind 30385 évalue les identifiants externes (livres, films, sites web, lieux, hashtags) référencés via NIP-73 (External Content IDs), qui standardise comment les événements Nostr référencent le contenu externe via les tags i et k :

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Chaque assertion est un événement adressable remplaçable où le tag d contient le sujet : une pubkey, un ID d’événement, une adresse d’événement ou un identifiant NIP-73. Les fournisseurs de services signent ces événements avec leurs propres clés, et les clients les évaluent en fonction des relations de confiance.

Découverte des fournisseurs :

Les utilisateurs déclarent quels fournisseurs d’assertions ils font confiance en publiant des événements kind 10040. Chaque entrée spécifie le type d’assertion avec la pubkey du fournisseur et le hint de relay, plus des variantes d’algorithme optionnelles :

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Les utilisateurs peuvent chiffrer la liste de tags dans .content en utilisant NIP-44 pour garder leurs préférences de fournisseur privées. Les clients construisent une liste de fournisseurs en vérifiant quels fournisseurs font confiance à leurs comptes suivis, créant une couche de réputation décentralisée pour les fournisseurs d’assertions eux-mêmes.

Modèle de sécurité :

Les fournisseurs doivent utiliser des clés de service différentes pour des algorithmes distincts, et une clé unique par utilisateur lorsque les algorithmes sont personnalisés, empêchant la corrélation croisée des requêtes entre utilisateurs. Chaque clé de service obtient un événement de métadonnées kind 0 décrivant le comportement de l’algorithme, donnant aux utilisateurs une transparence sur ce en quoi ils font confiance. Les événements d’assertion ne doivent être mis à jour que lorsque les données sous-jacentes changent réellement, évitant le trafic inutile sur les relays et permettant aux clients de mettre les résultats en cache avec confiance.

Adoption actuelle :

NIP-85 formalise un modèle qui émergeait déjà de façon informelle. Le serveur cache de Primal calcule les métriques d’engagement et les scores de Web of Trust. Antiprimal, couvert dans le Compass #9, relie ces calculs aux clients Nostr standard en utilisant les kinds d’événements NIP-85. Nostr.band exploite le relay wss://nip85.nostr.band référencé dans les propres exemples de la spec, servant des événements d’assertion pour les données de son index de recherche. Côté client, Amethyst (écrit par vitorpamplona, qui a également rédigé ce NIP) dispose d’un support expérimental des Trusted Assertions dans sa bibliothèque quartz, analysant les événements d’assertion et les déclarations de fournisseurs de services. Vertex calcule des métriques similaires de Web of Trust mais a choisi une approche différente, utilisant une API directe plutôt que des événements NIP-85, citant le problème de découverte et la surcharge computationnelle des architectures basées sur les assertions. Avec NIP-85, tout client peut consommer des assertions de n’importe quel fournisseur via un format d’événement standard, et les fournisseurs se font concurrence sur la précision tandis que les utilisateurs choisissent en qui faire confiance.

Approfondissement NIP : NIP-52 (Événements de calendrier)

NIP-52 définit les événements de calendrier sur Nostr, donnant aux clients un moyen standard de représenter et de découvrir des occurrences à des moments spécifiques ou entre des moments. La fusion du tag D de cette semaine a ajouté l’indexation à la granularité journalière, complétant une pièce manquante dans l’infrastructure de requête de la spec.

Deux types d’événements :

NIP-52 sépare les événements de calendrier en deux kinds selon la précision temporelle. Les événements basés sur la date (kind 31922) représentent les occurrences sur la journée entière comme les jours fériés ou les festivals multi-jours. Ils utilisent des chaînes de date ISO 8601 dans leurs tags start et end optionnel, sans considération de fuseau horaire :

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Les événements basés sur l’heure (kind 31923) représentent des moments spécifiques avec des timestamps Unix dans leurs tags start et end optionnel, plus des identifiants de fuseau horaire IANA (start_tzid, end_tzid) pour l’affichage. Les deux kinds sont des événements remplaçables paramétrés, de sorte que les organisateurs mettent à jour les détails en publiant un nouvel événement avec le même tag d.

Calendriers et RSVP :

Les événements kind 31924 définissent les calendriers comme des collections, référençant les événements via des tags a pointant vers les événements kind 31922 ou 31923 par leurs coordonnées d’adresse :

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Les utilisateurs peuvent maintenir plusieurs calendriers (personnel, professionnel, communautaire) et les clients peuvent s’abonner aux calendriers de pubkeys spécifiques. Les événements de calendrier peuvent inclure un tag a référençant un calendrier pour demander leur inclusion, permettant une gestion collaborative des calendriers où plusieurs utilisateurs contribuent des événements aux calendriers qu’ils ne possèdent pas.

Les RSVP utilisent le kind 31925, où les utilisateurs publient leur statut de présence avec un indicateur libre/occupé optionnel :

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

Les valeurs de status valides sont « accepted », « declined », « tentative », et le tag fb optionnel marque l’utilisateur comme libre ou occupé pour cette période. Les événements RSVP référencent le tag a de l’événement de calendrier et portent le tag p de l’organisateur, de sorte que le client de l’organisateur peut agréger les réponses à travers les relays.

L’ajout du tag D :

Avant la fusion de cette semaine, les clients interrogeant des événements dans une plage de dates devaient récupérer tous les événements d’une pubkey ou d’un calendrier et filtrer côté client. Le nouveau tag D obligatoire sur les événements basés sur l’heure (kind 31923) contient un timestamp Unix à granularité journalière calculé comme floor(unix_seconds / 86400). Les événements multi-jours portent plusieurs tags D, un par jour. Les relays peuvent maintenant indexer les événements par jour et répondre à des requêtes filtrées efficacement, transformant ce qui était un problème de filtrage côté client en une recherche d’index côté relay.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

La valeur D de 20139 est égale à floor(1740067200 / 86400), plaçant cet événement le 20 février 2025. Les clients interrogeant pour « tous les événements de cette semaine » envoient un filtre avec la plage D correspondante, et les relays ne retournent que les événements correspondants.

Décisions de conception :

NIP-52 omet intentionnellement les événements récurrents. La spec laisse de côté les règles de récurrence (RRULE d’iCalendar), déléguant cette complexité aux clients. Un organisateur publie des événements individuels pour chaque occurrence, gardant le modèle de données côté relay simple. Les tags de participants portent des rôles optionnels (« host », « speaker », « attendee »), et les tags de localisation peuvent inclure des tags géohash g pour les requêtes spatiales aux côtés des adresses lisibles par l’humain.

Implémentations :

Flockstr est le principal client de calendrier construit sur NIP-52. Coracle affiche les événements de calendrier dans son flux social. L’ajout du tag D cette semaine permet l’indexation temporelle côté relay que les deux clients peuvent utiliser pour réduire la bande passante lors des requêtes d’événements dans une plage de dates spécifique.

C’est tout pour cette semaine. Vous construisez quelque chose ou avez des actualités à partager ? Vous souhaitez que nous couvrions votre projet ? Contactez-nous via NIP-17 DM ou retrouvez-nous sur Nostr.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Mostro livre sa première bêta publique après trois ans de développement, apportant le trading P2P de Bitcoin sur mobile via Nostr. OpenSats attribue sa seizième vague de subventions Bitcoin, avec Minibits Wallet recevant un renouvellement pour son portefeuille Cashu intégré à Nostr. Zapstore atteint sa version stable 1.0, marquant la maturation du magasin d’applications Android décentralisé. Coracle 0.6.29 ajoute les topics et les commentaires sur les highlights. Igloo Desktop v1.0.3 livre un renforcement majeur de la sécurité pour la signature à seuil Frostr. Amber v4.1.2-pre1 migre vers l’architecture Flow. Angor atteint v0.2.5 avec la refonte de l’interface de financement et la configuration de serveur d’images NIP-96. NostrPress se lance comme outil convertissant les profils Nostr en blogs statiques. Antiprimal livre la passerelle conforme aux standards qui relie le serveur cache propriétaire de Primal aux NIP Nostr standards. Primal Android fusionne 18 PRs étendant l’infrastructure NWC avec le support double portefeuille, la journalisation d’audit et la méthode lookup_invoice. diVine livre les flux vidéo API-first. Le SDK TypeScript Marmot extrait son application de chat de référence dans un dépôt autonome et commence la migration vers ts-mls v2. Le dépôt NIPs fusionne le comptage approximatif HyperLogLog pour NIP-45 et extrait les tags d’identité du kind 0. Plusieurs propositions de vitorpamplona commencent à alléger systématiquement les événements de métadonnées kind 0. Au niveau du protocole, on trouve Nostr Relay Connect pour la traversée NAT et Nostr Web Tokens pour les revendications web signées. En approfondissement, le nouveau comptage approximatif HyperLogLog de NIP-45 pour les métriques d’événements inter-relais et le protocole de stockage de fichiers HTTP NIP-96, désormais déprécié en faveur de Blossom, alors que certains projets gèrent la transition entre ces deux standards média.

Actualités

Mostro livre sa première bêta publique

Mostro, la place d’échange Bitcoin pair-à-pair construite sur Nostr, a publié son application mobile v1.1.0, la première bêta publique du projet après trois ans de développement. L’application permet aux utilisateurs d’échanger du Bitcoin directement en utilisant Nostr pour la coordination, avec Lightning pour le règlement et aucun intermédiaire custodial.

La version introduit les notifications push avec fiabilité améliorée en arrière-plan sur Android, un système de journalisation optionnel permettant aux utilisateurs de capturer et partager les données de diagnostic en cas de problème, la mise à jour de relais plus fluide via l’initialisation additive, et les raffinements UI Phase 2 avec le support de l’internationalisation. L’application est disponible sur Zapstore et en téléchargement direct GitHub.

Mostro rejoint Shopstr et Plebeian Market parmi les applications de commerce natives Nostr, avec la particularité de se concentrer sur la coordination d’échanges fiat-Bitcoin. Le daemon Mostro sous-jacent gère l’appariement et la résolution de litiges via les relais Nostr.

Seizième vague de subventions Bitcoin d’OpenSats

OpenSats a annoncé les subventions à 17 projets open-source. Le point pertinent ici : Minibits Wallet, le portefeuille Android Cashu avec le support d’événements de portefeuille NIP-60 et l’intégration nutzap, reçoit un renouvellement de subvention. Minibits utilise les événements Nostr pour stocker l’état ecash, rendant les sauvegardes de portefeuille portables entre appareils via la synchronisation par relay.

NostrPress : du profil Nostr au blog statique

NostrPress (blog.besoeasy.com) est un nouvel outil qui convertit un profil Nostr en blog entièrement statique déployable partout. On publie les articles sur Nostr via n’importe quel client, et NostrPress génère un site web autonome à partir de ces événements, avec l’hébergement local de médias et les flux RSS.

Construit avec Nunjucks et JavaScript, NostrPress produit un site libre de toute dépendance de plateforme. La sortie générée est du HTML/CSS brut hébergeable sur n’importe quel serveur de fichiers statiques, GitHub Pages, Netlify ou un VPS personnel. L’outil rejoint Npub.pro et Servus parmi les options transformant du contenu Nostr en sites web traditionnels.

Antiprimal : passerelle conforme aux standards vers le cache Primal

antiprimal (antiprimal.net), un nouveau projet d’Alex Gleason et de l’équipe Soapbox, est la passerelle WebSocket qui relie le serveur cache propriétaire de Primal aux messages du protocole Nostr standard. Primal offre les fonctionnalités comme les statistiques d’événements, la recherche de contenu et les calculs de Web of Trust via wss://cache.primal.net/v1, mais y accéder nécessite un format de message propriétaire avec un champ cache non standard que les clients Nostr standards ne peuvent pas utiliser. Antiprimal traduit les requêtes NIP standards vers le format de Primal et convertit les réponses en retour.

La passerelle supporte les requêtes COUNT NIP-45 (réactions, réponses, reposts, comptages de zaps, comptages de followers), la recherche NIP-50, l’information relay NIP-11 et les Trusted Assertions NIP-85 au service des données Web of Trust précalculées de Primal. Un bot compagnon publie les événements NIP-85 kind 30382 (statistiques utilisateur) et kind 30383 (engagement événement) vers les relais configurables. Le projet est construit en TypeScript sur Bun et utilise la bibliothèque Nostrify. Créé le 6 février, il compte 53 commits dans ses trois premiers jours de développement et est en ligne sur antiprimal.net.

Ikaros : passerelle de messagerie IA sur Signal et Nostr

Ikaros, un nouveau projet de l’équipe Soapbox, est la passerelle de messagerie permettant aux agents IA de communiquer via Signal et les DM chiffrés Nostr. Le pont utilise l’Agent Client Protocol (ACP) afin de connecter tout assistant de codage IA compatible ACP à de vrais réseaux de messagerie. Trois pull requests constituent la construction initiale du projet cette semaine.

La PR #1 implémente un adaptateur complet de DM chiffrés NIP-04 avec support d’envoi/réception, mise en tampon avec vidage explicite à la complétion, formats de clé privée nsec et hex, publication multi-relay avec reconnexion automatique, et un assistant de configuration interactif. L’adaptateur utilise nostr-tools v2.23.0 et met à jour le SDK ACP vers v0.14.1.

La PR #2 corrige la perte silencieuse de messages causée par un problème de concurrence de mise à jour de session : les notifications entrantes arrivant avant l’enregistrement d’une session dans la map étaient silencieusement perdues, et le correctif met ces notifications en tampon afin de les rejouer à la fin de l’enregistrement. La PR #3 ajoute les métadonnées de nom/UUID Signal aux interactions d’agent, afin que l’agent IA sache à qui il parle et dans quel groupe. Le projet ouvre un nouvel espace de conception : les agents IA adressables via DM Nostr qui sont aussi accessibles depuis Signal, et inversement.

Campagne d’allègement du Kind 0

vitorpamplona a ouvert cette semaine plusieurs PRs proposant l’extraction systématique de données du kind 0 (métadonnées utilisateur) vers les kinds d’événements dédiés. La campagne répond à un problème croissant : ces événements ont accumulé au fil du temps les champs que la plupart des clients n’utilisent pas, gonflant la taille de chaque récupération de profil.

La PR #2216 (fusionnée) déplace les tags d’identité (tags i) du kind 0 vers un nouveau kind 10011, puisque l’adoption de ces tags a été minimale. La PR #2213 propose de déplacer la vérification NIP-05 vers le kind 10008, ce qui permettrait aux utilisateurs d’avoir plusieurs identifiants NIP-05 et de filtrer par adresse NIP-05. La PR #2217 propose d’extraire les adresses Lightning (lud06/lud16) vers un nouveau kind, évitant que tous les utilisateurs de kind 0 ne transportent les champs liés aux zaps qui n’importent qu’aux clients avec intégration Lightning.

Ces propositions ont relancé la discussion sur la question plus large de la structure du kind 0, incluant la PR #1770, la proposition de longue date visant à remplacer le JSON stringifié dans le contenu du kind 0 par les tags structurés.

Support relay de NIP-70 : critique pour la messagerie chiffrée

L’implémentation White Noise du protocole Marmot a identifié un manque critique dans le support par les relais de NIP-70 (Protected Events) et NIP-42 (Authentication). Ses tests ont révélé que de grands relais publics, incluant Damus, Primal et nos.lol, rejettent les événements protégés directement avec l’erreur blocked: event marked as protected au lieu d’initier le défi d’authentification requis.

Cela brise la fonctionnalité de sécurité clé : NIP-70 permet la suppression sécurisée de KeyPackages MLS expirés, empêchant les attaques de type « capturer maintenant, déchiffrer plus tard ». En l’absence de support relay, les protocoles de messagerie chiffrée ne peuvent pas protéger leurs utilisateurs contre la compromission future de clés. White Noise a désactivé NIP-70 par défaut en réponse, conservant un drapeau optionnel destiné à ceux disposant de relais compatibles.

Appel aux opérateurs de relais : Implémentez le flux d’authentification NIP-42 complet. Lorsqu’un événement protégé arrive, défiez le client de prouver sa propriété, puis acceptez l’écriture validée. Rejeter les événements protégés directement brise les garanties de sécurité du protocole dont dépendent les applications de messagerie chiffrée.

Versions

Coracle 0.6.29

Coracle (coracle.social), le client web de hodlbod, a livré 0.6.29. La version ajoute l’affichage de topics et de commentaires sur les highlights kind 9802. Un nouvel élément de navigation donne un accès rapide aux listes curatées par l’utilisateur depuis l’interface principale. En interne, Coracle a été mis à jour vers la dernière version de Welshman, la bibliothèque Nostr partagée qui alimente la gestion de relais et le traitement d’événements de Coracle. La liste de relais par défaut a été rafraîchie, et le suivi d’erreurs Glitchtip a été retiré du code.

Igloo Desktop v1.0.3

Igloo Desktop, l’application de signature à seuil FROST et de gestion de clés, a livré v1.0.3 avec un renforcement extensif de la sécurité. La version introduit la validation IPC, l’isolation Electron et les vérifications de relais sensibles au SSRF contre la falsification de requêtes côté serveur. Un nouveau flux d’intégration et d’importation de parts simplifie la distribution de clés, la planification de relais inclut désormais la normalisation et la fusion par priorité, et l’architecture API Electron basée sur le preload améliore la frontière de sécurité entre le renderer et le processus principal. Un système de maintien en vie du signataire assure la stabilité en session de signature à seuil, et les améliorations UX de récupération réduisent la friction de la restauration de clés.

Amber v4.1.2-pre1

Amber, le signataire d’événements Android, a publié v4.1.2-pre1 corrigeant l’affichage manquant du score de confiance de relais introduit dans v4.1.1, résolvant les problèmes d’analyse JSON propres aux requêtes de chiffrement/déchiffrement non-Nostr, et migrant le modèle de compte de LiveData vers Flow afin d’obtenir une gestion d’état plus prévisible. La version bascule aussi les secrets bunker vers les UUIDs complets et passe à Gradle plugin 9.

Mostro Mobile v1.1.0 et Daemon v0.16.1

Voir la section Actualités ci-dessus au sujet de la version mobile. Sur le serveur, le daemon Mostro a livré v0.16.1, ajoutant la publication automatique de métadonnées NIP-01 kind 0 au démarrage (PR #575), de sorte que le daemon annonce son identité sur le réseau quand il se connecte. La version corrige aussi la documentation du calcul de frais de développement (PR #571).

Angor v0.2.5

Angor (angor.io), le protocole de financement P2P décentralisé construit sur Bitcoin et Nostr, a livré v0.2.5 avec trois PRs fusionnées. La PR #649 redessine la section de gestion de fonds (V2), remplaçant la mise en page précédente par la nouvelle interface suivant les UTXOs individuels et les positions d’investissement. La PR #651 révise l’InvoiceView avec les styles de boutons mis à jour, les dialogues fermables, la commande « Copier l’adresse », le support de l’annulation de surveillance d’adresses et un flux d’investissement amélioré. La PR #652 ajoute les serveurs d’images NIP-96 (spec) configurables dans les paramètres, permettant aux utilisateurs de choisir quel point d’accès de téléversement média gère les images et la documentation de leurs projets. La v0.2.4 a été livrée la semaine précédente.

Ridestr v0.2.2 et v0.2.3

Ridestr, la plateforme de covoiturage décentralisée couverte la semaine dernière, a poursuivi son itération rapide avec v0.2.2 (Bridge Payment Hotfix) et v0.2.3 suite à la v0.2.0 « RoadFlare Release ». Le hotfix v0.2.2 corrige un bug où les paiements bridge Cashu inter-mints annulaient automatiquement les courses pendant que le paiement était encore en traitement ou allait finalement aboutir, empêchant l’annulation prématurée lors de règlements lents. La version corrige aussi le scintillement de l’UI et les zones tactiles cassées sur le bouton « ma position ». La v0.2.3 livre les corrections de bugs supplémentaires. Chaque version inclut les APK séparés, l’un Ridestr (application passager) et l’autre Drivestr (application conducteur).

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), la bibliothèque d’aide PHP, a livré 1.9.4 ajoutant la propriété timeout configurable à la classe de requête (PR #106). Cela permet aux développeurs de définir les durées de timeout personnalisées lors de la connexion aux relais et lors de chaque requête de message, évitant les blocages indéfinis quand un relay ne répond pas ou est lent.

Zapstore v1.0.0

Zapstore (zapstore.dev), le magasin d’applications Android construit sur Nostr, a atteint son jalon de version stable 1.0 cette semaine après plusieurs mois de release candidates.

La version 1.0 inclut les améliorations de stabilité critiques : la gestion de l’état du bouton d’installation garantissant que Supprimer apparaît immédiatement après la fin de l’installation, les messages d’erreur conviviaux avec détails techniques extensibles, et un bouton « Signaler un problème » qui envoie les DM chiffrés via Nostr avec les clés éphémères. On trouve aussi un nouvel écran de mises à jour avec polling et suivi par lots, un meilleur watchdog de téléchargement destiné aux transferts bloqués, les limites de téléchargements concurrents dynamiques basées sur la performance de l’appareil, la synchronisation plus fréquente de paquets installés et la logique de comparaison de versions améliorée. L’équipe a corrigé un problème critique avec flutter_secure_storage et amélioré la gestion de cas limites du gestionnaire de paquets.

Ce jalon représente la maturation de la première plateforme de distribution d’applications dédiée de Nostr, permettant aux développeurs de publier les applications Android directement aux utilisateurs, en dehors du contrôle centralisé de magasins d’applications.

ZSP v0.3.1

ZSP, l’outil CLI en Go de l’équipe Zapstore qui remplace l’outillage de publication précédent afin de signer et téléverser les applications Android vers les relais Nostr, a publié v0.3.1. ZSP gère l’acquisition d’APK depuis GitHub, GitLab, Codeberg, F-Droid ou les fichiers locaux, puis analyse les métadonnées, signe les événements Nostr (via clé privée, bunker NIP-46, ou extension navigateur NIP-07), et téléverse les artefacts vers les serveurs Blossom. Cette version ajoute un mode hors ligne complet destiné à la liaison de keystore en l’absence de connexion réseau, les en-têtes Content-Digest sur les téléversements Blossom assurant la conformité au protocole, la correction de la détection d’APK arm64-v8a depuis les dépôts F-Droid, les corrections de paramètres de requête de fin sur GitLab, et le support complet de fichiers .env dans la configuration.

Damus iOS 1.17

Damus, le client iOS Nostr, est passé à la version 1.17 (PR #3606). La version corrige un problème de RelayPool où les connexions se fermaient après la libération du bail éphémère (PR #3605), ce qui pouvait causer l’interruption inattendue d’abonnements. Elle résout aussi un bug où la timeline de favoris n’affichait pas d’événements lors du changement d’onglets (PR #3603).

nak v0.18.3

nak, le couteau suisse Nostr en CLI, a livré v0.18.3 avec trois corrections de stabilité : prévention d’un panic quand les tags de challenge AUTH sont nil ou trop courts, vérification d’erreurs du dateparser avant d’utiliser la valeur analysée, et gestion d’URLs de mint Cashu manquant le séparateur ://.

Mi : relay local en navigateur

Mi (mi.shakespeare.wtf), un nouveau MiniApp Shakespeare, est un relay local en navigateur qui archive les événements Nostr d’un utilisateur dans IndexedDB. Mi récupère les profils (kind 0), les listes de contacts (kind 3), les listes de relais (kind 10002) et les événements de portefeuille depuis les relais connectés et stocke le tout localement, donnant un accès hors ligne à ses propres données. Construit avec React et nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), la plateforme décentralisée d’activisme et de collecte de fonds de l’équipe Soapbox, a livré v1.0.2 avec un APK Android disponible en téléchargement direct. C’est la première mention d’Agora dans Compass, le projet ayant été lancé le 17 janvier avec cette déclaration de mission : « Rejoignez le mouvement mondial et envoyez votre soutien aux activistes sur le terrain internationalement. »

La plateforme s’articule autour de la carte du monde où l’on parcourt par pays, crée les « actions » géolocalisées (manifestations, campagnes, organisation communautaire) et en discute via les commentaires en fil. Tout le contenu se propage via les relais Nostr, de sorte qu’aucun serveur central ne peut être mis hors ligne afin de faire taire la coordination. Agora supporte plusieurs langues avec la parité de traduction imposée par la CI, intègre les serveurs média Blossom aux téléversements et inclut la recherche, la navigation par hashtags avec bascule global/régional, les profils utilisateurs et les systèmes de réactions. La version v1.0.2 est le build Android actuel, disponible en téléchargement direct d’APK.

xonos v0.1.6

xonos, le client Nostr 3D expérimental construit avec le moteur de jeu Bevy, a livré v0.1.6. xonos affiche les événements Nostr dans un environnement spatial 3D avec les capacités de synthèse vocale, explorant comment les données de protocole social pourraient fonctionner en dehors d’interfaces 2D conventionnelles.

Mises à jour des projets

Primal Android étend l’infrastructure NWC

Primal Android a fusionné 18 PRs cette semaine, poursuivant la construction NWC commencée la semaine dernière. La PR #883 ajoute le support de connexions NWC à travers deux portefeuilles (Spark et externe), et la PR #879 implémente la méthode NWC lookup_invoice vérifiant le statut de paiements.

La PR #880 ajoute la journalisation d’audit requête-réponse NWC servant au débogage d’interactions portefeuille. La PR #877 ajoute le support multi-comptes à PrimalNwcService, permettant aux utilisateurs avec plusieurs profils de maintenir les connexions de portefeuille séparées. La PR #882 implémente le nettoyage périodique de réservations de budget expirées, empêchant les réservations de paiement périmées de bloquer le portefeuille.

Le travail sur l’UI inclut la refonte de l’écran de mise à niveau du portefeuille (PR #889), la FAQ de mise à niveau du portefeuille (PR #885), le réglage de l’adresse Lightning pendant l’intégration (PR #888) et un correctif empêchant les transactions de zap d’apparaître comme paiements réguliers dans les types non-Lightning (PR #887).

diVine livre les flux vidéo API-first

diVine, le client vidéo courte, a fusionné 19 PRs cette semaine, s’orientant vers l’architecture API-first. La PR #1468 introduit les flux vidéo API-first, et la PR #1466 ajoute les points d’accès API tendances, récents et accueil. La PR #1433 indexe les contrôleurs vidéo spécifiques permettant un rendu efficace de flux.

La gestion de profils s’est améliorée avec la PR #1440 implémentant un pattern cache-plus-frais lors de la consultation de profils tiers, réduisant le temps de chargement tout en assurant la fraîcheur de données. L’équipe a aussi livré les corrections de notifications (PR #1437), la refonte du flux de commentaires (PR #1431) et le balayage d’onglets sur l’écran Notifications (PR #1388).

White Noise : unification du trousseau de clés et recherche d’utilisateurs

Le backend White Noise du protocole Marmot a fusionné 4 PRs cette semaine. Deux PRs ont amélioré la gestion du trousseau de clés : la PR #468 rend l’identifiant du service de trousseau configurable via WhitenoiseConfig, et la PR #475 unifie l’implémentation sur un seul crate keyring-core avec les magasins natifs par plateforme, remplaçant le code fragmenté spécifique à chaque plateforme. Séparément, la PR #470 ajoute la fonctionnalité de recherche d’utilisateurs.

Marmot TS extrait l’application de chat de référence

Le SDK TypeScript Marmot (marmot-ts) a fusionné la PR #40, retirant l’application de chat de référence intégrée et la transférant dans un dépôt autonome : marmots-web-chat. Ce nouveau dépôt, créé le 6 février, est l’implémentation de référence du SDK TypeScript Marmot avec sa propre pipeline CI, la vue de chat à onglets et un système de build indépendant. La séparation permet au SDK de se concentrer sur les préoccupations de bibliothèque tandis que l’application de chat itère sur l’UX de façon indépendante.

La PR ouverte #41 migre marmot-ts vers ts-mls v2.0.0, apportant l’API redessinée avec les objets de contexte unifiés, de nouveaux utilitaires de gestion de messages (création d’événements, lecture, désérialisation), les helpers de métadonnées de key package et le support d’événements de suppression.

Mises à jour d’Alby Hub

Alby Hub a fusionné 5 PRs cette semaine. La PR #2049 ajoute un Alby CLI à l’interface du magasin d’applications. La PR #2033 corrige la gestion de données de zap invalides dans la liste de transactions, et la PR #2046 retire la méthode ListTransactions inutilisée de l’interface LNClient.

Notedeck livre le tableau de bord et Agentium

Notedeck, le client multiplateforme Nostr de Damus, a fusionné 6 PRs cette semaine. La PR #1247 ajoute un tableau de bord initial. La PR #1293 introduit Agentium, un environnement de développement multi-agents qui transforme l’assistant IA Dave en un système avec deux modes IA et la gestion d’agents par scène. La PR #1276 ajoute un composeur de messages multiligne avec les raccourcis clavier style Signal, et la PR #1278 livre les améliorations de performance média. Parmi les PRs ouvertes à noter : l’infrastructure outbox et la NIP-34 planification de l’application Git.

Agora livre la refonte majeure de l’UI

Agora a fusionné 7 PRs cette semaine aux côtés de sa version v1.0.2. La PR #106 est la plus conséquente, fermant 11 tâches UI à travers paramètres, édition de profil, interactions carte, résultats de recherche, filtrage de commentaires et gestion de serveurs Blossom. La fusion a désactivé les boutons de réaction destinés aux utilisateurs non authentifiés (qui obtenaient auparavant un échec silencieux en essayant de réagir aux publications sur la carte), corrigé le défilement de la carte sur la ligne de date et ajouté le texte en gras correspondant dans les résultats de recherche.

La PR #108 ajoute le comptage de commentaires sous les publications du flux et sur les pages de fils. La PR #107 ajoute le réessai automatique lors d’échecs de chargement d’événements avec un bouton de rechargement explicite quand toutes les tentatives sont épuisées. La PR #104 change la navigation par hashtags afin d’utiliser par défaut la portée globale, puisque la portée par pays précédente retournait souvent zéro résultat.

La PR #109 ajoute l’étape CI qui vérifie la parité de traductions à travers toutes les langues, faisant échouer le build si la moindre clé manque de valeur. La PR #110 tronque les notes longues dans les flux afin de préserver le rythme de défilement, et la PR #111 corrige un problème de zoom mobile iOS lors de la rédaction de commentaires sur les actions, causé par de petites tailles de police.

Clawstr livre un CLI et les boutons Lightning Zap

Clawstr, la plateforme inspirée de Reddit où les agents IA créent et gèrent les communautés sur Nostr, a fusionné 3 PRs cette semaine. La PR #11 remplace toutes les commandes nak manuelles dans la définition de compétences d’agents IA par le nouveau package @clawstr/cli (npx -y @clawstr/cli@latest), remplaçant la construction manuelle d’événements JSON par les commandes CLI et ajoutant les opérations de portefeuille (init, balance, zap, npc) et la recherche plein texte NIP-50.

La PR #13 ajoute la page de documentation « For Humans » et un composant ProfileZapDialog. Le bouton de zap apparaît sur les pages de profil quand un utilisateur a configuré son adresse Lightning et fonctionne en dehors de toute connexion, utilisant LNURL-pay directement avec les montants prédéfinis en sats et l’affichage de QR code. La PR #12 documente la commande wallet sync, expliquant comment les paiements vers les adresses Lightning sont retenus par NPC jusqu’à ce que les agents synchronisent explicitement leurs portefeuilles.

Mises à jour des NIP

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

Fusionnés :

NIP-45 : Réponse relay HyperLogLog - NIP-45 (Comptage d’événements) supporte désormais le comptage approximatif HyperLogLog (HLL). Un relay peut retourner les valeurs de registres HLL de 256 octets aux côtés de réponses COUNT. En fusionnant ces registres de plusieurs relais, un client calcule la cardinalité approximative en évitant de télécharger les ensembles complets d’événements. Le cas d’utilisation principal concerne le comptage de followers et de réactions en évitant de dépendre d’un seul relay comme source faisant autorité. Même deux événements de réaction consomment plus de bande passante que la charge utile HLL de 256 octets. Avec les corrections HyperLogLog++, la précision s’améliore sur de petites cardinalités.
NIP-39 : Tags d’identité déplacés du Kind 0 - Les tags de revendication d’identité NIP-39 (tags i) ont été extraits du kind 0 vers un nouveau kind 10011 dédié. La raison : presque aucun client ne supporte ces tags, ils ajoutent donc du poids à chaque récupération de kind 0 en apportant peu de valeur. C’est la première d’une série de PRs d’extraction du kind 0 de vitorpamplona (voir la section Actualités).

PRs ouvertes et discussions :

NIP-XX : Nostr Relay Connect (NRC) - woikos propose un protocole d’accès aux relais Nostr via un tunnel chiffré passant par un relay de rendez-vous public. Le mécanisme permet l’accès aux relais derrière NAT ou pare-feu, incluant les relais personnels fonctionnant sur un serveur domestique ou un appareil mobile. Le tunnel utilise les événements kind 24891/24892 avec le chiffrement NIP-44 à travers un relay de rendez-vous qui ne peut pas déchiffrer le trafic. Application pratique : tout client Nostr peut exposer un stockage local (IndexedDB, SQLite) comme point d’accès relay destiné à la synchronisation inter-appareils. La sémantique NIP-01 standard (REQ, EVENT, CLOSE, COUNT) traverse le tunnel de façon transparente. Des implémentations de référence existent en Go (ORLY Relay) et TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc propose les Nostr Web Tokens, un format d’événement Nostr transmettant les revendications signées entre parties web, inspiré de JSON Web Tokens (JWTs). NWT peut représenter à la fois NIP-98 (HTTP Auth) et les événements d’autorisation Blossom, donnant aux clients de la flexibilité sur la durée de validité de tokens. La bibliothèque de référence en Go est disponible. L’explication vidéo et la comparaison détaillée avec NIP-98 et Blossom Auth sont liées dans la PR.
Simplification de NIP-47 - rolznz propose de retirer les méthodes multi_ de NIP-47 (Nostr Wallet Connect), qui étaient complexes à implémenter et n’ont pas gagné en adoption. La PR réduit aussi la duplication dans le chiffrement et la gestion de la rétrocompatibilité, nettoyant la spécification après l’ajout de factures de rétention la semaine dernière.
NIP-05 : Déplacement vers un kind d’événement propre - vitorpamplona propose de déplacer la vérification NIP-05 du kind 0 vers un nouveau kind 10008, permettant plusieurs identifiants NIP-05 par utilisateur et le filtrage par adresse NIP-05. Fait partie de la campagne d’allègement du kind 0.
NIP-57 : Adresses Lightning depuis le Kind 0 - vitorpamplona propose d’extraire lud06/lud16 (adresses Lightning) du kind 0 vers un kind d’événement dédié par NIP-57, poursuivant l’effort d’allègement du kind 0.
Hyperpersonnalisation de profil - fiatjaf propose les capacités de personnalisation de profil étendues au-delà de ce que le kind 0 supporte actuellement.

Approfondissement NIP : NIP-45 (Comptage d’événements) et HyperLogLog

NIP-45 (spec) définit comment un client peut demander aux relais de compter les événements correspondant à un filtre en évitant de transférer les événements eux-mêmes. La fusion cette semaine du support HyperLogLog ajoute la structure de données probabiliste qui résout un problème fondamental : comment compter les éléments à travers plusieurs relais indépendants.

Le problème :

Compter les événements sur un seul relay est simple : on envoie la requête COUNT, on reçoit un nombre en retour. Compter à travers le réseau est plus difficile. Si le relay A rapporte 50 réactions et le relay B en rapporte 40, le total n’est pas 90 car beaucoup d’événements existent sur les deux relais. En l’absence de téléchargement complet servant à dédupliquer, un client ne peut pas calculer le vrai comptage.

HyperLogLog :

HyperLogLog (HLL) est un algorithme probabiliste qui estime le nombre d’éléments distincts dans un ensemble en utilisant une quantité fixe de mémoire. L’implémentation NIP-45 utilise 256 registres d’un octet chacun, consommant exactement 256 octets quel que soit le nombre d’événements comptés. L’algorithme fonctionne en examinant la représentation binaire de chaque ID d’événement et en suivant la position de zéros en tête. Un événement dont l’ID commence par beaucoup de zéros est statistiquement rare, donc son occurrence indique un grand ensemble.

Fonctionnement dans NIP-45 :

Un relay répondant à la requête COUNT peut inclure un champ hll contenant les valeurs de registres encodées en base64 :

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

Le client collecte les valeurs HLL de plusieurs relais et fusionne le tout en prenant la valeur maximale à chaque position de registre. Ce HLL fusionné représente l’union de tous les ensembles d’événements à travers les relais, gérant automatiquement la déduplication. L’estimation finale de cardinalité est calculée à partir de registres fusionnés.

Précision :

Avec 256 registres, l’erreur standard est d’environ 5,2%. Un vrai comptage de 1 000 donnera typiquement une estimation entre 948 et 1 052. Avec de plus grands comptages, l’erreur relative reste constante : un vrai comptage de 100 000 s’estimera à environ 94 800-105 200. Grâce aux corrections HyperLogLog++, la précision s’améliore aussi sur de petites cardinalités (sous environ 200), où l’algorithme de base tend à surestimer.

Importance :

Les métriques sociales (comptages de followers, de réactions, de reposts) sont au centre de tout client de médias sociaux. En l’absence de HLL, un client doit soit interroger un seul relay « de confiance » (centralisant le comptage), soit télécharger tous les événements de tous les relais (gaspillant la bande passante). HLL permet aux clients d’obtenir un bon comptage approximatif de plusieurs relais avec la surcharge totale de 256 octets par relay, quel que soit le comptage réel. Même deux événements de réaction consomment plus de bande passante qu’une charge utile HLL complète.

La spécification fixe le nombre de registres à 256 dans un souci d’interopérabilité. Tous les relais produisent les valeurs HLL que tout client peut fusionner, quelle que soit l’implémentation de relay. Cette standardisation signifie qu’on peut implémenter le support HLL en une fois et bénéficier de chaque relay qui le supporte.

Statut actuel :

La PR a été ouverte par fiatjaf et discutée pendant plusieurs mois avant d’être fusionnée cette semaine. Il faudra ajouter le calcul HLL aux gestionnaires COUNT dans les implémentations de relais, et la fusion HLL à la logique d’agrégation de comptages dans les clients.

Approfondissement NIP : NIP-96 (Stockage de fichiers HTTP) et la transition vers Blossom

NIP-96 (spec) définissait comment les clients Nostr téléversent, téléchargent et gèrent les fichiers sur les serveurs média HTTP. Désormais marqué comme « non recommandé » en faveur de Blossom (hébergement média basé sur BUD), NIP-96 reste pertinent cette semaine car Angor v0.2.5 a ajouté la configuration de serveur NIP-96 et ZSP v0.3.1 téléverse vers les serveurs Blossom, illustrant la transition de protocole en cours.

Fonctionnement de NIP-96 :

Un client découvre la capacité d’un serveur de fichiers en récupérant /.well-known/nostr/nip96.json, qui retourne l’URL de l’API, les types de contenu supportés, les limites de taille et les transformations média disponibles :

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

Le client téléverse via un POST multipart/form-data vers l’URL de l’API avec un en-tête d’autorisation NIP-98 (un événement Nostr signé prouvant l’identité de celui qui téléverse). Le serveur retourne la structure de métadonnées de fichier NIP-94 contenant l’URL du fichier, les hashes SHA-256 originaux et transformés, le type MIME et les dimensions :

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

On télécharge via les requêtes GET vers <api_url>/<sha256-hash>, avec les paramètres de requête optionnels activant les transformations côté serveur comme le redimensionnement d’images. La suppression passe par DELETE avec l’authentification NIP-98, et seul l’auteur original du téléversement peut supprimer ses fichiers. Un point d’accès de listing de fichiers retourne les résultats paginés de téléversements d’un utilisateur.

Chaque utilisateur publie les événements kind 10096 déclarant ses serveurs de téléversement préférés, permettant aux clients de sélectionner automatiquement le bon serveur en l’absence de configuration manuelle.

Raisons de la dépréciation :

NIP-96 liait les URLs de fichiers à un serveur spécifique. Si files.example.com tombait en panne, chaque note Nostr référençant ses URLs perdait ses médias. Le serveur était l’adresse, et l’adresse était fragile.

Blossom (Blobs Stored Simply on Mediaservers) inverse cette logique en faisant du hash SHA-256 du contenu du fichier l’identifiant canonique. L’URL Blossom ressemble à https://blossom.example/<sha256>.png, mais tout serveur Blossom hébergeant le même fichier le sert au même chemin de hash. Si un serveur disparaît, le client interroge un autre serveur demandant le même hash. L’adressage par contenu rend les données portables entre serveurs par défaut.

Blossom simplifie aussi l’API. NIP-96 utilisait les téléversements de formulaires multipart avec les réponses JSON, les politiques de transformation et un point de découverte. Blossom utilise un simple PUT aux téléversements, GET aux téléchargements, et les événements Nostr signés à l’autorisation. La spécification Blossom est divisée en documents modulaires : BUD-01 couvre le protocole serveur, l’autorisation et la récupération, BUD-02 couvre le téléversement de blobs, BUD-03 couvre les serveurs utilisateurs, et BUD-04 couvre le mirroring entre serveurs.

La dépréciation a eu lieu en septembre 2025 via la PR #2047, qui a marqué NIP-96 comme « non recommandé » dans l’index de NIPs.

La transition en pratique :

Nostr.build et void.cat supportaient NIP-96 et ont ajouté ou migré vers les points d’accès Blossom. Sur le plan client, la version v0.2.5 d’Angor cette semaine a ajouté la configuration de serveur NIP-96 applicable aux images de projets, tandis que la version v0.3.1 de ZSP téléverse les artefacts exclusivement vers les serveurs Blossom avec les en-têtes Content-Digest assurant la conformité au protocole. Amethyst et Primal supportent les téléversements Blossom. La coexistence continuera probablement jusqu’à ce que toutes les implémentations NIP-96 restantes achèvent leur migration.

Ce qui perdure :

Les événements de préférence de serveur kind 10096 restent utiles à la sélection de serveur Blossom. Les métadonnées de fichier NIP-94 (événements kind 1063) décrivent toujours les propriétés de fichiers quel que soit le protocole de téléversement qui a servi à les créer. Le hachage SHA-256 que NIP-96 utilisait aux URLs de téléchargement est devenu le fondement de l’adressage par contenu de Blossom. La conception de NIP-96 a éclairé ce que Blossom a simplifié : la leçon était que l’hébergement média sur un réseau décentralisé nécessite un stockage adressé par contenu afin de correspondre à la résistance à la censure de la couche relay.

C’est tout pour cette semaine. Envoyez vos actualités et propositions de projets à couvrir via NIP-17 DM ou trouvez-nous sur Nostr.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : rust-nostr livre une refonte majeure de l’API avec 21 PRs révisant l’architecture du SDK. Nostria 3.0 lance avec la navigation à double volet, la gestion des listes et une refonte complète de l’interface. Vector ajoute l’accélération SIMD atteignant des gains de 65x à 184x et livre le support du protocole Marmot pour la messagerie de groupe chiffrée. Frostr apporte la signature à seuil sur iOS via TestFlight. Damus implémente les indices de relais NIP-19 (Entités encodées Bech32) pour la découverte de contenu inter-relais. Primal Android ajoute le chiffrement NWC et les exports de transactions du portefeuille. nostr-tools et NDK reçoivent des améliorations de fiabilité. NIP-82 (Applications logicielles) s’étend pour couvrir 98% des plateformes d’appareils. Le dépôt NIPs fusionne le support des factures de rétention pour NIP-47 (Nostr Wallet Connect). Les nouvelles propositions de protocole incluent NIP-74 pour les podcasts, NIP-DB pour les bases de données d’événements navigateur et une suite TRUSTed Filters pour la curation de contenu décentralisée. Les nouveaux projets incluent Instagram to Nostr v2 pour la migration de contenu, Pod21 lançant une place de marché d’impression 3D décentralisée, Clawstr introduisant des communautés gérées par agents IA, et Shosho et NosCall étendant les capacités de streaming en direct et d’appels vidéo.

Actualités

rust-nostr livre une refonte majeure de l’API

Le SDK rust-nostr a subi une refonte architecturale significative cette semaine avec 21 PRs fusionnées introduisant des changements cassants à travers la bibliothèque. La refonte affecte les APIs principales sur lesquelles la plupart des développeurs Rust comptent.

PR #1245 redessine les APIs de notification, tandis que PR #1244 remplace RelayNotification::Shutdown par RelayStatus::Shutdown pour une gestion d’état plus propre. Les APIs de signataire s’alignent maintenant avec les autres patterns du SDK via PR #1243. Les méthodes Client et Relay ont été nettoyées dans PR #1242, et les options client utilisent maintenant un pattern builder (PR #1241).

Les APIs d’envoi de messages ont été redessinées dans PR #1240, le désabonnement REQ dans PR #1239, et la suppression de relais dans PR #1229. Une PR ouverte #1246 ajoute le support des APIs bloquantes pour compléter la refonte.

Les changements apportent de la cohérence au SDK mais nécessiteront un effort de migration de la part des projets existants. Les développeurs construisant sur rust-nostr devraient examiner attentivement le changelog avant de mettre à jour.

Instagram to Nostr v2 permet la migration de contenu

Un nouvel outil permet aux créateurs de migrer leur contenu existant des plateformes centralisées vers Nostr. Instagram to Nostr v2 supporte l’import depuis Instagram, TikTok, Twitter et Substack sans nécessiter l’accès aux clés privées de l’utilisateur.

L’outil répond à une barrière d’intégration courante : les utilisateurs hésitants à repartir de zéro sur une nouvelle plateforme peuvent maintenant préserver leur historique de contenu. Il supporte également l’offre de comptes Nostr à de nouveaux utilisateurs ou la proposition de contenu à des comptes existants, le rendant utile pour aider les autres à transitionner vers le protocole.

Pod21 : Réseau d’impression 3D décentralisé

Pod21 (pod21.com) connecte les opérateurs d’imprimantes 3D avec les acheteurs en utilisant Nostr pour la coordination de la place de marché. La plateforme inclut un bot DM compatible NIP-17 (Messages directs privés) qui gère les interactions de la place de marché, permettant aux acheteurs de demander des impressions et de négocier avec les fabricants via des messages directs chiffrés.

Les fabricants listent leur capacité et leurs capacités d’impression ; les acheteurs parcourent les annonces et initient les commandes via le bot. L’architecture suit un pattern similaire aux autres applications de commerce Nostr : découverte basée sur les relais, messagerie chiffrée pour la coordination des commandes et Lightning pour le règlement. Pod21 rejoint Ridestr et Shopstr comme applications Nostr coordonnant des transactions du monde réel via le protocole.

Clawstr se lance comme une plateforme inspirée de Reddit où des agents IA créent et gèrent des communautés sur Nostr. La plateforme permet aux agents autonomes d’établir des communautés thématiques, de curer le contenu et d’interagir avec les utilisateurs. Les communautés fonctionnent comme des subreddits mais avec des modérateurs et curateurs IA guidant les discussions. L’architecture utilise le protocole ouvert de Nostr pour les interactions agent-à-agent et agent-à-humain, établissant un nouveau modèle pour la formation de communautés sur les médias sociaux décentralisés.

Versions

Ridestr v0.2.0 : Version RoadFlare

Ridestr a livré v0.2.0, baptisée la “Version RoadFlare”, introduisant les réseaux de covoiturage personnels. La fonctionnalité permet aux passagers d’ajouter leurs conducteurs favoris à un réseau de confiance. Les conducteurs approuvent les abonnés et partagent des localisations chiffrées, permettant aux passagers de voir quand les conducteurs de confiance sont en ligne et à proximité. Les demandes de trajet vont directement aux conducteurs connus.

La fiabilité des paiements s’est améliorée avec la récupération automatique de séquestre, une meilleure synchronisation du portefeuille entre appareils et un traitement des paiements plus rapide via le polling progressif. PR #37 ajoute l’infrastructure Phase 5-6 supportant ces fonctionnalités. v0.2.1 a suivi avec des corrections pour les bugs de dialogue de paiement et le flux “Ajouter aux favoris” après trajet.

Nostria 3.0

Nostria, le client multiplateforme de sondreb conçu pour l’échelle mondiale, a livré la version 3.0 avec une refonte complète de l’interface, un nouveau logo et des centaines de corrections. La version représente un cycle de développement intensif de six semaines.

La navigation à double volet est le plus grand changement UX, permettant aux utilisateurs de bureau de réduire les changements de contexte lors des déplacements entre listes, détails et fils de discussion. Une nouvelle section Accueil fournit une vue d’ensemble de toutes les fonctionnalités disponibles, et tous les écrans partagent une barre d’outils, une mise en page et des fonctionnalités unifiées.

La gestion des listes est la mise à jour de fonctionnalité la plus significative, intégrée dans toute l’application. Les utilisateurs peuvent gérer les listes de profils et filtrer le contenu dans n’importe quelle fonctionnalité : Streams, Musique ou Flux. Fatigué du spam dans les fils de discussion ? Filtrez par favoris pour ne voir que leurs réponses. Quick Zaps ajoute le zapping en un tap avec des valeurs configurables. Copier/Capture d’écran génère des captures d’écran pour le presse-papiers pour partager des événements n’importe où. Mots masqués filtre maintenant sur les champs de profil (name, display_name, NIP-05), permettant aux utilisateurs de bloquer tous les profils relayés avec un seul mot banni. Les paramètres sont devenus recherchables pour des changements de configuration plus rapides.

La version ajoute le rendu des demandes de paiement BOLT11 et BOLT12, la sélection de taille de texte et de police, et la messagerie “Note-à-soi-même” dans la section Messages avec le rendu du contenu référencé comme les articles et événements. Le nouveau dialogue de partage permet un partage rapide par email, sites web ou messages directs vers plusieurs destinataires. Les fonctionnalités additionnelles incluent les ensembles d’emoji personnalisés, les Intérêts (listes de hashtags comme flux dynamiques), les Favoris, les Flux de relais publics et la personnalisation complète du menu incluant quelle option l’icône Nostria ouvre.

Disponible sur Android, iOS, Windows et web sur nostria.app.

Applesauce v5.1.0

La suite de bibliothèques Applesauce de hzrd149 a publié v5.1.0 pour tous les packages. applesauce-signers ajoute le support des méthodes switch_relays et ping sur les signataires distants Nostr Connect, utile pour gérer les connexions de signataires de manière programmatique. applesauce-loaders introduit loadAsyncMap pour le chargement asynchrone parallèle. applesauce-react ajoute des arguments de remplissage à useAction().run(). applesauce-core met à jour le mapping event-to-store pour gérer les chaînes directement sans nécessiter onlyEvents.

nak v0.18.3

nak (Nostr Army Knife) de fiatjaf a atteint v0.18.3 avec des corrections de stabilité de mattn. La version prévient les panics quand les URLs de mint manquent le séparateur ://, valide les erreurs de dateparser avant d’utiliser les valeurs de date et gère les cas limites dans l’analyse des tags de challenge AUTH. Ces corrections défensives rendent le CLI plus résilient lors du traitement d’entrées malformées.

Aegis v0.3.7

Aegis, le signataire de bureau multiplateforme, a livré v0.3.7 ajoutant le support du navigateur d’applications Nostr avec la signature NIP-07 (Interface d’extension navigateur). La version enregistre les événements de chiffrement NIP-04 (Messages directs chiffrés) et NIP-44 (Chiffrement versionné), permettant aux utilisateurs de suivre quelles applications demandent des opérations de chiffrement. Le segment navigateur filtre maintenant par plateforme pour n’afficher que les applications web.

Bitchat v1.5.1 (iOS)

Bitchat, l’application de messagerie capable de fonctionner hors ligne utilisant Nostr et le mesh Bluetooth, a publié v1.5.1 avec un renforcement de la sécurité iOS. PR #1012 valide les signatures d’événements Nostr avant le traitement, rejette les giftwraps et paquets intégrés invalides, plafonne les charges utiles surdimensionnées et bloque les IDs d’expéditeur BLE annonce usurpés. PR #998 corrige l’authentification mesh BLE iOS en liant les IDs d’expéditeur aux UUIDs de connexion, empêchant l’usurpation d’identité dans le réseau mesh. PR #972 ajoute la limitation du taux de notifications pour prévenir les inondations de découverte de pairs quand plusieurs appareils mesh sont à proximité.

KeyChat v1.39.2

KeyChat a publié v1.39.2 ajoutant le support NIP-47 Nostr Wallet Connect via PR #148. Les utilisateurs peuvent maintenant connecter des portefeuilles Lightning externes pour les paiements dans l’application de messagerie. La version ajoute également les notifications de bureau macOS.

Nostrmo v3.5.0

Nostrmo, le client Flutter multiplateforme, a livré v3.5.0 révisant son système de flux. La mise à jour remplace les flux fixes par des alternatives personnalisables : Flux général, Flux de mentions et Flux de relais, chacun configurable via de nouvelles pages d’édition. La version implémente le support du modèle outbox pour un meilleur routage des événements et étend la fonctionnalité de relais local avec des limites de taille configurables et le support des abonnements.

Shosho v0.11.1

Shosho, l’application de streaming en direct pour Nostr, a publié v0.11.1 avec des capacités d’enregistrement et VOD. La mise à jour ajoute des indicateurs de présence dans la salle montrant qui regarde les streams, des conversations de chat en fil pour une meilleure organisation des discussions et le support Nostr Connect sur iOS via NIP-46. Les streamers peuvent maintenant sauvegarder leurs diffusions pour une visualisation ultérieure tout en maintenant des interactions de chat en temps réel avec leur audience.

NosCall v0.5.0

NosCall, l’application d’appels audio et vidéo pour Nostr, a livré v0.5.0 avec des groupes de contacts pour organiser les appels par catégorie, la gestion des relais pour l’optimisation des connexions et des paramètres de serveur ICE configurables pour une meilleure traversée NAT. La version ajoute également le support du mode sombre. NosCall utilise Nostr pour la signalisation et la coordination des appels, permettant des appels pair-à-pair sans serveurs centralisés.

diVine 1.0.4

diVine, le client vidéo courte en boucle de rabble, a publié 1.0.4 comme pré-version alpha Android avant sa soumission Zapstore. La version se concentre sur les tests de gestion des clés Nostr, incluant l’import nsec, la signature à distance NIP-46 (Nostr Connect) avec nsecBunker et Amber, et la gestion des URLs nostrconnect://. L’équipe sollicite des retours sur la compatibilité des relais et l’interopérabilité vidéo avec d’autres clients. PR #1265 corrige la gestion des chemins de fichiers iOS qui causait l’inutilisabilité des clips vidéo après les mises à jour de l’application en stockant des chemins relatifs au lieu de chemins absolus de conteneur. PR #1251 corrige les problèmes de navigation lors de la visualisation des profils depuis les commentaires.

Zeus v0.12.2

Zeus a livré v0.12.2 comme version stable, consolidant les corrections NWC couvertes dans les éditions précédentes.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) a lancé Igloo pour iOS sur TestFlight, étendant la signature à seuil aux appareils Apple. Frostr utilise les signatures FROST (Flexible Round-Optimized Schnorr Threshold) pour diviser les clés nsec en parts distribuées entre les appareils, permettant la signature k-sur-n avec tolérance aux pannes. Les utilisateurs rejoignant en “mode démo” participent à une expérience de signature à seuil 2-sur-2 en direct, démontrant les capacités de coordination en temps réel du protocole. La version iOS rejoint Igloo pour Android (v0.1.2), livrée en décembre avec le support NIP-55 (Signataire Android) pour les demandes de signature inter-applications. Les deux clients mobiles complètent Igloo desktop et l’extension navigateur Frost2x.

Mises à jour des projets

Damus implémente les indices de relais NIP-19

Damus a fusionné PR #3477, implémentant la consommation d’indices de relais NIP-19 pour la récupération d’événements. La fonctionnalité permet de visualiser des notes sur des relais n’étant pas dans le pool configuré de l’utilisateur en extrayant les indices de NIP-10 (Fils de réponse), NIP-18 (Reposts) et des références NIP-19. L’implémentation utilise des connexions de relais éphémères avec un nettoyage par comptage de références, évitant l’expansion permanente du pool de relais.

Les corrections additionnelles incluent l’analyse des factures Lightning (PR #3566), le chargement de la vue portefeuille (PR #3554), le timing de la liste de relais (PR #3553) et le préchargement des profils pour réduire le “popping” visuel (PR #3550). Une PR brouillon #3590 montre le support DM privé NIP-17 en cours.

Primal Android livre le chiffrement NWC

Primal Android a eu une semaine très active avec 18 PRs fusionnées axées sur l’infrastructure de portefeuille. L’application s’intègre maintenant avec Spark, le protocole Lightning auto-custodial de Lightspark. PR #874 ajoute le support du chiffrement NWC, tandis que PR #872 envoie des événements info NWC quand les connexions s’établissent.

PR #870 permet l’export CSV pour les transactions du portefeuille, utile pour la comptabilité et les impôts. PR #716 ajoute un sélecteur de compte local dans l’éditeur de notes. Plusieurs corrections de restauration de portefeuille (PR #876, PR #875, PR #873) traitent les cas limites pour les utilisateurs avec des configurations de portefeuille non-Spark.

Le SDK TypeScript Marmot ajoute l’historique des messages

L’implémentation TypeScript du protocole Marmot continue son développement. PR #38 par hzrd149 implémente la persistance de l’historique des messages avec pagination pour l’application de chat de référence, tandis que PR #39 améliore l’ergonomie de la bibliothèque.

Côté Rust, PR #161 implémente la gestion d’état récupérable pour préserver le contexte des messages en cas d’échec, et PR #164 passe à std::sync::Mutex pour éviter les panics tokio avec SQLite. Le backend whitenoise-rs ajoute l’intégration Amber (PR #418), met à niveau vers MDK et nostr-sdk 0.44 (PR #467) et introduit le streaming de notifications en temps réel via PR #460 avec les types d’événements NewMessage et GroupInvite.

HAVEN ajoute le rafraîchissement périodique WoT

HAVEN, le relais personnel, a fusionné PR #108 ajoutant le rafraîchissement périodique Web of Trust. La fonctionnalité assure que les scores de confiance restent à jour à mesure que les graphes sociaux des utilisateurs évoluent, améliorant la précision du filtrage de spam au fil du temps.

nostr-tools

nostr-tools, la bibliothèque JavaScript principale, a reçu plusieurs améliorations cette semaine. Les commits incluent une correction pour l’analyse des hashtags après les sauts de ligne dans les mentions NIP-27 (Références de notes textuelles), l’élagage automatique des objets relay cassés avec suivi d’inactivité pour le nettoyage des connexions, la suppression de la file de messages pour l’optimisation des performances mono-thread et les exports de fichiers source pour de meilleurs imports TypeScript.

NDK

NDK a livré beta.71 avec une correction pour la reconnexion après les cycles veille/réveil de l’appareil et la gestion des connexions périmées, traitant les problèmes de fiabilité pour les applications mobiles.

Notedeck

Notedeck, le client de bureau de l’équipe Damus, a une PR ouverte #1279 ajoutant un visualiseur NIP-34 (Collaboration Git). Cela permettrait de parcourir les dépôts git, patches et issues publiés sur les relais Nostr directement dans le client, faisant de Notedeck un potentiel front-end pour les flux de travail basés sur ngit.

njump

njump, la passerelle web Nostr, a ajouté le support de deux types d’événements NIP-51 (Listes) via PR #152. La passerelle affiche maintenant les kind:30000 Follow Sets, qui sont des regroupements catégorisés d’utilisateurs que les clients peuvent afficher dans différents contextes, et les kind:39089 Starter Packs, qui sont des collections de profils curatées conçues pour le partage et le suivi en groupe. Ces ajouts permettent à njump d’afficher des listes curatées par la communauté quand les utilisateurs partagent des liens nevent.

Amethyst

Amethyst, le client Android, a corrigé un bug empêchant le partage vidéo depuis la vue lecteur (PR #1695). L’option “Partager vidéo” n’apparaissait pas parce que le paramètre content n’était pas passé au composant des boutons de contrôle. Les utilisateurs peuvent maintenant partager du contenu vidéo Nostr vers d’autres applications directement depuis le lecteur. PR #1693 corrige les crashs de désérialisation Jackson JSON qui se produisaient lors de l’analyse de certains événements malformés.

Jumble

Jumble, le client web axé sur la navigation des flux de relais, a ajouté les uploads de fichiers audio via le presse-papiers dans PR #743. Les utilisateurs peuvent maintenant coller des fichiers audio directement dans l’éditeur de post, qui les uploade vers les serveurs médias configurés et intègre l’URL dans la note. La fonctionnalité reflète la fonctionnalité existante de collage d’images.

Flotilla

Flotilla, le client de communautés NIP-29 (Groupes basés sur les relais) de hodlbod, a livré les notifications via PR #270. La mise à jour refactorise le système d’alertes du polling basé sur les ancres vers les notifications pull locales pour le web et les notifications push pour le mobile. L’architecture implémente le standard NIP-9a proposé (voir PR #2194 ci-dessous), où les utilisateurs enregistrent des callbacks webhook avec les relais et reçoivent des charges utiles d’événements chiffrées quand les filtres correspondent.

Formstr

Formstr, l’application de formulaires native Nostr, a ajouté l’import de formulaires et le support des formulaires chiffrés dans PR #422. Les utilisateurs peuvent maintenant importer des formulaires existants via un lien de réponse ou depuis d’autres instances Formstr. La fonctionnalité de chiffrement permet aux créateurs de formulaires de restreindre les réponses afin que seuls les destinataires désignés puissent lire les soumissions, utile pour les sondages collectant des informations sensibles.

Pollerama

Pollerama (pollerama.fun), construit sur nostr-tools, a ajouté le partage de sondages par DM NIP-17 via PR #141 et PR #142. Les utilisateurs peuvent maintenant partager des sondages directement aux contacts via des messages directs chiffrés.

Nostrability Schemata

Nostrability schemata, la collection de schémas de vérification JSON pour les événements Nostr, a ajouté la couverture NIP-59 (Gift Wrap) via PR #59. La mise à jour inclut les schémas pour les événements kind 13 (seal) et kind 1059 (gift wrap), complétant la couverture existante des schémas NIP-17.

Vector

Vector, le messager de bureau axé sur la confidentialité utilisant NIP-17, NIP-44 et NIP-59 pour le chiffrement sans métadonnées, a fusionné PR #39 introduisant des optimisations de performance accélérées par SIMD. L’encodage hex s’exécute 65x plus vite, la génération d’aperçus d’images jusqu’à 38x plus vite et les recherches de messages 184x plus vite via l’indexation par recherche binaire. La PR ajoute les intrinsèques ARM64 NEON pour Apple Silicon et x86_64 AVX2/SSE2 avec détection runtime pour Windows et Linux. L’utilisation mémoire a chuté avec les structs de messages réduits de 472 à 128 octets et le stockage npub réduit de 99,6% grâce à l’internement.

Vector v0.3.0 (décembre 2025) a intégré MDK (Marmot Development Kit) pour la messagerie de groupe basée sur le protocole MLS, apportant des groupes chiffrés de bout en bout avec confidentialité persistante au client. Le partage de fichiers MIP-04 gère maintenant les pièces jointes imeta pour les groupes MLS, conçu pour l’interopérabilité avec White Noise. La version a également introduit une plateforme Mini Apps avec des jeux multijoueurs P2P basés sur WebXDC, un app store décentralisé appelé The Nexus, l’intégration du portefeuille PIVX pour les paiements in-app, l’édition de messages avec suivi complet de l’historique et une réduction de 4x de la mémoire pendant les uploads d’images.

Mises à jour des NIP

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

Fusionnés :

NIP-47 : Support des factures de rétention - NIP-47 (Nostr Wallet Connect) supporte maintenant les factures de rétention, permettant des flux de paiement avancés où les receveurs doivent explicitement régler ou annuler les paiements. La PR ajoute trois nouvelles méthodes RPC : make_hold_invoice crée une facture de rétention en utilisant une préimage pré-générée et un hash de paiement, settle_hold_invoice réclame le paiement en fournissant la préimage originale, et cancel_hold_invoice rejette le paiement en utilisant son hash de paiement. Une nouvelle notification hold_invoice_accepted se déclenche quand un payeur verrouille le paiement. Cela permet des cas d’usage comme le contenu pay-to-unlock, les systèmes de séquestre de place de marché et le gating de paiement. Les implémentations sont déjà en cours dans Alby Hub, Alby JS-SDK et dart NDK.
NIP-05 : Exigence de minuscules - NIP-05 (Vérification de domaine) exige maintenant explicitement les minuscules pour les clés publiques hex et les noms locaux dans le fichier nostr.json. C’était implicite dans la spécification mais non déclaré, causant des problèmes d’interopérabilité quand certaines implémentations utilisaient des casses mixtes tandis que d’autres normalisaient en minuscules. Les clients validant les identifiants NIP-05 devraient maintenant rejeter toute réponse nostr.json contenant des caractères majuscules dans les clés ou noms.
NIP-73 : Codes pays - NIP-73 (Géotags) supporte maintenant les codes pays ISO 3166 comme alternative aux geohashes. Les événements peuvent inclure des tags ["g", "US", "countryCode"] pour indiquer la localisation au niveau du pays sans nécessiter de coordonnées précises. Cela permet le filtrage et la découverte de contenu basés sur le pays pour les applications où la localisation exacte est inutile ou indésirable. La PR a également ajouté un exemple de geohash manquant à la documentation de la spécification.

PRs ouvertes et discussions :

NIP-82 : Applications logicielles - franzap a annoncé une mise à jour majeure de cette spécification brouillon, qui définit comment les applications logicielles sont distribuées via Nostr en utilisant des événements release kind 30063. La mise à jour couvre maintenant environ 98% des plateformes d’appareils globalement, incluant macOS, Linux, Windows, FreeBSD, les environnements WASM, les extensions VS Code, les extensions Chrome et les Web Bundles/PWAs. L’équipe se concentre ensuite sur le support Android, PWA et iOS, invitant les développeurs à converger vers ce standard partagé. Zapstore prévoit de migrer vers le nouveau format dans les semaines à venir.
NIP-74 : Podcasts - Définit des événements adressables pour les émissions de podcast (kind 30074) et les épisodes (kind 30075). Les émissions incluent des métadonnées comme le titre, la description, les catégories et les images de couverture. Les épisodes référencent leur émission parente et incluent les URLs d’enclosure, les durées et les marqueurs de chapitres. La spécification s’intègre avec les standards de métadonnées Podcasting 2.0 et inclut des tags value pour la monétisation V4V (value-for-value) via Lightning. Des plateformes comme transmit.fm, une plateforme de publication de podcasts native Nostr, peuvent publier directement sur les relais en utilisant ce format, permettant aux podcasteurs de distribuer du contenu sans intermédiaires.
NIP-FR : Notes réservées aux amis - Propose un mécanisme pour publier des notes visibles uniquement par une liste d’amis définie par l’utilisateur, en utilisant une clé symétrique partagée appelée ViewKey. L’auteur chiffre les notes (kind 2044) avec le ViewKey en utilisant NIP-44. Le ViewKey lui-même est distribué à chaque ami une seule fois via NIP-59 (Gift Wrap). Les amis possédant le ViewKey peuvent déchiffrer et lire les notes ; tous les autres ne voient que du texte chiffré. Lorsque l’auteur supprime un ami, le ViewKey est renouvelé : une nouvelle clé est générée et redistribuée à tous les amis restants via gift wrap, assurant que l’ami supprimé perde l’accès aux publications futures. Cette approche sépare le chiffrement du contenu (symétrique, efficace) de la distribution des clés (asymétrique, par ami), gardant le protocole léger tout en permettant une fonctionnalité de confidentialité fréquemment demandée.
NIP-DB : Interface de base de données d’événements Nostr navigateur (spec) - Propose une interface window.nostrdb standard pour les extensions navigateur fournissant un stockage local d’événements Nostr. L’API inclut des méthodes pour ajouter des événements, requêter par ID ou filtre, compter les correspondances et s’abonner aux mises à jour. Les applications web peuvent utiliser cette interface pour lire depuis les événements mis en cache localement sans faire de requêtes aux relais, réduisant la bande passante et la latence. L’extension navigateur nostr-bucket de hzrd149 fournit une implémentation de référence, injectant l’interface dans tous les onglets du navigateur. Une bibliothèque polyfill compagnon implémente la même API en utilisant IndexedDB pour les environnements sans l’extension.
TRUSTed Filters - Une suite de cinq propositions connexes pour la curation de contenu décentralisée, s’appuyant sur la merged PR Trusted Assertions #1534 de vitorpamplona. La spécification principale introduit les événements kind 17570 pour déclarer les préférences de fournisseur de confiance, permettant aux utilisateurs de spécifier quels services ils font confiance pour le filtrage et le classement des événements. Les fournisseurs de confiance publient des assertions (kind 37571), des statistiques (kind 37572) et des classements (kind 37573) auxquels les clients peuvent s’abonner. Le système utilise une architecture de plugins avec des tags W/w pour spécifier les types de filtres et les transformations. Cela permet aux opérations coûteuses en calcul comme la détection de spam, le scoring de réputation et le classement de contenu de s’exécuter sur une infrastructure dédiée tandis que les utilisateurs maintiennent le contrôle sur les fournisseurs auxquels ils font confiance. La suite inclut des spécifications séparées pour les préréglages de filtres, les classements d’utilisateurs, les événements de confiance et les définitions de plugins.
NIP-9a : Notifications push - hodlbod propose un standard pour les notifications push basées sur les relais utilisant des événements d’enregistrement kind 30390. Les utilisateurs créent un enregistrement contenant des filtres pour les événements qu’ils veulent recevoir et une URL de callback webhook. L’enregistrement est chiffré vers la pubkey du relais (depuis son champ self NIP-11). Quand des événements correspondants se produisent, les relais POST vers le callback avec l’ID de l’événement (en clair pour la déduplication) et l’événement lui-même (chiffré NIP-44 vers l’utilisateur). Cette architecture permet aux relais de pousser les notifications tout en protégeant le contenu des événements des serveurs push intermédiaires. La PR #270 de Flotilla implémente ce standard.
Catallax - Propose un protocole de travail contractuel décentralisé avec séquestre utilisant des événements kind 33400. Le système définit trois rôles : les arbitres annoncent leur disponibilité et leurs conditions, les patrons créent des tâches financées avec du Bitcoin séquestré, et les agents libres complètent le travail pour réclamer le paiement. Les arbitres résolvent les litiges quand nécessaire. Le protocole permet la coordination de travail freelance sans confiance où les fonds sont verrouillés jusqu’à ce que les livrables soient acceptés ou que l’arbitrage conclue.

Approfondissement NIP : NIP-47 (Nostr Wallet Connect)

NIP-47 définit Nostr Wallet Connect (NWC), un protocole pour le contrôle à distance de portefeuille Lightning utilisant Nostr comme couche de communication. Avec l’ajout cette semaine du support des factures de rétention, NWC couvre maintenant la gamme complète des opérations Lightning.

Le protocole fonctionne via un échange simple. Une application de portefeuille publie un événement “wallet info” (kind 13194) décrivant ses capacités. Les applications clientes envoient des requêtes chiffrées (kind 23194) demandant au portefeuille d’effectuer des opérations comme payer des factures, créer des factures ou vérifier les soldes. Le portefeuille répond avec des résultats chiffrés (kind 23195).

NWC utilise le chiffrement NIP-44 entre le client et le portefeuille, avec une paire de clés dédiée pour les opérations de portefeuille, la gardant séparée de l’identité principale de l’utilisateur. Cette séparation signifie que compromettre une connexion NWC n’expose pas l’identité Nostr de l’utilisateur.

Méthodes supportées :

La spécification définit des méthodes pour les opérations Lightning principales : pay_invoice envoie des paiements, make_invoice génère des factures pour recevoir, lookup_invoice vérifie le statut de paiement, get_balance retourne le solde du portefeuille, et list_transactions fournit l’historique des paiements. Le nouveau pay_keysend fusionné permet les paiements sans factures, et hold_invoice supporte les paiements conditionnels.

Exemples d’événements :

Le service de portefeuille publie un événement info (kind 13194) annonçant ses capacités :

{
 "kind": 13194,
 "pubkey": "<pubkey du service de portefeuille>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<horodatage unix>",
 "id": "<hash de l'événement>",
 "sig": "<signature du service de portefeuille>"
}

Un client envoie une requête chiffrée (kind 23194) pour payer une facture :

{
 "kind": 23194,
 "pubkey": "<pubkey éphémère du client depuis le secret de l'URI de connexion>",
 "content": "<NIP-44 chiffré: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<pubkey du service de portefeuille>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<horodatage unix>",
 "id": "<hash de l'événement>",
 "sig": "<signature de la clé éphémère du client>"
}

Le service de portefeuille répond (kind 23195) avec le résultat du paiement :

{
 "kind": 23195,
 "pubkey": "<pubkey du service de portefeuille>",
 "content": "<NIP-44 chiffré: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<pubkey éphémère du client>"],
 ["e", "<id de l'événement de requête>"]
 ],
 "created_at": "<horodatage unix>",
 "id": "<hash de l'événement>",
 "sig": "<signature du service de portefeuille>"
}

Le tag e dans la réponse référence la requête originale, permettant aux clients de faire correspondre les réponses à leurs requêtes.

Factures de rétention :

La PR #1913 de cette semaine a ajouté le support des factures de rétention, permettant des paiements de type séquestre. Contrairement aux factures standard où le destinataire réclame immédiatement le paiement en libérant la préimage, les factures de rétention permettent au destinataire de différer cette décision. Quand un payeur envoie vers une facture de rétention, les fonds se verrouillent le long de la route de paiement. Le destinataire choisit ensuite de régler (libérer la préimage et réclamer les fonds) ou d’annuler (rejeter le paiement, retournant les fonds au payeur). Si aucune action ne se produit, le paiement expire et les fonds retournent automatiquement. La PR ajoute trois méthodes NWC : make_hold_invoice, settle_hold_invoice et cancel_hold_invoice, plus une notification hold_invoice_accepted. Ce mécanisme alimente des applications comme le séquestre de covoiturage de Ridestr et la résolution de litiges de place de marché.

Implémentations actuelles :

Les principaux portefeuilles supportent NWC : Zeus, Alby et Primal (depuis la PR #874 de cette semaine) implémentent tous le support côté portefeuille. Côté client, Damus, Amethyst et la plupart des clients Nostr majeurs peuvent se connecter aux portefeuilles NWC pour le zapping et les paiements.

Le protocole permet une séparation des préoccupations : les utilisateurs peuvent faire fonctionner leur portefeuille sur un appareil tout en interagissant avec Nostr depuis un autre, avec les relais Nostr servant de canal de communication. Cette architecture signifie que les clients mobiles n’ont pas besoin de détenir des fonds directement, améliorant la sécurité en gardant l’infrastructure de portefeuille séparée des clients sociaux.

Considérations de sécurité :

Les connexions NWC devraient être traitées comme sensibles. Bien que le chiffrement protège le contenu des messages, la pubkey du portefeuille et le secret de connexion doivent être protégés. Les applications devraient permettre aux utilisateurs de révoquer les connexions et de définir des limites de dépenses. Le protocole supporte les restrictions de capacités, permettant aux portefeuilles de limiter les opérations qu’une connexion particulière peut effectuer.

Approfondissement NIP : NIP-59 (Gift Wrap)

NIP-59 définit un protocole pour encapsuler n’importe quel événement Nostr dans plusieurs couches de chiffrement, cachant l’identité de l’expéditeur aux relais et observateurs. Les propositions de cette semaine pour les notes réservées aux amis (NIP-FR) et les notifications push (NIP-9a) s’appuient toutes deux sur le gift wrapping, en faisant une primitive de confidentialité fondamentale à comprendre.

Les trois couches :

Le gift wrapping utilise trois structures imbriquées :

Rumor (événement non signé) : Le contenu original comme événement Nostr sans signature. Le rumor ne peut pas être envoyé directement aux relais car les relais rejettent les événements non signés.
Seal (kind 13) : Le rumor est chiffré en utilisant NIP-44 et placé dans un événement kind 13. Le seal EST signé par la clé de l’auteur réel. C’est la preuve cryptographique de paternité.
Gift Wrap (kind 1059) : Le seal est chiffré et placé dans un événement kind 1059 signé par une paire de clés aléatoire à usage unique. Le gift wrap inclut un tag p pour le routage vers le destinataire.

Une idée fausse courante : La déniabilité

La spécification mentionne que les rumors non signés fournissent la “déniabilité”, mais c’est trompeur. La couche seal EST signée par l’auteur réel. Quand le destinataire déchiffre le gift wrap puis le seal, il a une preuve cryptographique de qui a envoyé le message. Le destinataire pourrait même construire une preuve à divulgation nulle révélant l’identité de l’expéditeur sans exposer sa propre clé privée.

Ce que le gift wrap fournit réellement est la confidentialité de l’expéditeur vis-à-vis des observateurs : les relais et tiers ne peuvent pas déterminer qui a envoyé le message car ils ne voient que le gift wrap signé par une clé aléatoire. Mais le destinataire sait toujours, et peut le prouver.

Exemples d’événements :

Voici la structure complète à trois couches de la spécification (envoyant “Tu vas à la fête ce soir ?”) :

Le rumor (non signé, ne peut pas être publié aux relais) :

{
 "created_at": 1691518405,
 "content": "Tu vas à la fête ce soir ?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

Le seal (kind 13, signé par l’auteur réel, contient le rumor chiffré) :

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

Le gift wrap (kind 1059, signé par une clé éphémère aléatoire, contient le seal chiffré) :

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Remarquez : la pubkey du seal est l’auteur réel (611df01...), tandis que la pubkey du gift wrap est une clé à usage unique aléatoire (18b1a75...). Les relais ne voient que le gift wrap, donc ils ne peuvent pas attribuer le message à l’auteur réel.

Ce que chaque couche protège :

Le rumor est non signé et ne peut pas être publié directement aux relais. Le seal est signé par l’auteur réel et prouve la paternité au destinataire. Le gift wrap est signé par une clé à usage unique aléatoire, cachant l’auteur réel aux relais et observateurs. Seul le destinataire peut déchiffrer à travers les deux couches pour atteindre le contenu original et vérifier la signature de l’auteur sur le seal.

Applications actuelles :

NIP-17 (Messages directs privés) utilise le gift wrap pour les DM chiffrés, remplaçant l’ancien schéma NIP-04. Le NIP-FR proposé (notes réservées aux amis) utilise le gift wrapping pour distribuer des ViewKeys aux amis, qui déchiffrent ensuite les notes chiffrées avec ces clés. NIP-9a (notifications push) chiffre les charges utiles de notification en utilisant les principes du gift wrap.

Protection des métadonnées :

Les horodatages devraient être randomisés pour contrecarrer l’analyse temporelle. Les relais devraient exiger AUTH avant de servir les événements kind 1059 et ne les servir qu’au destinataire marqué. Lors de l’envoi à plusieurs destinataires, créez des gift wraps séparés pour chacun.

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

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur Nostr.

Cette semaine : Ridestr apporte le covoiturage décentralisé sur Nostr avec des paiements Cashu et le partage de localisation chiffré. Pomade introduit la récupération par email pour les signataires multisig. Damus intègre negentropy pour une synchronisation fiable des messages privés. L’application de bureau d’Amethyst ajoute la recherche, les favoris et les zaps. Amber v4.1.1 affiche les scores de confiance des relais. Marmot fusionne MIP-03 et construit une application de chat de référence en TypeScript. diVine ajoute l’authentification QR NIP-46 et le support des mentions. De nouvelles propositions de NIP abordent la gestion des communautés, la synchronisation basée sur les séquences et le stockage de fichiers chiffrés. Nous revenons également sur cinq années de janvier Nostr, retraçant l’évolution du protocole depuis une poignée d’adopteurs précoces en 2021 jusqu’au lancement explosif de Damus sur l’App Store en 2023, en passant par l’écosystème de clients mature de 2025.

Actualités

Ridestr apporte le covoiturage décentralisé sur Nostr

Ridestr développe une application de covoiturage pair-à-pair entièrement construite sur Nostr, permettant des transactions directes entre conducteurs et passagers avec des paiements Bitcoin et Cashu. Le protocole utilise des types d’événements personnalisés (30173, 3173-3175, 30180/30181) pour coordonner les trajets tout en préservant la confidentialité grâce à la divulgation progressive de la localisation et au chiffrement NIP-44.

Le système fonctionne selon un flux soigneusement orchestré : les conducteurs diffusent leur disponibilité en utilisant des localisations encodées en geohash (précision d’environ 5 km) via des événements kind 30173, les passagers demandent des trajets avec des estimations de tarifs via kind 3173, et les paiements sont sécurisés par des tokens séquestrés HTLC avant le début du trajet. La confidentialité de la localisation est préservée grâce à la divulgation progressive, où les détails du point de prise en charge ne sont révélés qu’à l’arrivée des conducteurs et les destinations sont partagées après vérification du code PIN. Toutes les communications entre les parties utilisent le chiffrement NIP-44 pour la confidentialité.

Ridestr implémente la sécurité des paiements via un séquestre HTLC avec signatures P2PK. Lorsqu’un passager accepte l’offre d’un conducteur, il verrouille des tokens Cashu avec un hash de paiement que seul le conducteur peut réclamer après la fin du trajet. Le protocole fonctionne actuellement avec une architecture à mint unique, exigeant que les passagers et les conducteurs utilisent le même mint Cashu. L’implémentation Android basée sur Kotlin gère la vérification des preuves et la récupération des preuves périmées via les vérifications d’état NUT-07.

Ridestr s’attaque à des défis que la plupart des applications Nostr évitent : la coordination de localisation en temps réel, le séquestre de paiement avec résolution des litiges et les systèmes de réputation pour les interactions dans le monde physique. Le projet est en bêta et démontre que le modèle d’événements de Nostr peut supporter des places de marché de services pair-à-pair, pas seulement le partage de contenu.

Pomade lance un système de récupération Alpha pour les signataires Multisig

Pomade, développé par hodlbod, s’appuie sur l’écosystème FROSTR existant pour fournir un service de signature à seuil axé sur la récupération. En utilisant les signatures FROST (Flexible Round-Optimized Schnorr Threshold) via la bibliothèque @frostr/bifrost, Pomade ajoute des flux de récupération par email en plus de la cryptographie à seuil. Le système fragmente la clé secrète d’un utilisateur en utilisant le partage de secret de Shamir, distribuant les fragments entre plusieurs signataires indépendants avec un seuil configurable (2-sur-3, 3-sur-5, etc.).

Le protocole fonctionne entièrement sur Nostr en utilisant un seul type d’événement (28350) avec des charges utiles chiffrées NIP-44. Lors de la signature, le client demande des signatures partielles à au moins threshold signataires, puis les agrège en une signature Schnorr valide. Pour le chiffrement, les signataires collaborent pour dériver des secrets partagés via ECDH sans qu’aucune partie n’apprenne la clé complète.

La récupération fonctionne via deux méthodes d’authentification : basée sur mot de passe (utilisant argon2id avec la pubkey du signataire comme sel) ou par OTP email. Pour prévenir les attaques MITM pendant la récupération OTP, chaque signataire génère son propre code de vérification avec un préfixe fourni par le client, exigeant que les utilisateurs s’authentifient indépendamment auprès de chaque signataire. Le protocole exige une preuve de travail sur les événements d’inscription (20+ bits selon NIP-13) pour prévenir le spam.

Le modèle de confiance est explicite : si threshold signataires s’entendent, ils peuvent voler la clé. Les fournisseurs d’email bénéficient d’une confiance totale puisqu’ils peuvent intercepter les OTP. Les utilisateurs ne peuvent pas récupérer indépendamment leur clé secrète complète ; cela nécessite la coopération de threshold signataires. Le protocole est conçu pour l’intégration de nouveaux utilisateurs non familiers avec la gestion des clés, avec la recommandation explicite que les utilisateurs migrent vers l’auto-conservation une fois à l’aise. Pomade avertit des potentiels « pertes de clés, vols, dénis de service ou fuites de métadonnées » étant donné son statut alpha non audité.

Versions

Damus intègre Negentropy pour une synchronisation fiable des messages privés

Damus v1.13 intègre l’implémentation negentropy que nous avions présentée comme PR ouverte la semaine dernière. PR #3536 ajoute le support de base de negentropy à la couche réseau, permettant la réconciliation d’ensembles avec les relais qui supportent le protocole. Une PR #3547 complémentaire ajoute la synchronisation des messages privés par glissement vers le bas qui utilise negentropy pour récupérer les messages manquants lorsque les abonnements REQ standard échouent.

L’implémentation suit une approche conservatrice : le chargement normal des messages privés continue inchangé, avec negentropy disponible comme mécanisme de récupération lorsque les utilisateurs actualisent manuellement. Les tests automatisés démontrent la correction en générant un message privé avec un ancien horodatage que les requêtes standard manqueraient, puis en utilisant la synchronisation negentropy pour le récupérer avec succès. Bien que le support de negentropy nécessite des relais compatibles, l’implémentation gère gracieusement les environnements de relais mixtes en utilisant le protocole là où il est disponible.

Amber v4.1.1 - Scores de confiance des relais

Amber v4.1.1 intègre l’affichage des scores de confiance des relais (PR #289), implémentant les concepts d’évaluation des relais discutés dans la couverture des attestations de confiance des relais de la semaine dernière. Les scores de confiance apparaissent désormais sur la page Relais et pour les demandes de connexion NostrConnect, aidant les utilisateurs à évaluer la fiabilité des relais avant d’autoriser les connexions. La version inclut également une interface utilisateur login/événements/permissions redessinée et le support de la méthode switch_relays. Les améliorations de performance mettent en cache les opérations du keystore, répondant aux rapports de temps de chargement de plus de 20 secondes sur les appareils plus anciens.

nak v0.18.2 - Intégration MCP

nak (Nostr Army Knife) de fiatjaf v0.18.2 ajoute le support du Model Context Protocol via nak mcp, permettant aux agents IA de rechercher des personnes sur Nostr, publier des notes, mentionner des utilisateurs et lire du contenu en utilisant le modèle outbox. La version introduit également un installateur en une ligne (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) qui télécharge des binaires pré-compilés, éliminant le besoin de la chaîne d’outils Go pour les utilisateurs finaux. Le mode Bunker supporte maintenant les sockets Unix et switch_relays.

Zeus v0.12.2 Beta - Corrections NWC

Zeus v0.12.2-beta1 intègre plusieurs corrections NWC répondant aux problèmes couverts dans la couverture de Zeus de la semaine dernière.

Mises à jour des projets

Amethyst Desktop - Phase 2A livrée

Amethyst a déployé la Phase 2A de son application de bureau, ajoutant la Recherche, les Favoris, les Zaps, les vues de Threads et le contenu long format (Lectures) à l’expérience de bureau. Une PR #1683 complémentaire ajoute un retour transparent sur la diffusion des événements afin que les utilisateurs voient maintenant le statut en temps réel par relais lorsque leurs événements se propagent à travers le réseau, facilitant le diagnostic des problèmes de connectivité.

Progression de Notedeck : Application Calendrier et perfectionnement UX

Le client de bureau Notedeck de l’équipe Damus a fusionné le comportement de masquage automatique de la barre d’outils (PR #1268) qui répond à la vélocité de défilement pour plus d’espace d’écran sur les vues mobiles. Une PR brouillon #1271 ajoute une application Calendrier NIP-52 complète avec des vues mois/semaine/jour/agenda, le support RSVP et les commentaires NIP-22 sur les événements de calendrier, actuellement sous feature flag pour les tests.

Jumble ajoute le mode Communauté

Jumble, le client web axé sur les relais, a ajouté le mode communauté et le support des préréglages d’ensembles de relais via variables d’environnement, facilitant le déploiement d’instances thématiques comme nostr.moe.

Tableau de bord des commandes Shopstr

Shopstr a remplacé sa gestion des commandes par chat par un Tableau de bord des commandes dédié. La nouvelle interface fournit une vue centralisée pour que les marchands suivent le statut des commandes, marquent les messages comme lus et gèrent l’exécution sans faire défiler les fils de discussion. La mise à jour déprécie la mise en cache IndexedDB en faveur des API de statut de commande côté serveur et révise la façon dont les messages privés de commande sont tagués pour un meilleur filtrage.

Formstr ajoute les questions en grille

Formstr, l’application de formulaires native Nostr, a ajouté les questions en grille et réécrit son SDK avec le support de l’intégration. Une correction pour les signataires non-NIP-07 a résolu les problèmes pour les utilisateurs avec des signataires bunker ou locaux essayant de soumettre des formulaires avec leur identité.

nostr-tools met à jour les dépendances cryptographiques

nostr-tools, la bibliothèque JavaScript principale, a mis à jour vers @noble/curves v2.0.1, répondant aux changements d’API cassants dans 27 fichiers et adoptant les dernières bibliothèques noble auditées. fiatjaf a également ajouté le support de switch_relays à NIP-46, permettant aux clients bunker de changer dynamiquement les connexions de relais.

Zeus travaille sur les avis de mint NIP-87

Zeus a une PR ouverte pour les avis de mint NIP-87, permettant aux utilisateurs de découvrir et d’évaluer les mints Cashu filtrés par les follows Nostr. Les avis incluent des notes étoilées et peuvent être soumis de manière anonyme ou avec le nsec de l’utilisateur.

Camelus intègre le support complet des messages privés

Camelus, un client Android basé sur Flutter construit avec Dart NDK pour des performances mobiles économes en batterie, a ajouté la messagerie directe complète avec plus de 20 commits cette semaine. La mise à jour inclut les catégories de chat, les dates des messages, l’interface d’envoi optimiste, la fonctionnalité note-à-soi-même et la gestion appropriée des relais de messages privés.

Mises à jour du protocole Marmot

La résolution déterministe des commits MIP-03 que nous avions couverte comme PR ouverte la semaine dernière a maintenant été fusionnée. MDK PR #152 garantit que tous les chats de groupe basés sur MLS convergent vers le même état lorsque plusieurs commits valides arrivent pour la même époque.

Une PR spec #28 complémentaire ajoute les exigences de cycle de vie des init_key répondant aux lacunes des audits d’implémentation : le matériel de clé privée des messages Welcome doit être supprimé de manière sécurisée après traitement (zéroisation, nettoyage du stockage), et les nouveaux membres doivent effectuer des auto-mises à jour dans les 24 heures pour la confidentialité persistante.

Le SDK TypeScript (marmot-ts) construit une application de chat de référence. PR #37 ajoute la création/liste de groupes, la gestion des paquets de clés avec les flux publier/diffuser/supprimer et les invitations par code QR. Une PR ouverte #38 par hzrd149 implémente la persistance de l’historique des messages avec pagination. Le backend whitenoise-rs a fusionné 15 PRs cette semaine incluant le support multilingue (PR #455) et les références médias MIP-04 v2 (PR #450).

diVine ajoute des fonctionnalités d’intégration Nostr

diVine, l’application de vidéos courtes, poursuit son intégration rapide de Nostr.

Les PRs ouvertes incluent l’authentification par code QR NIP-46 (PR #1019) et la messagerie directe chiffrée NIP-17 (PR #834). L’activité de cette semaine s’est concentrée sur le support des mentions convertissant les URI nostr: et les @mentions en liens de profil cliquables, les fallbacks d’avatars Classic Viners utilisant les profils Nostr, et les outils d’édition vidéo incluant le dessin, les filtres et les stickers.

Mises à jour des NIP

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

Fusionnés :

Attestations de confiance des relais - La proposition pour standardiser le scoring de confiance des relais que nous avons couverte la semaine dernière a été fusionnée. La spécification définit des événements kind 30385 pour les attestations de confiance des relais avec un scoring sur la fiabilité, la qualité et l’accessibilité. Le débat menant à la fusion portait sur le fait de savoir si les scores de confiance devraient être « globaux » (calculés une fois pour tous les utilisateurs) ou « personnalisés » (relatifs au graphe social de chaque observateur). Les algorithmes de type PageRank comme le Trust Rank de nostr.band et GrapeRank résistent aux attaques sybil en divisant tout rang passé à travers des comptes factices par la taille de la ferme de bots.

PRs ouvertes et discussions :

Communikeys - Une proposition complète pour la gestion des communautés qui utilise les npubs existants comme identifiants de communauté au lieu d’approches basées sur les relais. N’importe quelle npub peut devenir une communauté en publiant un événement kind 10222 ; les publications ciblent les communautés via des événements kind 30222. Le contrôle d’accès utilise les badges NIP-58, permettant la gestion déléguée des membres avec stockage à froid pour les clés de communauté.
NIP-CF : Flux de changements - Un brouillon proposant la synchronisation d’événements basée sur les séquences comme alternative aux filtres since basés sur les horodatages. Le problème : la synchronisation Nostr standard utilisant les horodatages since peut manquer des événements lorsque plusieurs événements partagent le même horodatage à la seconde près, les horloges du client et du relais dérivent l’une par rapport à l’autre, ou le checkpointing est imprécis. NIP-CF résout cela en faisant assigner par les relais des numéros de séquence croissants de manière monotone aux événements stockés, fournissant un ordre total strict. Les clients demandent les changements depuis un numéro de séquence spécifique et reçoivent les événements dans un ordre garanti, avec un checkpointing précis qui ne manque jamais d’événements. La proposition supporte également le mode live/continu où les abonnements restent ouverts après la synchronisation initiale pour les mises à jour en temps réel.
NIP-XX : Synchronisation de fichiers chiffrés - Un protocole définissant les kinds 30800 (fichiers chiffrés), 30801 (index de coffre) et 30802 (documents partagés) pour synchroniser du contenu chiffré entre appareils en utilisant les relais Nostr. Le protocole permet aux applications de prise de notes local-first de fournir une synchronisation chiffrée de bout en bout sans serveurs centralisés. Les contenus des fichiers, les chemins, les noms et la structure des dossiers sont tous chiffrés en utilisant l’auto-chiffrement NIP-44, de sorte que les relais stockent des blobs qu’ils ne peuvent pas lire. Les pièces jointes binaires comme les images utilisent des serveurs Blossom avec chiffrement côté client. Le kind 30802 permet le partage de documents entre utilisateurs en chiffrant vers la clé publique du destinataire.

Cinq années de janvier Nostr

La newsletter du mois dernier a retracé les jalons de décembre de Nostr depuis la première version client de fiatjaf jusqu’au don catalyseur de Jack Dorsey. Cette rétrospective trace ce qui s’est passé chaque janvier de 2021 à 2025, en se concentrant sur les développements techniques vérifiés.

Janvier 2021 : Développement précoce

Le troisième mois de Nostr a vu la poursuite du développement de Branle, le client Vue.js de fiatjaf lancé en décembre 2020. Un petit groupe d’adopteurs précoces, probablement moins de 15 personnes, se coordonnait via le groupe Telegram @nostr_protocol (créé le 16 novembre 2020), testant le protocole sur un ou deux relais expérimentaux. Le client en ligne de commande noscl fournissait une interaction basée sur le terminal.

Les fondations techniques étaient déjà verrouillées : les utilisateurs identifiés par des clés publiques secp256k1, les posts signés cryptographiquement avec des signatures Schnorr, et les relais servant de stockage passif qui ne communiquent pas entre eux. C’était délibérément de la cryptographie native Bitcoin, un choix de conception qui façonnerait les modèles d’adoption des années plus tard.

Janvier 2022 : Découverte par les développeurs

Janvier 2022 s’est ouvert avec Nostr encore en effervescence après sa première apparition sur Hacker News (31 décembre 2021), qui a généré 110 points et 138 commentaires. Au moment de ce post, seulement environ sept relais alimentaient l’ensemble du réseau, les commentateurs notant que « le spam n’est pas encore un problème parce que nostr est super nouveau et personne ne l’utilise encore ». Robert C. Martin (« Uncle Bob ») avait soutenu Nostr comme potentiellement « la solution finale pour la communication sociale ». La discussion s’est poursuivie en janvier, avec des développeurs débattant de l’architecture des relais versus le vrai P2P, la résistance à la censure versus la modération, et si la simplicité pouvait passer à l’échelle.

Le post HN a déclenché une vague de nouvelles implémentations. Uncle Bob lui-même a commencé more-speech, un client desktop Clojure, le 18 janvier. La bibliothèque go-nostr de fiatjaf (créée en janvier 2021) et le client en ligne de commande noscl fournissaient des outils Go, tandis que nostr-tools offrait le support JavaScript. En décembre 2022, environ 800 profils avaient des bios. Branle restait le principal client web, recevant des mises à jour incluant l’import de clés privées et le support multi-relais. Les défis techniques étaient évidents : les clés hex de 64 caractères s’avéraient peu intuitives, les délais de messages frustraient les utilisateurs, et la communauté se demandait si l’architecture pouvait gérer le trafic à l’échelle de Twitter.

Janvier 2023 : L’explosion

Janvier 2023 a transformé Nostr d’expérience en mouvement. Damus, le client iOS de William Casarin (jb55), a bataillé avec le processus d’approbation de l’App Store d’Apple. Rejeté le 1er janvier, rejeté à nouveau le 26 janvier, il a finalement été approuvé le 31 janvier. Cette approbation a déclenché une cascade : Damus a immédiatement atteint la 10e place des Réseaux Sociaux aux États-Unis. Jack Dorsey l’a qualifié de « jalon pour les protocoles ouverts ».

Huit jours plus tôt, le 23 janvier, Edward Snowden a annoncé sa présence sur Nostr : « Une des choses cool à propos de Nostr… au-delà de la résistance à la censure, c’est que vous n’êtes pas limité à 280 caractères ». Son soutien en tant que lanceur d’alerte de la NSA avait du poids dans les cercles soucieux de la vie privée, et les utilisateurs ont immédiatement commencé à lui envoyer des sats via Lightning.

Les clients web ont fait la course pour intégrer l’afflux. Snort, créé par kieran en décembre 2022, a émergé comme un client React riche en fonctionnalités ; le 13 janvier, Snort a intégré l’enregistrement NIP-05 via l’API Nostr Plebs, permettant aux nouveaux utilisateurs de revendiquer des identités lisibles par l’homme lors de l’intégration. Iris, développé à temps plein par Martti Malmi (un contributeur précoce de Bitcoin qui a reçu la deuxième transaction Bitcoin jamais effectuée de Satoshi), offrait des interfaces web et mobiles avec des identités NIP-05 gratuites sur iris.to. Astral, construit par monlovesmango avec Quasar (Vue.js) comme fork de Branle, se concentrait sur la gestion des relais avec sa fonctionnalité de groupement de relais qui permettait aux utilisateurs d’organiser les relais en ensembles pour la publication et le filtrage. Les bêtas TestFlight pour les clients iOS se remplissaient en quelques heures, et Amethyst dominait Android.

L’infrastructure s’est démêlée pour suivre le rythme. Tous les relais étaient exploités par des enthousiastes payant de leur poche. Les relais payants utilisant des micropaiements Lightning créaient un filtrage naturel du spam mais introduisaient une friction d’accès. Damus a été retiré de l’App Store chinois seulement deux jours après son approbation, apparemment sur demande du principal régulateur internet chinois.

Janvier 2024 : Durcissement du protocole

Janvier 2024 s’est concentré sur la standardisation du protocole et la construction de la communauté. Nostr PHX a lancé l’année avec un meetup le 5 janvier à Phoenix, rassemblant les cypherpunks locaux. C’était le premier de nombreux événements communautaires cette année-là incluant BTC Prague (juin), Nostriga à Riga (août) et Nostrasia.

Le développement de protocole le plus significatif a été la fusion de NIP-59 (Gift Wrap) le 29 janvier, fournissant la protection des métadonnées pour les communications chiffrées. Gift Wrap s’appuie sur le standard de chiffrement NIP-44 (qui avait été audité par Cure53 en décembre 2023) pour cacher l’identité de l’expéditeur aux relais. Le protocole enveloppe les messages chiffrés dans un événement externe signé par une paire de clés aléatoire à usage unique. Les relais ne voient que la pubkey jetable, tandis que la véritable identité de l’expéditeur est enfouie dans la charge utile chiffrée que seul le destinataire peut déchiffrer. Cela empêche les opérateurs de relais et les observateurs du réseau d’apprendre qui envoie des messages à qui. Les horodatages peuvent également être randomisés pour déjouer l’analyse temporelle.

L’écosystème s’est étendu au-delà des réseaux sociaux. Plebeian Market est devenu entièrement natif Nostr avec la conformité NIP-15, permettant les paniers d’achat multi-étals et un navigateur d’étals pour découvrir les marchands. Shopstr a émergé comme une place de marché sans permission facilitant le commerce Bitcoin. Zap.stream, construit par kieran, a apporté le streaming en direct sur Nostr avec des paiements Lightning à 21 sats/minute. Les outils de développement ont mûri avec NDK fournissant des abstractions TypeScript et rust-nostr offrant des bindings Rust. Zeus v0.8.1 a intégré l’import de contacts Nostr et LND persistant, posant les bases de l’intégration Nostr Wallet Connect dans les versions ultérieures.

Pourtant, la durabilité de l’infrastructure restait difficile. La recherche académique de cette période a trouvé que 95% des relais peinaient à couvrir les coûts opérationnels, avec 20% connaissant des temps d’arrêt significatifs. Les frais d’admission pour les relais payants étaient en moyenne inférieurs à 1 000 sats (~0,45 $), insuffisants pour maintenir les opérations.

Une note sur les arnaques : Le « Nostr Assets Protocol » et le token « $NOSTR » associé lancés autour de cette période ont été publiquement dénoncés par fiatjaf comme « 100% frauduleux » et « une arnaque par affinité » sans aucune connexion avec le protocole Nostr réel.

Janvier 2025 : Maturation des clients

Janvier 2025 a vu la poursuite du développement des clients à travers l’écosystème. Nostur 1.17.0 a été livré le 13 janvier avec la synchronisation multi-appareils des états de lecture, le support de connexion multi-sig FROST et des performances de base de données locale optimisées. Amethyst a poursuivi sa transition vers le modèle outbox, compilant automatiquement les ensembles de relais basés sur les listes de follows plutôt que de nécessiter une configuration manuelle.

Les principaux clients ont commencé à s’éloigner de NIP-04 pour les messages directs, migrant vers NIP-17 et le proposé NIP-104 pour un chiffrement amélioré et une protection des métadonnées. Le modèle Gossip (communication outbox/inbox) a gagné en adoption alors que l’écosystème convergeait vers des modèles d’utilisation des relais plus efficaces. Les observateurs de l’industrie ont prédit que ce serait l’année où Nostr passerait de protocole de niche à reconnaissance grand public, avec une migration potentielle de plateforme très médiatisée qui pourrait doubler l’activité quotidienne.

Janvier 2026 : Infrastructure de sécurité et de signature

Janvier 2026 a apporté des avancées significatives dans l’infrastructure de sécurité et de signature. Primal Android 2.6.18 a intégré la signature à distance NIP-46 et le support de signataire local NIP-55, rejoignant Amber et Aegis comme hub de signature complet pour d’autres applications Android. Bitchat a complété un audit de sécurité Cure53, la même firme qui a audité Signal et NIP-44, avec plus de 17 PRs corrigeant des découvertes critiques incluant l’effacement des secrets DH et des problèmes de sécurité des threads. Bitchat et Damus ont tous deux migré de C Tor vers Rust Arti pour une fiabilité améliorée et la sécurité mémoire.

Le travail sur le protocole a continué avec la fusion de NIP-71 (événements vidéo adressables) et un NIP de cryptographie post-quantique ouvrant la discussion sur la protection future de Nostr contre les attaques quantiques. Le brouillon des Attestations de confiance des relais a proposé de standardiser le scoring de confiance des relais via des attestations signées. Le protocole Marmot a durci sa messagerie chiffrée basée sur MLS avec 18 PRs fusionnées répondant aux découvertes d’audit.

Les applications du monde réel se sont étendues avec Ridestr développant le covoiturage décentralisé utilisant le séquestre Cashu et le chiffrement NIP-44, et Pomade ajoutant des flux de récupération par email à la signature à seuil FROST. Damus a intégré negentropy pour une synchronisation fiable des messages privés, tandis que l’application de bureau d’Amethyst a atteint la Phase 2A avec la recherche, les favoris et les zaps.

Perspectives

Six années de janvier révèlent l’évolution de Nostr du développement précoce (2021) à la découverte publique (2022) à la croissance explosive (2023) au durcissement du protocole (2024) à la maturation des clients (2025) à l’infrastructure de sécurité (2026). Le modèle est familier à quiconque a observé la croissance des protocoles ouverts : des années de construction silencieuse, une explosion soudaine quand les conditions s’alignent, puis le travail plus long pour rendre tout cela fiable. Ce qui a commencé avec sept relais et un fil Hacker News est maintenant une infrastructure auditée avec des applications réelles. La question pour 2027 : quand quelqu’un appellera un trajet, enverra un message chiffré ou récupérera une clé perdue en utilisant Nostr, saura-t-il même qu’il l’utilise ?

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

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

Cette semaine : Bitchat remplace le Tor en C par l’implémentation Rust Arti pour une meilleure fiabilité et performance. nostrdb-rs gagne des requêtes fold en streaming qui permettent des opérations de base de données sans allocation. Listr reçoit une refonte majeure avec migration vers NDK 3 beta et maintenance assistée par IA après un an de dormance. Zeus livre 17 PR fusionnées axées sur les correctifs NIP-47 (Nostr Wallet Connect pour le contrôle Lightning à distance) et les améliorations Cashu, tandis que Primal Android ajoute des flux de sauvegarde de portefeuille et le support NIP-92 (dimensions de média pour des ratios d’aspect corrects). Un nouveau NIP brouillon propose les Assertions de Relais de Confiance pour une notation de confiance standardisée des relais.

Actualités

Bitchat adopte Rust Arti pour le support Tor

Bitchat a migré du Tor en C vers Arti, l’implémentation Rust du protocole Tor. PR #958 supprime la dépendance au Tor en C et intègre Arti, apportant des garanties de sécurité mémoire et une fiabilité améliorée. Le changement élimine les tentatives de réveil en dormance qui causaient des redémarrages du service en premier plan, un problème persistant avec l’implémentation en C.

Ce que cela signifie pour les utilisateurs : Messagerie chiffrée plus stable avec moins de déconnexions, en particulier sur les appareils mobiles. L’implémentation Rust réduit les risques de plantage et la consommation de batterie due aux tentatives de reconnexion constantes.

Arti est une réécriture complète de Tor en Rust, développée par le projet Tor pour offrir une meilleure sécurité grâce à la sûreté mémoire et une intégration plus facile dans les applications. Pour Bitchat, les propriétés de sûreté mémoire réduisent la surface d’attaque lors du traitement des messages chiffrés et des connexions relais. La migration fait suite au récent audit de sécurité Cure53 de l’équipe (couvert dans la Newsletter #5), poursuivant leurs améliorations de sécurité.

La PR introduit également une couverture de tests complète pour ChatViewModel et BLEService, supprime le code mort et stabilise la suite de tests. Les améliorations de fiabilité du maillage Bluetooth Low Energy accompagnent les changements Tor, traitant les échecs de transferts importants. Ensemble, ces changements améliorent la résilience de Bitchat pour les scénarios de réseau maillé hors ligne où Tor fournit la connectivité Internet aux côtés de la communication BLE locale.

Listr revitalisé avec maintenance assistée par IA

JeffG a annoncé une refonte majeure de Listr, l’application de gestion de listes Nostr disponible sur listr.lol, après que le projet avait été en dormance pendant plus d’un an. Avec l’assistance IA, il a complété une mise à niveau complète incluant la migration vers NDK 3 beta, les mises à jour vers les dernières versions de Svelte et Vite, et toutes les dépendances mises à jour. La refonte ajoute un support de première classe pour les packs de suivi, implémente la pagination pour les listes dépassant 50 éléments et corrige de nombreux bugs qui s’étaient accumulés pendant la période de dormance.

Ce que cela signifie pour les utilisateurs : Listr est de retour en ligne avec des performances améliorées et de nouvelles fonctionnalités pour gérer les listes de suivi, les collections de contenu et la curation de sujets. Le correctif de pagination rend les grandes listes réellement utilisables.

JeffG a noté que sans l’assistance IA, ce travail de maintenance n’aurait probablement jamais eu lieu, empêchant le projet d’être abandonné. Listr permet la curation de contenu sur Nostr, permettant aux utilisateurs de créer, gérer et partager des listes de profils, sujets et ressources. La mise à niveau maintient l’application compatible avec les normes Nostr actuelles et les attentes des clients alors que la gestion des listes devient plus centrale pour la découverte de contenu sur le protocole.

Mises à jour des NIP

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

Fusionnées :

NIP-29 (Groupes basés sur les relais) - Clarification de la clé de relais (#2190 - fusionnée) clarifie que la clé de relais est l’URL du relais elle-même, pas une pubkey. La spécification indique maintenant explicitement “La clé de relais est l’URL WebSocket du relais (par ex., wss://groups.example.com)” pour éviter toute confusion. Cela affecte la façon dont les clients identifient quel relais héberge un groupe donné, garantissant que les groupes sont correctement attribués à leurs relais d’hébergement.

PR ouvertes et discussions :

Assertions de Relais de Confiance - Un NIP brouillon propose de standardiser la notation de confiance des relais via des événements kind 30385 contenant des scores de confiance (0-100) calculés à partir des métriques NIP-66 (découverte et surveillance de relais), de la réputation de l’opérateur et des rapports utilisateurs. La spécification divise la confiance en composantes de fiabilité (disponibilité, latence), qualité (TLS, documentation, vérification de l’opérateur) et accessibilité (juridiction, barrières, risque de surveillance). La vérification de l’opérateur inclut des signatures cryptographiques via NIP-11 (documents d’information de relais), des enregistrements DNS TXT et des fichiers .well-known. Les utilisateurs déclarent les fournisseurs d’assertions de confiance via des événements kind 10385, permettant aux clients d’interroger plusieurs fournisseurs pour des perspectives diverses. La proposition complète la découverte NIP-66 avec l’évaluation, aidant NIP-46 (signature à distance/Nostr Connect) à évaluer la fiabilité des relais dans les URI de connexion.
Cryptographie post-quantique - PR #2185 (ouverte) continue d’évoluer depuis que la Newsletter #5 a introduit la proposition pour des algorithmes résistants aux attaques quantiques. La discussion de cette semaine s’est concentrée sur les détails d’implémentation pour la crypto-agilité : comment les clients gèrent les signatures doubles pendant la migration, la rétrocompatibilité pour les anciens clients et les implications de performance des signatures résistantes quantiques plus grandes. Les contributeurs ont débattu de la nécessité de n’imposer que ML-DSA-44 ou de supporter plusieurs algorithmes (ML-DSA-44, Falcon-512, Dilithium) pour la flexibilité. Le consensus penche vers une approche progressive : signatures quantiques optionnelles initialement, devenant obligatoires seulement après un support client généralisé et l’émergence d’une menace quantique réelle.

Plongée approfondie dans les NIP : NIP-11 et NIP-66

Cette semaine, nous examinons deux NIP qui fonctionnent ensemble pour permettre la découverte et l’évaluation des relais : NIP-11 définit comment les relais se décrivent, et NIP-66 standardise comment nous mesurons le comportement des relais. Ensemble, ils forment la base des systèmes d’évaluation de la confiance des relais.

NIP-11 : Document d’information de relais

NIP-11 définit un document JSON que les relais servent via HTTP pour décrire leurs capacités, politiques et informations d’opérateur. Lorsqu’un client se connecte à wss://relay.example.com, il peut récupérer https://relay.example.com (en remplaçant wss:// par https://) pour obtenir le document d’information du relais.

Le document utilise la négociation de contenu HTTP standard avec l’en-tête Accept: application/nostr+json. Cela permet aux relais de servir leur site web normal aux navigateurs tout en fournissant des métadonnées lisibles par machine aux clients Nostr. La réponse inclut le nom du logiciel de relais et la version, les informations de contact de l’opérateur (pubkey, email, contact alternatif), les NIP supportés et les paramètres opérationnels comme les exigences de paiement ou les restrictions de contenu.

Important, les documents NIP-11 de base sont du JSON non signé servi via HTTPS, s’appuyant uniquement sur les certificats TLS pour l’authenticité. Cela signifie que quiconque contrôle le serveur web du relais peut modifier le document, rendant les déclarations de l’opérateur invérifiables. La proposition d’Assertions de Relais de Confiance répond à cette lacune en introduisant des attestations signées via le champ self pubkey d’un relais, permettant une preuve cryptographique de l’identité de l’opérateur similaire à la façon dont les relais utilisent des événements signés pour les mécanismes d’authentification.

{
 "name": "relay.example.com",
 "description": "Un relais public à usage général",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "contact": "admin@example.com",
 "supported_nips": [1, 2, 4, 9, 11, 12, 16, 20, 22],
 "software": "git+https://github.com/relay/relay.git",
 "version": "1.2.3",
 "limitation": {
 "max_message_length": 16384,
 "max_subscriptions": 20,
 "max_filters": 100,
 "max_limit": 5000,
 "max_subid_length": 100,
 "min_prefix": 4,
 "max_event_tags": 2000,
 "max_content_length": 8196,
 "min_pow_difficulty": 0,
 "auth_required": false,
 "payment_required": false
 },
 "payments_url": "https://relay.example.com/payments",
 "fees": {
 "admission": [{"amount": 5000, "unit": "msats"}],
 "subscription": [{"amount": 1000, "unit": "msats", "period": 2592000}],
 "publication": []
 }
}

L’objet limitation indique aux clients quelles contraintes le relais applique. max_message_length limite la taille des trames WebSocket, max_subscriptions limite le nombre d’abonnements REQ simultanés par connexion, max_filters limite les filtres par REQ, et max_limit restreint combien d’événements un seul filtre peut demander. Ces paramètres aident les clients à adapter leur comportement aux capacités des relais, évitant les déconnexions dues au dépassement des limites.

Les informations de paiement apparaissent dans fees et payments_url. Les relais peuvent facturer pour l’admission (accès unique), l’abonnement (accès récurrent) ou la publication (frais par événement). Le payments_url pointe vers les détails sur les méthodes de paiement, généralement des factures Lightning ou des coffres ecash. Les relais payants utilisent ces champs pour communiquer les tarifs avant que les clients tentent l’authentification.

Le tableau supported_nips permet aux clients de découvrir les capacités des relais. Si un relais liste NIP-50, les clients savent qu’ils peuvent envoyer des requêtes de recherche en texte intégral. Si NIP-42 apparaît, les clients doivent s’attendre à des défis d’authentification. Cette publicité déclarative des capacités permet une amélioration progressive : les clients peuvent utiliser des fonctionnalités avancées là où elles sont disponibles tout en se dégradant gracieusement sur les relais avec un support limité.

Les informations sur l’opérateur renforcent la responsabilité. Le champ pubkey identifie l’opérateur du relais sur Nostr, permettant la communication directe via les DM NIP-17 ou les mentions publiques. L’email contact fournit un repli hors protocole. Ensemble, ces champs aident les utilisateurs à joindre les opérateurs pour signaler des abus, demander l’accès ou résoudre des problèmes techniques.

Les documents NIP-11 sont auto-déclarés : les relais décrivent ce qu’ils prétendent supporter, pas nécessairement ce qu’ils font réellement. C’est là que NIP-66 devient important.

NIP-66 : Découverte de relais et surveillance de disponibilité

NIP-66 standardise la publication des données de surveillance de relais sur Nostr. Les services de surveillance testent en continu les relais pour la disponibilité, la latence, la conformité au protocole et les NIP supportés. Ils publient les résultats sous forme d’événements kind 30166, fournissant un état de relais en temps réel indépendant de l’auto-déclaration des relais.

Les moniteurs vérifient la disponibilité des relais en se connectant et en envoyant des abonnements de test. Les mesures de latence suivent le temps de connexion, le temps de réponse d’abonnement et le délai de propagation d’événement. Les tests de conformité au protocole vérifient que le comportement du relais correspond aux spécifications, détectant les bugs d’implémentation ou les déviations intentionnelles. La vérification du support NIP va au-delà des déclarations NIP-11 en testant réellement si les fonctionnalités annoncées fonctionnent correctement.

{
 "id": "a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
 "pubkey": "4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4",
 "created_at": 1736784000,
 "kind": 30166,
 "tags": [
 ["d", "wss://relay.example.com"],
 ["rtt", "open", "143", "1736784000"],
 ["rtt", "read", "89", "1736784000"],
 ["rtt", "write", "92", "1736784000"],
 ["nips", "1", "2", "4", "9", "11", "12"],
 ["geo", "US", "United States", "New York"],
 ["other", "network", "clearnet"],
 ["other", "payment_required", "false"],
 ["other", "auth_required", "false"]
 ],
 "content": "{\"last_check\": 1736784000, \"checks\": 8760}",
 "sig": "8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b"
}

Le tag d contient l’URL du relais, faisant de ceci un événement remplaçable paramétré. Chaque moniteur publie un événement par relais, mis à jour au fur et à mesure que les mesures changent. Plusieurs moniteurs peuvent suivre le même relais, fournissant redondance et validation croisée. Les clients interrogent plusieurs pubkeys de moniteurs pour obtenir des perspectives diverses sur la santé des relais.

Les tags de temps d’aller-retour (rtt) mesurent la latence pour différentes opérations. rtt open suit l’établissement de connexion WebSocket, rtt read mesure le temps de réponse d’abonnement et rtt write teste la vitesse de publication d’événement. Toutes les valeurs sont en millisecondes. Les clients utilisent ces métriques pour préférer les relais à faible latence pour les opérations sensibles au temps ou dé-prioriser les relais lents.

Le tag nips liste le support NIP réellement vérifié, pas seulement le support revendiqué. Les moniteurs testent chaque NIP en exerçant sa fonctionnalité. Si un relais revendique la recherche NIP-50 dans son document NIP-11 mais que les requêtes de recherche échouent, les moniteurs omettront NIP-50 de la liste vérifiée. Cela fournit une vérité terrain sur les capacités des relais.

Les informations géographiques aident les clients à sélectionner des relais proches pour une meilleure latence et résistance à la censure. Le tag geo contient le code pays, le nom du pays et la région. Le tag network distingue les relais clearnet des services cachés Tor ou des points de terminaison I2P. Ensemble, ces tags permettent la diversité géographique : les clients peuvent se connecter à des relais dans plusieurs juridictions pour résister à la censure régionale.

Les données de surveillance alimentent les sélecteurs de relais dans les clients, les sites web explorateurs et la proposition d’Assertions de Relais de Confiance. En combinant les documents NIP-11 auto-déclarés avec les données NIP-66 mesurées et les assertions de confiance calculées, l’écosystème évolue vers une sélection de relais informée plutôt que de s’appuyer sur des valeurs par défaut codées en dur ou des recommandations de bouche à oreille.

Sorties

0xchat v1.5.3 - Fonctionnalités de messagerie améliorées

0xchat v1.5.3 apporte des améliorations significatives au client de messagerie Nostr de style Telegram. La version corrige les problèmes de conformité NIP-55 (application de signature Android) qui empêchaient la signature correcte des événements via des signataires externes comme Amber. La conformité totale signifie que 0xchat délègue maintenant correctement les opérations de signature, améliorant la sécurité en gardant les clés privées isolées.

La mise à jour intègre à la fois FileDropServer et BlossomServer comme options de stockage de média par défaut, offrant aux utilisateurs une redondance pour les téléchargements de fichiers. Blossom fournit un stockage adressable par contenu où les fichiers sont référencés par leurs hachages SHA-256, garantissant l’intégrité et permettant la déduplication sur le réseau. L’enregistrement automatique des brouillons pour Moments empêche la perte de données lors de la composition de contenu long, répondant aux plaintes des utilisateurs concernant les publications perdues lors des changements d’application ou des interruptions de connectivité.

L’intégration du portefeuille Cashu reçoit un polissage avec un filtrage automatique des preuves qui supprime les jetons dépensés de la vue du portefeuille. Cela résout l’UX confuse où les utilisateurs voyaient des preuves invalides aux côtés de l’ecash valide, rendant les calculs de solde peu fiables. Le filtrage se fait côté client, maintenant la confidentialité tout en améliorant l’expérience de paiement pour les transactions pair-à-pair dans les discussions.

Amber v4.1.0 Pré-versions - Refonte de l’interface

Amber v4.1.0-pre1 à v4.1.0-pre3 introduisent une interface repensée pour le signataire d’événements Android populaire. L’écran de connexion affiche maintenant clairement quelle application demande des permissions de signature, répondant à la confusion des utilisateurs concernant les flux d’autorisation. Le nouvel écran d’événements fournit une inspection détaillée des données que les applications veulent signer, permettant aux utilisateurs de prendre des décisions de sécurité éclairées avant d’approuver les opérations.

La gestion des permissions reçoit une attention significative avec une interface remaniée montrant exactement quelles capacités chaque application connectée a été accordée. Les utilisateurs peuvent révoquer des permissions spécifiques sans se déconnecter entièrement, permettant un contrôle fin sur la délégation de signature. Les compteurs de relais refactorisés utilisant la bibliothèque quartz mise à jour fournissent des statistiques en temps réel sur le débit d’événements et les performances des relais. Les connexions bunker NIP-46 (Nostr Connect) affichent maintenant des messages d’erreur détaillés lorsque les connexions échouent, remplaçant les erreurs de délai d’attente cryptiques par des diagnostics exploitables.

Changements notables de code et de documentation

Ce sont des pull requests fusionnées et des développements en phase précoce qui méritent d’être suivis. Certains sont des fonctionnalités expérimentales qui peuvent évoluer avant la sortie.

Zeus (Portefeuille Lightning avec Nostr Wallet Connect)

Zeus a fusionné 17 pull requests cette semaine, renforçant sa position en tant qu’implémentation NIP-47 Nostr Wallet Connect leader. Les correctifs les plus significatifs traitent les problèmes de cohérence des données et de conformité au protocole qui causaient des problèmes d’interopérabilité avec les clients Nostr.

Correctif de l’historique des transactions - PR #3542 résout un bug critique où les listes de transactions NWC affichaient des entrées incorrectes ou dupliquées. Le problème se produisait lorsque Zeus mettait en cache les données de transaction sans gérer correctement les mises à jour d’événements, amenant les utilisateurs à voir des transactions fantômes ou des paiements manquants. Le correctif implémente une déduplication d’événements appropriée et une invalidation de cache, garantissant que l’historique des transactions reflète avec précision l’état du nœud Lightning.

Conformité au protocole - PR #3548 traite les réponses getInfo incomplètes qui cassaient la compatibilité avec les clients attendant une conformité NIP-47 complète. Certains clients Nostr plantaient lors de la réception de réponses partielles manquant de champs comme block_height ou network. La PR garantit que tous les champs requis retournent avec des valeurs par défaut sensées même lorsque l’implémentation Lightning sous-jacente ne les fournit pas, améliorant la compatibilité de Zeus dans l’écosystème.

Résilience de connexion - PR #3543 implémente des notifications de délai d’attente pour les connexions Nostr bloquées. Auparavant, les utilisateurs attendaient indéfiniment lorsque les connexions relais tombaient silencieusement. Maintenant Zeus affiche des messages de délai d’attente clairs après 30 secondes d’inactivité, permettant aux utilisateurs de réessayer ou de changer de relais. PR #3541 ajoute une validation backend pour empêcher l’activation NWC sur des implémentations Lightning incompatibles, détectant les erreurs de configuration avant qu’elles ne causent des plantages à l’exécution.

Condition de concurrence Cashu - PR #3531 corrige un bug de concurrence dans la gestion des jetons Cashu où des opérations de frappe simultanées pouvaient corrompre la base de données de jetons. La condition de concurrence se produisait lorsque plusieurs threads mettaient à jour les compteurs de jetons sans verrouillage approprié, résultant occasionnellement en soldes incorrects. Le correctif ajoute une protection mutex autour des sections critiques, garantissant des mises à jour atomiques de l’état des jetons.

Primal Android (Client)

Primal Android a livré 12 PR fusionnées avec des améliorations significatives de la sécurité du portefeuille et du traitement des médias. L’implémentation de sauvegarde de portefeuille répond à l’une des fonctionnalités les plus demandées, tandis que le support NIP-92 améliore l’expérience visuelle dans toute l’application.

Système de sauvegarde de portefeuille - Une série de quatre PR (#844, #845, #846, #848) implémente une fonctionnalité complète de sauvegarde de phrase de récupération. Les utilisateurs peuvent maintenant exporter leur mnémonique de 12 mots via un flux sécurisé qui empêche les captures d’écran, affiche l’état de sauvegarde dans le tableau de bord du portefeuille et guide les utilisateurs existants à travers la migration. L’implémentation suit les normes BIP-39 et inclut une validation pour empêcher les utilisateurs de perdre des fonds en raison d’un enregistrement incorrect de la phrase.

Dimensions de média (NIP-92) - PR #718 implémente le support NIP-92 pour des ratios d’aspect d’image et de vidéo corrects. Sans métadonnées de dimensions, les clients doivent télécharger les images pour déterminer leur taille, causant des sauts de mise en page au chargement du contenu. NIP-92 ajoute des tags dim (comme ["dim", "1920x1080"]) aux événements de métadonnées de fichiers, permettant à Primal de réserver l’espace correct avant de télécharger les médias. Cela élimine les reflux gênants dans les galeries d’images et améliore les performances perçues.

Fiabilité du signataire distant - PR #841 corrige les problèmes de connexion NIP-46 où les préfixes wss:// manquants causaient des échecs silencieux. La PR valide les URI de relais lors de la configuration de la connexion bunker, ajoutant automatiquement le préfixe de protocole lorsque les utilisateurs collent des domaines nus. PR #843 traite un bug de threading où de mauvaises conditions réseau causaient la publication de réponses comme notes racines, cassant le flux de conversation. Le correctif garantit que les ID d’événement parent persistent à travers les interruptions réseau.

Protocole Marmot : White Noise (Bibliothèque de discussion de groupe chiffrée)

White Noise, la bibliothèque Rust alimentant les discussions de groupe chiffrées du Protocole Marmot, a fusionné six PR améliorant l’expérience utilisateur et la sécurité. Les changements rapprochent Marmot de la parité de fonctionnalités avec les applications de messagerie grand public tout en maintenant son architecture axée sur la confidentialité.

Accusés de réception de lecture - PR #433 et #436 implémentent le suivi de lecture de messages pour les conversations de groupe. Le système stocke les positions de lecture par utilisateur par groupe dans un seul appareil, permettant des badges de comptage non lu. L’implémentation utilise des horodatages monotones pour suivre la dernière position de message lu pour chaque conversation. Cette fonctionnalité fondamentale permet des indicateurs d’interface utilisateur montrant les compteurs de messages non lus par conversation.

Épinglage de conversation - PR #442 ajoute l’épinglage de conversation persistant via un champ pin_order dans la table de jonction accounts_groups qui relie les comptes aux groupes. Les conversations épinglées maintiennent leur position en haut des listes de discussions indépendamment de l’activité des messages, correspondant aux attentes des utilisateurs de Signal et WhatsApp. L’implémentation utilise l’ordonnancement par entiers pour permettre des épingles illimitées avec un tri déterministe.

Résolution déterministe de commit (MIP-03) - PR #152 (ouverte) implémente la proposition d’amélioration Marmot 03, résolvant le problème critique des conditions de concurrence de commit dans les discussions de groupe distribuées. Lorsque plusieurs membres soumettent simultanément des changements d’état de groupe (ajout/suppression de membres, changement de permissions), les clients pouvaient diverger sur l’ordonnancement des commits, fragmentant le groupe en états incompatibles. MIP-03 introduit des instantanés d’époque et une sélection déterministe de gagnant : le commit avec l’horodatage created_at le plus ancien gagne, avec l’ID d’événement lexicographique comme bris d’égalité. Cela permet à tous les clients de converger vers le même état via rollback et rejeu, maintenant la cohérence du groupe même pendant les partitions réseau.

Durcissement de sécurité - PR #443 empêche la copie inutile de secrets cryptographiques en utilisant des références dans resolve_group_image_path. Cela réduit la fenêtre pour les attaques mémoire où les secrets pourraient être récupérés à partir d’allocations tas libérées. PR #438 active le chiffrement de base de données SQLCipher via des paramètres de trousseau, protégeant l’historique des messages au repos. L’intégration du trousseau permet un stockage sécurisé des clés dans les trousseaux de plateforme plutôt que dans les fichiers de configuration.

nostrdb-rs (Bibliothèque de base de données) - PR ouverte

Implémentation de requêtes en streaming - PR #58 (ouverte) propose des requêtes fold en streaming pour permettre des opérations de base de données sans allocation. L’implémentation ajoute des méthodes fold, try_fold, count, any, all et find_map qui traiteraient les résultats de base de données un par un sans matérialiser des ensembles de résultats entiers en vecteurs. Cette approche réduirait la consommation de mémoire et permettrait une terminaison précoce pour les modèles de requête courants.

L’implémentation technique expose les rappels de résultats de requête de bas niveau (ndb_query_visit) en tant que visiteurs Rust avec état qui mappent les variantes ControlFlow aux actions de visiteur C. Une fois fusionné, le code d’application se lira comme une logique d’itérateur tout en s’exécutant près de la couche de base de données. Par exemple, compter les notes correspondantes diffuserait à travers les résultats plutôt que de les collecter, et find_map retournerait le premier résultat utile sans traiter les lignes restantes.

nostrdb alimente Damus et Notedeck, clients iOS/macOS et de bureau respectivement. Les requêtes en streaming permettraient des modèles efficaces comme la pagination, le filtrage conditionnel et les vérifications d’existence. La PR modifie 3 fichiers avec +756 ajouts et -32 suppressions, une refactorisation substantielle de la couche de requête. Les utilisateurs d’applications basées sur nostrdb-rs verraient une utilisation mémoire réduite lors de la navigation dans de grandes chronologies ou de la recherche dans des bases de données d’événements étendues.

nak (Outil CLI)

nak, l’outil en ligne de commande Nostr de fiatjaf, a fusionné six PR axées sur les améliorations du système de construction et les nouvelles fonctionnalités. PR #91 implémente une fonctionnalité de miroir Blossom, permettant à nak de servir de miroir pour les serveurs de média Blossom. Blossom est un protocole de stockage de média adressable par contenu qui fonctionne aux côtés des événements Nostr.

Les PR restantes traitent la compatibilité du système de construction sur les plateformes Windows, macOS et Linux, permettant le support du système de fichiers FUSE pour monter les événements Nostr comme répertoires locaux.

Damus (Client iOS) - PR ouvertes

Damus a 11 PR ouvertes explorant des améliorations architecturales significatives. Bien que celles-ci n’aient pas encore fusionné, elles signalent des directions importantes pour le développement de clients Nostr iOS, en particulier autour de la confidentialité, de l’efficacité de synchronisation et de l’optimisation des données mobiles.

Intégration Tor - PR #3535 intègre le client Tor Arti directement dans Damus, permettant des connexions relais anonymes sans dépendances externes. Contrairement aux approches Orbot ou Tor Browser, l’intégration d’Arti fournit une intégration transparente avec le sandboxing iOS et les limites d’exécution en arrière-plan. L’implémentation Rust apporte la sûreté mémoire à l’anonymisation réseau, réduisant la surface d’attaque par rapport au Tor en C. Les utilisateurs pourraient basculer le mode Tor par relais ou globalement, le client gérant la gestion des circuits de manière transparente.

Protocole de synchronisation Negentropy - PR #3536 implémente Negentropy, un protocole de réconciliation d’ensemble qui améliore radicalement l’efficacité de synchronisation. Au lieu de télécharger tous les événements depuis la dernière connexion, Negentropy échange des empreintes compactes (arbres Merkle) pour identifier exactement quels événements diffèrent entre le client et le relais. Pour les utilisateurs suivant des centaines de pubkeys, cela réduit la bande passante de synchronisation de mégaoctets à kilooctets. L’implémentation s’intègre avec RelayPool et SubscriptionManager, permettant une synchronisation efficace automatique sur tous les relais connectés.

Mode données réduites - PR #3549 ajoute des fonctionnalités de conservation de données cellulaires répondant aux retours des utilisateurs sur la consommation de bande passante. Le mode désactive le chargement automatique d’images, la pré-extraction vidéo et réduit les limites d’abonnement. Les utilisateurs sur connexions mesurées peuvent parcourir le contenu texte sans crainte de dépasser les plafonds de données. L’implémentation respecte les paramètres de mode données réduites iOS et fournit des contrôles granulaires pour différents types de médias.

Optimisations de base de données - PR #3548 retravaille le stockage d’instantané nostrdb pour des requêtes plus rapides et une utilisation disque réduite. L’optimisation change la façon dont les instantanés de base de données persistent sur disque, améliorant à la fois les performances de lecture et l’amplification d’écriture. Cela répond aux plaintes de décharge de batterie des utilisateurs avec de grandes bases de données d’événements.

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

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

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

Cette semaine : Bitchat fait l’objet d’un audit de sécurité professionnel par Cure53, la même entreprise qui a audité Signal et NIP-44, avec plus de 17 PR déjà fusionnées corrigeant des découvertes critiques. NIP-71 est fusionnée, apportant des événements vidéo adressables au protocole. Un NIP sur la cryptographie post-quantique ouvre la discussion sur la protection de Nostr contre les attaques quantiques futures. Amethyst v1.05.0 propose des listes de favoris, des notes vocales et une version de bureau anticipée, tandis que Nostur v1.25.3 améliore les DM NIP-17 avec des réactions et des réponses. Côté bibliothèques, rust-nostr étend le support de NIP-62 aux backends SQLite et LMDB, et NDK corrige un bug de suivi des abonnements.

Actualités

Bitchat termine l’audit de sécurité Cure53

Bitchat, la messagerie chiffrée iOS combinant Nostr avec Cashu, a fait l’objet d’un audit de sécurité professionnel par Cure53, l’une des entreprises de sécurité les plus respectées du secteur. Cure53 a précédemment audité Signal, Mullvad VPN, et notamment la spécification de chiffrement NIP-44 qui sous-tend la messagerie privée moderne sur Nostr.

L’audit a révélé plus de 12 problèmes de sécurité (BCH-01-002 à BCH-01-013). L’équipe Bitchat a répondu avec plus de 17 pull requests. Les corrections clés incluent :

Effacement des secrets DH du protocole Noise - PR #928 corrige six emplacements où les secrets partagés Diffie-Hellman n’étaient pas effacés après l’accord de clés, restaurant les garanties de confidentialité persistante. Lorsque les secrets persistent en mémoire plus longtemps que nécessaire, un vidage mémoire ou une attaque par démarrage à froid pourrait compromettre les communications passées.

Vérification des signatures - Plusieurs PR renforcent les chemins de vérification cryptographique, garantissant que les contrôles d’authenticité des messages ne peuvent pas être contournés par des entrées malformées.

Sécurité des threads - PR #929 ajoute une synchronisation par barrière aux files d’accusés de réception dans NostrTransport, évitant les conditions de concurrence qui pourraient causer une corruption de données ou des plantages sous des volumes de messages élevés.

Sécurité mémoire - PR #920 optimise le dédoublonneur de messages pour de meilleures performances avec un débit de messages élevé tout en évitant l’épuisement de la mémoire.

Validation des entrées - PR #919 renforce l’analyse des chaînes hexadécimales pour éviter les plantages dus aux entrées malformées, un vecteur d’attaque courant pour les dénis de service.

Bitchat gère l’ecash Cashu, rendant l’examen de sécurité professionnel essentiel. L’audit fait suite à l’audit du protocole Marmot de l’année dernière et à l’audit NIP-44 qui a vérifié la couche de chiffrement.

Mises à jour des NIP

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

Fusionnées :

NIP-71 - Événements vidéo adressables (#1669) introduit les kinds 34235 (vidéo horizontale) et 34236 (vidéo verticale) comme événements adressables. Un tag d requis fournit des identifiants uniques, permettant de mettre à jour les métadonnées vidéo sans republier l’événement entier. Un tag origin optionnel permet de suivre les sources d’importation. Déjà implémenté dans Amethyst et nostrvine.

PR ouvertes :

Cryptographie post-quantique - PR #2185 propose d’ajouter des algorithmes cryptographiques résistants aux attaques quantiques à Nostr. La spécification introduit ML-DSA-44 et Falcon-512 pour les signatures numériques, ciblant les « événements de très haute valeur » comme les applications et les autorités plutôt que les utilisateurs individuels. Bien que le chiffrement symétrique de NIP-44 (ChaCha20) soit résistant aux attaques quantiques, son échange de clés utilise secp256k1 ECDH qui est vulnérable à l’algorithme de Shor. La proposition inclut ML-KEM pour l’accord de clés afin de combler cette lacune. Il s’agit d’une proposition à un stade précoce ouvrant la discussion sur l’agilité cryptographique pour la sécurité à long terme de Nostr.
BOLT12 pour NIP-47 - Après 137 commentaires et une discussion approfondie, la communauté a décidé que les offres BOLT12 méritent leur propre spécification plutôt que d’étendre NIP-47. Les offres BOLT12 apportent des améliorations significatives par rapport aux factures BOLT11, notamment la réutilisabilité, une meilleure confidentialité grâce aux chemins masqués et des informations optionnelles sur le payeur. Le nouveau NIP définira des méthodes comme make_offer, pay_offer et list_offers pour les implémentations Nostr Wallet Connect.
NIP Audio Track - PR #1043 propose les kinds 32100 pour les pistes musicales et 32101 pour les épisodes de podcast, donnant au contenu audio le même traitement de première classe que NIP-71 offre pour la vidéo. Actuellement, les plateformes audio comme Wavlake, Zapstr et Stemstr utilisent chacune des formats d’événements propriétaires, fragmentant l’écosystème. Un standard commun permettrait l’interopérabilité afin que les utilisateurs puissent découvrir et lire de l’audio depuis n’importe quel client compatible.
NIP-A3 Universal Payment Targets - PR #2119 propose des événements kind 10133 utilisant les URI payto: RFC-8905 pour exposer les options de paiement sur plusieurs réseaux. Plutôt que de créer des kinds d’événements séparés pour Bitcoin, Lightning, Cashu ou les rails de paiement traditionnels, cette abstraction permet aux clients d’analyser des tags standardisés et d’invoquer des gestionnaires de paiement natifs. L’approche est pérenne puisque les nouvelles méthodes de paiement n’ont besoin que d’un schéma d’URI payto:.

Plongée approfondie dans les NIP : NIP-51 et NIP-65

Cette semaine, nous couvrons deux NIP qui stockent les préférences utilisateur : NIP-51 pour organiser le contenu, et NIP-65 pour organiser les connexions relay. Les deux utilisent des événements remplaçables, ce qui signifie que chaque nouvelle publication écrase la version précédente.

NIP-51 : Listes

NIP-51 définit plusieurs types de listes pour organiser les références aux événements, utilisateurs, hashtags et autres contenus. Amethyst v1.05.0 ajoute le support des favoris, ce qui en fait un bon moment pour comprendre comment fonctionnent les listes.

La spécification définit plusieurs kinds de listes, chacun servant un objectif différent. Le kind 10000 est votre liste de mise en sourdine pour masquer les utilisateurs, fils de discussion ou mots. Le kind 10001 épingle les événements à mettre en avant sur votre profil. Le kind 30003 stocke les favoris, ce que Amethyst supporte maintenant. D’autres kinds gèrent les ensembles de suivi (30000), les collections d’articles sélectionnés (30004), les centres d’intérêt hashtag (30015) et les ensembles d’emojis personnalisés (30030).

Les listes référencent le contenu via des tags. Une liste de favoris utilise des tags e pour des événements spécifiques et des tags a pour du contenu adressable comme les articles :

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

Le tag d fournit un identifiant unique, vous permettant de maintenir plusieurs ensembles de favoris comme « saved-articles », « read-later » ou « favorites » sous le même kind.

Les listes supportent à la fois les éléments publics et privés. Les éléments publics apparaissent dans le tableau des tags, visibles par quiconque récupère l’événement. Les éléments privés vont dans le champ content, chiffrés en utilisant NIP-44 pour vous-même. Cette structure duale vous permet de garder des favoris publics tout en attachant des notes privées, ou de maintenir une liste de mise en sourdine sans révéler qui vous avez mis en sourdine. Pour chiffrer pour vous-même, utilisez NIP-44 avec votre propre pubkey comme destinataire.

Les kinds de la série 10000 sont remplaçables, ce qui signifie que les relays ne conservent qu’un seul événement par pubkey. La série 30000 est paramétrable et remplaçable, permettant un événement par combinaison de pubkey et de tag d. Dans les deux cas, mettre à jour une liste signifie publier un remplacement complet ; vous ne pouvez pas envoyer de changements incrémentiels. Les clients doivent préserver les tags inconnus lors de la modification des listes pour éviter d’écraser les données ajoutées par d’autres applications.

NIP-65 : Métadonnées de liste de relays

NIP-65 définit des événements kind 10002 qui annoncent quels relays un utilisateur préfère pour la lecture et l’écriture. Cela aide les autres utilisateurs et clients à trouver votre contenu.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Chaque tag r contient une URL de relay et un marqueur optionnel. Un marqueur write désigne votre boîte d’envoi : les relays où vous publiez votre contenu. Un marqueur read désigne votre boîte de réception : les relays où vous vérifiez les mentions, réponses et tags. L’absence de marqueur indique les deux.

Quand Alice veut trouver les publications de Bob, son client récupère le kind 10002 de Bob, extrait ses relays d’écriture (sa boîte d’envoi) et s’y abonne. Quand Alice répond à Bob, son client publie vers ses relays de lecture (sa boîte de réception) pour qu’il voie la mention. Ce routage conscient des relays est le « modèle outbox », et il distribue les utilisateurs sur de nombreux relays plutôt que de concentrer tout le monde sur quelques serveurs centraux.

NIP-65 gère le routage du contenu public, mais les messages privés utilisent une liste séparée. NIP-17 définit le kind 10050 pour les relays de boîte de réception DM, utilisant des tags relay au lieu de tags r. Lors de l’envoi d’un message privé à quelqu’un, les clients recherchent l’événement kind 10050 du destinataire et y publient le message emballé-cadeau chiffré. Cette séparation garde le routage des DM distinct du routage du contenu public, et permet aux utilisateurs de spécifier différents relays pour les communications privées et publiques.

Le modèle outbox améliore la résistance à la censure puisqu’aucun relay unique n’a besoin de stocker ou de servir le contenu de tout le monde. Les clients maintiennent des connexions aux relays listés dans les événements NIP-65 de leurs utilisateurs suivis, se connectant dynamiquement à de nouveaux relays à mesure qu’ils découvrent de nouveaux comptes. NIP-65 complète les indices de relay trouvés dans d’autres NIP. Quand vous taguez quelqu’un avec ["p", "pubkey", "wss://hint.relay"], l’indice dit aux clients où chercher cette référence spécifique. NIP-65 fournit la liste autoritaire contrôlée par l’utilisateur, tandis que les indices offrent des raccourcis intégrés dans les événements individuels.

Pour de meilleurs résultats, gardez votre liste de relays à jour car les entrées obsolètes vous rendent plus difficile à trouver. La spécification recommande deux à quatre relays par catégorie. Lister trop de relays surcharge chaque client qui veut récupérer votre contenu, ralentissant leur expérience et augmentant la charge réseau. Les clients mettent en cache les événements NIP-65 et les rafraîchissent périodiquement pour rester à jour lorsque les utilisateurs mettent à jour leurs préférences.

Versions

Amethyst v1.05.0 - Le client Android populaire publie une mise à jour majeure avec plusieurs fonctionnalités phares. Les listes de favoris kind 30003 de NIP-51 permettent aux utilisateurs de sauvegarder des publications pour référence ultérieure, se synchronisant entre les clients compatibles. Les notes vocales fonctionnent maintenant dans les DM et les publications régulières avec visualisation de forme d’onde, sélection du serveur média et indicateurs de progression de téléchargement. Les scores de Web of Trust sont maintenant visibles dans l’interface, aidant les utilisateurs à comprendre comment l’algorithme évalue les comptes par rapport à leur graphe social. La migration de base de données Quartz améliore les performances des requêtes dans le cadre du travail Kotlin Multiplatform financé par OpenSats. Une version de bureau anticipée amène Amethyst sur Windows, macOS et Linux via Compose Multiplatform, partageant le même code que l’application Android. De nouveaux flux d’intégration facilitent l’expérience pour les nouveaux utilisateurs Nostr.

Nostur v1.25.3 - Le client iOS et macOS se concentre sur la messagerie privée avec des améliorations NIP-17. Les conversations DM supportent maintenant les réactions et les réponses, apportant l’interactivité des publications publiques aux messages chiffrés. La vue de conversation a été retravaillée avec un meilleur threading pour que les échanges multi-messages soient plus faciles à suivre, et les horodatages affichent « il y a » dans la liste des DM pour un balayage rapide. Les utilisateurs de bureau obtiennent des dispositions multi-colonnes pour visualiser plusieurs flux ou conversations côte à côte. Le support du signataire distant NIP-46 permet aux utilisateurs de garder leurs clés privées dans des applications de signature dédiées comme Amber ou nsec.app. Des corrections supplémentaires restaurent la fonctionnalité DM sur iOS 15 et iOS 16, résolvent les retards de notification et ajoutent la possibilité de configurer quels relays reçoivent les DM publiés.

Changements notables de code et documentation

Ce sont des pull requests ouvertes et des travaux à un stade précoce, parfaits pour obtenir des retours avant leur fusion. Si quelque chose attire votre attention, pensez à faire une revue ou à commenter !

Citrine (Relay Android)

PR #89 corrige une vulnérabilité d’injection SQL dans l’application de relay personnel Android. Le problème permettait à des données d’événements malformées d’exécuter des requêtes de base de données arbitraires, un défaut sérieux pour toute application qui stocke et traite des entrées non fiables. La correction assainit correctement toutes les opérations de base de données en utilisant des requêtes paramétrées. Aucune version n’a encore été taguée, donc les utilisateurs devront attendre la prochaine version ou compiler depuis les sources. PR #90 optimise les performances de requête ContentProvider avec un filtrage et une pagination au niveau de la base de données, réduisant la latence lorsque des applications externes comme Amethyst accèdent à la base de données d’événements de Citrine via la couche de communication inter-processus d’Android.

rust-nostr (Bibliothèque)

Le support de NIP-62 (requêtes de disparition) s’étend aux backends de base de données de rust-nostr. PR #1180, fusionnée il y a deux semaines, a ajouté le support NIP-62 à SQLite, gérant les requêtes de disparition ALL_RELAYS puisque la couche base de données ne connaît pas les URL de relay spécifiques. PR #1210 étend ceci au backend LMDB, garantissant que les requêtes de disparition sont persistées sur le disque et survivent aux redémarrages de relay. Une implémentation IndexedDB pour les environnements navigateur est également en cours. Ensemble, ces changements donnent aux développeurs un support NIP-62 cohérent à travers SQLite, LMDB et bientôt le stockage navigateur.

NDK (Nostr Development Kit)

PR #375 corrige un bug dans le système de suivi seenEvents. Le problème faisait que certains patterns d’abonnement marquaient incorrectement les événements comme déjà vus, conduisant à du contenu manqué lorsque les utilisateurs ouvraient de nouveaux abonnements ou se reconnectaient aux relays. La correction garantit que les événements sont suivis avec précision à travers les cycles de vie des abonnements, ce qui est particulièrement important pour les applications qui s’abonnent et se désabonnent dynamiquement en fonction de la navigation de l’utilisateur. NDK est passé à la version beta.70 avec cette correction incluse.

Damus (iOS)

PR #3515 corrige un plantage au démarrage affectant les utilisateurs iOS 17. Le problème provenait d’un dépassement arithmétique dans NdbUseLock, une classe de repli utilisée car les Swift Mutexes ne sont pas disponibles sur iOS 17. La correction remplace l’approche de synchronisation précédente par NSLock, qui est disponible sur iOS 17 et gère correctement les conditions de concurrence restantes. Les utilisateurs iOS 18+ n’étaient pas affectés puisqu’ils ont accès à l’implémentation native Swift Mutex.

Séparément, un lot d’améliorations pour les articles longs a été intégré via PR #3509. Des barres de progression de lecture suivent votre position dans les articles, les temps de lecture estimés apparaissent sur les aperçus, et le mode sépia avec des paramètres de hauteur de ligne ajustables offrent une lecture plus confortable. Le mode concentration masque automatiquement l’interface de navigation lors du défilement vers le bas et la restaure au toucher, réduisant l’encombrement visuel pour une lecture sans distraction. Plusieurs corrections traitent l’affichage des images dans le contenu markdown et garantissent que les articles s’ouvrent en haut plutôt qu’à mi-chemin.

Zap.stream (Streaming en direct)

L’intégration du chat YouTube et Kick relie les messages des plateformes de streaming externes à Nostr. Les streamers qui diffusent sur YouTube, Kick et Zap.stream peuvent maintenant voir tous les messages de chat dans une vue unifiée, avec les messages de chaque plateforme apparaissant aux côtés des commentaires Nostr natifs. Cela supprime un point de friction majeur pour les créateurs qui veulent utiliser Nostr pour le streaming mais ne peuvent pas abandonner leurs audiences sur les plateformes établies. L’intégration affiche de quelle plateforme chaque message provient et gère le flux d’authentification pour connecter les comptes externes.

Chachi (Groupes NIP-29)

Le client de chat de groupe NIP-29 a publié six PR fusionnées cette semaine. Une mise à jour de sécurité traite CVE-2026-22029, une vulnérabilité XSS dans react-router qui pourrait permettre des attaques de redirection ouverte ; la correction met à jour vers react-router-dom 6.30.0. PR #92 ajoute le chargement paginé des messages pour les chats de groupe, de sorte que les longues conversations se chargent de manière incrémentielle plutôt que tout d’un coup. PR #91 corrige plusieurs bugs NIP-29 incluant une condition de concurrence qui causait des noms de groupe vides au chargement initial et des listes de participants indéfinies qui plantaient les vues de membres. La couverture de traduction s’étend maintenant aux 31 langues supportées avec 1060 clés chacune.

0xchat (Messagerie)

Le client de messagerie style Telegram a amélioré la conformité NIP-55 en sauvegardant correctement les noms de paquets des signataires lors de l’utilisation d’applications de signature externes, corrigeant les problèmes où l’application perdait la trace du signataire à utiliser après les redémarrages. La gestion des réponses NIP-17 inclut maintenant correctement le tag e pour le threading, garantissant que les réponses apparaissent dans le bon contexte de conversation entre les clients. Des optimisations de performance traitent le lag de défilement dans les listes de messages, un point de douleur courant lors du chargement de longs historiques de chat. La sauvegarde automatique des brouillons empêche la perte de messages si vous naviguez ailleurs en cours de composition, et les options de stockage de fichiers incluent maintenant les endpoints FileDropServer et BlossomServer par défaut.

Primal (iOS)

Le support du signataire distant NIP-46 arrive sur iOS via PR #184, complétant le déploiement multiplateforme commencé avec Android il y a plusieurs semaines. Les utilisateurs peuvent maintenant garder leurs clés privées dans des services bunker dédiés comme nsec.app ou des instances nsecBunker auto-hébergées, se connectant via les relays Nostr pour signer les événements sans exposer les clés à l’application cliente. Cette séparation améliore la posture de sécurité pour les utilisateurs qui veulent utiliser les fonctionnalités de Primal tout en maintenant des pratiques de gestion de clés plus strictes. L’implémentation inclut le scan de code QR pour les URI de connexion bunker et gère le flux requête/réponse NIP-46 via des messages relay chiffrés.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire de l’écosystème du protocole Nostr.

Cette semaine : Primal Android intègre la signature à distance NIP-46 et le support du signataire local NIP-55, en faisant un hub de signature complet pour les autres applications Android. L’équipe du Protocole Marmot a répondu aux conclusions d’un audit de sécurité avec 18 PR fusionnées renforçant la messagerie chiffrée basée sur MLS. Citrine atteint la v1.0 et Applesauce livre la v5.0 sur l’ensemble de sa suite de bibliothèques. TENEX développe la supervision des agents IA sur Nostr, et Jumble ajoute un pooling intelligent des relais. Une correction de la spec NIP-55 clarifie les champs de retour de nip44_encrypt, et une PR NIP-50 propose des extensions d’expressions de requête pour la recherche avancée. Dans notre analyse approfondie, nous expliquons NIP-04 et NIP-44 : pourquoi le chiffrement historique présente des failles de sécurité et comment le remplacement moderne les corrige.

Actualités

Primal Android devient un hub de signature complet - La version 2.6.18 ajoute à la fois la signature à distance NIP-46 et la signature locale NIP-55, transformant Primal en un signataire complet pour les autres applications Nostr. La signature à distance via NIP-46 permet aux utilisateurs de se connecter aux services bunker via les relais Nostr, gardant les clés entièrement hors de leur appareil. La signature locale via NIP-55 expose Primal comme un fournisseur de contenu Android, permettant aux applications comme Amethyst ou Citrine de demander des signatures sans jamais toucher à la clé privée. Plusieurs PR de suivi ont corrigé des problèmes de compatibilité avec l’exigence de pubkey hexadécimale de la spec NIP-55, et amélioré l’analyse des URI nostrconnect:// malformées. La version inclut également la pré-mise en cache des médias pour un défilement plus fluide, des temps de chargement des fils améliorés et la pré-mise en cache des avatars.

Le Protocole Marmot renforce la sécurité après un audit - Le Marmot Development Kit (mdk), qui implémente la messagerie chiffrée de bout en bout basée sur MLS NIP-104, a reçu d’importants correctifs de sécurité cette semaine. Dix-huit pull requests fusionnées ont traité les conclusions de l’audit, notamment : la vérification de hachage pour les images de groupe chiffrées pour prévenir les attaques de substitution de blobs au niveau du stockage, la pagination des welcomes en attente pour prévenir l’épuisement de la mémoire, la fuite d’ID de groupe MLS dans les messages d’erreur, et l’application de l’encodage base64 pour les packages de clés. La spec Marmot elle-même a été mise à jour avec le versionnement MIP-04 v2 et des améliorations de sécurité. Des PR actives continuent de traiter la réutilisation de nonce, la mise à zéro des secrets et les vecteurs de pollution du cache.

Nostrability suit le support des indications de relais - Un nouveau tracker de compatibilité des indications de relais documente comment les clients construisent et consomment les indications de relais à travers l’écosystème. Le tracker révèle que bien que la plupart des clients construisent maintenant des indications selon NIP-10 et NIP-19, la consommation varie largement : certains clients incluent des indications dans les événements sortants mais n’utilisent pas les indications entrantes pour la récupération. Six clients ont obtenu le statut “Full” pour une implémentation complète. Le tracker est utile pour les développeurs vérifiant l’interopérabilité et pour les utilisateurs se demandant pourquoi certains clients trouvent du contenu que d’autres ne peuvent pas trouver.

Nostria 2.0 livre une refonte des fonctionnalités multi-plateformes - Le client Nostria a publié la version 2.0 le 30 décembre avec des ajouts significatifs sur iOS (TestFlight), Android (Play Store), Web et Windows. La version ajoute le support natif de la musique avec création de playlists, téléchargement de pistes, paiements aux artistes via zaps et un lecteur style WinAmp avec égaliseur fonctionnel. Le streaming en direct bénéficie de l’intégration de l’API de jeu montrant des métadonnées enrichies pendant les streams de gameplay. Une nouvelle fonctionnalité Résumé génère des digests d’activité horaires, quotidiens ou hebdomadaires sous forme de vues de timeline compressées. La section Découvrir offre des listes curatées pour trouver du contenu et des profils. La publication de médias est simplifiée avec la génération automatique de publications courtes pour la découvrabilité inter-clients. Les connexions aux signataires distants fonctionnent maintenant via scan de code QR sans configuration manuelle. La découverte de profils répond à un point douloureux courant de Nostr : lorsque les utilisateurs changent de relais sans emporter leurs métadonnées, Nostria localise leur profil et le republie sur leurs relais actuels. Les abonnés Premium bénéficient de l’intégration de chaînes YouTube, de Memos privés, de tableaux de bord analytiques et de sauvegardes automatiques de la liste de suivi avec options de fusion/restauration.

Mises à jour des NIP

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

Fusionné :

NIP-55 - Correction du champ de retour pour la méthode nip44_encrypt (#2184). Les signataires Android doivent maintenant retourner le payload chiffré dans le champ signature (comme nip44_decrypt) plutôt que dans un champ séparé. Cela aligne la spec avec les implémentations existantes dans Amber et Primal.

PR ouvertes :

NIP-50 - Extensions d’expressions de requête (#2182) propose d’étendre la recherche NIP-50 avec des expressions de requête structurées. La PR ajoute des opérateurs comme kind:1, author:npub1..., et des combinaisons booléennes (AND, OR, NOT), permettant des requêtes de recherche plus précises au-delà de la simple correspondance de texte. Cela permettrait aux clients de construire des interfaces de recherche avancées tout en maintenant la compatibilité ascendante avec les chaînes de recherche basiques.

Analyse approfondie des NIP : NIP-04 et NIP-44

Cette semaine, nous couvrons les standards de chiffrement de Nostr : le NIP-04 historique que vous rencontrerez encore, et son remplacement moderne NIP-44 qui corrige des failles de sécurité critiques.

NIP-04 : Messages directs chiffrés (historique)

NIP-04 était la première tentative de Nostr pour la messagerie chiffrée, utilisant des événements kind 4. Bien que simple à implémenter, il présente des faiblesses de sécurité connues et est déprécié en faveur de NIP-44.

Comment ça fonctionne : NIP-04 utilise ECDH (Elliptic Curve Diffie-Hellman) pour dériver un secret partagé entre l’expéditeur et le destinataire, puis chiffre avec AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

Le flux de chiffrement :

Calculer le point partagé : shared = ECDH(sender_privkey, recipient_pubkey)
Dériver la clé : key = SHA256(shared_x_coordinate)
Générer un IV aléatoire de 16 octets
Chiffrer : ciphertext = AES-256-CBC(key, iv, plaintext)
Formater le contenu : base64(ciphertext)?iv=base64(iv)

Problèmes de sécurité :

Pas d’authentification : AES-CBC fournit la confidentialité mais pas l’intégrité. Un attaquant qui contrôle un relais pourrait modifier les bits du texte chiffré, causant des changements prévisibles au texte clair (attaques par inversion de bits).
IV en clair : Le vecteur d’initialisation est transmis avec le texte chiffré, et le mode CBC avec des IV prévisibles permet des attaques à texte clair choisi.
Pas de validation du padding : Les implémentations varient dans leur gestion du padding PKCS#7, permettant potentiellement des attaques par oracle de padding.
Exposition des métadonnées : La pubkey de l’expéditeur, la pubkey du destinataire et l’horodatage sont tous visibles par les relais.
Réutilisation de clé : Le même secret partagé est utilisé pour tous les messages entre deux parties, indéfiniment.

Pourquoi il existe encore : De nombreux anciens clients et relais ne supportent que NIP-04. Vous le rencontrerez lors d’interactions avec des systèmes héritage. Les signataires comme Amber et les applications comme Primal implémentent encore nip04_encrypt/nip04_decrypt pour la compatibilité ascendante.

NIP-44 : Chiffrement versionné

NIP-44 est le standard de chiffrement moderne, conçu pour corriger les failles bien connues de NIP-04. Un audit de sécurité Cure53 des implémentations NIP-44 a identifié 10 problèmes (incluant des attaques temporelles et des préoccupations de confidentialité persistante) qui ont été traités avant la finalisation de la spec. Il utilise ChaCha20-Poly1305 avec une dérivation de clé appropriée et un chiffrement authentifié.

Améliorations clés par rapport à NIP-04 :

Aspect	NIP-04	NIP-44
Chiffrement	AES-256-CBC	XChaCha20-Poly1305
Authentification	Aucune	MAC Poly1305
Dérivation de clé	SHA256(shared_x)	HKDF avec sel
Nonce	IV 16 octets, patron réutilisé	Nonce aléatoire 24 octets
Padding	PKCS#7 (fuite de longueur)	Padding puissance de 2
Versionnement	Aucun	Octet de version préfixé

Flux de chiffrement :

Clé de conversation : Dériver une clé stable pour chaque paire expéditeur-destinataire :

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Clés de message : Pour chaque message, générer un nonce aléatoire de 32 octets et dériver les clés de chiffrement/authentification :

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Padding du texte clair : Padding à la puissance de 2 suivante (minimum 32 octets) pour masquer la longueur du message :
```
padded = [length_u16_be] + [plaintext] + [zeros to next power of 2]
```

Chiffrer et authentifier :

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Formater le payload :

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Octet de version : Le premier octet (0x02) indique la version de chiffrement. Cela permet des mises à niveau futures sans casser les messages existants. La version 0x01 était un brouillon antérieur qui n’a jamais été largement déployé.

Déchiffrement :

Décoder le base64, vérifier que l’octet de version est 0x02
Extraire le nonce (octets 1-32), le texte chiffré et le MAC (derniers 32 octets)
Dériver la clé de conversation en utilisant la clé privée du destinataire et la clé publique de l’expéditeur
Dériver les clés de message à partir de la clé de conversation et du nonce
Vérifier le MAC avant de déchiffrer (rejeter si invalide)
Déchiffrer le texte chiffré, extraire le préfixe de longueur, retourner le texte clair sans padding

Propriétés de sécurité :

Chiffrement authentifié : Le MAC Poly1305 garantit que toute altération est détectée avant le déchiffrement
Confidentialité persistante (partielle) : Chaque message utilise un nonce unique, donc compromettre un message ne révèle pas les autres. Cependant, compromettre une clé privée révèle toujours tous les messages passés (pas de ratcheting).
Masquage de longueur : Le padding en puissance de 2 obscurcit la longueur exacte du message
Résistance aux attaques temporelles : Comparaison à temps constant pour la vérification du MAC

Utilisation en pratique : NIP-44 est la couche de chiffrement pour :

Les messages directs privés NIP-17 (à l’intérieur du gift wrap)
La communication avec les signataires distants NIP-46
Le chiffrement seal NIP-59
Les messages de groupe Protocole Marmot, où NIP-44 enveloppe le contenu chiffré MLS en utilisant une clé dérivée du secret exportateur MLS
Toute application nécessitant un chiffrement sécurisé point-à-point

Guide de migration : Les nouvelles applications devraient utiliser exclusivement NIP-44. Pour la compatibilité ascendante, vérifiez si le client d’un contact supporte NIP-44 (via les métadonnées d’application NIP-89 ou le support du relais) avant de revenir à NIP-04. Lors de la réception de messages, tentez d’abord le déchiffrement NIP-44, puis revenez à NIP-04 pour le contenu héritage.

Versions

Primal Android v2.6.18 - La version complète ajoute la signature à distance NIP-46 et la signature locale NIP-55, transformant Primal en hub de signature pour les autres applications Android. Les améliorations de performance incluent la pré-mise en cache des médias, la pré-mise en cache des avatars et un chargement plus rapide des fils. Les corrections de bugs traitent les auto-mentions dans les bios, les crashs de la galerie média et les replis de titres de stream. Sur iOS, Primal utilise la lecture audio en arrière-plan pour garder l’application active pour recevoir les demandes de signature NIP-46 ; les utilisateurs peuvent changer le son ou le couper entièrement dans les paramètres.

Mostro v0.15.6 - La dernière version de la plateforme de trading Bitcoin P2P NIP-69 complète l’implémentation du fonds de développement avec les événements d’audit Phase 4. Les paiements de frais de développement sont maintenant suivis via des événements Nostr kind 38383 publiés après chaque paiement réussi, permettant la vérification et l’analyse par des tiers. Les calculs de montants ont été corrigés pour les messages acheteur/vendeur, et la logique de premium a été alignée avec l’implémentation de référence lnp2pbot.

Aegis v0.3.5 - Le signataire multi-plateforme ajoute le mode sombre, un affichage amélioré des icônes d’application et des mises en page UI plus propres. Les corrections de bugs traitent les conflits iCloud Private Relay sur iOS et les problèmes d’analyse d’événements. La version améliore également la façon dont le JSON d’événement est passé à la fonction de signature Rust.

Citrine v1.0.0 - L’application relais Android atteint la 1.0. Citrine vous permet d’exécuter un relais Nostr personnel directement sur votre appareil Android, utile pour le cache local, la sauvegarde ou comme compagnon NIP-55. Cette version ajoute un gestionnaire de rapports de crash, améliore l’efficacité des requêtes de base de données et met à jour les traductions via Crowdin.

Applesauce v5.0.0 - La suite de bibliothèques TypeScript de hzrd149 livre une version majeure avec des changements cassants axés sur la correction et la simplicité. Le package core vérifie maintenant les signatures d’événements par défaut et renomme les méthodes de coordonnées pour utiliser une terminologie “address” plus claire (parseCoordinate -> parseReplaceableAddress). Le package relay réduit les tentatives par défaut de 10 à 3 et ignore les relais inaccessibles par défaut, plus ajoute createUnifiedEventLoader pour une récupération d’événements plus simple. Le package wallet gagne la découverte de mint Cashu NIP-87. Les dépendances directes à nostr-tools ont été supprimées dans tous les packages, réduisant la taille du bundle et les conflits de versions.

Changements notables de code et de documentation

Ce sont des pull requests ouvertes et des travaux en phase initiale, parfaits pour obtenir des retours avant fusion. Si quelque chose attire votre attention, envisagez de réviser ou commenter !

Damus (iOS)

Une série de PR améliore l’expérience des articles longs. Les améliorations UX de lecture ajoutent une barre de progression, un temps de lecture estimé, un mode sépia, une hauteur de ligne ajustable et un mode focus qui masque la navigation pendant le défilement. Les corrections d’images garantissent que les images dans le contenu markdown s’affichent avec les bons ratios d’aspect en pré-traitant les images autonomes comme éléments de niveau bloc. Les cartes d’aperçu d’articles longs remplacent le texte inline @naddr1... par des cartes d’aperçu riches montrant le titre et les métadonnées de l’article. Une nouvelle suite de tests d’intégration relais ajoute 137 tests liés au réseau incluant la vérification du protocole NIP-01 et le comportement sous conditions réseau dégradées (simulation 3G).

Bitchat (Messagerie chiffrée)

Renforcement de la sécurité dans le messager Nostr+Cashu iOS. L’effacement des secrets DH du protocole Noise corrige six emplacements où les secrets partagés n’étaient pas mis à zéro après l’accord de clé Diffie-Hellman, restaurant les garanties de confidentialité persistante. La sécurité des threads pour les files d’accusés de réception ajoute la synchronisation par barrière pour prévenir les conditions de course dans NostrTransport. L’optimisation du déduplicateur de messages améliore les performances avec des volumes de messages élevés, et le renforcement de l’analyse des chaînes hexadécimales prévient les crashs dus à des entrées malformées.

Frostr (Signature à seuil)

Le protocole de signature à seuil basé sur FROST a ajouté l’affichage de codes QR pour les identifiants de groupe et les identifiants de partage pendant l’onboarding et dans l’interface du signataire. Cela facilite la configuration lors de la distribution des parts de clé sur plusieurs appareils, permettant aux utilisateurs de scanner les identifiants au lieu de copier manuellement de longues chaînes.

Marmot mdk (Bibliothèque)

Au-delà des correctifs de sécurité mentionnés ci-dessus, des PR actives traitent les conclusions d’audit restantes : le type Secret pour la mise à zéro introduit un type wrapper qui met automatiquement à zéro les données sensibles à la destruction, la pagination des requêtes de messages prévient l’épuisement de la mémoire lors du chargement de l’historique de chat, et le stockage chiffré ajoute le chiffrement au repos pour la base de données SQLite stockant l’état du groupe et les messages.

Amethyst (Android)

Une semaine chargée de corrections de stabilité dans le client Android. L’analyse JSON tolérante prévient les crashs dus aux événements malformés en rendant la sérialisation Kotlin plus indulgente. La validation des événements vérifie maintenant la taille du champ kind avant traitement pour éviter les exceptions dues à des valeurs surdimensionnées. L’UI du score de confiance a reçu une icône plus petite pour réduire l’interférence visuelle, et la journalisation des erreurs améliorée aide à diagnostiquer les problèmes de connexion aux relais. Les mises à jour de traduction sont arrivées via Crowdin, et plusieurs avertissements SonarQube ont été traités.

TENEX (Agents IA)

Le framework d’agents IA natif Nostr a vu 81 commits cette semaine développant des capacités autonomes. Le nouveau système de supervision des agents implémente des heuristiques comportementales pour surveiller les actions des agents et intervenir si nécessaire. La transparence de délégation ajoute la journalisation des interventions utilisateur aux transcriptions de délégation, permettant aux utilisateurs d’auditer ce que les agents ont fait en leur nom. Le registre de fournisseurs LLM a été modularisé pour une intégration plus facile de différents backends IA. Le support de conversation inter-projets permet aux agents de maintenir le contexte à travers plusieurs projets basés sur Nostr.

Jumble (Client Web)

Le client web axé sur les relais a ajouté plusieurs améliorations de l’expérience utilisateur. Le pool de relais intelligent gère intelligemment les connexions selon les patterns d’utilisation. Le toggle de flux en direct permet aux utilisateurs de basculer entre le streaming en temps réel et le rafraîchissement manuel. L’affichage automatique des nouvelles notes en haut fait remonter le contenu frais sans nécessiter de rechargement de page. Le cache persistant pour le flux de suivi et les notifications améliore les temps de chargement lors des visites de retour. Les utilisateurs peuvent maintenant changer les relais par défaut via les paramètres.

Nostr Compass #3

Wed, 31 Dec 2025 00:00:00 +0000

Bienvenue dans Nostr Compass, votre guide hebdomadaire sur l’écosystème du protocole Nostr.

Cette semaine : Alors que 2025 s’achève, nous revenons sur cinq années de jalons de décembre dans l’évolution de Nostr. De la première version client de fiatjaf en décembre 2020, au don décisif de 14 BTC de Jack Dorsey en décembre 2022, jusqu’à la prolifération des signers NIP-55 et à l’accélération de cache 162x de NDK ce mois-ci, décembre a marqué de façon répétée des tournants pour le protocole. Ce numéro spécial retrace l’histoire technique de chaque mois de décembre, documentant la croissance du protocole, de deux relays expérimentaux à plus de 2 500 nœuds dans 50 pays. En plus : le module desktop d’Amethyst prend forme via Quartz, Notedeck gagne une messagerie, Citrine héberge des applications web et NIP-54 corrige l’internationalisation pour les écritures non latines.

Récapitulatif de décembre : cinq années de décembres Nostr

Nostr fête ses cinq ans cette année. fiatjaf a lancé le protocole le 7 novembre 2020, et chaque mois de décembre depuis a marqué une phase distincte de son évolution : de la preuve de concept au mouvement mondial, puis à l’écosystème de production. Il s’agit d’une rétrospective technique de décembre 2020 à décembre 2025, les années formatrices qui ont posé les fondations de Nostr et catalysé son moment de bascule.

Décembre 2020 : genèse

Le premier mois complet d’existence de Nostr a vu fiatjaf publier Branle, le premier client du protocole, construit avec Quasar (Vue.js) et absurd-sql pour le stockage local. fiatjaf avait déjà posé l’architecture de base : des utilisateurs identifiés par des clés publiques secp256k1, des messages tous signés cryptographiquement, et des relays servant de stockage passif sans communiquer entre eux. Un ou deux relays expérimentaux servaient une poignée d’adoptants précoces qui se coordonnaient dans le groupe Telegram @nostr_protocol, lancé le 16 novembre. La documentation d’origine décrivait « the simplest open protocol that is able to create a censorship-resistant global social network », une promesse qui demanderait encore deux années avant d’être prouvée.

Décembre 2021 : premiers développements

Le 31 décembre 2021, Nostr a atteint la page d’accueil de Hacker News avec 110 points et 138 commentaires, via une soumission de Cameri. Cela a marqué la première exposition significative du protocole auprès de la communauté de développeurs au sens large. Le réseau fonctionnait sur environ sept relays avec moins de 1 000 utilisateurs. Branle a reçu des mises à jour, dont l’import de clé privée le 31 décembre et le support multi-relays. Un client en ligne de commande, noscl, permettait une interaction via terminal. Les spécifications du protocole vivaient encore dans la documentation de fiatjaf, puisque le dépôt formel des NIPs ne serait créé qu’en mai 2022. Le protocole était, selon les mots de fiatjaf, « a work in progress ».

Décembre 2022 : le point de bascule

Décembre 2022 a transformé Nostr, d’expérience confidentielle en mouvement plus large. Le catalyseur est arrivé le 15 décembre, quand Jack Dorsey a donné 14.17171699 BTC (environ 245 000 à 250 000 dollars) à fiatjaf après avoir découvert le protocole et déclaré qu’il représentait « 100 percent what we wanted from Bluesky, but it wasn’t developed from a company ». Le 16 décembre, fiatjaf a annoncé qu’il partageait les fonds avec le développeur de Damus William Casarin (jb55), et Dorsey a vérifié son compte Nostr (npub : npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m). Ce financement a légitimé le projet du jour au lendemain.

La même semaine, le chaos sur Twitter a accéléré l’adoption. Les 14 et 15 décembre ont vu la suspension de journalistes en vue du New York Times, de CNN et du Washington Post. Le 18 décembre, Twitter a annoncé des interdictions visant les comptes faisant la promotion de Nostr, Mastodon et d’autres plateformes. La politique a été annulée dès le lendemain après un retour de bâton. Cet exode a poussé les utilisateurs à explorer des alternatives.

Le développement du protocole s’est emballé. Le 16 décembre, NIP-19 a été fusionné (#57), introduisant des identifiants encodés en bech32 (npub, nsec, note, nprofile, nevent) qui rendaient les clés lisibles par des humains et faciles à distinguer. Le dépôt des NIPs a enregistré plus de 36 commits ce mois-là, y compris des mises à jour pour NIP-40 et NIP-07. Les clients se sont multipliés : Damus a rempli sa bêta TestFlight en quelques heures, Astral a forké Branle pour la création de profils, Snort a lancé un client web « fast, censorship-resistant », et Vitor Pamplona a commencé le développement d’Amethyst. Alby v1.22.1 « Kemble’s Cascade of Stars » est sorti le 22 décembre avec le support de NIP-19. Au 7 décembre, Nostr comptait environ 800 utilisateurs avec un profil. Quand Damus est arrivé sur l’App Store le 31 janvier 2023, les vannes se sont ouvertes, poussant la croissance à plus de 315 000 utilisateurs en juin 2023.

Décembre 2023 : maturation de l’écosystème

Décembre 2023 a marqué un point d’inflexion critique pour la sécurité du protocole Nostr. Le 20 décembre, la révision 3 de NIP-44 a été fusionnée après un audit de sécurité indépendant de Cure53 (NOS-01) qui avait identifié 10 problèmes dans les implémentations TypeScript, Go et Rust, dont des attaques temporelles et des inquiétudes autour de la forward secrecy. La spécification mise à jour a remplacé le chiffrement défaillant de NIP-04 par ChaCha20 et HMAC-SHA256, posant la base cryptographique qui soutient désormais les DMs privés de NIP-17 et le gift wrapping de NIP-59. La même semaine, OpenSats a annoncé sa quatrième vague de grants le 21 décembre, finançant sept projets dont Lume, noStrudel, ZapThreads et un audit indépendant de NIP-44. Cela faisait suite à la première vague de juillet 2023, qui avait financé Damus, Coracle, Iris et d’autres, portant l’allocation totale du Nostr Fund à environ 3,4 millions de dollars sur 39 grants.

Le mois a aussi mis en lumière les tensions de soutenabilité dans l’écosystème. Le 28 décembre, William Casarin (jb55) a écrit sur Stacker News que 2024 serait « likely be the last year of Damus », expliquant que « nostr clients don’t make money » après que les restrictions d’Apple sur les zaps intégrés ont fortement limité le potentiel de revenus. L’équipe Damus avait auparavant rejeté un financement VC. Pendant ce temps, Nostr Wallet Connect v0.4.1 est sorti le 26 décembre, étendant NIP-47 avec les méthodes pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance et get_info, posant les bases des intégrations wallet qui deviendraient standard dans les clients.

Décembre 2024 : avancée du protocole

Décembre 2024 s’est ouvert avec le lancement alpha de Notedeck le 30 novembre, le client desktop Rust de l’équipe Damus, avec interface multi-colonnes et support de plusieurs comptes. Construit pour Linux, macOS et Windows, avec Android prévu pour 2025, Notedeck a d’abord été livré aux abonnés Damus Purple et représentait une expansion stratégique au-delà d’iOS. Deux semaines plus tard, OpenSats a annoncé sa neuvième vague de grants le 16 décembre, finançant AlgoRelay, le premier relay algorithmique pour les flux personnalisés, Pokey, une application Android avec maillage Bluetooth pour internet restreint, Nostr Safebox (stockage de jetons NIP-60 Cashu) et LumiLumi, un client web léger et accessible, portant l’allocation totale du Nostr Fund à environ 9 millions de dollars, soit une hausse de 67 % sur un an.

Le mois a vu une maturation importante des clients dans tout l’écosystème. Gossip 0.13.0 est arrivé le 23 décembre avec le support de File Metadata (NIP-92/NIP-94), l’intégration Blossom et la recherche de relays NIP-50. Coracle 0.5.0 est sorti le 12 décembre avec un onboarding retravaillé et l’intégration de nostr-editor. Le développement du protocole est resté actif avec 30 pull requests soumises entre le 9 et le 22 décembre, dont 10 fusionnées, y compris des réécritures de NIP-46 pour n’utiliser que le chiffrement NIP-44, ainsi que la poursuite des travaux sur NIP-104 pour un chiffrement à double cliquet de niveau Signal. Les statistiques réseau montraient plus de 224 000 événements quotidiens de trusted pubkeys, une multiplication par quatre d’une année sur l’autre des nouveaux profils avec listes de contacts, et une hausse de 50 % des événements d’écriture publique.

Décembre 2025 : expansion de l’écosystème

Décembre 2025 a apporté une maturation continue du protocole et une expansion de l’écosystème. Le 21 décembre, OpenSats a annoncé sa quatorzième vague de grants Nostr, finançant trois projets : YakiHonne, un client multi-plateforme avec portail créateur pour le contenu long format et intégration de paiements Cashu et Nutzaps, Quartz, la bibliothèque Kotlin Multiplatform de Vitor Pamplona qui alimente Amethyst et rendra possible une version iOS, et Nostr Feedz, l’intégration bidirectionnelle RSS-vers-Nostr de PlebOne. Des renouvellements de grants ont été attribués à Dart NDK et au nostr-relay de Mattn.

L’évolution du protocole a continué avec NIP-BE, la messagerie Bluetooth Low Energy, fusionné en novembre (#1979), ce qui permet la synchronisation hors ligne entre appareils. NIP-A4, Public Messages, kind 24, a suivi plus tard dans le mois (#1988), en définissant des messages destinés à l’écran de notification qui utilisent des tags q pour éviter les complications de threading. NIP-29 a reçu une clarification importante (#2106), introduisant le tag hidden pour des groupes réellement privés et intraçables. La spécification NIP-55 a elle aussi été affinée (#2166), pour corriger une erreur d’implémentation fréquente où des développeurs appelaient get_public_key depuis des processus en arrière-plan.

Côté client, Primal Android est devenu un signer NIP-55 complet grâce à huit PRs fusionnées implémentant LocalSignerContentProvider, rejoignant Amber et Aegis parmi les options de signature Android. La bibliothèque NDK a atteint des requêtes de cache 162x plus rapides, passant d’environ 3 690 ms à environ 22 ms, en éliminant les écritures en double et les recherches inutiles dans le cache LRU (PR #371, PR #372). Shopstr a introduit Zapsnags pour les ventes flash via zaps. White Noise a livré MIP-05, des notifications push préservant la vie privée. Voir Newsletter #1 et Newsletter #2 pour la couverture complète.

Il y a cinq ans, fiatjaf publiait Branle pour une poignée d’utilisateurs répartis sur deux relays expérimentaux. Aujourd’hui, le protocole alimente plus de 140 clients, plus de 2 500 relays dans 50 pays, et un web of trust en croissance reliant des centaines de milliers de paires de clés. Le schéma de grandes sorties en décembre s’est poursuivi ce mois-ci avec la messagerie Bluetooth, la multiplication des signers Android et des grants d’infrastructure signalant des investissements durables dans les outils cross-platform.

Actualités

Amethyst Desktop prend forme - Le grant Quartz de la quatorzième vague d’OpenSats produit déjà des résultats. PR #1625 crée un module :desktopApp complet pour Amethyst en utilisant Compose Multiplatform, avec écrans de connexion et de flux global déjà fonctionnels sur Desktop JVM. L’architecture convertit le module :commons en Kotlin Multiplatform avec une structure propre de source sets (commonMain, jvmAndroid, androidMain, jvmMain), ce qui permet de partager des composants UI entre Android et desktop tout en laissant les décisions spécifiques à chaque plateforme à leur cible respective. Cela pose les bases de la future version iOS via la même approche Kotlin Multiplatform.

Réponses vocales dans Amethyst - Cadeau de Noël signé davotoula : PR #1622 ajoute des écrans dédiés aux réponses vocales avec visualisation de forme d’onde, possibilité de réenregistrer, sélection du serveur média et indicateurs de progression d’upload. Les utilisateurs peuvent maintenant répondre en audio aux messages vocaux racine comme aux réponses vocales.

Notedeck ajoute la messagerie - Notedeck, le client desktop de Damus, a gagné une fonctionnalité de messages dans PR #1223, élargissant son périmètre au-delà de la navigation dans la timeline vers la communication directe.

Citrine héberge des applications web - Citrine peut maintenant héberger des applications web, transformant votre téléphone en serveur web Nostr local-first. Une autre PR #85 ajoute la reconnexion automatique et la diffusion d’événements quand la connectivité réseau revient, avec une couverture de tests complète à travers les niveaux d’API Android.

Registre d’outils développeur Nostrability - Le suivi Developer Kits & Tooling maintient un registre sélectionné de SDKs, bibliothèques et outils de développement à travers les langages, dont TypeScript, Rust, Python, Go, Dart et Swift. Si vous débutez dans le développement Nostr, c’est un bon point de départ pour trouver la boîte à outils adaptée à votre stack.

Mises à jour des NIP

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

NIP-54 - Correctif critique d’internationalisation pour la normalisation du d-tag wiki (#2177). Les règles précédentes convertissaient tous les caractères non ASCII en -, ce qui cassait la prise en charge du japonais, du chinois, de l’arabe, du cyrillique et d’autres écritures. La spécification mise à jour préserve les lettres UTF-8, n’applique les minuscules qu’aux caractères qui disposent d’une variante de casse, et inclut des exemples détaillés : "ウィキペディア" reste "ウィキペディア", "Москва" devient "москва", et des écritures mixtes comme "日本語 Article" se normalisent en "日本語-article".

Versions

Zapstore 1.0-rc1 - La boutique d’applications permissionless basée sur Nostr livre la première release candidate de sa nouvelle architecture, avec rafraîchissement complet de l’UI, gestionnaire de paquets réécrit avec une meilleure gestion des erreurs, App Stacks pour la découverte curatée, écrans de profil repensés, vérification des mises à jour en arrière-plan et défilement infini dans les listes de versions.

KeyChat v1.38.1 - L’application de messagerie chiffrée fondée sur MLS ajoute le support UnifiedPush pour les notifications push sur Android et Linux, ainsi qu’une authentification biométrique pour les opérations sensibles. Disponible sur Android, Windows, macOS et Linux.

Alby Go v2.0.0 - Le compagnon mobile du wallet Lightning livre une refonte visuelle avec nouveau logo, palette de couleurs mise à jour, carnet d’adresses repensé et clavier de saisie des montants amélioré. BTC Map est maintenant accessible depuis l’écran d’accueil, et les descriptions de transactions apparaissent dans les notifications.

nak v0.17.4 - L’outil Nostr en ligne de commande de fiatjaf est sorti, après le correctif de la restriction Linux LMDB dans v0.17.3 évoqué la semaine dernière.

Changements de code et de documentation à surveiller

Pull requests ouvertes et travaux encore précoces qui méritent d’être suivis.

Damus (iOS)

Indices de relais NIP-19 implémente la consommation d’indices de relais pour la récupération d’événements. Quand des utilisateurs ouvrent des liens nevent, nprofile ou naddr, Damus extrait désormais les indices de relais depuis les données TLV bech32 et se connecte à des relays éphémères pour récupérer du contenu absent du pool de relays de l’utilisateur. L’implémentation inclut un nettoyage avec comptage de références pour éviter les conditions de course lors de recherches simultanées. Détection d’URL d’image convertit automatiquement les URLs d’image collées en miniatures d’aperçu dans le compositeur, avec badge de position de carrousel pour plusieurs images. Conversion de collage npub transforme des chaînes npub ou nprofile collées en liens de mention avec résolution de profil asynchrone.

Amethyst (Android)

Cibles de paiement ajoute une interface d’événement pour les partages de zap NIP-57, permettant aux posts de spécifier plusieurs destinataires se partageant les zaps entrants, utile pour les collaborations, le partage de revenus ou les pourboires au créateur comme à ses outils. Documentation de parité fonctionnelle Quartz ajoute un tableau détaillé recensant les fonctionnalités implémentées sur Android, Desktop JVM et iOS, en signalant qu’iOS manque encore de cryptographie de base (Secp256k1Instance), de sérialisation JSON et de structures de données.

Notedeck (Desktop)

Reconstruction des filtres de timeline corrige un bug où des comptes non suivis continuaient d’apparaître dans les flux. Les filtres de timeline étaient construits une seule fois à partir de la liste de contacts et n’étaient jamais mis à jour. Le correctif ajoute un suivi contact_list_timestamp et une méthode invalidate() pour déclencher une reconstruction quand l’état de suivi change.

Citrine (relay Android)

API ContentProvider expose la base de données d’événements du relay local à d’autres applications Android via ContentResolver. Contrairement à l’interface WebSocket, qui oblige les applications à maintenir une connexion persistante et à parler le protocole de relay Nostr, ContentProvider offre un accès direct et synchrone à la base via le mécanisme IPC natif d’Android. Les applications externes peuvent interroger les événements par ID, pubkey, kind ou plage de dates, insérer de nouveaux événements avec validation et supprimer des événements sans gérer de connexions socket.

rust-nostr (bibliothèque)

Support NIP-40 au niveau relay ajoute la gestion de l’expiration au niveau du relay builder. Les événements expirés sont désormais rejetés avant stockage et filtrés avant envoi aux clients, ce qui évite à chaque implémentation de base de données d’avoir à gérer elle-même les vérifications d’expiration.

nak (CLI)

Miroir Blossom implémente une fonctionnalité de mirroring de blobs pour l’outil en ligne de commande.

Mostro (trading P2P)

Événements d’audit des frais de développement ajoute des pistes d’audit transparentes pour les paiements au fonds de développement via des événements Nostr de kind 8383. L’implémentation publie des événements d’audit non bloquants après les paiements de frais réussis, avec détails de commande et hash de paiement, tout en excluant les pubkeys acheteur et vendeur pour préserver la vie privée.

MDK (Marmot Development Kit)

Trois correctifs issus d’audit de sécurité ont été fusionnés : Vérification d’auteur impose que les pubkeys des rumors correspondent aux identifiants d’expéditeur MLS afin d’empêcher l’usurpation. Liaison d’identité KeyPackage vérifie que l’identité du credential correspond au signataire de l’événement. Validation des mises à jour admin empêche les ensembles d’admins vides et l’assignation d’admins non membres.

Shopstr (marketplace)

Escrow sur facture HODL implémente un système de paiement minimisant la confiance pour les biens physiques. L’architecture utilise makeHoldInvoice d’Alby pour verrouiller les fonds de l’acheteur dans son propre wallet, avec règlement déclenché seulement après vérification de l’inventaire par le marchand. Le protocole d’échange passe par des DMs chiffrés NIP-17 : l’acheteur envoie une demande de commande, le marchand répond avec une facture HODL, l’acheteur paie, les fonds sont verrouillés, le marchand confirme le stock et l’expédition, puis le règlement libère les fonds. Le support des paniers multi-marchands répartit les paiements entre vendeurs.

Jumble (client web)

Mode de découverte par relay ajoute un interrupteur pour masquer, sur certains relays, les posts d’utilisateurs suivis, ce qui permet des flux de découverte par langue, par exemple nostr.band/lang/*. La fonctionnalité filtre les posts dont la pubkey d’auteur apparaît dans la liste de suivis de l’utilisateur, en persistant l’état de l’option par URL de relay dans localStorage.

White Noise (messagerie chiffrée)

Réessai d’upload média ajoute des options de réessai pour les uploads échoués. Avertissements sur l’édition de profil alertent les utilisateurs à propos des changements de profil. Côté backend, whitenoise-rs corrige une condition de course lors de la création d’AccountGroup.

npub.cash (service d’adresses Lightning)

Réécriture v3 migre le monorepo et le serveur vers Bun, ajoute le support SQLite, abandonne la compatibilité v1, implémente LUD-21 et ajoute des mises à jour temps réel des quotes de mint.

nostr-java (bibliothèque)

v1.1.1 livre des refactorings de gestion WebSocket et une robustesse de tests améliorée à travers deux PRs.

Dépôt NIPs

Migration Djot pour NIP-54 propose un changement séparé pour la spécification wiki : passer le format de contenu d’Asciidoc à Djot, un langage de balisage léger à la syntaxe plus propre. La PR introduit des liens en style référence pour les wikilinks, ce qui rend les renvois entre articles wiki plus lisibles dans le source. NIP-XX Quorum introduit une gouvernance multi-signature à seuil pour les groupes Nostr en s’appuyant sur FROST, Flexible Round-Optimized Schnorr Threshold signatures. Un Quorum est un nsec partagé entre ses membres dans un schéma T-sur-N où les membres peuvent se représenter eux-mêmes ou déléguer à un conseil de représentants. Quand le conseil change, l’ancien nsec devient obsolète et un nouveau est distribué, l’acte final de tout conseil étant la signature de l’événement de transition de gouvernance. La spécification définit l’adhésion, publique ou privée, les élections et votes, y compris les motions de défiance, des « lois » éventuelles en langage naturel, et surtout des ontologies de quorum où des quorums peuvent être membres d’autres quorums, ce qui permet des structures hiérarchiques comme des localités rejoignant des entités régionales. Les cas d’usage vont du développement logiciel aux conseils d’administration, associations de copropriété et communautés modérées.

C’est tout pour cette semaine et pour cette année. Vous construisez quelque chose ? Vous avez des nouvelles à partager ? Vous voulez que nous couvrions votre projet ? Contactez-nous via DM NIP-17 ou retrouvez-nous sur Nostr.

Nostr Compass #2

Wed, 24 Dec 2025 00:00:00 +0000

Bon retour sur Nostr Compass, votre guide hebdomadaire de l’écosystème du protocole Nostr.

Cette semaine : Trois implémentations de signers NIP-55 reçoivent des mises à jour : Amber ajoute la mise en cache des performances, Aegis gagne le support des URI nostrsigner:, et Primal Android les rejoint en tant que signer local complet. Shopstr introduit les « Zapsnags » pour les ventes flash via zaps. Mostro ajoute un fonds de développement. Quatre mises à jour NIP sont déployées, incluant les Messages Publics (kind 24) et des améliorations de confidentialité des groupes. Les requêtes de cache NDK accélèrent de 162x, Applesauce ajoute les réactions et le support de portefeuille NIP-60, et Tenex introduit l’architecture RAL pour la délégation d’agents IA. Dans notre analyse approfondie, nous expliquons NIP-02 (listes d’abonnements) et NIP-10 (threading des réponses), des spécifications fondamentales pour construire des timelines sociales et des conversations.

Actualités

Primal Android devient un signer NIP-55 - S’appuyant sur le support Nostr Connect de la semaine dernière, Primal a implémenté des capacités complètes de signature locale à travers huit pull requests fusionnées. L’implémentation inclut un LocalSignerContentProvider complet qui expose les opérations de signature aux autres applications Android via l’interface content provider d’Android, suivant la spécification NIP-55. L’architecture sépare proprement les responsabilités : SignerActivity gère les flux d’approbation côté utilisateur, LocalSignerService gère les opérations en arrière-plan, et un nouveau système de permissions permet aux utilisateurs de contrôler quelles applications peuvent demander des signatures. Cela fait de Primal une alternative viable à Amber pour les utilisateurs Android qui veulent garder leurs clés dans une seule application tout en utilisant d’autres pour différentes expériences Nostr.

Shopstr Zapsnags : Ventes flash via Lightning - La place de marché native Nostr a introduit les « Zapsnags », une fonctionnalité de vente flash qui permet aux acheteurs d’acheter des articles directement depuis leur flux social avec un seul zap. L’implémentation filtre les notes kind 1 taguées avec #shopstr-zapsnag et les affiche comme des cartes produit avec un bouton « Zap to Buy » au lieu du flux panier standard. Quand un acheteur zappe, le système génère une demande de paiement utilisant NIP-57, interroge le reçu de zap kind 9735 pour confirmer le paiement, puis chiffre les informations de livraison en utilisant l’emballage cadeau NIP-17 avant de les envoyer en privé au vendeur. La fonctionnalité stocke les détails de l’acheteur localement pour les achats répétés et inclut un tableau de bord marchand pour créer des annonces de vente flash. C’est une combinaison astucieuse de primitives sociales, de paiement et de confidentialité qui démontre comment la conception composable de Nostr permet des modèles de commerce innovants.

Mostro introduit un fonds de développement - La plateforme de trading Bitcoin P2P NIP-69 a implémenté des frais de développement configurables pour soutenir une maintenance durable. Les opérateurs peuvent définir dev_fee_percentage entre 10-100% des frais de trading Mostro (par défaut 30%), qui achemine automatiquement vers un fonds de développement à chaque trade réussi. L’implémentation ajoute trois colonnes de base de données (dev_fee, dev_fee_paid, dev_fee_payment_hash) pour suivre les contributions et valide le pourcentage au démarrage du daemon. La documentation technique dans docs/DEV_FEE.md explique le système. Ce modèle opt-in permet aux opérateurs de soutenir le développement continu tout en maintenant une transparence totale sur l’allocation des frais.

Mises à jour NIP

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

Nouveaux NIPs :

NIP-A4 (Messages Publics, kind 24) - Un nouveau kind pour les messages d’écran de notification conçu pour un support client large (#1988). Contrairement aux conversations threadées, ces messages n’ont pas de concept d’historique de chat ou de chaînes de messages. Ils utilisent des tags q (citations) plutôt que des tags e pour éviter les complications de threading, les rendant idéaux pour des notifications publiques simples qui apparaissent dans le flux de notifications d’un destinataire sans créer d’état de conversation.

Changements significatifs :

NIP-29 - Clarification majeure de la sémantique des groupes (#2106). Le tag closed signifie maintenant « incapable d’écrire » (lecture seule pour les non-membres), découplé des mécaniques d’adhésion. Un nouveau tag hidden empêche les relais de servir les métadonnées ou événements de membres aux non-membres, permettant des groupes véritablement privés qui sont indécouverts sans invitation hors bande. Le tag private contrôle la visibilité des messages tout en permettant des métadonnées publiques pour la découverte.
NIP-51 - Ajout du kind 30006 pour les ensembles d’images curées (#2170), suivant le modèle de 30004 (articles) et 30005 (vidéos). Déjà implémenté dans Nostria.
NIP-55 - Clarification de l’initiation de connexion pour les signers Android (#2166). Les développeurs implémentant des sessions multi-utilisateurs utilisaient incorrectement get_public_key en l’appelant depuis des processus en arrière-plan. La spécification mise à jour recommande de l’appeler seulement une fois lors de la connexion initiale, prévenant une erreur d’implémentation courante.

Analyse approfondie NIP : NIP-02 et NIP-10

Cette semaine, nous couvrons deux NIPs essentiels pour les fonctionnalités sociales : comment les clients savent qui vous suivez et comment les conversations sont threadées.

NIP-02 : Liste d’abonnements

NIP-02 définit les événements kind 3, qui stockent votre liste d’abonnements. Ce mécanisme simple alimente le graphe social qui rend les timelines possibles.

Structure : Un événement kind 3 contient des tags p listant les clés publiques suivies :

{
 "id": "d7a8f...",
 "pubkey": "a3b9c...",
 "created_at": 1734912000,
 "kind": 3,
 "tags": [
 ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
 ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
 ["p", "612ae..982b", "", ""]
 ],
 "content": "",
 "sig": "e4f8a..."
}

Chaque tag p a quatre positions : le nom du tag, la clé publique suivie (hex), une indication de relais URL optionnelle, et un « petname » optionnel (un surnom local). L’indication de relais dit aux autres clients où trouver les événements de cet utilisateur. Le petname vous permet d’assigner des noms mémorables aux contacts sans vous fier à leurs noms d’affichage auto-déclarés.

Comportement remplaçable : Le Kind 3 tombe dans la plage remplaçable (0, 3, 10000-19999), donc les relais ne gardent que la dernière version par clé publique. Quand vous suivez quelqu’un de nouveau, votre client publie un nouveau kind 3 complet contenant tous vos abonnements plus le nouveau. Cela signifie que les listes d’abonnements doivent être complètes à chaque fois ; vous ne pouvez pas publier de mises à jour incrémentales.

Construction des timelines : Pour construire un flux d’accueil, les clients récupèrent le kind 3 de l’utilisateur, extraient toutes les clés publiques des tags p, puis s’abonnent aux événements kind 1 de ces auteurs :

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

Le relais renvoie les notes correspondantes, et le client les affiche. Les indications de relais dans le kind 3 aident les clients à savoir quels relais interroger pour chaque utilisateur suivi.

Petnames et identité : Le champ petname permet un schéma de nommage décentralisé. Plutôt que de faire confiance au nom qu’un utilisateur revendique dans son profil, vous pouvez assigner votre propre étiquette. Un client pourrait afficher « alice (Ma Sœur) » où « alice » vient de son profil kind 0 et « Ma Sœur » est votre petname. Cela fournit un contexte que les noms d’utilisateur globaux ne peuvent pas offrir.

Considérations pratiques : Parce que les événements kind 3 sont remplaçables et doivent être complets, les clients devraient préserver les tags inconnus lors de la mise à jour. Si un autre client a ajouté des tags que votre client ne comprend pas, écraser aveuglément perdrait ces données. Ajoutez les nouveaux abonnements plutôt que de reconstruire à partir de zéro.

NIP-10 : Threading des notes textuelles

NIP-10 spécifie comment les notes kind 1 se référencent mutuellement pour former des fils de réponses. Comprendre ceci est essentiel pour construire des vues de conversation.

Le problème : Quand quelqu’un répond à une note, les clients doivent savoir : À quoi est-ce une réponse ? Quelle est la racine de la conversation ? Qui devrait être notifié ? NIP-10 répond à ces questions à travers les tags e (références d’événements) et les tags p (mentions de clés publiques).

Tags marqués (préféré) : Les clients modernes utilisent des marqueurs explicites dans les tags e :

{
 "id": "f9c2e...",
 "pubkey": "a3b9c...",
 "created_at": 1734912345,
 "kind": 1,
 "tags": [
 ["e", "abc123...", "wss://relay.example.com", "root"],
 ["e", "def456...", "wss://relay.example.com", "reply"],
 ["p", "91cf9..."],
 ["p", "14aeb..."]
 ],
 "content": "Excellent point ! Je suis d'accord.",
 "sig": "b7d3f..."
}

Le marqueur root pointe vers la note originale qui a commencé le fil. Le marqueur reply pointe vers la note spécifique à laquelle on répond. Si vous répondez directement à la racine, utilisez seulement root (pas besoin de tag reply). La distinction compte pour l’affichage : le reply détermine l’indentation dans une vue de fil, tandis que root regroupe toutes les réponses ensemble.

Règles de threading :

Réponse directe à la racine : Un tag e avec marqueur root
Réponse à une réponse : Deux tags e, un root et un reply
Le root reste constant tout au long du fil ; reply change selon ce à quoi vous répondez

Tags pubkey pour les notifications : Incluez des tags p pour tous ceux qui devraient être notifiés. Au minimum, taguez l’auteur de la note à laquelle vous répondez. La convention est aussi d’inclure tous les tags p de l’événement parent (pour que tout le monde dans la conversation reste dans la boucle), plus tous les utilisateurs que vous @mentionnez dans votre contenu.

Indications de relais : La troisième position dans les tags e et p peut contenir une URL de relais où cet événement ou le contenu de cet utilisateur pourrait être trouvé. Cela aide les clients à récupérer le contenu référencé même s’ils ne sont pas connectés au relais original.

Tags positionnels dépréciés : Les premières implémentations Nostr déduisaient le sens de la position des tags plutôt que des marqueurs : le premier tag e était la racine, le dernier était la réponse, ceux du milieu étaient des mentions. Cette approche est dépréciée car elle crée de l’ambiguïté. Si vous voyez des tags e sans marqueurs, ils proviennent probablement de clients plus anciens. Les implémentations modernes devraient toujours utiliser des marqueurs explicites.

Construction des vues de fil : Pour afficher un fil, récupérez l’événement racine, puis interrogez tous les événements avec un tag e référençant cette racine :

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

Triez les résultats par created_at et utilisez les marqueurs reply pour construire la structure d’arbre. Les événements dont le reply pointe vers la racine sont des réponses de premier niveau ; les événements dont le reply pointe vers une autre réponse sont des réponses imbriquées.

Sorties

Zeus v0.12.0 - S’appuyant sur le support de paiements parallèles NWC de la semaine dernière, la version majeure du portefeuille Lightning livre un service Nostr Wallet Connect NIP-47 complet avec support de relais personnalisé et suivi de budget. Une correction de rechargement de budget assure que les connexions utilisent les limites actuelles. La copie d’adresse Lightning n’inclut plus le préfixe lightning:, corrigeant les problèmes de collage dans les champs de profil Nostr.

Amber v4.0.6 - Le signer Android NIP-55 ajoute la mise en cache des performances aux opérations de signature et améliore la gestion des erreurs lors du déchiffrement de contenu malformé. La fiabilité de connexion améliorée avec une logique de réessai pour les événements de connexion relais, et plusieurs corrections de crash adressent les cas limites autour des URI nostrconnect:// invalides et des interactions de l’écran de permissions.

nak v0.17.3 - La dernière version de l’outil Nostr en ligne de commande restreint les builds LMDB à Linux, corrigeant les problèmes de compilation cross-platform.

Aegis v0.3.4 - Le signer Nostr cross-platform ajoute le support du schéma URI nostrsigner: défini dans NIP-55, correspondant au flux de connexion d’Amber. Les données de relais local peuvent maintenant être importées et exportées pour la sauvegarde, et la version inclut des corrections de bugs pour les erreurs de socket relais et des améliorations UI pour l’interface du relais local.

Changements notables de code et documentation

Ce sont des pull requests ouvertes et du travail en phase précoce, parfaits pour obtenir des retours avant fusion. Si quelque chose attire votre attention, considérez la review ou les commentaires !

Damus (iOS)

Persistance de la liste de mutes corrige un problème où les listes de mutes étaient effacées au démarrage à froid. La correction ajoute des gardes pour prévenir les écrasements accidentels pendant l’initialisation de l’application. Timing du flux de profil élimine un délai d’environ 1 seconde avant que les profils en cache n’apparaissent. Précédemment, les vues attendaient le redémarrage des tâches d’abonnement ; maintenant streamProfile() renvoie immédiatement les données en cache de NostrDB, supprimant la fenêtre où les clés publiques abrégées et les images placeholder s’affichaient.

White Noise (Messagerie chiffrée)

Streaming de messages en temps réel remplace le mécanisme de polling précédent par une architecture basée sur les streams. Le nouveau ChatStreamNotifier consomme directement le stream de messages du SDK Rust, maintenant l’ordre chronologique et gérant les mises à jour incrémentales efficacement. Les tests ont montré une amélioration significative de la réactivité. Une API de liste de chats ajoute get_chat_list pour récupérer les résumés de conversation, et une correction de tri stable prévient les boucles de réordonnancement de messages en utilisant createdAt avec l’ID de message comme critère de départage.

NDK (Bibliothèque)

Deux pull requests ont livré des améliorations dramatiques de performance du cache. PR #371 a corrigé un bug où les événements lus depuis le cache SQLite étaient immédiatement réécrits, causant 100% d’écritures dupliquées au démarrage de l’application. La correction ajoute une garde fromCache et implémente une vérification de doublons O(1) via un Set en mémoire. Pour les petits ensembles de résultats (<100 événements), le transfert JSON direct remplace le surcoût d’encodage binaire. PR #372 a supprimé les appels seenEvent inutiles pour les événements en cache. La recherche dans le cache LRU coûtait 0.24-0.64ms par événement ; pour 5 700 événements en cache, cela ajoutait environ 1.4 secondes de surcoût. Résultat : les requêtes de cache sont passées d’environ 3 690ms à environ 22ms (162x plus rapide).

rust-nostr (Bibliothèque)

Support REQ multi-filtres a été restauré après avoir été supprimé dans un refactoring précédent. Le SDK accepte à nouveau Vec<Filter> pour les requêtes d’abonnement, permettant des requêtes efficaces qui combinent plusieurs conditions de filtre avec la logique OR. La provenance du relais a été ajoutée aux méthodes stream_events*, donc chaque événement streamé inclut maintenant le RelayUrl dont il provient et un Result indiquant le succès ou l’échec, utile pour suivre la fiabilité des relais et déboguer les problèmes de connexion. Une correction de sécurité a supprimé la dépendance url-fork suite à RUSTSEC-2024-0421, éliminant une vulnérabilité connue.

Applesauce (Bibliothèque)

La bibliothèque TypeScript alimentant noStrudel a connu un développement significatif cette semaine. Les nouveaux modèles incluent un système de réactions et le casting de groupes d’utilisateurs. Les fonctionnalités de portefeuille se sont étendues avec le support NIP-60, un onglet d’envoi et des outils de récupération de tokens améliorés. Une nouvelle propriété user.directMessageRelays$ expose la configuration des relais DM. Toutes les actions ont été refactorisées pour utiliser des interfaces async (supprimant les générateurs async), et des corrections de bugs ont adressé la restauration de contenu chiffré et les cas limites des filtres d’événements basés sur le temps.

Tenex (Agents IA)

Le système de coordination multi-agents construit sur Nostr a introduit l’architecture RAL (Request-Action-Lifecycle) dans cinq PRs fusionnés. RAL permet aux agents de se mettre en pause lors de la délégation de tâches et de reprendre quand les résultats arrivent, avec une persistance d’état limitée à la conversation. Les outils de délégation (delegate, ask, delegate_followup, delegate_external) publient maintenant des événements Nostr et retournent des signaux d’arrêt au lieu de bloquer. Le refactoring inclut la migration AI SDK v6, l’infrastructure de test VCR pour l’enregistrement déterministe des interactions LLM, et le support d’images multimodal.

Nostr Compass #1

Mon, 15 Dec 2025 00:00:00 +0000

Bienvenue dans Nostr Compass, une newsletter hebdomadaire dédiée à l’écosystème du protocole Nostr. Notre mission est de tenir les développeurs, opérateurs de relais et constructeurs informés des développements importants à travers le réseau. Nous documentons l’évolution du protocole avec précision technique, neutralité et profondeur, couvrant tout, des propositions NIP aux sorties de clients en passant par les meilleures pratiques d’implémentation.

Nostr Compass s’inspire de Bitcoin Optech, dont les années de travail dévoué à l’avancement des connaissances techniques de Bitcoin ont établi la norme pour les newsletters axées sur les protocoles. Nous sommes reconnaissants pour leur exemple et espérons apporter la même rigueur à l’écosystème Nostr.

Ce numéro inaugural établit notre format hebdomadaire. Chaque mercredi, nous vous apporterons des mises à jour NIP, des notes de version, des points forts du développement et des conseils techniques. Que vous construisiez un client, gériez un relais ou contribuiez au protocole, Nostr Compass vise à être votre source fiable pour ce qui se passe dans l’écosystème.

Qu’est-ce que Nostr ?

Comme c’est notre premier numéro, nous commençons par une introduction au fonctionnement de Nostr. Les lecteurs réguliers peuvent passer directement aux actualités.

Nostr (Notes and Other Stuff Transmitted by Relays) est un protocole décentralisé pour les réseaux sociaux et la messagerie. Contrairement aux plateformes traditionnelles, Nostr n’a pas de serveur central, pas d’entreprise qui le contrôle et pas de point unique de défaillance. Les utilisateurs possèdent leur identité grâce à des paires de clés cryptographiques, et le contenu circule via des serveurs relais indépendants que n’importe qui peut exploiter.

Comment ça fonctionne : Les utilisateurs génèrent une paire de clés (une clé privée appelée nsec et une clé publique appelée npub). La clé privée signe les messages appelés « événements », et la clé publique sert d’identité. Les événements sont envoyés aux relais, qui les stockent et les transmettent aux autres utilisateurs. Comme vous contrôlez vos clés, vous pouvez passer d’un client ou d’un relais à l’autre sans perdre votre identité ou vos abonnés.

Pourquoi c’est important : Nostr offre une résistance à la censure grâce à la diversité des relais (si un relais vous bannit, d’autres peuvent toujours servir votre contenu), la portabilité (votre identité fonctionne sur n’importe quelle application Nostr) et l’interopérabilité (tous les clients Nostr parlent le même protocole). Il n’y a pas d’algorithme décidant ce que vous voyez, pas de publicités et pas de collecte de données.

L’écosystème aujourd’hui : Nostr prend en charge le microblogging (comme Twitter/X), le contenu long format (comme Medium), les messages directs, les places de marché, le streaming en direct, et plus encore. Les clients incluent Damus (iOS), Amethyst (Android), Primal, Coracle et des dizaines d’autres. L’intégration du Lightning Network permet des paiements instantanés via les « zaps ». Le protocole continue d’évoluer grâce aux NIPs (Nostr Implementation Possibilities), des spécifications pilotées par la communauté qui étendent les fonctionnalités.

Actualités

NIP-BE fusionné : Support Bluetooth Low Energy - Une nouvelle capacité significative a été intégrée au protocole. NIP-BE spécifie comment les applications Nostr peuvent communiquer et se synchroniser via Bluetooth Low Energy. Cela permet aux applications capables de fonctionner hors ligne de synchroniser les données entre appareils à proximité sans connectivité Internet. La spécification adapte les modèles de relais WebSocket aux contraintes du BLE, utilisant la compression DEFLATE et la messagerie fragmentée pour gérer les petites tailles MTU du BLE (20-256 octets). Les appareils négocient les rôles en fonction de la comparaison UUID, l’UUID le plus élevé devenant le serveur GATT.

MIP-05 : Notifications push préservant la vie privée - Le Protocole Marmot a publié MIP-05 (spécification), une spécification pour les notifications push qui maintiennent la confidentialité. Les systèmes push traditionnels exigent que les serveurs connaissent les jetons d’appareil et les identités des utilisateurs ; MIP-05 résout ce problème en chiffrant les jetons d’appareil avec ECDH+HKDF et ChaCha20-Poly1305, utilisant des clés éphémères pour empêcher la corrélation. Un protocole de propagation à trois événements (kinds 447-449) synchronise les jetons chiffrés entre les membres du groupe, et les notifications utilisent l’emballage cadeau NIP-59 avec des jetons leurres pour masquer la taille des groupes. Cela permet à WhiteNoise et autres clients Marmot de délivrer des notifications en temps opportun sans compromettre la vie privée des utilisateurs.

Blossom BUD-10 : Nouveau schéma URI - Le protocole média Blossom obtient un schéma URI personnalisé via BUD-10 (spécification). Le nouveau format blossom:<sha256>.ext intègre le hash du fichier, l’extension, la taille, plusieurs indications de serveur et les clés publiques des auteurs pour la découverte de serveur BUD-03. Cela rend les liens blob plus résilients que les URL HTTP statiques en permettant le basculement automatique entre serveurs.

Mises à jour de la place de marché Shopstr - La place de marché native Nostr a implémenté Nostr Wallet Connect (NIP-47) pour les paiements, ajouté l’expiration des annonces utilisant NIP-40, et introduit les codes de réduction pour les vendeurs.

Mises à jour NIP

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

Nouveaux NIPs :

NIP-BE - Messagerie Bluetooth Low Energy et synchronisation d’appareils (#1979)
NIP-63 - Standard Paywall/Contenu Premium pour la gestion du contenu à accès restreint dans le protocole (#2156)

Changements significatifs :

NIP-24 - Ajout d’un tableau optionnel languages aux métadonnées utilisateur Kind 0, permettant aux utilisateurs de spécifier plusieurs langues préférées en utilisant les tags IETF BCP 47 pour une meilleure découverte de contenu et correspondance de relais (#2159)
NIP-69 - Ajout du support d’expiration des ordres pour le trading P2P avec les tags expires_at et expiration (#2118)
NIP-59 - Les événements Gift wrap peuvent maintenant être supprimés via les requêtes NIP-09/NIP-62 (#2131)
NIP-51 - Suppression des tags hashtag et URL des signets génériques ; les hashtags utilisent maintenant le kind 30015 (#2133)
NIP-18 - Amélioration des reposts génériques pour les événements remplaçables avec support du tag a (#2132)
NIP-17 - Formulation affinée et ajout du support de réaction kind 7 aux DMs (#2098)
NIP-11 - Ajout du champ self pour l’identification de la clé publique du relais (#1764)

Analyse approfondie NIP : NIP-01 et NIP-19

Pour ce numéro inaugural, nous couvrons deux NIPs fondamentaux que chaque développeur Nostr devrait comprendre. Consultez nos pages thématiques pour NIP-01 et NIP-19.

NIP-01 : Protocole de base

NIP-01 définit le protocole de base. Tout dans Nostr se construit sur cette spécification.

Les événements sont le seul type d’objet. Chaque événement contient :

id : Hash SHA256 de l’événement sérialisé (l’identifiant unique de l’événement)
pubkey : La clé publique du créateur (hex 32 octets, secp256k1)
created_at : Horodatage Unix
kind : Entier catégorisant le type d’événement
tags : Tableau de tableaux pour les métadonnées
content : La charge utile (l’interprétation dépend du kind)
sig : Signature Schnorr prouvant que la clé publique a créé cet événement

Les kinds déterminent comment les relais stockent les événements :

Événements réguliers (1, 2, 4-44, 1000-9999) : Stockés normalement, toutes les versions conservées
Événements remplaçables (0, 3, 10000-19999) : Seul le dernier par clé publique est conservé
Événements éphémères (20000-29999) : Non stockés, juste transmis aux abonnés
Événements adressables (30000-39999) : Dernier par combinaison clé publique + kind + tag d

Le Kind 0 représente les métadonnées utilisateur (profil), le kind 1 est une note textuelle (le post de base), le kind 3 est la liste d’abonnements.

Kind 1 : Notes textuelles sont le cœur du Nostr social. Un événement kind 1 est un post court, similaire à un tweet. Le champ content contient le texte du message (texte brut, bien que les clients rendent souvent le markdown). Les tags permettent les réponses, mentions et références :

{
 "id": "<32-byte-hex>",
 "pubkey": "<32-byte-hex>",
 "created_at": 1734480000,
 "kind": 1,
 "content": "Bonjour Nostr ! Découvrez le travail de @jb55 sur Damus.",
 "tags": [
 ["e", "<replied-to-event-id>", "wss://relay.example.com", "reply"],
 ["p", "<jb55-pubkey>"]
 ],
 "sig": "<64-byte-hex>"
}

Le tag e avec le marqueur “reply” indique qu’il s’agit d’une réponse (voir NIP-10 pour les conventions de threading). Le tag p mentionne un utilisateur, permettant aux clients de le notifier et d’afficher son nom au lieu de la clé publique brute. Les clients récupèrent l’événement kind 0 de l’utilisateur mentionné pour obtenir son nom d’affichage et son image.

Pour construire une timeline, un client s’abonne aux événements kind 1 des clés publiques suivies : ["REQ", "feed", {"kinds": [1], "authors": ["<pubkey1>", "<pubkey2>", ...], "limit": 50}]. Le relais renvoie les notes correspondantes, et le client les affiche chronologiquement.

Les événements adressables (30000-39999) fonctionnent comme les événements remplaçables mais utilisent un tag d comme identifiant supplémentaire. Le relais ne conserve que la dernière version de chaque combinaison clé publique + kind + tag d. Cela permet des articles modifiables, des fiches produits, ou tout cas où vous avez besoin de plusieurs éléments remplaçables par utilisateur.

Les tags sont des tableaux où le premier élément est le nom du tag. Les tags standards à une seule lettre (e, p, a, d, t) sont indexés par les relais pour une interrogation efficace. Par exemple, ["e", "<event-id>"] référence un autre événement, ["p", "<pubkey>"] référence un utilisateur.

La communication Client-Relais utilise des connexions WebSocket avec des tableaux JSON comme messages. Le premier élément identifie le type de message.

Du client au relais :

["EVENT", <event>] - Publier un événement sur le relais
["REQ", <sub-id>, <filter>, ...] - S’abonner aux événements correspondant au(x) filtre(s)
["CLOSE", <sub-id>] - Terminer un abonnement

Du relais au client :

["EVENT", <sub-id>, <event>] - Livre un événement correspondant à votre abonnement
["EOSE", <sub-id>] - « Fin des événements stockés » - le relais a envoyé toutes les correspondances historiques et n’enverra maintenant que les nouveaux événements à leur arrivée
["OK", <event-id>, <true|false>, <message>] - Accuse réception de l’acceptation ou du rejet d’un événement (et pourquoi)
["NOTICE", <message>] - Message lisible par l’humain du relais

Le flux d’abonnement : le client envoie REQ avec un ID d’abonnement et un filtre, le relais répond avec des messages EVENT correspondants, puis envoie EOSE pour signaler qu’il a rattrapé l’historique. Après EOSE, tout nouveau message EVENT est en temps réel. Le client envoie CLOSE quand il a terminé.

Les filtres spécifient quels événements récupérer. Un objet filtre peut inclure : ids (IDs d’événements), authors (clés publiques), kinds (types d’événements), #e/#p/#t (valeurs de tags), since/until (horodatages), et limit (résultats max). Toutes les conditions dans un filtre utilisent la logique AND. Vous pouvez inclure plusieurs filtres dans un REQ, et ils se combinent avec la logique OR - utile pour récupérer différents types d’événements en un seul abonnement.

NIP-19 : Identifiants encodés en Bech32

NIP-19 définit les formats conviviaux que vous voyez partout dans Nostr : npub, nsec, note, et plus encore. Ceux-ci ne sont pas utilisés dans le protocole lui-même (qui utilise l’hex), mais ils sont essentiels pour le partage et l’affichage.

Pourquoi bech32 ? Les clés hex brutes sont sujettes aux erreurs de copie et difficiles à distinguer visuellement. L’encodage Bech32 ajoute un préfixe lisible par l’humain et une somme de contrôle. Vous pouvez immédiatement distinguer un npub (clé publique) d’un nsec (clé privée) ou note (ID d’événement).

Formats de base encodent des valeurs brutes de 32 octets :

npub - Clé publique (votre identité, peut être partagée)
nsec - Clé privée (gardez-la secrète, utilisée pour signer)
note - ID d’événement (référence un événement spécifique)

Exemple : La clé publique hex 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d devient npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.

Identifiants partageables incluent des métadonnées utilisant l’encodage TLV (Type-Length-Value) :

nprofile - Profil avec indications de relais (aide les clients à trouver l’utilisateur)
nevent - Événement avec indications de relais, clé publique de l’auteur et kind
naddr - Référence d’événement adressable (clé publique + kind + tag d + relais)

Ceux-ci résolvent un problème clé : si quelqu’un partage un ID de note, comment savez-vous quel relais l’a ? Un nevent regroupe l’ID de l’événement avec les relais suggérés, rendant le partage plus fiable.

Important : N’utilisez jamais les formats bech32 dans le protocole lui-même. Les événements, messages de relais et réponses NIP-05 doivent utiliser l’hex. Bech32 est purement pour les interfaces humaines : affichage, copier/coller, codes QR et URLs.

Sorties

Amber v4.0.4 - L’application de signature Android corrige une NullPointerException, améliore les performances sur l’écran d’activité et ajoute des traductions pour certains types d’événements. La version précédente v4.0.3 avait ajouté une interface de chiffrement/déchiffrement remaniée, l’export/import de comptes, la gestion de relais par compte, le support ping bunker et les rapports de crash. Version

Coracle 0.6.28 - Version de correction de bugs pour le client web. Correction des flux de topics, de la gestion des images quand imgproxy est désactivé, et de la création de liens pour les sources de surlignage non-lien. Version

Flotilla v1.6.2 - Le client de communautés de style Discord corrige le défilement des modales et les problèmes de style. Les versions précédentes de ce cycle avaient ajouté des badges et sons optionnels pour les notifications, un rendu de liens amélioré, le scan de codes QR pour les liens d’invitation et une configuration de portefeuille simplifiée. Version

nak v0.17.2 - L’outil Nostr en ligne de commande a ajouté une nouvelle commande nip pour la consultation rapide des références NIP, plus des corrections pour la gestion des dépôts git et le traitement des événements stdin. Version

White Noise v0.2.1 - Version majeure pour l’application de messagerie chiffrée basée sur MLS ajoutant le partage d’images via Blossom, la synchronisation en arrière-plan, les notifications push, la localisation en 8 langues et la gestion des membres de groupe. Version

Amethyst v1.04.2 - Version fonctionnelle introduisant les listes/packs de suivi, de nouveaux filtres de timeline, une galerie d’images et la compression vidéo H.265 (fichiers 50% plus petits). Migration Kotlin Multiplatform terminée. Version

Mostro v0.15.5 - Mise à jour de la plateforme de trading P2P avec support d’expiration des ordres NIP-69 et réponses améliorées de l’historique des trades. Version

Nosflare v8.9.26 - Relais Nostr serverless construit sur l’infrastructure Cloudflare. Cette version apporte un correctif critique adressant un bug qui pouvait causer des échecs de websocket, assurant des connexions plus stables pour les utilisateurs et applications qui dépendent du relais. Version

Noscall v0.4.1 - Application d’appels audio et vidéo sécurisés basée sur Nostr. Cette version améliore l’interface popup sur la page Me et corrige plusieurs problèmes connus, résultant en une meilleure stabilité et fiabilité des appels. Version

Gitplaza v0.25.0 - Client Nostr de bureau axé sur l’activité liée à Git. Cette version introduit un filtre de kind avancé pour le flux inbox, inclut les zaps réguliers dans les filtres et simplifie le formatage du texte des onglets. Les améliorations de performance optimisent le chargement de l’arbre des commentaires, réduisent les requêtes de base de données inutiles et utilisent des branches de commentaires en cache pour un affichage plus rapide. Version

Changements notables de code et documentation

Damus (iOS)

Focus sur la stabilité avec des corrections de crash et d’interface : correction du saut de curseur pour la vue de composition, refonte de l’interface NostrDB utilisant les types Swift ~Copyable pour la sécurité des transactions, stabilité de l’interface de thread corrigeant la réinstanciation de la barre d’actions, gel de la liste de mutes dû aux cycles AttributeGraph, et crash de profil du nettoyage de transaction inter-thread. Ajout également de AGENTS.md avec des directives pour les agents de codage IA.

Notedeck (Desktop/Mobile)

Stockage sécurisé des clés déplace nsec vers le magasin sécurisé du système d’exploitation avec migration automatique. Filtrage des notes futures cache les événements datés de plus de 24 heures dans le futur (anti-spam). Copie de nevent inclut maintenant les indications de relais. Aussi : ajout rapide de colonne de profil, navigation au clavier, optimisation du chargement média.

Amethyst (Android)

[NIP-46 signature distante](https://github.com/vitorpamplona/amethyst/pull/1555) support pour Nostr Connect. Organisation des signets avec gestion des listes publiques/privées. Correction de compatibilité strfry pour les cas limites d’analyse des infos de relais.

Primal (Android)

Deep links Nostr Connect pour les URLs nostrconnect://. Connexion distante via scan QR pour les connexions bunker. Correction de condition de course de connexion.

White Noise (Messagerie chiffrée)

Correction de rétention des données d’application désactive la sauvegarde automatique Android pour la confidentialité. Comportement de défilement du chat préserve la position lors de la lecture de l’historique.

Zeus (Portefeuille Lightning)

[NIP-47 paiements parallèles](https://github.com/ZeusLN/zeus/pull/3407) pour un débit de zaps en lot amélioré.

Bonnes pratiques pour développeurs

Validez les événements Auth de manière défensive - go-nostr a corrigé un panic dans la validation NIP-42 quand le tag relay était manquant. Vérifiez toujours les tags requis avant d’y accéder, même dans les flux d’authentification où vous attendez des événements bien formés.

Limitez le débit selon l’état d’authentification - khatru a ajouté la limitation de débit basée sur NIP-42, permettant aux relais d’appliquer différentes limites pour les connexions authentifiées vs anonymes. Considérez des limites par paliers basées sur le statut d’authentification plutôt que des restrictions générales.

Utilisez la pagination par curseur pour les listes - Blossom a remplacé la pagination basée sur la date par la pagination par curseur sur l’endpoint /list. La pagination basée sur la date échoue quand les éléments partagent des horodatages ; les curseurs fournissent une itération fiable.

Validation de schéma pour les types d’événements - Le projet nostrability/schemata fournit des schémas JSON pour valider les événements conformes aux NIP. Considérez l’intégration de la validation de schéma en développement pour attraper les événements malformés avant qu’ils n’atteignent les relais.