Nostr Compass #42

Bienvenue à nouveau dans Nostr Compass, votre guide hebdomadaire de Nostr.

Notre application dédiée Nostr Compass pour Android rassemble les lettres d’information, les épisodes de podcast, les guides thématiques et les notes vocales des contributeurs. Ses dernières notes de version signées décrivent des lettres d’information intégrales dont les signatures sont vérifiées, des numéros enregistrés et 110 guides thématiques disponibles hors ligne, ainsi qu’une recherche locale dans les articles et les transcriptions disponibles. Les contributeurs peuvent enregistrer des notes vocales et répondre avec celles-ci, réécouter une prise enregistrée avant de l’envoyer et signer via Amber sans stocker leur clé privée dans l’application. Les enregistrements publics sont publiés sur Nostr et Blossom.

La dernière mise à jour de l’application conserve les enregistrements en attente et les points de reprise des téléversements lorsqu’Android arrête les tâches en arrière-plan, indique quand une approbation d’Amber est nécessaire et ouvre l’enregistrement concerné depuis une notification. Les vues distinctes des épisodes et des notes vocales conservent chacune leur position de défilement, tandis que la lecture reprend au même endroit. Les notifications de nouveaux enregistrements dépendent de la planification des tâches par Android et des autorisations.

Cette semaine : White Noise ajoute des sondages de groupe chiffrés et des avertissements signalant un historique de conversation incomplet ; Holoboard ajoute des commandes de promotion par message privé et une application Android ; fips-pub-domains teste des noms publics signés sur un réseau maillé ; Marmot MDK rend visibles les lacunes de l’historique des groupes chiffrés ; et Myco dote le partage d’applications de proximité d’une identité Nostr et d’une boutique. nostream adapte l’admission sur les relays à leur charge, tandis que Nostr double ratchet corrige une faille concernant les membres retirés. Le développement corrige l’interopérabilité des groupes chiffrés d’Amethyst, ajoute les messages vidéo chiffrés de Divine et met Nostr Atlas en ligne. Les mises à jour du protocole affinent les preuves d’identité, les invitations aux relays, les ensembles d’abonnements et les revendications de domaines proposées. La rétrospective de septembre qui clôt le mois suit ces mêmes questions à travers six années de Nostr.

À la une

Holoboard ajoute des commandes de promotion Nostr et une application Android

Holoboard est un tableau permettant de trouver des notes Nostr grâce à un classement qui peut être amélioré par des paiements Lightning. Les publications originales restent des events Nostr ; Holoboard fournit ses données de classement et de présentation via sa propre API HTTP. Cette distinction compte lorsqu’un lecteur s’attend à ce que l’ordre du tableau corresponde à un flux natif de relay.

Son journal des modifications du 23 septembre mentionne des commandes de promotion par message direct utilisant à la fois les voies chiffrées de NIP-17 et celles, plus anciennes, de NIP-04. NIP-17 enveloppe les messages privés pour masquer leur contenu et leur expéditeur aux relays, tandis que NIP-04 est l’ancien format de chiffrement des messages directs. Un utilisateur peut demander une facture de promotion dans la même conversation, recevoir un devis unique et identifié pour la première promotion payante et choisir de recevoir des rappels d’expiration en répondant YES. Le système d’envoi des promotions réessaie les relays en échec, tandis que la mise à jour du 24 septembre ajoute une application Android et simplifie le parcours de facturation.

Les notes d’intégration aux relays du projet décrivent les notes et commentaires ordinaires sur Nostr, le routage des boîtes de réception chiffrées et la gestion des citations et des suppressions. Sa fiche Android signée sur Zapstore atteste l’existence d’une version de l’application, mais il n’a pas été établi que la clé de cette fiche correspond à l’identité du tableau public de Holoboard. C’est la première fois que Compass couvre ce projet.

fips-pub-domains teste des noms publics signés pour un réseau maillé

fips-pub-domains est une nouvelle expérimentation de résolution et de nommage qui associe des noms de domaine publics à des nœuds sur FIPS, un réseau maillé chiffré utilisant les messages Nostr pour découvrir des pairs. Sa première version combine ces revendications avec des enregistrements DNS TXT, une validation DNSSEC facultative, des associations épinglées localement, un démon de résolution Linux et une intégration Android avec fips2go, le client FIPS pour téléphones. Une revendication signée ne suffit pas à établir la propriété d’un domaine public ; les clients ont besoin de preuves DNS ou DNSSEC, d’un témoin configuré ou d’une association épinglée précédemment reconnue comme fiable.

La version 0.2.0 ajoute des preuves DNSSEC aux revendications afin qu’un client disposant uniquement d’un relay sur le réseau maillé puisse valider un nom non épinglé, et permet à plusieurs serveurs validés de desservir un même domaine. Elle corrige également les associations épinglées obsolètes et le basculement DNS. La version 0.2.1 corrige une unité systemd qui ne parvenait pas à démarrer et exécute le serveur sans les privilèges root ; les installations existantes doivent remplacer cette unité pour bénéficier du correctif.

Sur Android, une modification intégrée à fips2go suit les associations vérifiées de noms publics dans son proxy DNS. Une seconde modification intégrée fait passer les connexions aux relays Nostr configurés par le réseau maillé, afin que le résolveur puisse récupérer et vérifier une revendication de domaine jamais rencontrée auparavant alors que le téléphone n’a pas de connexion internet. Les résultats sur les appareils sont rapportés par les responsables du projet dans ces demandes d’intégration ; ils ne démontrent pas un déploiement plus large.

Les tests à deux nœuds et avec un relay accessible uniquement par le réseau maillé du projet constituent des éléments rapportés par ses responsables pour une implémentation précoce, et non un déploiement en production. Son NIP-DB reste une proposition ouverte, et les valeurs de kind des events dans son brouillon restent provisoires dans l’attente de leur enregistrement. L’article de la semaine dernière sur fips2go couvrait l’amorçage du réseau maillé et la découverte de pairs ; les travaux de cette semaine portent sur les noms publics et leur vérification.

Marmot MDK 0.11.0 rend visibles les lacunes de l’historique des comptes

Marmot MDK, l’environnement d’exécution Rust et les liaisons générées pour la messagerie de groupe Nostr chiffrée avec MLS, fait suite à la version de la semaine dernière consacrée à l’envoi durable avec la version 0.11.0. La récupération d’un compte ne déclare désormais une lacune de l’historique entièrement comblée qu’une fois que chaque relay requis a terminé une comparaison non tronquée des events ; une lacune dont la résolution n’est pas prouvée produit un avertissement persistant qu’une application hôte peut afficher à l’utilisateur. Une file de livraison pleine déverse son contenu dans la base de données du compte au lieu d’abandonner des events, et la livraison en direct fait avancer le curseur de transport afin qu’un redémarrage ne récupère pas à nouveau le même historique.

Les notes de version complètes décrivent également des sondages de groupe chiffrés facultatifs, une vérification sans état des events dans les liaisons et des bibliothèques Android alignées pour des pages mémoire de 16 Ko. Les applications doivent mettre à jour ensemble les liaisons générées et les bibliothèques natives provenant de ce même ensemble de sources ; les bases de données des comptes migrent jusqu’au schéma 98 à la première ouverture, et le retour à une version antérieure de la base de données n’est pas pris en charge. Un défaut intermittent de rattrapage déjà présent peut encore laisser indéchiffrables des messages ayant plus de cinq époques de groupe de retard, sans produire d’avertissement ; cette version ne prétend donc pas assurer une récupération complète de l’historique dans tous les cas.

Myco 0.8.0–0.8.1 dote les applications de proximité de leur propre boutique Nostr

Myco est une application Android permettant d’échanger de petits programmes Nostr, appelés napplets, avec des téléphones à proximité, y compris lorsqu’ils sont hors ligne. La version 0.8.0 attribue à chaque installation une identité Nostr invitée et permet de se connecter avec une clé existante ou Amber, un outil de signature Android qui approuve les signatures sans partager la clé du compte. Elle remplace aussi l’onglet Découvrir par une boutique d’applications qui est elle-même un napplet. Cette boutique lit des fiches d’applications et des recommandations signées, tandis qu’une mise à jour téléchargée peut circuler entre les téléphones du Circle d’un utilisateur sans connexion internet.

La version 0.8.1 facilite la découverte de ces fiches en interrogeant les relays annoncés par un auteur ; les versions précédentes s’appuyaient sur des relays publics par défaut. Elle affiche immédiatement les profils et applications en cache, enregistre les réponses des relays plus lents pour les visites ultérieures, espace les tentatives auprès des relays en échec et maintient les abonnements actifs tant qu’une vue est ouverte. Les deux mises à jour conservent le format de transmission existant entre téléphones. Les téléphones mis à jour peuvent télécharger et partager les mises à jour des napplets ; les téléphones plus anciens ne transmettent que leurs annonces.

Versions étiquetées

White Noise Android ajoute des sondages de groupe et des durées par défaut de disparition des messages propres à chaque compte

White Noise Android est une messagerie Nostr pour les conversations privées chiffrées avec Marmot. Après les améliorations de livraison et de partage présentées la semaine dernière, la version du 30 septembre ajoute, par l’intermédiaire du Marmot Development Kit, des sondages de groupe avec des réponses sélectionnables, des barres de résultats et des dates limites. Elle ajoute également des durées par défaut de disparition des messages propres à chaque compte et stockées localement sur l’appareil : les nouvelles conversations directes et les nouveaux groupes héritent de la durée choisie, tandis que les conversations existantes et leurs réglages individuels conservent leur politique actuelle. Faire un signe de la main envoie une salutation qui mentionne un membre nouvellement ajouté sans perturber le brouillon en cours.

La version permet aux utilisateurs de choisir le point focal du recadrage des images de profil et de groupe, et de supprimer un dossier de discussions sans supprimer ses conversations. Ses avertissements relatifs à l’historique indiquent lorsqu’une récupération laisse l’historique d’un compte ou d’un groupe potentiellement incomplet, avec des commandes distinctes pour les fermer. La pagination des conversations évite de reconstruire la chronologie affichée lors d’un saut vers les messages récents, et les modifications de messages en attente conservent leur texte pendant que l’envoi initial obtient son identifiant d’event confirmé. Ce transfert de la modification couvre les changements de conversation dans l’application en cours d’exécution ; il ne garantit pas la persistance après l’arrêt du processus.

La dictée permet désormais de choisir Coller ou Envoyer pour chaque enregistrement, la fin automatique plaçant la transcription dans le brouillon. La configuration du fournisseur hors ligne explique le traitement sur l’appareil, maintient son consentement distinct de celui des autres fournisseurs de reconnaissance vocale et rétablit les médias interrompus après la fin de la capture. La gestion des fichiers généraux accepte des documents non vides de taille limitée, avec des noms de fichiers exacts, des métadonnées MIME et des messages d’échec ; les téléchargements explicites de pièces jointes utilisent les tâches de transfert Android initiées par l’utilisateur, avec une solution de repli au premier plan. Les commandes de collage utilisent désormais l’action système d’Android afin que GrapheneOS Secure Paste puisse accorder l’accès au presse-papiers. Android affiche également les partages GIPHY d’iOS sous forme de médias animés, tout en respectant la politique de téléchargement.

Les correctifs des notifications actualisent les surnoms des expéditeurs et effacent les alertes à l’ouverture d’une conversation. Les changements apportés à la récupération des notifications préservent les tâches de notification push en attente lorsque leur prise en charge au premier plan est indisponible et limitent le nombre de nouvelles tentatives. La signature avec Amber coordonne les rafales d’approbations pour un même compte afin d’éviter que les limites de fréquence n’annulent les envois. La nouvelle configuration d’audit demande un nouveau choix concernant le partage des journaux avant leur téléversement vers le nouveau destinataire. Le code source adopte également la licence AGPL-3.0-only.

nostream 3.1.0 adapte la preuve de travail du relay à la charge

nostream est un relay Nostr en TypeScript s’appuyant sur PostgreSQL. La version 3.1.0 peut augmenter ou diminuer le seuil de preuve de travail des event entre les limites fixées par l’opérateur, à mesure que le débit d’event observé évolue. Ce réglage est désactivé par défaut, utilise le débit mesuré par chaque worker et laisse indépendant le seuil statique existant relatif aux clés publiques ; les opérateurs doivent donc l’activer explicitement avant que les expéditeurs ne soient soumis à une exigence d’admission différente.

La même version ajoute un tableau de bord d’administration pour les métriques du relay, de WebSocket et des event, les résultats des sondes de santé du réseau et des notifications configurables pour l’opérateur. Son API d’administration est désactivée par défaut. Ces commandes aident les opérateurs à distinguer les problèmes de charge du relay des problèmes d’accessibilité, tout en soumettant la nouvelle politique à une configuration explicite.

Après sa version introduisant une preuve de travail sensible à la charge, nostream a intégré des actions pour les signalements provenant de modérateurs de confiance. NIP-56 définit les event de signalement de contenu ; la nouvelle option nip56.hideActionableReports exclut les event signalés des résultats REQ et COUNT lorsque le signalement est également activé. Un signalement d’event masque cet event, tandis qu’un signalement de clé publique masque tous les event de cet auteur. La nouvelle option vaut false par défaut ; l’activation de la seule collecte des signalements préserve donc les résultats des requêtes existants.

Nostr double ratchet 0.0.171–0.0.172 corrige une faille concernant les membres exclus

