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.