Nostr double ratchet est une bibliothèque TypeScript pour les discussions privées chiffrées acheminées par Nostr. La version 0.0.171 renouvelle la clé d’expéditeur d’un groupe après les changements de membres, afin qu’une personne exclue disposant des anciennes clés ne puisse pas déchiffrer les messages ultérieurs d’un expéditeur mis à jour, même après le redémarrage de celui-ci. Elle refuse également les envois ou le renouvellement des clés par un propriétaire local exclu et interrompt un envoi si la composition du groupe change pendant la distribution des clés.

La version 0.0.172 transporte l’approbation existante de l’appareil, signée par le compte, dans une réponse d’invitation chiffrée facultative. Un destinataire utilisant cette mise à jour peut vérifier l’appareil de l’expéditeur avant l’arrivée d’un event d’enregistrement distinct, tandis que les appareils liés conservent leur approbation après les redémarrages. Le champ d’invitation est facultatif et laisse intacts l’échange initial et le format des messages du ratchet.

Les versions 0.0.173–0.0.175 prolongent ce travail sur l’exclusion avec des transferts persistants de clés de groupe et un état de livraison en file d’attente enregistré avant la publication, afin que les transferts interrompus reprennent après un redémarrage. Les fonctions de rappel de publication transportent un contexte de groupe local qui permet aux applications d’annuler les nouvelles tentatives persistantes après une exclusion, tout en maintenant la livraison des commandes de gestion des membres ; les envois en file d’attente préservent leurs identifiants d’event internes d’origine. Les réponses d’invitation en double préservent les sessions établies, les abonnements restent stables lorsque les contacts changent et les instantanés des clés d’application conservent les noms des appareils sans partager de copies mutables. Le format signé transmis sur le réseau reste inchangé ; les notes de la version 0.0.173 font également état de Rust 0.0.168, avec un mécanisme de repli pour les sessions de réception et un filtrage local des échos de groupe.

Scramble 0.7.4–0.7.5 récupère les messages qu’un nouveau membre du groupe doit voir

Scramble est une messagerie de groupe Marmot multiplateforme dotée d’une interface Android native. Dans la version 0.7.5, chaque groupe dispose de son propre seuil temporel pour l’historique du relay : auparavant, le seuil de la conversation la plus active était appliqué à tous les groupes, si bien qu’un groupe nouvellement rejoint pouvait rester vide parce que ses messages postérieurs à l’adhésion n’étaient jamais demandés. Le mécanisme de reconnexion reçoit le même correctif, et un groupe sans activité locale demande désormais tous les messages disponibles ; MLS empêche toujours un nouveau membre de déchiffrer les messages envoyés avant son adhésion.

La version 0.7.4 précédente corrige les acceptations répétées d’invitations causées par l’accumulation de gestionnaires de clics dans les lignes Android recyclées, et rend persistant le réglage d’un serveur de médias Blossom personnalisé dans l’application native. La version 0.7.5 ne fournit que l’APK Android natif ; les utilisateurs qui suivent l’ancien nom de fichier Avalonia doivent donc modifier leur cible de mise à jour. Les comptes et l’historique passent d’une de ces deux versions Android à l’autre, mais les groupes créés avec l’ancien moteur MLS 0.6.x ne migrent pas vers 0.7.x.

Scramble 0.7.6 ajoute une commande manuelle Récupérer les messages manquants qui interroge toutes les adresses de routage utilisées par un groupe, supprime la restriction temporelle, corrige une adresse stockée obsolète et indique ce qu’elle a récupéré. Elle ne peut toujours pas déchiffrer les époques antérieures à l’adhésion de l’utilisateur. Les administrateurs utilisant l’application native peuvent promouvoir ou rétrograder d’autres membres, avec l’état actuel de la liste des membres et des résultats d’échec visibles ; les conversations à deux masquent toujours ces commandes. L’action Copier des informations du groupe répond désormais, bien que les conversations sur invitation puissent encore copier un identifiant interne de discussion au lieu de l’identifiant de groupe du protocole. La version 0.7.7 traite également les messages retenus lorsque le commit d’un autre membre arrive ; la version 0.7.8 ajoute un test de non-régression pour ce chemin de traitement des membres passifs.

Amber 6.6.6 corrige les secrets de connexion au signataire distant

Amber est un signataire Android qui approuve les signatures d’event Nostr sans transmettre à une application la clé de son compte. Après la modification du chiffrement des sauvegardes de la semaine dernière, la version 6.6.6 corrige son analyseur nostrconnect : un paramètre de connexion contenant =, tel qu’un secret avec remplissage, était altéré avant qu’Amber ne réponde. Cela faisait échouer la vérification du secret par les clients basés sur NDK, même lorsque la connexion au signataire semblait par ailleurs valide.

La version envoie également les signalements aux relays indiqués dans l’annonce du dépôt d’Amber, avec un repli vers le relay précédent si l’annonce ne peut pas être récupérée. Des délais d’attente Tor plus longs donnent aux relays lents davantage de temps pour accuser réception de cette publication. Les autres modifications améliorent la visibilité des icônes et du texte dans les thèmes d’Amber.

FIPS 0.5.2 met fin à une fuite de données privées dans la découverte Nostr

FIPS est un réseau maillé chiffré qui utilise des identités Nostr et des messages de relay pour découvrir des pairs. Sa version de maintenance 0.5.2 cesse de signer les demandes de suppression liées à la traversée NAT avec la clé de routage du nœud, ce qui associait cette clé au trafic de traversée sur les relays. Elle met également à jour la bibliothèque TLS utilisée pour les connexions aux relays vers une version qui corrige une vulnérabilité faisant l’objet d’un avis de sécurité publié, et corrige plusieurs cas de perte de messages lors du renouvellement des clés de liaison et de session.

Les notes de version appellent les opérateurs de toutes les plateformes à effectuer la mise à niveau, tout en détaillant des correctifs distincts concernant les permissions des fichiers de clés sous Windows, les passerelles et les services de paquets. Les nœuds éphémères n’écrivent plus de fichier privé fips.key qu’un redémarrage ultérieur pourrait écraser ; les opérateurs qui souhaitaient une identité stable doivent activer le mode persistant avant la mise à niveau. La version ne modifie pas le format de transmission du réseau maillé, de sorte que les nœuds de versions différentes peuvent être mis à niveau individuellement.

napplet soyLI 0.23.1–0.23.4 corrige la publication du backend et l’approbation du signataire

soyLI de napplet.soy est la boîte à outils de création et de publication de petits programmes Nostr exécutés dans un environnement isolé. Après la version de la semaine dernière consacrée aux créations partagées, la version 0.23.1 intègre les manifestes, les gestionnaires et les schémas du backend aux vérifications de création et aux aperçus multijoueurs. Elle conserve la configuration portable des fournisseurs dans le manifeste du projet, tout en laissant les associations privées d’identité et les bases de données de développement hors de l’instantané du code source publié.

La version 0.23.2 permet aux projets qui avaient auparavant ajouté à leur historique un contexte public de backend généré de publier à nouveau après une validation stricte, tout en continuant à rejeter les associations privées, les journaux, les bases de données et les identifiants présents dans l’historique accessible. La version 0.23.4, publiée ensuite, corrige une défaillance de session du backend persistant qui pouvait rejeter une approbation valide provenant d’une extension ou d’un signataire distant lorsqu’une personne mettait plusieurs secondes à signer. Les hôtes publics ont également besoin du correctif pour les hôtes partagés ; la mise à jour de la seule CLI du créateur n’a pas corrigé un hôte déployé.

Dart NDK 0.10.0 définit le périmètre de l’authentification Blossom et de la signature distante

Dart NDK est une bibliothèque Flutter et Dart pour l’accès aux relays Nostr, la signature, les demandes adressées aux portefeuilles et les opérations sur les médias. Après la préversion de la semaine dernière, 0.10.0-dev.7 modifie les requêtes de médias Blossom afin qu’elles restent anonymes jusqu’à ce qu’un serveur les refuse, puis les autorise au moyen d’une politique explicite indiquant quelle identité une opération peut révéler. Elle transmet cette autorisation tout au long du cheminement de la requête et remplace les anciennes options useAuth et customSigner, un changement d’intégration incompatible pour les applications utilisant l’API de la préversion.

Dev.9 cesse de retenir une réponse du signataire distant jusqu’à ce que le relay le plus lent en accuse réception. Dev.8 réduit l’interrogation des relay en arrière-plan et le travail sur le cache ; ses autres correctifs concernent la persistance de la phrase de récupération du portefeuille et les échéances de règlement. La version stable 0.10.0 regroupe désormais cette série de développement avec les modifications relatives aux métadonnées de connexion et aux identifiants d’abonnement privés décrites ci-dessous. La comparaison avec dev.9 inclut ces modifications fusionnées. Les applications qui effectuent la mise à niveau doivent examiner à la fois la modification de l’API d’authentification des médias et le cheminement des réponses du signataire distant.

La version stable inclut les métadonnées de connexion NIP-46 et les permissions demandées, remplaçant les champs de connexion séparés par une valeur Nip46ClientMetadata. Il s’agit d’une modification de l’API au niveau du code source qui permet aux widgets de connexion de transmettre au bunker l’identité de l’application et les permissions demandées. Une autre modification des identifiants de requête utilise 32 caractères hexadécimaux aléatoires en production, afin de ne pas exposer les noms des cas d’usage et les phases de pagination dans les identifiants d’abonnement visibles par les relays. Les identifiants explicites restent soumis à la limite de 64 caractères de NIP-01, tandis que le mode de débogage conserve un nom court à des fins de diagnostic.

Mostro Core 0.16.0 supprime l’ancien transport gift-wrap

Mostro Core fournit le protocole de messagerie utilisé par les clients d’échange de pair à pair de Mostro basés sur Nostr et par son coordinateur. La version 0.16.0 supprime son transport gift-wrap du protocole v1 et ses anciennes fonctions d’enveloppement et de désenveloppement, ne laissant que le transport plus récent comme voie proposée par la bibliothèque. Il s’agit d’un changement incompatible pour les applications qui construisent ou lisent encore des messages v1 au moyen de cette bibliothèque.

La version de la bibliothèque précède la version 0.19.0 désormais publiée du coordinateur. Les opérateurs qui desservent des clients plus anciens doivent mettre à jour les deux côtés de la migration du transport. Le tag 0.15.1 précédent ajoute un état de litige pour l’annulation coopérative, mais la suppression du transport constitue le jalon de compatibilité.

Cambium 0.6.0–0.7.1 enregistre un téléphone de déverrouillage via des messages de relay

Cambium est un compagnon de signature Android pour une clé matérielle Heartwood, qui peut également déverrouiller la carte après un redémarrage. La version 0.6.0 permet d’enregistrer un téléphone pour le déverrouillage via les relays Nostr de la carte, sans câble USB ; l’utilisateur compare les cinq mots de la demande sur le téléphone, la carte et Sapwood, l’interface d’enregistrement de la carte, avant d’appuyer sur le bouton de la carte. Les relay nouvellement annoncés sont soumis à un délai de connexion aléatoire afin que le premier contact du téléphone ne révèle pas exactement quand il a vu la mise à jour de la carte.

La version 0.7.0 inverse le processus d’invitation : un téléphone scanne le code QR éphémère de Sapwood et renvoie un seul event chiffré à usage unique depuis une clé jetable. Une nouvelle tentative republie ce même event si aucun relay ne l’accepte, tandis que l’ancien parcours d’affichage du code reste disponible pour les anciennes compilations de Sapwood. Le correctif 0.7.1 maintient le code de vérification final visible et améliore la reproductibilité des compilations F-Droid ; le parcours QR nécessite toujours les versions récentes spécifiées de Sapwood et de Heartwood.

Bray 3.5.0–3.5.2 limite les dépenses du portefeuille Nostr initiées par un agent

Bray est un serveur d’outils Nostr qui permet à un assistant IA de demander des actions sur les relays, les identités et les portefeuilles via une interface à périmètre défini. Sa version 3.5.0 ajoute un plafond pour chaque paiement Nostr Wallet Connect et un budget quotidien persistant, avec confirmation humaine lorsque l’hôte de l’assistant la prend en charge. Fournir des connexions de dépense distinctes nécessite désormais un réglage explicite du service de portefeuille ; Bray revérifie chaque autorisation avant utilisation et limite les recherches de factures aux hachages compris dans cette autorisation.

La version demande également aux utilisateurs de conserver l’URI de connexion au portefeuille dans un fichier privé plutôt que de le coller dans une conversation, et refuse de retenter un paiement au résultat incertain comme si son échec était avéré. La version 3.5.2 effectue localement la mise en correspondance des circuits de paiement de la place de marché après que les relays ont rejeté le filtre demandé sur les moyens de paiement. Ces vérifications limitent ce qu’un assistant délégué peut dépenser et empêchent qu’une hypothèse sur le filtrage par les relays ne masque des offres correspondantes.

Mafrend 1.3.0-alpha fait migrer les groupes cartographiques privés vers la spécification actuelle de Marmot

Mafrend est une application sociale Nostr basée sur une carte, qui permet d’explorer des lieux et de discuter autour de destinations. Sa version 1.3.0-alpha met les groupes privés à niveau vers une spécification plus récente des groupes chiffrés Marmot et ajoute la consultation des profils depuis les conversations et les avis. Le format des groupes est incompatible avec les anciennes conversations alpha ; les utilisateurs doivent considérer cette mise à jour comme une migration alpha comportant une rupture de compatibilité.

La même version ajoute le partage de captures d’écran et des modifications des conversations, ainsi que des améliorations de la carte et des marqueurs. Les fonctionnalités de profil sont toujours indiquées comme étant en cours de développement par le projet. Le changement notable pour Nostr est l’évolution de l’interopérabilité des groupes privés ; les utilisateurs ayant d’anciens groupes de test doivent consulter la note de compatibilité avant d’effectuer la mise à niveau.

Sonar alpha.15–alpha.15.1 corrige la publication dans les groupes chiffrés

Sonar est une messagerie privée qui peut acheminer des conversations via un réseau maillé Bluetooth et Nostr. Alpha.15 ajoute des réactions par emoji aux messages et le partage privé de l’heure locale dans les conversations chiffrées, avec un paramètre permettant de révoquer ce partage. Son portefeuille passe à Cashu, mais ce changement concernant les paiements est distinct de la mise à jour de la messagerie.

Alpha.15.1 corrige un échec au lancement qui pouvait laisser l’index des conversations vide après qu’une compilation issue d’une ancienne branche avait écrit une version de schéma étrangère. Sans cet index, l’application chiffrait à nouveau et republiait les partages d’heure locale dans chaque groupe à chaque réouverture, envoyant parfois des centaines d’event avant que les limites de débit des relay n’interviennent. Le correctif reconstruit cet état local et arrête les publications répétées dans les groupes.

Les paquets de commerce d’Elisym introduisent des commandes privées sur Nostr

Elisym est une boîte à outils pour agents fondée sur Nostr qui développe désormais un parcours commercial reposant sur des event signés. Son paquet commerce fusionné définit les produits des boutiques, l’autorisation du propriétaire, les commandes et reçus enveloppés de manière privée, ainsi que la vérification des offres pour les composants de paiement et de gestion marchande. Un tag commerce 0.2.0 ultérieur dérive la référence de paiement d’une commande à partir de cette commande, liant la recherche du paiement au parcours d’achat signé.

La série de paquets introduit également des travaux distincts sur payment-core et le paiement dans le navigateur, mais ses tag de version n’établissent pas qu’un parcours complet de paiement marchand est déployé. Le kind d’event d’autorisation de boutique est explicitement provisoire dans la source primaire du projet. Les onze tag SDK, MCP, CLI et payment-core jalonnent une seule fonctionnalité commerciale en cours de développement.

Les nouvelles versions des paquets d’Elisym mettent le nœud marchand autohébergé à disposition sous forme de paquet, tandis que MCP 0.31.0 ajoute buy_product et get_order pour les produits commerciaux. Les versions ultérieures de commerce et merchant-node ajoutent la prise en charge des paiements Tempo dans ce même parcours de paiement. Ces paquets font progresser l’intégration existante des produits signés et des commandes privées ; la liste des tag ne fait pas du schéma d’event provisoire une norme et n’établit pas le lancement complet d’un service hébergé.

Flotilla 1.11.2 débloque les outils de signature et les flux incomplets des relay

Flotilla est un client Nostr pour les conversations, les salons et les espaces partagés. La version 1.11.2 offre à l’utilisateur une issue lorsque le démarrage reste bloqué dans l’attente d’un outil de signature distant, et déconnecte une session dont les données locales de l’application ont été effacées. Un salon peut désormais afficher ses messages avant que l’espace plus large auquel il appartient ait terminé sa synchronisation, tandis que les flux n’omettent plus de publications simplement parce qu’un relay a répondu plus tard qu’un autre.

La même version publie également une compilation F-Droid signée avec la clé existante de l’application et maintient les versions GitHub à jour pour Obtainium. Ce travail de distribution compte pour les utilisateurs qui changent de canal de mise à jour, mais les corrections concernant les relays et les outils de signature sont la raison immédiate de mettre à niveau.

Ditto 2.42.3 affiche la livraison aux relays et renforce le cloisonnement des comptes

Ditto est un client social Nostr qui permet aux utilisateurs de choisir leurs relay et de s’y authentifier. Dans la version 2.42.3, les détails de l’event d’une publication indiquent quels relay de l’utilisateur et de l’auteur la détiennent ; la diffusion ne cible que ceux où elle manque. La version signale également les relays de lecture qui ne répondent pas et leur associe une commande permettant de réessayer, ce qui facilite le diagnostic d’une publication manquante sans la renvoyer partout.

Les notes de version indiquent que le changement de compte n’envoie plus de publications aux relays du compte précédent, que les utilisateurs mis en sourdine ne peuvent pas déclencher d’alertes génériques sur le téléphone et que les liens ou images des publications ne peuvent pas atteindre les appareils du réseau local du lecteur. Les publications provenant de relay lents cessent de disparaître des flux Abonnements et Coups de cœur, tandis que les discussions des diffusions en direct et les jeux webxdc se mettent à jour sans télécharger à nouveau l’intégralité de la vue à répétition. La navigation parmi les torrents et les contenus audio est également nouvelle, mais le routage vers les relays et l’isolation des comptes sont les changements qui ont l’incidence la plus large sur Nostr.

Iris Chat 2026.9.24.4 intègre les appels aux conversations chiffrées

Iris Chat est une messagerie Nostr chiffrée de bout en bout qui utilise la famille de protocoles de discussion à double ratchet. Sa version du 24 septembre ajoute les appels vocaux et vidéo avec les contacts compatibles, y compris via une connexion locale existante lorsque l’accès à Internet est indisponible. Un utilisateur peut réduire la qualité vidéo, répondre à un appel vidéo en mode vocal et gérer un appel entrant via l’interface d’appel d’Android ; répondre ou refuser l’appel arrête également la sonnerie sur les autres appareils liés.

La version permet également de se connecter par l’intermédiaire d’une application de signature distincte et de voir quels appareils liés sont connectés. Des correctifs ultérieurs du 24 septembre conservent les horodatages d’origine des messages retardés et améliorent la livraison à proximité après la perte d’un paquet de reconnexion. Ces comportements entre appareils et pour les appels en sont à leurs débuts ; la mise à jour est donc surtout utile aux contacts qui peuvent utiliser des compilations compatibles d’Iris.

La mise à jour ultérieure du 30 septembre, signée par le développeur, conserve l’historique local du groupe d’un membre retiré tout en désactivant les envois, améliore la livraison entre les appareils liés et dans les grands groupes, et corrige les indicateurs de lecture et les compteurs de messages non lus. Les appels bénéficient de la sélection du périphérique audio et du rétablissement des tonalités d’appel sortant ; un état périmé du microphone ne coupe plus le son entrant. La mise en sourdine temporaire, la copie d’images, les pièces jointes ajoutées par dépôt de fichiers, le routage des notifications et l’enregistrement des notifications push reçoivent des correctifs, tandis que la déconnexion efface les caches locaux et que le retrait d’un appareil met fin à sa session. Une seconde mise à jour améliore l’accès aux fichiers mis en cache par d’autres applications Iris sur le même appareil et maintient le partage local de fichiers disponible lorsque Nearby est désactivé.

LibreNostr 0.6.0–0.7.0 fait passer les connexions aux relays par Tor intégré

LibreNostr est un client Nostr pour Android avec des paramètres de relay et de confidentialité configurables. La version 0.6.0 intègre un moteur Tor fondé sur Arti sur ARM64 et applique le mode choisi, Direct, Tor pour tout ou .onion uniquement, aux connexions WebSocket des relay, aux requêtes HTTP, aux médias, aux téléversements et aux pages web. Le mode Tor strict bloque les connexions lorsque Tor est indisponible et n’envoie jamais silencieusement une requête directement ; changer de mode reconnecte les sockets des relay via le nouvel itinéraire.

La version 0.6.2 ajoute un filtre fondé sur un réseau de confiance, construit sur l’appareil à partir des listes publiques d’abonnements, et choisit les relays supplémentaires selon les personnes suivies additionnelles qu’ils permettent d’atteindre. La version 0.7.0 affiche ensuite les notes et les notifications avant la fin des recherches de profils et de compteurs, limite la durée des requêtes aux relays lents et cesse de déchiffrer l’intégralité de la boîte de messages privés à chaque ouverture d’une conversation. Ensemble, ces versions modifient à la fois les destinations auxquelles le client peut se connecter et la durée pendant laquelle un relay lent peut bloquer son interface.

Sa première version stable, 1.0.0, signée par le développeur, ajoute des tableaux de bord pour tablette enregistrés par profil, avec des colonnes déplaçables pour les flux, les hashtags, les profils, la lecture de textes longs, les notifications et les messages. Les tablettes en mode paysage bénéficient de cette disposition ; les téléphones conservent leur interface existante. La recherche bénéficie de OR, d’exclusions, de filtres de médias et de plages de dates fonctionnelles, renvoie les profils mis en cache avant les affinements via les relays et passe immédiatement à la suite lorsque des requêtes de recherche en texte intégral sont refusées. Les hashtags sont triés chronologiquement, la pagination attend suffisamment de réponses des relay et les flux inutilisés libèrent leurs abonnements.

La même version conserve les entrées existantes, publiques et chiffrées, des listes de mise en sourdine et des signets lors des modifications, au lieu de les remplacer par un seul changement. Elle isole les signets et les notifications entre les comptes et restreint les relays auxiliaires des auteurs aux lectures publiques, sans leur transmettre de requêtes privées ni y effectuer d’authentification auprès des relay. Elle empêche également les réponses de profil périmées de remplacer des métadonnées plus récentes, corrige la pagination et les badges des notifications, conserve les anciens éléments des flux lorsque de nouveaux arrivent, et corrige les comptes à rebours d’annulation des réponses, les publications en double, les URL de médias comportant des chaînes de requête et les compteurs de messages non lus après qu’une conversation a été marquée comme lue. La version 1.0.1 corrige un plantage au démarrage des tableaux de bord pour tablette dans la nouvelle disposition.

Newlay 0.3.45 diffuse en flux les requêtes volumineuses au lieu de fermer les connexions

Newlay est un relay Nostr hébergé sur Android, accompagné de services locaux connexes. Son annonce signée de la version 0.3.45 indique que les résultats des requêtes volumineuses sont désormais transmis en flux avec contre-pression, au lieu de fermer la connexion du client. L’hôte Git intégré supprime les packs devenus obsolètes après les envois, tandis que son coordinateur de messagerie chiffrée Cordn accepte les requêtes client surdimensionnées et envoie une trame d’abandon lorsqu’une sonde expire.

La version fournit aussi à l’opérateur Android une carte d’état en temps réel pour les events, le stockage, l’adresse et l’administration, et adapte la bibliothèque cryptographique native aux appareils dont les pages mémoire font 16 Ko. Les changements du relay et du coordinateur s’étalent sur plusieurs versions depuis la précédente version disponible dans la boutique, 0.3.39 ; la version 0.3.45 les regroupe dans un même paquet.

ngit-grasp 3.0.5 maintient la progression des envois Git et de la synchronisation des relay

ngit-grasp est un relay Nostr et un serveur Git auto-hébergés pour la collaboration signée sur des dépôts. Son annonce signée de la version 3.0.5 déplace la réconciliation lente de l’historique hors de l’acteur partagé de synchronisation en temps réel, ce qui permet aux abonnements aux relays de démarrer pendant la vérification des events antérieurs. Elle applique des temporisations distinctes pour les limites de débit, les requêtes d’historique incomplètes, les lectures de boîtes aux lettres et les recherches d’identité, de sorte qu’un relay défaillant ne monopolise plus la capacité de réessai.

La même version effectue la réconciliation à partir de l’inventaire local des events pour éviter de récupérer à nouveau l’historique stocké, et ferme les abonnements incomplets avant de considérer leur couverture comme vérifiée. Côté Git, elle accepte les envois que la promotion d’état en arrière-plan a déjà appliqués, conserve la protection contre les conflits pour les refs modifiées et consomme la sortie de progression de Git pendant les téléversements pour éviter qu’un envoi ne se bloque. Ces détails comptent, car un dépôt peut sembler à jour sur les relays alors que son transfert Git attend encore un résultat faisant autorité.

Armada 0.63.0 étend les alertes push aux différents types de signataires

Armada est un client Nostr pour les communautés, les canaux et les messages directs chiffrés. Après la version de la semaine dernière consacrée à la confidentialité des médias, son annonce signée de la version 0.63.0 décrit un nouveau mécanisme de notifications push dans le navigateur, qui fonctionne lorsque l’application est fermée pour les connexions par extension et par signataire distant, ainsi que pour les autres types de comptes. Tenna, une application hôte qui intègre Armada, bénéficie aussi de notifications en arrière-plan pour ses utilisateurs.

La version charge plus rapidement les anciens messages dans les longs canaux communautaires et évite de relire tout l’historique pour les nouveaux messages. Les indicateurs de saisie des messages directs utilisent moins de connexions aux relays. Les mises à jour sur ordinateur affichent désormais une invite de redémarrage, tandis que les mises à niveau directes depuis des versions antérieures à 0.50.0 ne sont plus prises en charge.

La version complémentaire 0.63.1, signée, ajoute des packs d’émojis modifiables avec importation de dossiers et réorganisation, récupère les messages cités au-delà de l’historique chargé et rend interopérables les réponses hébergées sur des relay. Elle réduit le trafic de reconnexion sur Android, rattrape les longues déconnexions sans répéter les anciennes alertes, exclut les mentions antérieures à l’arrivée dans le groupe et préserve les champs de groupe non modifiés ainsi que les entrées privées de la liste des serveurs. Les suppressions dans les groupes hébergés sur des relay exigent désormais que l’action soit effectuée par l’auteur du message ou un administrateur. Le déplacement des serveurs par glisser-déposer, le traitement des informations de relay malformées et les abonnements aux dépôts reçoivent également des correctifs.

La version 0.63.2 étend la prise en charge de Markdown dans les messages aux citations et listes imbriquées, aux lignes horizontales, aux blocs de code délimités, aux titres soulignés et à la mise en forme couvrant des liens ou des mentions. Les liens vers des pages Tenor et Giphy sont lus sous forme de GIF. La synchronisation de l’état de lecture transfère moins de données, la reconnexion évite les téléchargements et les connexions redondants, et les notifications Android en arrière-plan suspendent la synchronisation des relay lorsque de volumineuses mises à jour des paramètres la submergent.

deed 0.3.0–0.3.2 rend la publication Nostr en Zig plus stable

deed est un outil en ligne de commande écrit en Zig pour lire et publier des events Nostr. Sa version 0.3.2 du 24 septembre ajoute une compétence pour agent et corrige les délais d’expiration des pings aux relays ; les versions précédentes, 0.3.1 et 0.3.0, améliorent les performances et la fiabilité de la publication. Les trois tags décrivent une même série de versions initiales de l’outil. Le bénéfice visible pour Nostr est une connexion aux relays et un mécanisme de publication d’events plus stables pour les scripts qui utilisent la CLI.

Cordn 0.5.1 permet aux autres groupes de continuer lorsqu’un coordinateur tombe en panne

Cordn est une messagerie de groupe chiffrée avec MLS qui utilise les identités et les relays Nostr pour localiser les coordinateurs de conversation. Sa version client 0.5.1 signée poursuit le travail de la semaine dernière sur la file d’attente hors ligne en séparant la planification des coordinateurs de celle de la boîte d’envoi : un coordinateur indisponible ne retarde plus les envois des groupes sans rapport avec lui. Les indications de relay résolues sont conservées après la découverte, les documents de groupe les transportent entre appareils et un enregistrement persistant des publications en attente permet de récupérer les envois bloqués. La récupération multi-appareils exécute en parallèle les requêtes sur la chaîne d’historique et sur les lacunes tout en lisant la configuration actuelle.

La version ajoute aussi les pièces jointes par glisser-déposer, les groupes épinglés, les noms de profil dans les aperçus et les notifications, ainsi que les libellés des coordinateurs. Elle corrige le positionnement sur le premier message non lu, les compteurs de messages non lus, les alertes en double, les aperçus des médias et des messages système, les réponses associées à des médias accompagnés d’une légende et les commandes de zoom des images. Les téléchargements natifs utilisent une boîte de dialogue « Enregistrer sous ». Un signataire qui apparaît tardivement ne provoque plus de faux avertissement de chiffrement non pris en charge, et le changement de compte n’entre plus en concurrence avec l’initialisation en arrière-plan.

Nymbot 1.0.7 ajoute le traitement local des documents et le partage chiffré des conversations

Nymbot est un assistant accessible par des messages Nostr chiffrés et encapsulés au format gift-wrap. Sa version 1.0.7 signée par le développeur lit les documents sur l’appareil, sélectionne les passages pertinents lorsqu’un fichier est trop volumineux pour être envoyé en entier et identifie les pages utilisées. Les conversations peuvent être partagées au moyen d’un lien chiffré de bout en bout dont l’accès peut ensuite être révoqué. Les réponses en Python et en JavaScript peuvent être exécutées localement, leur sortie étant renvoyée dans la conversation.

La même version ajoute des recherches sourcées avec un prix affiché avant l’envoi, la retouche d’images, la sélection du modèle pour chaque message et des plafonds de dépenses par conversation et par bot. Les outils externes connectés via MCP demandent une confirmation avant de modifier des données. Les exécutions sur des dépôts peuvent suspendre les modifications pour examen, afficher les résultats de CI et reprendre après l’indisponibilité d’une passerelle occupée. Des réponses suggérées, des avis épinglés, des listes de sources repliées et un sélecteur de modèles doté d’une recherche complètent la mise à jour ; ces affirmations proviennent des notes de version du développeur ; Compass n’a pas audité de manière indépendante la confidentialité de l’application.

0xchat 1.5.6 intègre ses correctifs de signature et d’authentification des messages

0xchat est une messagerie Nostr avec des conversations privées, la signature externe et des fonctionnalités de portefeuille. La version 1.5.6 intègre les correctifs de sécurité présentés la semaine dernière comme des fusions dans le code source, notamment l’authentification gift-wrap, la configuration d’une infrastructure de confiance et le consentement à la signature depuis une page intégrée. Elle ferme aussi les voies de contournement du proxy Tor, valide les certificats TLS pour les hôtes non-onion et empêche les versions de production d’écrire sur la console de l’appareil des identifiants et des données de portefeuille potentiellement sensibles. Les journaux développeur activés volontairement continuent d’enregistrer les erreurs.

La version fait progresser le délai entre les tentatives de reconnexion aux relays de trois secondes à cinq minutes, répare les abonnements après la reconnexion et transmet les requêtes mises en file d’attente pendant qu’un relay se connecte. Les changements de compte n’accumulent plus d’écouteurs de relay en double, un échec de connexion préserve le compte déjà actif et les connexions aux signataires externes persistent d’un démarrage à l’autre. Les envois échoués affichent désormais des erreurs et conservent le texte non envoyé ou un état récupérable de partage de jetons. Le déchiffrement des clés au démarrage et le calcul des empreintes pour les téléversements sont déplacés hors du thread de l’interface ; les caches des conversations et des vidéos évitent les rendus et les téléchargements répétés. La version fournit des fichiers Android et de bureau avec des sommes de contrôle SHA-256, dont l’APK Android signé par Play et un programme d’installation Windows compilé à partir du code source.

Nostr Mail Client 0.17.0 masque les actions sur la boîte mail aux relays

Nostr Mail Client échange des courriels via Nostr tout en prenant en charge leur acheminement classique. Après la version de la semaine dernière consacrée au transport par destinataire et à la confidentialité des médias, la version 0.17.0 masque aux relays les états de lecture, d’archivage, de classement dans les dossiers et d’étiquetage, ainsi que le moment de ces actions, et permet aux utilisateurs de supprimer un courriel sans en avertir l’expéditeur. Cette version impose de mettre à jour tous les appareils ensemble, car les anciens clients ne voient ni les nouveaux états ni les suppressions. Elle protège également les destinataires en copie cachée dans les courriels de plus de 32 KB, empêche les alias locaux des contacts de figurer dans les messages sortants, répare la connexion par QR avec Amber et publie les courriels publics sur les relays de lecture des destinataires.

La version ajoute des dossiers et des étiquettes colorés avec des règles portant sur l’expéditeur, l’objet et les pièces jointes ; des citations dans les réponses et les transferts ; des images collées intégrées au texte ; l’aperçu et le renommage des pièces jointes ; et la sélection de plages dans les listes de courriels. Le transfert conserve les images et les pièces jointes d’origine, les citations dans les réponses sont initialement repliées et l’éditeur web dispose désormais d’un menu contextuel. Les tableaux HTML et les images intégrées sont rendus plus fidèlement, les liens en texte brut fonctionnent et la programmation prend en charge des dates jusqu’à cinq ans à l’avance. Les noms et les photos du carnet d’adresses apparaissent dans toute l’interface, et les couleurs du thème proposent des palettes système, suggérées ou personnalisées.

La même version conserve localement les arrière-plans sélectionnés depuis un fichier et met en cache ceux fournis par un lien, avec un coût de migration explicite : les anciens arrière-plans provenant de fichiers sur les plateformes natives doivent être ajoutés à nouveau. Elle modifie les recommandations par défaut pour les relays et les médias, ajoute la découverte d’applications Nostr pendant la prise en main ainsi que des avis de mise à jour, préserve les paramètres inconnus écrits par d’autres clients et répare la création interrompue du stockage des courriels ainsi que le packaging Linux. Les échecs au démarrage affichent désormais des détails et un rapport prérempli au lieu d’un écran vide.

Nostr WoT 0.8.7 lie l’authentification à la destination

Nostr WoT est une extension de navigateur qui combine la signature Nostr avec des outils de confiance. La version 0.8.7 exige un consentement pour l’authentification HTTP signée NIP-98, portant sur l’URL exacte, les paramètres de requête, la méthode, le compte et l’origine à l’origine de la demande. Les anciennes autorisations générales nécessitent un nouveau consentement. L’authentification auprès des relays NIP-42 dispose d’un système distinct d’autorisations liées au compte, dans lequel les refus propres à un site priment sur les autorisations partagées pour les relays. Les demandes d’authentification doivent provenir d’une origine vérifiée du contexte de navigation de premier niveau, et toute attente d’approbation ou de déverrouillage déclenche une nouvelle vérification du compte et des droits d’accès.

La version vérifie les signatures distantes NIP-46 et l’event approuvé dans son intégralité afin qu’une signature renvoyée ne puisse pas substituer silencieusement un contenu ou une destination. La création des portefeuilles et les changements d’adresse utilisent une authentification liée au corps de la requête, des défis à usage unique côté backend et des jetons de transaction distincts ; la signature générique pour les sites web ne peut pas créer ces jetons internes de portefeuille. Le backend compatible doit être déployé en premier, et le client refuse de revenir aux points de terminaison retirés. Les paiements Nostr Wallet Connect vérifient également la préimage de paiement renvoyée par rapport au hachage de la facture demandée et considèrent toute discordance comme une issue inconnue.

Dans l’interface des demandes, les utilisateurs peuvent examiner les events bruts complets, choisir des demandes précises dans un groupe associé à un site et consulter des messages privés localement sans autoriser leur renvoi à un site web. Les aperçus locaux se masquent après 30 secondes ; les demandes entrantes restent non cochées et l’approbation groupée ordinaire exclut l’authentification. L’extension sépare les autorisations de relay par site de celles valables pour tous les sites, limite la mise en cache des profils vérifiés, départage les events remplaçables de même horodatage en retenant l’ID d’event le plus bas et garde locales les lectures de publications de la fenêtre contextuelle d’accueil. Chrome et Firefox reçoivent des paquets vérifiés séparément et des workflows de soumission des versions stables exécutés en série ; ces workflows ne prouvent pas la disponibilité actuelle dans les boutiques d’extensions.

L’environnement d’exécution partagé d’Iris maintient la cohérence de l’historique des relays et des pairs

nostr-pubsub fournit un environnement d’exécution partagé pour les events Nostr, avec un stockage persistant des events et une file de publication sortante. Les versions 0.5.7–0.5.13 regroupent les abonnements exacts, les rejouent après reconnexion, gardent distincts les éléments attestés localement, par les relays et par les pairs, et signalent un historique incomplet lorsque le stockage durable échoue. Les requêtes terminées attendent que chaque event reçu ait achevé son admission. Le lot par défaut destiné aux relays contient désormais au maximum 20 filtres OR pour assurer la compatibilité avec les serveurs courants, tandis que les lots destinés aux pairs conservent une mise en correspondance et une annulation indépendantes.

Les mises à jour de l’environnement d’exécution de Hashtree remplacent la gestion réseau propre aux workers par cet environnement d’exécution partagé, des index persistants d’events et une file sortante, permettant aux events et aux fichiers mis en cache de partager un même nœud FIPS. FIPS TypeScript 0.0.44–0.0.45 sélectionne des routes ayant une capacité suffisante pour des enregistrements de signalisation complets, récupère les tentatives d’établissement de session perdues dans le délai imparti à la négociation et ne réessaie les réponses WebRTC qu’après un rejet explicite du routage. Les routes WebSocket transportant des trames plus volumineuses nécessitent des pairs natifs compatibles ; les notes de la version 0.0.44 imposent de déployer d’abord FIPS natif 0.4.85.

Iris Kit 0.2.5 ajoute un client applicatif persistant pour les events simples et la signature NIP-46 indépendante du transport, tout en préservant les clés des comptes et les lectures hors ligne. La version 0.2.6 renvoie immédiatement depuis le worker ou le backend natif un ID d’event complet déjà vérifié ; les requêtes par préfixe et celles portant sur les events remplaçables attendent toujours l’historique avant de choisir la valeur la plus récente. Il s’agit de versions de bibliothèques, et les notes n’établissent pas leur déploiement dans toutes les applications Iris.

La mise à jour du code source d’Iris Meet du 30 septembre remplace son intégration NDK par une infrastructure persistante de publication et d’abonnement et des signataires d’identité partagés. Le correctif ajoute une couverture de tests pour la restauration d’identité hors ligne, la signature NIP-07 et l’isolation des salles de réunion. L’application de réunion existante utilise Nostr pour la signalisation chiffrée et WebRTC pour l’audio et la vidéo. Il s’agit d’une avancée de l’implémentation sur la branche par défaut ; le dépôt ne comporte aucune version étiquetée prouvant que cette mise à jour précise a atteint le site en ligne.

Chama propage l’annulation des annonces et les alertes en arrière-plan

Chama utilise des events signés pour les échanges communautaires et les conversations privées. Les versions 6.4.14–6.4.16 publient une annulation signée avant de supprimer une annonce localement, afin que les autres clients puissent retirer la même offre mise en cache. Les tags de réveil des destinataires accompagnent désormais les events indépendamment du paramètre de notification de l’expéditeur, et le serveur d’alertes déduplique selon l’event signé afin qu’un message de discussion envoyé immédiatement après une participation puisse toujours déclencher un réveil. Les tâches en arrière-plan rejouent les échanges concernés à partir des curseurs enregistrés, isolent les chaînes en échec et déchiffrent localement le texte des notifications ; cette version nécessite de redéployer le service de surveillance compagnon.

Ces versions regroupées appliquent également les renouvellements des participants aux heures de leurs events signés, mettent en quarantaine les verrouillages de fonds effectués après l’expiration d’une place et permettent de récupérer le titre au porteur enregistré. La publication d’une demande attend la confirmation de l’importation ou du paiement. Les filtres d’annonces préservent la devise du lecteur dans les différents périmètres communautaires, et les en-têtes des échanges utilisent le montant finalisé des participations. Ces modifications harmonisent ce que deux clients connectés à Nostr déduisent du même historique d’events.

Earthly 0.1.12 ajoute des configurations de carte réutilisables

Earthly est un éditeur de cartes collaboratif Nostr doté de la publication signée et du partage chiffré. La version 0.1.12 ajoute des configurations GMapper réutilisables pour les cartes publiques Google My Maps, la découverte de Maplets créés par des développeurs, le stockage privé ou la publication publique des configurations, ainsi que la copie de géométries avec attribution. La même version ajoute le partage chiffré des connexions, les dépôts d’entités et la navigation dans les discussions sur mobile. La disponibilité des exports Google et les restrictions CORS des navigateurs limitent l’importation, les Maplets exécutables téléchargés restent indisponibles dans Tauri et les vérifications de mise à niveau sur des appareils Android physiques restent à effectuer.

Le travail sur les configurations a migré les adresses de publication et les préférences existantes et ajouté l’examen ou le retrait des mises à jour de configuration. Son workflow Android initial a échoué avant la compilation ; un correctif de l’outillage a préparé la version étiquetée par la suite.

Mostro 0.19.0 abandonne son transport de première génération

Mostro coordonne des transactions pair à pair sur Nostr. La version 0.19.0 intègre désormais la suppression de son transport gift-wrap de première génération, les clients doivent donc utiliser le nouveau protocole. Les tags d’horodatage existants pour la création d’ordres et l’ouverture de litiges sont renommés published_at sans modification de leurs valeurs stockées ; le champ created_at de l’event englobant reste l’heure de sa signature. Les réponses de restauration renvoient la clé de transaction de la contrepartie, les opérations de création et de prise d’ordre acceptées reconnaissent les clés de transaction, et la publication sur les relays s’achève au premier accusé de réception positif d’un relay. Cette même version met à jour les échéances et l’annulation des cautions, clôt les litiges lorsqu’une transaction se résout, avertit l’arbitre et limite l’ancienneté des prix transmis par les relays.

Le correctif d’admission des clés de transaction de Mostro reconnaît une clé dès que l’ordre ou le litige qui l’introduit est enregistré. Auparavant, les nœuds exigeant une preuve de travail plus stricte au premier contact pouvaient rejeter un message de suivi légitime jusqu’à l’actualisation périodique des clés connues ; les seuils égaux par défaut n’étaient pas concernés. Une transaction de litige enregistre de façon atomique la transition de l’ordre et la ligne du litige, éliminant les défaillances dues à des états incohérents. Les notifications de clôture envoient à l’arbitre désigné un message privé sans garantie de livraison lorsque les utilisateurs résolvent un litige, l’event remplaçable existant restant la solution de repli hors ligne.

SCRUTINY Lens introduit la recherche en sécurité sur Nostr

SCRUTINY Lens v0.1.0, sa première version publique publiée le 29 septembre, est un client pour navigateur destiné aux métadonnées de sécurité publiées via Nostr. Les analystes peuvent effectuer des recherches par identifiants CVE, de paquets ou de certificats, examiner les historiques d’events et les rétractations, et explorer les relations dans un graphe de sujets. Le navigateur vérifie les signatures et les identifiants des events. La recherche et les explications facultatives par IA utilisent un point de terminaison choisi par l’utilisateur ; l’application vérifie les citations fournies par rapport aux events sous-jacents. Les notes de version décrivent explicitement les limites des relay et indiquent les dépendances de compilation locale qui nécessitent encore des dépôts voisins.

Mangatsu et Noteds arrivent sur Android

Mangatsu v0.1.11 fait partie de la première série de versions Android du lecteur et outil de publication de bandes dessinées cette semaine. Son code source ajoute la connexion avec Amber via NIP-55, l’interface Android permettant de demander à un signataire externe d’approuver des opérations Nostr. Les bandes dessinées et les chapitres sont des events Nostr, tandis que leurs pages sont hébergées sur des serveurs Blossom ; le lecteur prend également en charge une bibliothèque enregistrée chiffrée et la lecture hors ligne. Des commits ultérieurs corrigent l’invocation du signataire et l’actualisation des listes de relay.

Noteds v0.1.2 apporte une place de marché de petites annonces Nostr sur Android grâce à Tauri. Son intégration du signataire Android utilise la signature Android NIP-55. L’application publie des annonces et des messages sur Nostr et construit un graphe de recherche local avec des catégories, des zones géographiques et, en option, des plongements vectoriels dans le navigateur. Le code source le plus récent corrige l’accès natif à la localisation pour la recherche à proximité. Les deux projets en sont à leurs premières versions ; leurs pages de versions GitHub ne comportent pas de notes détaillées, ces fonctionnalités sont donc décrites à partir des README associés aux versions étiquetées et des commits d’implémentation.

Statim combine les messages privés Nostr avec d’autres réseaux

Statim v0.4.0 fait suite à sa version initiale du 23 septembre. Le code source étiqueté décrit une messagerie proposant des messages privés Nostr NIP-17 aux côtés de XMTP, Status, Telegram et Matrix. Les comptes sont créés à partir d’une phrase de récupération conservée localement ; chaque conversation indique son protocole, car ces réseaux offrent des propriétés de confidentialité différentes. L’intégration Telegram est actuellement absente sur Android. Il s’agit des fonctionnalités documentées du projet, et non de garanties testées de manière indépendante ni d’une confirmation de disponibilité dans les boutiques d’applications.

En développement

Amethyst corrige l’interopérabilité des groupes chiffrés

Amethyst est un client Nostr pour Android prenant en charge les groupes chiffrés Marmot. White Noise est une autre messagerie Marmot ; un ensemble de modifications d’interopérabilité testé avec ses clients traite l’administration des groupes, les libellés de suppression et d’autres comportements révélés lorsque les deux clients partagent une conversation. Des corrections plus ciblées envoient les réactions et suppressions à l’intérieur du groupe Marmot plutôt que sous forme de messages privés distincts enveloppés selon NIP-17 et appliquent les modifications provenant d’un autre client après un redémarrage. Il s’agit de modifications fusionnées dans le code source ; les tests décrits dans les PR ont une portée plus restreinte qu’une version publiée assurant l’interopérabilité entre clients.

Une fusion distincte du moteur d’exécution et de l’interface des groupes Cordn ajoute une autre voie pour les groupes chiffrés, passant par des serveurs coordinateurs. Cordn est distinct de Marmot ; ces deux changements ne doivent donc pas être interprétés comme une seule migration de transport.

Amethyst a également fusionné des commandes HTTP pour relay dans son relay Geode et son client Quartz dans le cadre de sa proposition NIP-FE, ainsi qu’une interface d’examen des conflits de sauvegarde pour les events remplaçables de profil et de liste. NIP-FE est une appellation de proposition propre au projet ; le processus de sauvegarde permet à une personne de comparer les versions avant d’accepter un remplacement et empêche les écrasements silencieux de l’état local.

Amethyst développe également Concord, un protocole distinct de communautés chiffrées utilisé par Armada et Accordion. Un ensemble de modifications de conformité ajoute des listes de communautés fragmentées, des preuves d’épinglage, la rotation des clés et des enregistrements de dissolution, suivi par des messages éphémères et des invitations directes. Une invitation reste dans une boîte de réception privée jusqu’à son acceptation ; sa réception ne contacte pas les relays de la communauté. Le même changement corrige une comparaison d’auteurs qui pouvait permettre à une suppression émise par un autre auteur de retirer un message. Des corrections entre clients corrigent la sérialisation des rumors non signés, les champs d’invitation manquants, la création de communautés confirmée par relay et l’adhésion sans redémarrage ; les tests sur émulateur rapportés ont impliqué des pairs Armada et Accordion actifs.

Une implémentation ultérieure des canaux privés renouvelle les clés des canaux après les révocations d’accès concernées et ajoute des commandes de création, de passage en mode privé ou public et de renouvellement des clés. Elle ajoute aussi des expulsions coopératives avec vérification du rang et fait expirer les pièces jointes des messages en même temps que leurs messages parents. Les mises à jour WebXDC peuvent être placées dans un tampon de canal distinct, mais Amethyst ne dispose toujours pas d’un hôte pour les applications WebXDC. Cet ensemble ultérieur fait état de tests du format de transmission et de tests unitaires, sans essais sur appareil ni avec des relays actifs ; le résultat d’interopérabilité antérieur ne certifie donc pas chaque commande nouvellement ajoutée.

Le moteur MLS de Quartz conserve désormais les secrets des générations de messages sautées après un redémarrage, ce qui permet aux messages reçus dans le désordre de rester déchiffrables après la restauration de l’état sauvegardé. Quatre époques antérieures conservées permettent aux appelants d’authentifier les messages applicatifs tardifs, de conserver leurs données authentifiées et d’empêcher qu’une génération déjà consommée soit de nouveau ouverte. Une mise à jour de l’arbre de secrets charge les secrets de nœuds non développés depuis un état de type ts-mls ; des erreurs de génération obsolète propres à l’expéditeur distinguent une collision du propre cliquet d’un client d’un rejeu par un autre membre. La PR indique explicitement que le mécanisme de repli existant de Marmot sur les époques conservées reste distinct ; il s’agit donc d’une capacité du moteur, et non d’une preuve que chaque voie de traitement des messages d’Amethyst l’utilise.

Un audit du lecteur de tags de Quartz corrige des entrées geohash privées qui pouvaient être publiées en clair et un analyseur qui traitait la clé privée issue d’un nsec comme une clé publique. Il corrige également les adresses de republication, les cibles de masquage de canaux, les tags racine des salons en direct et les events de mint adressables. Le lecteur obsolète ForkTag est supprimé, ce qui modifie l’API au niveau du code source pour les utilisateurs de Quartz ; les lignes de mint SQLite préexistantes nécessitent toujours une migration distincte. Des modèles d’events supplémentaires couvrent les propositions de Buzz relatives aux conteneurs de projets, aux révisions d’artefacts et aux équipes, tandis que les modèles de vues vidéo et de contrôle chiffré des notifications push suivent les schémas de Divine ; ces ajouts établissent une prise en charge de l’analyse et de la construction, et non des interfaces client complètes ou des NIP numérotés adoptés.

Le client affiche aussi les photographies Ultra HDR dans le fil et la visionneuse plein écran sur Android 14 ou version ultérieure. Android 15 et les versions ultérieures plafonnent l’augmentation de luminosité du fil au double de la plage ordinaire, tandis que le plein écran peut utiliser toute la plage de l’écran ; les appareils de test mentionnés utilisaient des API Android plus récentes, laissant Android 14 et 15 non testés. Une fusion de l’interface partagée et du portage des téléversements fait passer 140 écrans à du code commun Android/ordinateur et déplace le traitement des médias Android hors du thread de l’interface. Son audit rétablit également le signalement des erreurs de suppression des métadonnées, faisant de cette refactorisation plus qu’un déplacement de fichiers.

Divine ajoute la vidéo chiffrée aux messages directs

Divine est un client vidéo Nostr. NIP-17 transporte les messages privés dans des enveloppes chiffrées qui dissimulent leur expéditeur aux relays. Les travaux fusionnés de Divine sur les messages vidéo chiffrent une vidéo jointe sur l’appareil, téléversent le contenu chiffré et envoient la clé de déchiffrement dans ce message privé. Un destinataire peut vérifier et déchiffrer le fichier pour le lire ou l’enregistrer. Une correction distincte de la restauration de l’historique empêche un refus ambigu d’un relay de mettre fin prématurément à la récupération lorsque d’autres relays peuvent encore répondre.

La correction de Divine concernant les clés de modération retirées refuse les clés retirées lors de la résolution des étiquettes de modération et sélectionne le destinataire actuel des signalements lorsqu’un signalement est déposé. Les signalements en attente adressés à une clé retirée sont redirigés vers la clé épinglée dans la version compilée, et les conversations non résolues restent en lecture seule. Le changement distingue également la garde associée aux clés retirées lorsqu’il détermine quels fils historiques un mineur peut lire ; les mises à jour de garde nécessitent toujours une nouvelle version de l’application. La gestion du cache des commentaires supprimés empêche un commentaire récent supprimé avec succès de réapparaître lors du rechargement d’un fil.

Pour les créateurs, un mode d’enregistrement avec masque de couleur en direct affiche un aperçu de l’arrière-plan de remplacement avant l’enregistrement d’une prise, et le masquage des murs blancs ajoute un masquage sensible à la luminosité via le plugin vidéo. Les sous-titres mot à mot conservent les repères temporels des mots reconnus et utilisent un minutage approximatif lorsque le serveur ne fournit que des segments entiers. La reprise d’une animation en stop motion ajoute de nouvelles images fixes au rythme de la composition existante, tandis que la réintégration des clips détachés, la sélection groupée des polices et les préréglages de vitesse ajoutent des commandes de montage sans modifier le format des events Nostr.

L’alignement lors de l’exportation au format carré et sa correction complémentaire pour les clips plus petits maintiennent le texte et les autocollants en place entre des clips de résolutions différentes. La lecture HLS de sources tierces évite un plantage du tas mémoire sur Android en revenant en arrière aux limites des boucles plutôt qu’en préchargeant des répétitions de listes de lecture importées ; ces boucles peuvent marquer une brève pause à chaque redémarrage. Un rechargement des préférences de compte maintient les filtres liés au compte à leurs valeurs par défaut lors d’un changement de compte, tout en corrigeant une partie d’une assertion de connexion en mode débogage. Un problème distinct d’actualisation des étiquettes de modération reste ouvert ; la PR ne prétend donc pas que toutes les erreurs de connexion sont corrigées.

Buzz étend les contrôles des canaux et des identités de son relay

Buzz est un espace de travail basé sur Nostr, avec son propre relay et ses propres clients. Son implémentation intégrée des artefacts de canal attribue à un enregistrement modifiable un seul canal de rattachement et une chaîne de révisions ; deux modifications contradictoires ne peuvent pas toutes deux devenir la révision de tête. L’appellation NIP-AR du projet désigne sa propre proposition et sa propre implémentation, et non une norme Nostr établie.

Pour les requêtes HTTP entrantes protégées, une autre modification intégrée associe une assertion d’identité fédérée à la même clé que celle attestée par l’autorisation NIP-98. NIP-98 définit des events signés d’authentification HTTP ; l’assertion NIP-FI de Buzz est une spécification propre au projet. Il a également intégré le chiffrement HPKE des enveloppes de sauvegarde de clés secrètes. Cette PR atteste d’un travail de sécurité au niveau du code source ; sa distribution à tous les clients reste non vérifiée.

Buzz desktop 0.5.26 inclut le travail sur les artefacts de canal, le chiffrement HPKE natif des sauvegardes de clés secrètes et une console d’administration du relay sur ordinateur. Ses modifications communes corrigent les requêtes concernant les canaux de projet non répertoriés, synchronisent les sections de la barre latérale, le tri, les favoris et les mises en sourdine entre appareils, bornent les lectures de longs fils de discussion et renforcent les assertions d’identité Blossom. Les notes couvrant l’ensemble du dépôt recensent séparément l’association des identités du relay, la livraison des mentions au compagnon, les URL de notifications push configurables, la suppression administrative atomique et les noms contextuels sur mobile. Une version pour ordinateur établit la distribution des composants pour ordinateur et des composants communs ; elle ne prouve pas que ces modifications mobiles ont été livrées dans une version mobile.

Le contrôle NIP-FI sur WebSocket de Buzz vérifie une assertion d’identité fédérée avant d’accepter les trames, puis exige que sa clé Nostr corresponde à la clé authentifiée par NIP-42, qui prouve l’identité d’un client auprès d’un relay. Une session expire à la première des échéances suivantes : expiration du jeton, âge maximal de l’assertion et durée de vie configurée de la connexion ; après expiration, elle n’admet aucun nouvel effet. Ce mode NIP-FI propre au projet est désactivé par défaut. Les opérations de validation audio et de mise en place d’abonnements déjà admises peuvent encore attendre une dépendance bloquée ; la modification n’établit donc pas de délai de déconnexion universellement borné.

La préparation à la suppression par le propriétaire fait passer les requêtes attestées par l’opérateur par une approbation automatique liée à l’inventaire, avant de les transmettre à l’exécuteur de suppression existant. Un complément côté relay fait en sorte qu’une nouvelle tentative de la même requête renvoie son état actuel et réserve le quota actif du propriétaire jusqu’à la fin de la suppression ; les marqueurs de suppression d’hôte conservés définitivement comptent dans une limite de 20 communautés sur toute la durée de vie. Il s’agit de modifications administratives au niveau du code source, et le complément demande aux opérateurs de laisser la suppression désactivée tant que son relay et son exécuteur de vidage ne sont pas en service. Séparément, un audit du catalogue des partitions détecte les partitions fourre-tout et les mois non couverts avant de créer de nouvelles partitions d’events et de journaux de livraison, rendant visibles aux opérateurs la sûreté du service et la fraîcheur de l’audit.

Buzz mobile distingue désormais les personnes et les agents qui partagent un même nom d’affichage. Son résolveur de noms d’identité précise les agents par leur propriétaire et n’ajoute un court suffixe de clé que si nécessaire ; l’intégration aux conversations utilise ces noms pour les auteurs, les mentions et les avis d’appartenance. Les listes, la recherche et Pulse complètent ce même comportement en dehors d’une conversation. La précision visible modifie le libellé local, tandis qu’une mention sélectionnée conserve le nom original de l’identité transmis sur le réseau.

Conduit fait progresser le processus de commande après l’acceptation par un relay

Conduit est une place de marché Nostr qui envoie des messages de commande privés aux commerçants. La publication progressive sur les relays distingue le premier accusé de réception positif d’un relay de l’achèvement de toutes les tentatives auprès des relays, et un complément au processus de commande enregistre durablement ce premier accusé de réception avant de poursuivre. L’acceptation par un relay signifie que la commande signée est parvenue à un relay ; elle ne prouve pas qu’un commerçant l’a lue ou exécutée.

Conduit a également intégré des sessions récupérables avec un signataire distant et une négociation transactionnelle entre signataire et relay. NIP-46 permet à une application de demander des signatures à partir d’une clé détenue par un signataire distinct ; ces modifications conservent l’espace de travail du compte de l’utilisateur pendant la réparation de son transport, puis vérifient le compte exact avant de reprendre. Les PR établissent le comportement du code source, et non la livraison d’une version du processus de commande.

L’intégration de la recherche de produits classée de Conduit envoie une seule requête ordinaire de recherche en texte intégral NIP-50 pour les produits de kind 30402 et préserve l’ordre de pertinence du relay lors des vérifications de signature, de la réconciliation des révisions et du filtrage local d’éligibilité. Les fiches peuvent apparaître avant la fin des lectures en arrière-plan ciblant les produits exacts, tandis que les suppressions signées plus récentes continuent de faire autorité. Les actions Actualiser et Réessayer restent limitées à la recherche et aux lectures ciblant les produits exacts, au lieu de lancer une exploration étendue du catalogue. Une limite de 100 résultats suivie d’un filtrage local peut manquer des correspondances éligibles ; une réponse partielle vide propose donc une possibilité de récupération et ne prouve pas l’absence de produits.

Elisym construit un processus de commande commerciale sur Nostr

Elisym développe une boîte à outils commerciale qui signe les produits et transporte des messages privés de commande et de reçu sur Nostr. Son paquet commercial intégré définit la vérification des offres et des events de commande encapsulés par gift wrap ; une interface de commande gère l’examen de l’offre, le paiement par portefeuille et le statut de livraison, tandis qu’un nœud commerçant auto-hébergé regroupe les composants côté boutique. Le projet qualifie le kind 30490 de provisoire et décrit un périmètre minimal pour octobre. Ces intégrations dans le code source établissent une intégration émergente ; aucune norme commerciale Nostr acceptée ni aucun lancement public complet n’ont été démontrés.

Les outils de commande pour agents d’Elisym ajoutent buy_product et get_order pour ses produits annoncés sur Nostr. Le premier appel renvoie un devis sans passer commande, et un second appel accepte le devis à usage unique et les avertissements pour le même agent et le même réseau ; l’état de la commande est conservé durablement dans le backend local de fichiers de l’agent. La prise en charge du paiement avec Tempo ajoute un parcours de paiement par portefeuille de navigateur avec vérification du commerçant et livraison. Un hash de transaction envoyée maintient la tentative active jusqu’à ce que son issue soit établie, évitant un résultat indiquant un impayé alors qu’une transaction diffusée pourrait encore être réglée.

Un correctif ultérieur du processus de commande permet au processus de commande de produits signés de s’initialiser lorsqu’un portefeuille de navigateur se signale immédiatement pendant la découverte. La modification du code source place la déclaration de session avant que cette fonction de rappel puisse s’exécuter ; la seule intégration ne vérifie pas un déploiement hébergé.

nostter améliore les vérifications du signataire et la récupération des events

nostter est un client social Nostr. Sa modification intégrée des capacités du signataire vérifie si un signataire utilisable est présent avant de proposer les actions de suivi et de réaction. Les nouveaux tags d’épinglage contiennent la clé de l’auteur et une indication de relay connu sans en deviner un, et l’ordonnancement du cache des events remplaçables suit les règles de NIP-01 concernant l’horodatage et le départage par identifiant d’event. NIP-01 définit les règles fondamentales des events Nostr, notamment la manière dont les clients choisissent entre des events remplaçables.

Pensieve prépare une réconciliation isolée des archives

Pensieve est un outil d’archivage et de récupération Nostr. Son environnement d’exécution negentropy isolé intégré fournit à la synchronisation un worker borné et un comportement d’achèvement durable. La fonctionnalité nécessite une activation volontaire et la PR précise explicitement qu’aucun service ni aucune configuration de production n’ont été activés ; il s’agit de bases pour un parcours de récupération plus sûr, et non d’une preuve de déploiement en fonctionnement.

ContextVM évite les appels en double entre relays

Le SDK TypeScript de ContextVM transporte les requêtes d’outils et de ressources sous forme d’events Nostr. Son correctif intégré de déduplication des requêtes entrantes reconnaît une même requête en texte clair par son identifiant d’event, même lorsque plusieurs relays ou une reconnexion la livrent à nouveau, conformément au traitement existant des messages encapsulés. La PR signale qu’avant le correctif, un outil non idempotent s’exécutait trois fois pour un seul appel. Une modification complémentaire des notifications de ressources n’envoie les mises à jour qu’aux clients abonnés ; les sessions initialisées sans abonnement ne les reçoivent plus.

Cyberspace révise les règles des objets DECK-0003

Cyberspace développe le format DECK-0003 pour les objets Nostr structurés et les sacs de région chiffrés, dont Amethyst a commencé l’implémentation dans le numéro de la semaine dernière. De nouvelles règles pour les parties et les objets cachés et références de sacs permettent à un sac de référencer un objet publié séparément plutôt que d’incorporer chaque partie. Une correction ultérieure précise qu’une référence par identifiant d’event ne peut pas figer de manière fiable une ancienne version d’un event adressable, car un relay peut la supprimer après son remplacement. Les lecteurs doivent utiliser la règle corrigée de référence par coordonnées ; la formulation de la fusion précédente a été remplacée.

Wisp corrige les réponses aux commentaires Nostr

Wisp est un client Nostr doté de fonctions de routage vers les relays et de portefeuille. Après la prise en charge des commentaires NIP-22 publiée la semaine dernière, un correctif complémentaire fusionné fait d’une réponse à un commentaire NIP-22 un event de commentaire lui aussi, avec les références appropriées au parent et à la racine ; le traitement précédent publiait toujours une note ordinaire. NIP-22 permet de rattacher des commentaires à de nombreux types de contenu Nostr. Le correctif a été fusionné après le tag 1.2.5 de Wisp, dont les notes se limitent à une mise à jour du numéro de version : il s’agit donc d’une avancée dans le code source dont la publication reste non vérifiée.

Cordn transmet les emplacements des coordinateurs à un second appareil

Cordn coordonne la messagerie de groupe chiffrée sur Nostr. Sa modification fusionnée de la spécification multiappareil inclut les indications de relay du coordinateur d’un groupe dans le document de groupe répliqué. Un appareil nouvellement initialisé peut alors trouver un coordinateur absent des relay par défaut, plutôt que de sembler rejoindre un groupe dont il ne peut récupérer ni l’historique ni les messages en direct. Il s’agit d’un travail sur la documentation du protocole qui fait suite à la publication de la file d’attente hors ligne de Cordn la semaine dernière, et non d’une nouvelle version du client.

Nostr Atlas ouvre un annuaire d’identités vérifiables

Nostr Atlas est un nouvel annuaire qui présente des profils Nostr accompagnés de revendications de comptes externes. Sa publication du site fusionnée sépare l’annuaire de la démonstration des composants du projet, et le site est accessible publiquement. Une fusion du parcours de revendication permet au propriétaire d’un compte X de publier une preuve signée NIP-39 avec un outil de signature dans le navigateur, tandis que l’enrichissement des profils ne lit les métadonnées Nostr kind-0 qu’une fois la preuve vérifiée. NIP-39 définit le modèle de preuve permettant d’associer une clé Nostr à une autre identité en ligne ; un simple accusé de réception d’un relay ne suffit pas à marquer une revendication comme vérifiée.

nostr-java ajoute des outils d’hébergement de médias et préserve les positions des tags

nostr-java est une bibliothèque Java et un ensemble d’outils MCP pour les applications Nostr. Ses outils Blossom fusionnés permettent à un appelant de téléverser, rechercher, lister et supprimer des médias adressés par leur empreinte de hachage, ainsi que de gérer la liste de serveurs de l’utilisateur. Un correctif de publication distinct conserve les valeurs de tag vides à leur place : les tags Nostr sont positionnels, de sorte que supprimer une indication de relay vide pourrait décaler un marqueur dans le mauvais champ et rendre l’event publié différent de l’aperçu approuvé.

Zap Cooking modifie la façon de récupérer l’historique d’un compte

Zap Cooking est un client Nostr de partage de recettes. Ses travaux fusionnés sur la récupération Lazarus remplacent une sauvegarde fondée sur les events de données propres aux applications NIP-78 par une approche qui analyse les versions d’events remplaçables conservées par les relays pour détecter les abonnements, les mises en sourdine ou les profils écrasés. Lazarus reste un projet de protocole ; la récupération dépend des relay qui ont conservé les anciennes versions, et une PR fusionnée du client web ne garantit pas que chaque event perdu puisse être récupéré.

Le client a également fusionné des options facultatives de preuve de travail NIP-13 pour les notes et les réponses, ainsi qu’un modèle de pièces jointes qui maintient la cohérence de l’ordre des médias et des descriptions NIP-92 entre l’aperçu et la publication. NIP-13 permet à un expéditeur de consacrer du calcul local à un event avant de le publier ; NIP-92 transporte les métadonnées des médias sous forme de tags d’event.

Le correctif de revendication NIP-05 de Zap Cooking exige une autorisation NIP-98 portant sur le corps exact de la requête et rejette un signataire différent de la clé publique qui revendique le nom. Auparavant, ce point de terminaison public acceptait des revendications non authentifiées susceptibles de remplacer le nom d’un autre membre. Le niveau d’adhésion provient désormais de l’enregistrement d’adhésion existant, et les utilisateurs d’un outil de signature à distance reçoivent une demande de signature lors de la revendication. Le parcours d’inscription distinct et de confiance côté serveur reste inchangé.

Une réparation de la liste de mise en sourdine empêche les actions de mise en sourdine de profils de remplacer toute la liste kind 10000 par les seuls tags de clés publiques. Le traitement précédent effaçait les entrées de mots, de hashtags et de fils de discussion ainsi que le contenu chiffré, et une interface pouvait republier publiquement des clés privées de mise en sourdine déchiffrées. Le nouveau traitement lit la copie du relay, préserve les tags sans rapport avec l’action et le texte chiffré, et refuse de publier lorsque cette lecture est impossible. Supprimer une mise en sourdine privée nécessite un déchiffrement et un nouveau chiffrement par l’outil de signature.

Opal apporte la signature à distance à Omarchy

Opal est un outil de signature Nostr de bureau conçu pour l’environnement Linux Omarchy. Sa version 0.3.3 du 28 septembre fait suite à la première série de versions publiques avec la prise en charge de la signature à distance NIP-46, un trousseau de clés local et une interface d’autorisations pour les requêtes des applications connectées. NIP-46 conserve la clé du compte auprès de l’outil de signature tandis qu’un client distinct lui demande d’approuver des opérations. Il s’agit d’une première version d’un outil de signature propre à une plateforme, et non d’une affirmation de prise en charge plus large des environnements de bureau.

WatchTower ouvre un panneau de contrôle de relay NIP-86

WatchTower est un panneau récemment publié pour l’administration des relay via NIP-86, le protocole de requêtes authentifiées de gestion des relay. Une instance publique est accessible, offrant aux opérateurs un endroit où examiner l’interface. Le dépôt a été créé le 22 septembre ; un site accessible ne démontre ni que ses parcours d’autorisation ont fait l’objet d’un audit indépendant, ni qu’il fonctionne avec toutes les implémentations de relay.

Hubstr Blossom ouvre un serveur d’origine personnel pour les médias

Le serveur Hubstr Blossom, récemment publié, permet à un client Nostr de téléverser des images, des vidéos et des fichiers vers un point de terminaison Blossom auto-hébergé, puis d’insérer ces URL dans des events. Son README documente le stockage local par empreinte de hachage du contenu, un index SQLite, une autorisation signée kind-24242 pour les modifications, ainsi qu’un ensemble d’opérations Blossom pour le téléversement, la mise en miroir, le listage et la suppression. Les lectures publiques permettent à d’autres clients d’afficher les médias publiés sans recevoir de droits de téléversement.

Les options documentées du serveur extraient également les métadonnées des fichiers pour les events NIP-94, qui décrivent les médias partagés. Le serveur peut réencoder les images sans métadonnées EXIF et protège par défaut les requêtes de mise en miroir contre les cibles situées sur des réseaux privés. Il s’agit d’une implémentation récemment publiée avec des instructions de déploiement, et non d’une preuve de déploiement à grande échelle en production.

Hubstr Relay a publié son code source initial le 24 septembre. Il associe un cache personnel d’events SQLite à un relay public : les lecteurs non authentifiés voient les events publics autorisés, tandis que les utilisateurs hébergés authentifiés par NIP-42 peuvent lire leur cache. Les enveloppes cadeaux NIP-17 restent inaccessibles aux lecteurs invités. Sa mise à jour du 25 septembre corrige les enregistrements renvoyés par les méthodes de liste de pubkey de NIP-86.

Meshstr expérimente un maillage de relay sans autorisation préalable

Meshstr est une conception en phase alpha permettant aux relays Nostr de négocier des budgets entre pairs et d’échanger des reçus d’utilisation signés. Sa première implémentation comprend une passerelle de politique d’écriture pour strfry, un relay Nostr, ajoutée le 27 septembre, avec un correctif de socket le lendemain. Le dépôt décrit la négociation DIDComm et la réconciliation NIP-77, qui permet aux pairs de comparer des ensembles d’events sans échanger leurs inventaires complets, ainsi que des rapports vérifiables sur les pairs qui dépassent les budgets convenus.

Ces règles du projet constituent une proposition, et non un NIP adopté ou un réseau public de relay dont le fonctionnement aurait été démontré. L’avancée concrète de cette semaine est la publication du code reliant la politique d’écriture d’un relay à la comptabilisation proposée pour le maillage.

Dossier montre ce qu’un historique Nostr public peut révéler

Dossier est un nouvel outil d’auto-audit exécuté dans le navigateur pour examiner l’empreinte Nostr et Lightning d’une personne, avec une démo publique. Il rassemble les liens de profil visibles, les traces de zap, les horaires de publication, les métadonnées d’anciens messages directs chiffrés NIP-04 et les métadonnées des médias, comme les données EXIF des photos ; il peut aussi montrer où un relay sert encore un event que quelqu’un a tenté de supprimer. La prise en charge des outils de signature NIP-07 permet à un utilisateur d’autoriser des opérations de nettoyage sans coller de clé privée dans la page.

Les limites documentées du projet sont importantes : une analyse ne voit que les relays qu’elle atteint, et une demande de suppression ne peut pas effacer les copies conservées ailleurs. Le dépôt est apparu le 27 septembre et ne comporte aucune version étiquetée ; la démo et le code source attestent d’un outil à ses débuts, pas d’un inventaire complet de l’activité passée de quiconque.

Marmot MDK étend les sondages, les émojis personnalisés et les métadonnées de compte

Marmot MDK fournit l’environnement d’exécution et les interfaces de liaison pour la messagerie de groupe chiffrée sur Nostr. Des fusions ultérieures dans le code source de MDK exposent les choix de sondage paginés par votant, en appliquant les mêmes règles de réponse effective que les décomptes agrégés. Des composants de groupe facultatifs appartenant à l’application donnent aux applications hôtes des paramètres contrôlés par les administrateurs, qui subsistent après l’application des règles de rétention des messages et sont transmis aux nouveaux arrivants dans leur message Welcome. Les envois avec tag et réactions à des médias transmettent les métadonnées des émojis personnalisés à travers l’environnement d’exécution et les interfaces de liaison, conservent les éléments de déchiffrement des images jointes aux réactions après un changement d’époque et rejettent les tags de pièce jointe falsifiés. Ce changement élargit la structure C de demande de téléversement ; les programmes qui l’utilisent en C doivent donc être recompilés avec le nouvel en-tête.

Une correction de convergence maintient les messages en attente lorsqu’aucune branche canonique n’a été sélectionnée, au lieu de les invalider sans essayer l’état actif. Un nettoyage des chemins inaccessibles qui l’accompagne oriente les commits préparés non résolus vers le mécanisme conservé de nouvelle tentative. Les lectures de médias chiffrés alignent le délai d’expiration de lecture HTTP sur la gestion de l’inactivité du corps de réponse reprenable, pour traiter les blocages de transferts volumineux sans affirmer que le test d’acceptation sur appareil de l’APK entrant, encore en attente, a réussi. Des marqueurs des étapes de démarrage indiquent à quelle étape de l’ouverture du compte le délai a expiré, ajoutant des éléments de diagnostic sans affirmer que le blocage sous-jacent au démarrage est résolu.

Le connecteur d’agent local fusionne aussi les métadonnées de profil existantes lors de la publication d’une mise à jour kind 0, en préservant les champs omis dans la requête. Les mises à jour du profil de groupe exposent les modifications du nom et de la description d’un groupe par la voie existante autorisée par l’administrateur actuel. Son authentification par socket donne toujours accès à l’ensemble de l’API locale ; cette fusion n’ajoute pas d’attributions de capacités par entité. Ces modifications du code source font suite à la version étiquetée 0.11.0.

rust-nostr corrèle les réponses de comptage des relays

rust-nostr, une bibliothèque Rust et un SDK pour les applications Nostr, a intégré les réponses COUNT corrélées et des erreurs plus claires pour les mécanismes d’attente. Le SDK s’abonne avant d’envoyer COUNT et n’accepte que la réponse correspondante, empêchant qu’un récepteur perdu ou fermé ne soit interprété comme un zéro légitime. Il préserve aussi les erreurs du récepteur pour les accusés de réception de publication et l’authentification auprès des relays, afin que les appelants puissent distinguer une confirmation manquante d’un rejet explicite. Les signatures des méthodes publiques restent inchangées.

ZapTracker ajoute des indicateurs sur le réseau Nostr et les citations

ZapTracker est un tableau de bord destiné aux créateurs pour suivre l’engagement sur Nostr et l’activité de leur portefeuille. Une fusion concernant le tableau de bord réseau remplace les statistiques du réseau Lightning par des données sur les relays Nostr en ligne provenant de nostr.watch et des informations sur leurs capacités issues des documents NIP-11. Une modification des indicateurs de citation compte les events kind 1 portant des tags q, aux côtés des mentions J’aime, des republications, des signets et des zaps. Cela permet aux créateurs de voir les citations dans les classements de contenu et les graphiques d’engagement ; les éléments attestés restent ceux du code source fusionné.

LaWallet NWC achemine les rechargements de carte vers le portefeuille de la carte

LaWallet NWC connecte les portefeuilles Lightning aux applications via Nostr Wallet Connect. Sa fusion pour le rechargement des BoltCard annonce un lien de paiement LUD-19 qui crée une facture par la méthode NWC make_invoice du portefeuille de la carte. Les cartes bloquées, désactivées ou non appairées n’annoncent pas de lien de paiement, et ce parcours ne redirige pas les rechargements vers l’adresse Lightning distincte du propriétaire. Une modification ultérieure expose le même lien dans l’émulateur et transmet, lors des envois LNURL, les notes du payeur acceptées par le destinataire.

Un nouveau relay khatru expose des commandes de modération pour le propriétaire

nostr-relay-khatru a publié son code source initial le 29 septembre en tant que relay généraliste dérivé de l’implémentation spécifique à HiveScope, désormais abandonnée. L’instance publique sert un document NIP-11 qui désigne ce dépôt et annonce l’authentification, l’expiration des events, les events protégés, le comptage, la réconciliation et l’administration du relay. Une implémentation du 30 septembre ajoute des commandes de modération au panneau du propriétaire. Les métadonnées publiques attestent d’un point d’accès déployé, pas de tests réussis de toutes les méthodes annoncées.

Un outil local de construction d’un réseau de confiance suit les désabonnements

etemiz/wot a publié un robot d’exploration du réseau de confiance Nostr le 30 septembre. Il lit les listes d’abonnements et les listes de relays NIP-65, calcule la confiance à partir de racines configurables et écrit les scores dans LMDB pour les politiques de relay, les fils et les filtres antispam. La documentation du projet explique le compromis : les mises à jour en direct augmentent la confiance, tandis que les explorations complètes planifiées appliquent les baisses et les désabonnements. Les scores dépendent des racines choisies. Il s’agit de code source nouvellement publié, sans version étiquetée ni affirmation d’un déploiement en production.

Moyu ouvre le code d’un client d’espace de travail Marmot

Moyu a publié le code source d’un client de discussion pour espace de travail écrit en Rust et construit sur Marmot, avec des interfaces en ligne de commande, en terminal et de bureau. Ses modifications du 30 septembre utilisent les changements d’adhésion enregistrés localement pour empêcher d’anciennes demandes d’adhésion de réadmettre des membres exclus, font expirer les codes d’invitation au bout de sept jours et permettent aux administrateurs de les révoquer. La sortie du terminal filtre les caractères de contrôle et les remplacements du sens du texte fournis par d’autres membres. Un fork de MDK fixé à une révision précise fait passer les transferts de pièces jointes Blossom par le proxy SOCKS5 configuré, la résolution des noms d’hôte étant effectuée par ce proxy. Les modifications de la version 0.3.0 figurent dans le code source public ; aucune étiquette de version publique ni entrée de publication n’est encore disponible.

Travaux sur les protocoles et les spécifications

NIP-39 étend les preuves d’identité à Bluesky et Discord

NIP-39 permet à un compte Nostr de pointer vers une preuve qu’il contrôle une identité sur une autre plateforme. Une modification fusionnée le 27 septembre fournit une phrase recommandée pour les nouvelles preuves et indique aux vérificateurs d’accepter les anciennes preuves qui contiennent le npub du compte, même lorsque leur formulation diffère. Elle documente également les publications Bluesky et les messages Discord comme emplacements de preuve. Une affirmation concernant Discord ne peut être vérifiée que par une personne capable de lire le serveur où son message a été publié.

NIP-86 ajoute la gestion des codes d’invitation pour les administrateurs de relays

Compass a décrit dans le numéro du 8 juillet la proposition d’invitations NIP-86 alors qu’elle était encore ouverte ; elle a maintenant été fusionnée. NIP-86 définit une API standard de gestion des relays, et NIP-43 définit comment les relays à accès restreint annoncent l’adhésion et traitent les demandes d’admission. La fusion du 24 septembre ajoute listclaims, createclaim et deleteclaim afin qu’un administrateur puisse lister, émettre et révoquer les codes d’invitation acceptés par un relay. Cela donne aux opérateurs un moyen de gérer les invitations qui peuvent attribuer un rôle à un membre après son adhésion ; cela n’impose pas à tous les relays de prendre en charge ces méthodes.

Une correction à la présentation de NIP-86 de la semaine dernière : la spécification fusionnée a ajouté unallowevent, unbanevent, listallowedevents et listdisallowedkinds. L’article précédent énumérait des noms tirés d’une description obsolète de la proposition. Les deux premières méthodes annulent une décision d’autorisation ou d’interdiction au niveau d’un event ; les autres permettent d’examiner les events autorisés et les kinds interdits.

NIP-51 déplace les ensembles d’abonnements favoris vers un kind d’event inutilisé

NIP-51 définit des listes publiques et privées, notamment une liste des ensembles d’abonnements favoris d’un utilisateur. Compass a décrit la proposition relative à la collision de kind dans le numéro du 22 juillet ; elle a maintenant été fusionnée. La correction du 27 septembre attribue à cette liste de favoris le kind 10021, car le numéro précédent était déjà utilisé. Ses tags a pointent toujours vers des ensembles d’abonnements kind 30000. Le changement résout une collision de numéros dans la spécification ; il ne crée pas de nouvelle manière de suivre des personnes.

NIP-51 propose des réponses masquées pour chaque fil

Une proposition NIP-51 ouverte permettrait à l’auteur d’un fil de publier un ensemble public de réponses masquées que les clients participants afficheraient derrière un bouton de bascule. Elle utilise un event adressable de kind-30027 par fil, avec l’identifiant de la racine comme tag d et des tags e désignant les réponses ; seul un ensemble signé par l’auteur de la racine s’applique. Inclure la racine dans la liste demande aux clients de masquer les réponses des autres auteurs et de ne plus proposer de champ de rédaction de réponse, tandis que des réponses peuvent toujours être publiées sur les relays. Le format par fil limite les conflits de modification à une même conversation. L’auteur signale une implémentation dans Nostrich, mais l’examen des sources publiques ne l’a pas établie ; la proposition n’a toujours pas été fusionnée et le format de son ensemble reste en discussion.

NIP-DB propose des noms de domaine vérifiés pour les services adressés par clé

La proposition NIP-DB ouverte, soumise le 28 septembre, décrit des events Nostr qui lient un domaine Internet ordinaire à la clé qui le dessert sur un réseau adressé par clé tel que FIPS, un réseau maillé chiffré qui adresse les nœuds par leur clé publique Nostr. Un propriétaire de domaine peut établir cette liaison avec un enregistrement DNS TXT ou une preuve DNSSEC jointe à la déclaration ; les clients conserveraient un résultat vérifié pour une utilisation ultérieure hors ligne. La proposition interdit explicitement la résolution à partir d’une déclaration non vérifiée, puisque n’importe qui peut revendiquer le domaine d’autrui dans un event Nostr. fips-pub-domains est l’implémentation de référence de l’auteur, mais les numéros de kind d’event et certaines formulations propres aux réseaux superposés sont encore en cours d’examen. Les tests de bout en bout rapportés constituent les éléments de preuve de l’auteur, et non une affirmation selon laquelle la proposition est un NIP accepté.

Un brouillon de flux privé explore des groupes chiffrés de destinataires

Une nouvelle proposition d’enveloppe à destinataires multiples, ouverte le 29 septembre, esquisse des notes, des réponses et des connexions privées dont les destinataires prévus peuvent trouver un event sans exposer leurs clés publiques habituelles dans ses tags visibles. Elle propose des tags d’alias opaques par paire, dérivés de secrets partagés, et des kinds d’event provisoires, notamment un moyen d’envelopper un autre event Nostr pour des centaines de lecteurs. Cela pourrait offrir aux petits flux privés un moyen de récupération plus direct que l’envoi d’un message distinct à chaque membre.

L’auteur de la proposition la décrit explicitement comme un travail en cours. Le brouillon ne dispose d’aucune implémentation démontrée ni d’aucun examen de sécurité, et ses attributions de kind ainsi que ses règles de signature au niveau des octets restent ouvertes.

Une proposition Blossom permet à d’autres personnes d’annoncer des médias répliqués

Une proposition NIP ouverte décrit un moyen pour une personne qui réplique un blob Blossom d’un autre auteur d’annoncer cette copie via Nostr. Un client pourrait alors chercher cette copie si le serveur d’origine perd le blob. La discussion a également évoqué la vérification de la liste actuelle des serveurs BUD-03 de la personne qui héberge la copie lorsqu’une indication de serveur annoncée n’est plus à jour. Il s’agit d’un mécanisme de découverte proposé, et non d’une garantie que les clients ou les relays d’archivage fournissent déjà un stockage de secours.

Les signalements d’incidents routiers cherchent un format Nostr commun

La proposition Road Event Reports ouverte décrit des signalements et des confirmations concernant les nids-de-poule, les fermetures, les caméras et d’autres conditions routières. Elle utilise des tags de localisation et l’horodatage d’expiration de NIP-40, qui indique aux relays quand cesser de diffuser un event, afin qu’un signalement ne soit pas considéré comme actuel indéfiniment. L’auteur a fondé ses révisions sur un échantillon d’events récupérés auprès de relays publics et sur les clients Roadstr existants pour le signalement des conditions routières, mais le brouillon laisse encore ouverte une question d’encodage compact, et le numéro de NIP proposé n’a pas été adopté.

Marmot réexamine la coordination entre plusieurs appareils

La refonte multi-appareils de Marmot remplace un brouillon External Commit non implémenté par une présentation pas à pas non normative destinée à recueillir de premiers retours. La nouvelle orientation explore l’approbation d’un nouvel appareil par un appareil existant, son intégration aux conversations et le retrait ultérieur d’appareils, tout en laissant les questions ouvertes visibles. Les identifiants réservés par le brouillon supprimé sont libérés, car aucune implémentation ne les a adoptés. Le document d’idées n’attribue aucun nouvel identifiant ni aucun nouveau format de transmission et ne constitue pas une fonctionnalité multi-appareils implémentée.

Six années de septembre dans Nostr

Le dernier numéro de septembre est l’occasion de retracer comment Nostr est passé d’esquisses à un ensemble plus vaste d’outils interopérables. Un prototype de mise en relation pour des trajets en 2021 utilisait des events signés pour coordonner un service ; cinq ans plus tard, la formulation des preuves d’identité et les collisions de kinds de listes font partie des détails que les responsables de maintenance règlent. Entre-temps, les clients ont appris à présenter les conversations, les médias et la récupération d’une manière accessible au grand public. Les sources datées ci-dessous montrent des étapes de cette progression. Elles n’établissent pas que chaque expérimentation a été lancée ni que chaque ancienne conception reste recommandée.

Septembre 2021 : premières expérimentations aux formes utiles

Un commit BUber du 4 septembre explorait un concept de mise en relation pour des taxis à l’aide d’events Nostr. Il montrait comment une demande signée, transmise par un relay, pouvait coordonner des personnes sans confier l’ensemble du service à un seul serveur. La source présente un concept et n’établit pas le lancement d’un service de transport.

Plus tard dans le mois, le code source de Loquaz du 23 septembre proposait un prototype de messagerie pour ordinateur. C’était une autre tentative précoce de donner aux messages des relays l’apparence d’une application ordinaire. La source n’établit ni un chiffrement de bout en bout abouti ni une messagerie de production ; le fil conducteur durable est la recherche d’une interface de conversation utilisable reposant sur des events simples. BUber testait la mise en relation pour des trajets, et Loquaz testait la messagerie ; tous deux utilisaient des events signés avant que les modèles communs aux clients ne se stabilisent. Ces essais ont mis en évidence deux problèmes récurrents pour les clients ultérieurs : la coordination par les relays et la présentation des events sous la forme d’une conversation utilisable.

Septembre 2022 : la messagerie et les actions déléguées entrent dans les spécifications

La modification de NIP-28 du 10 septembre décrivait des canaux de discussion publics avec des messages et des métadonnées que les clients pouvaient interpréter ensemble. NIP-28 a fait du salon partagé un objet explicite du protocole et a donné aux clients une convention commune pour les canaux.

Le 23 septembre, le texte de NIP-26 sur la signature déléguée documentait un moyen pour une clé d’en autoriser une autre à signer des events dans un périmètre limité. Il rendait compte d’une question de conception importante en 2022 : comment utiliser une identité Nostr sans confier la clé principale à chaque application. NIP-26 est désormais indiqué comme non recommandé, il s’agit donc de la trace d’une expérimentation, et non d’un conseil pour de nouvelles intégrations. Son statut ultérieur montre comment le modèle de signature a évolué : une spécification peut conserver un énoncé utile du problème même lorsque la réponse proposée est abandonnée.

Septembre 2023 : les clients gagnent en maturité autour de la découverte des relays et des métadonnées

Damus est un client social Nostr. Son journal des modifications du 21 septembre consignait des travaux sur sa base de données Nostr locale, la recherche et la navigation par hashtag. Ces modifications ont facilité la consultation d’un flux social très actif et sa récupération sur un téléphone ; le journal daté atteste cette version du client, et non toutes les capacités ultérieures de Damus.

Les détails du protocole évoluaient eux aussi. Une modification du 26 septembre de NIP-24 clarifiait les champs facultatifs des métadonnées de profil, tandis que la modification de NIP-65 du 29 septembre traitait de la normalisation et de la déduplication des URI de relays. NIP-65 indique aux clients comment publier les relays qu’ils utilisent pour la lecture et l’écriture ; un traitement cohérent des URI aide ces listes à désigner le même relay même lorsque les chaînes diffèrent de manière sans conséquence. Cette petite convention a fait évoluer la conception des clients vers une découverte fiable : trouver les events d’une personne dépend de la connaissance de leur lieu de publication.

Septembre 2024 : les publications acquièrent un contexte plus riche

Les notes de version de Damus du 22 septembre décrivaient la prise en charge des passages mis en évidence et des commentaires de NIP-84. NIP-84 donne aux lecteurs un moyen de citer et de discuter un passage d’un contenu long. Le travail sur le client montre comment une idée de protocole est devenue quelque chose que les gens pouvaient utiliser pendant leur lecture.

Pendant ce temps, NIP-34 a reçu une modification du 20 septembre précisant les sujets et les étiquettes des tickets pour la collaboration git via Nostr, et NIP-73 a reçu une modification le même jour précisant les identifiants de contenus externes. Il s’agit de modifications distinctes des spécifications : l’une aide les tickets d’un dépôt à conserver leur structure, tandis que l’autre permet à un event de faire référence à du contenu extérieur à Nostr. Toutes deux étendent le sens qu’un client peut préserver lorsque le contenu circule entre communautés, dépôts et autres médias.

Septembre 2025 : les contrôles d’accès et le contexte des paiements se précisent

Une révision de NIP-42 du 6 septembre a porté sur l’authentification multi-utilisateur auprès d’un relay. NIP-42 permet à un relay de demander à un client de prouver quelle clé Nostr effectue une requête ; cette mise à jour était importante pour les services qui prennent en charge plusieurs comptes authentifiés sur une même connexion.

Une mise à jour de NIP-47 du 15 septembre a ajouté des métadonnées de paiement facultatives aux requêtes Nostr Wallet Connect. NIP-47 permet à une application de demander à un portefeuille d’effectuer des actions via Nostr. Un contexte plus riche peut rendre une interaction avec un portefeuille compréhensible, mais les métadonnées peuvent révéler des informations sur le payeur ; les clients et les portefeuilles doivent donc toujours les traiter comme sensibles. Ce changement illustre comment les travaux sur l’interopérabilité incluaient désormais ce qu’un destinataire peut apprendre, et pas seulement la possibilité de transmettre une requête.

Septembre 2026 : les détails de l’interopérabilité rencontrent l’identité publique

Ce mois de septembre, une modification intégrée de NIP-51 a changé le kind de l’event d’ensemble d’abonnements pour éviter une collision. NIP-51 définit des listes qu’une personne peut tenir à jour et partager ; des valeurs de kind uniques pour les events permettent aux clients de distinguer un type de liste d’un autre. Un numéro antérieur de Compass avait abordé la proposition, tandis que son intégration en septembre constitue le changement de statut.

Une deuxième modification intégrée à NIP-39 a clarifié le texte de preuve et ajouté d’autres moyens d’associer un compte externe à une identité Nostr. NIP-39 concerne des déclarations d’identité vérifiables, et non un registre central des identités. Ensemble, ces deux intégrations montrent que les travaux actuels sur le protocole se concentrent sur les petits détails qui déterminent si des clients indépendants interprètent correctement les mêmes events d’identité et de liste. Elles montrent aussi une transition de l’invention de nouvelles catégories d’events vers la réduction de l’ambiguïté dans celles qui existent déjà.

Au fil de ces six mois de septembre, la tendance est une progression allant de la démonstration qu’un event signé peut décrire une requête d’application à la question de savoir comment un client vérifie une déclaration concernant une personne. Les anciens prototypes sont importants parce qu’ils mettent en évidence les questions auxquelles les spécifications et les clients ultérieurs ont dû répondre : qui signe, où trouver un event, ce qu’il signifie et comment savoir s’il est digne de confiance. C’est aussi pourquoi une correction du protocole, même mineure mais précise, peut compter autant qu’une nouvelle interface.