Nostr Compass #39

Bienvenue dans Nostr Compass, votre guide hebdomadaire de Nostr.

Cette semaine : ngit et GitWorkshop font passer les flux git signés sur Nostr et Blossom, nsite-clay rend la publication depuis le navigateur récupérable, et Wingman App réunit navigation, signature locale, authentification et fichiers. Shosho et Livelier connectent les flux auto-hébergés à Nostr, Communitator rend les modèles de relais inspectables avant signature, cal.emre.xyz publie des créneaux de rendez-vous, et Plektos chiffre les événements privés. Des versions étiquetées ajoutent un travail de récupération et de confidentialité dans Vector, Primal Android, LibreNostr et SkateSpots. Le travail de développement couvre le rendu NIP-27, les préférences de relais signées dans Conduit, les cibles de paiement NIP-A3 et les miroirs Blossom. Des modifications fusionnées dans le dépôt NIPs clarifient les abonnements réservés au direct et les données d’application authentifiées. Notre analyse approfondie explique comment les liens NIP-21 et les références NIP-27 transportent les profils et événements Nostr entre les applications.

À la une

Les flux git signés font passer l’intégration continue, les dépôts privés et les versions sur Nostr

Le lancement v3 du 8 septembre réunit ngit, GitWorkshop, ngit-grasp et ngit-ci dans un flux signé unique. ngit transporte branches, correctifs et demandes de fusion sous forme d’événements NIP-34, tandis que GitWorkshop fournit l’interface de révision. Le lancement ajoute ngit-ci 0.1, un service d’intégration continue auto-hébergé dont les instructions et les résultats circulent sous forme d’événements Nostr signés, de sorte que les vérifications peuvent s’exécuter sur du matériel contrôlé par les mainteneurs, parallèlement à la révision du code.

La même version offre à ngit-grasp v3 des dépôts privés grâce à l’extension de dépôts privés GRASP-08 et rend explicite l’autorité des mainteneurs. Les enregistrements de version signés peuvent pointer vers des ressources dans Blossom, gardant les métadonnées de version et les fichiers adressés par contenu en dehors d’une forge hébergée. Le nouveau site de documentation rassemble le client, les dépôts privés, l’intégration continue et les composants web.

nsite-clay rend la publication depuis le navigateur récupérable

Une correction des invites du signataire du 31 août, la récupération de publication et des contrôles d’édition du 2 septembre font de nsite-clay un outil de publication dans le navigateur pour un site d’une seule page. L’utilisateur modifie le modèle objet du document sur place, sérialise le résultat, le téléverse sous forme de blob Blossom adressé par contenu, puis republie le manifeste NIP-5A du site. Aucune compilation locale ni serveur n’est requis.

L’outil de publication dans le navigateur rend désormais une publication échouée récupérable et réduit les invites répétées du signataire, tandis que le guide d’édition documente la boucle. Le résultat reste un site NIP-5A ordinaire pour les passerelles existantes.

Wingman App réunit navigation, signature et fichiers

Le travail de septembre ajoute des sélecteurs de fichiers, la publication de profil, un signataire sûr et la restauration de session et des compilations mobiles testées à Wingman App. Son enveloppe Flutter injecte un fournisseur NIP-07 dans les pages ouvertes au sein de l’application, tandis que Flight Deck et Drive, adossé à Tower, fournissent une surface de travail et un espace de fichiers à côté du navigateur.

Wingman signe les requêtes HTTP authentifiées à l’aide de NIP-98. L’implémentation des requêtes construit l’événement qu’un serveur vérifie avant de répondre, offrant à une identité installée un chemin d’approbation cohérent pour les actions sur les relais, la signature dans les applications web et les fichiers.

Shosho prend en charge les flux auto-hébergés de Livelier

Shosho 1.1.0 est sorti le 1er septembre avec la prise en charge de Livelier, dont la mise à jour d’attribution du 31 août identifie le pont et la source Owncast dans les profils pontés. Livelier surveille le répertoire public d’Owncast, vérifie si un flux vidéo est en direct, puis publie un événement adressable kind:30311 NIP-53. La découverte transite par Nostr tandis que la vidéo reste sur le serveur du diffuseur.

Le chat traverse le pont sous forme d’événements kind:1311. La conception du pont n’ouvre une connexion côté source que lorsqu’un lecteur Nostr y est abonné, étiquette les identités dérivées et envoie le chat éphémère vers un relais qui le supprime au bout de trois heures. Le relais de découverte n’accepte les écritures d’événements en direct que depuis la clé du pont ; le relais de chat utilise l’authentification NIP-42 et les indicateurs d’événements protégés NIP-70.

Communitator rend les modèles de relais inspectables avant signature

La série de lancements du 31 août offre à Communitator des modèles canoniques pour les listes de relais de kind 10002, les serveurs Blossom de kind 10063 et les boîtes de réception de messages privés de kind 10050. Avant qu’un signataire ne se connecte, l’application affiche les points de terminaison normalisés, les permissions de lecture et d’écriture, les kinds d’événements, les relais de publication fixes et les destinations.

Le flux de signature et de publication borné sépare la connexion de l’application. Chaque événement est signé séparément, une exécution utilise au plus quatre connexions WebSocket, et une destination n’est comptabilisée qu’après un OK positif NIP-01. Les résultats distinguent les livraisons complètes, partielles, échouées et annulées. Les modèles partagés restent des recommandations non fiables ; la surface de consentement explique l’observabilité des relais et du réseau.

cal.emre.xyz publie les disponibilités de rendez-vous via NIP-52

Le dépôt public a été ouvert dans un commit initial du 2 septembre, suivi d’une annonce signée du gestionnaire le 3 septembre pour cal.emre.xyz. Un hôte publie ses disponibilités sous forme d’événement kind:31923 NIP-52 ; un invité publie un RSVP kind:31925.

Il lit les événements des hôtes et les RSVP d’occupation acceptés depuis les relais, exclut les plages horaires qui se chevauchent et conserve les événements Nostr comme registre de planification sans les copier dans une base de données distincte. Les hôtes peuvent signer avec NIP-07, NIP-46 ou une clé locale ; les invités peuvent générer une clé séparée. Son dépôt expose également le naddr résultant et les liens de calendrier, l’email étant désactivé par défaut.

Plektos fait des événements privés un canal chiffré unique

L’implémentation des événements privés du 2 septembre fait de chaque rassemblement Plektos un canal privé au sein d’une communauté chiffrée Concord. La liste des invités, la liste des RSVP, le tableau d’inscription, le fil de discussion, les contributions, les images de couverture, les modifications et les suppressions sont chiffrés ensemble ; une invitation ne transporte que la clé de cet événement et aucun événement de calendrier en clair n’est publié.

L’audit du cycle de vie du 6 septembre ancre l’identifiant de définition d’événement pour une recherche directe lorsque plus de 500 enveloppes existent, tout en conservant une solution de repli paginée. Les paquets d’invitation expirent 30 jours après la fin d’un événement et peuvent être désactivés, mais quelqu’un qui a déjà obtenu une clé de canal peut la conserver. Une réparation de sécurité du parseur distincte fait échouer les identifiants NIP-19 type-length-value (TLV) malformés au lieu de piéger le parseur.

Versions étiquetées

Vector 0.4.4 rend la récupération de communauté chiffrée plus sûre

Vector 0.4.4 est sorti le 31 août avec des correctifs de récupération de communauté, de rotation des clés, de modération et de routage des réponses. La refondation ferme une communauté pillée au chemin d’invitation utilisé par les attaquants ; l’appartenance de remplacement supplante l’état local obsolète ; et un membre injoignable ne fige plus la liste des membres. Les rotations vides sont rejetées, les promotions préservent les membres en ligne, et les opérations refusent de s’exécuter lorsque les membres requis ne peuvent pas être joints.

La version persiste également les suppressions et bannissements des modérateurs, rechiffre le livre d’or après un changement de mot de passe, lie les réponses de notification à leur conversation après un redémarrage, et n’utilise que des chemins multijoueurs vérifiés. Il s’agit de contrôles de récupération, et non d’une révocation des clés déjà obtenues.

Primal Android 3.5.27 vérifie l’identité du signataire et du portefeuille

Primal Android 3.5.27 est sorti le 3 septembre après la fusion, le 31 août, de la vérification de l’identité du signataire et de l’authentification des requêtes de portefeuille. La signature locale rejette une requête dont l’identité ne correspond pas au compte détenu, et les requêtes NIP-47 entrantes sont authentifiées avant traitement. Le routage des sondages à zaps envoie également les votes à l’auteur du sondage lorsque celui-ci apparaît dans une réponse.

GRAIN 0.8.0-rc2 corrige un chemin de type « acquitté mais non stocké »

GRAIN 0.8.0-rc2 est sorti le 7 septembre après qu’une défaillance de stockage a permis l’émission d’un OK avant que son moteur d’écriture asynchrone de base de données LMDB ne remarque que la capacité de stockage était pleine. Le relais avertit désormais à 80 et 95 pour cent, refuse les nouveaux événements à 97 pour cent tout en laissant de la place pour les suppressions, et signale les défaillances d’écriture survenant après l’acceptation. La rétention parcourt les événements du plus ancien au plus récent, la fermeture gère les messages tardifs, et les filtres invalides n’écartent plus leurs homologues valides.

La version prend également en charge les annonces de moniteurs de kind 10166 et les rapports de relais de kind 30166, expulse les rapports obsolètes, conserve les relais configurés comme solution de repli, et rapporte les limites en vigueur et l’authentification dans NIP-11 au lieu de zéros statiques.

LibreNostr 0.5.0–0.5.2 fait échouer le routage Tor en mode sécurisé

LibreNostr 0.5.0 est sorti le 7 septembre avec un mode Orbot qui fait passer les relais, les zaps, les téléversements, les médias, la lecture et les aperçus par un seul port SOCKS, ainsi qu’une réparation d’un plantage du panneau de zaps. Si Orbot ou le proxy est indisponible, les connexions s’arrêtent au lieu de fuiter vers une route directe. La version 0.5.1 empêche les recherches NIP-50 lentes de retarder les résultats locaux ; la 0.5.2 remplace la mise en page récursive des fils de discussion et répare leur ordonnancement.

Le comportement d’échec sécurisé s’applique à chaque surface réseau répertoriée par la version, et un redémarrage est nécessaire car ces clients ont une longue durée de vie. Les versions correctives préservent ce choix tout en limitant les défaillances sans lien concernant la recherche, la profondeur de pile et la mise en page.

SkateSpots ajoute un chemin de relais embarqué

La version Zapstore signée du 8 septembre ajoute un relais Citrine optionnel à SkateSpots. Les spots, les crews, les messages et les données cartographiques peuvent se charger localement ; les publications sont mises en file d’attente hors ligne ; et le téléphone conserve une copie locale. Les contenus de stash et de messages existants restent chiffrés de bout en bout. Les vérifications de paiement exigent les montants des factures et des reçus de zap émis par le fournisseur avant d’accorder l’accès ou de comptabiliser les contributions.

Le relais local est une option de stockage et de continuité, et non un remplacement de chaque relais distant. Il permet à un skateur de continuer à travailler pendant une période de déconnexion, puis de réconcilier plus tard l’activité signée, tandis que les changements de paiement empêchent un reçu auto-rédigé de devenir une preuve de règlement.

Whistle 1.8.15 répare la récupération du cycle de vie des groupes chiffrés

Whistle 1.8.15 est sorti le 3 septembre après qu’une réparation du cycle de vie Android a empêché les détenteurs d’état au niveau des routes de détruire les abonnements aux relais et les mises à jour de localisation à l’échelle de l’application. Ses notes de version décrivent également un état de connexion rafraîchi après un verrouillage ou une mise en veille, ainsi qu’un arriéré de 501 événements récupéré dans le cas observé.

Le bogue liait la propriété d’un service à longue durée de vie à un écran à courte durée de vie. Garder en vie l’instance à portée d’activité et vérifier le socket avant une lecture ponctuelle rend la navigation Android ordinaire et la suspension en arrière-plan moins susceptibles de ressembler à un groupe vide.

TWENTY ONE Companion 1.12.0 sépare les DM chiffrés du chat historique

TWENTY ONE Companion 1.12.0 est sorti le 5 septembre avec les DM emballés-cadeau de NIP-17. La boîte de réception chiffrée est séparée de l’ancien chat d’espaces, qui reste distinct car ces messages n’ont jamais été chiffrés et ne peuvent pas être migrés. Les PDF et les vidéos sont pris en charge sous réserve de la politique des relais, et les masquages personnels se synchronisent sans devenir des bannissements de modérateur.

La séparation visible fait partie du modèle de sécurité. Qualifier l’ancien historique de boîte de réception sécurisée dénaturerait sa provenance, tandis qu’une migration silencieuse suggérerait un chiffrement qui n’existait pas au moment de son écriture.

ZapStore 1.1.2 valide les identifiants d’événements et la rotation des certificats

ZapStore 1.1.2 est sorti le 4 septembre avec la validation des identifiants d’événements NIP-01 : le client recalcule l’id d’un événement entrant et rejette les non-concordances avant de l’utiliser. La version identifie également les paquets installés en dehors de ZapStore. Côté serveur, la rétention des empreintes de certificats préserve les balises apk_certificate_hash répétées afin que la rotation des clés de signature Android puisse conserver une lignée approuvée.

La vérification de l’identifiant d’événement empêche un relais ou un cache de modifier les balises ou le contenu tout en conservant l’ancien id. L’indicateur de source d’installation fournit une provenance distincte lorsqu’un paquet Android portant le même identifiant d’application provient d’un autre canal.

Amber 6.6.1 garde les réponses du signataire attribuables

Amber 6.6.1 est sorti le 4 septembre après que l’analyse des permissions a été corrigée pour tolérer un kind optionnel manquant, et que les demandes de signature rejetées ont commencé à renvoyer leur identifiant de demande d’origine. Les applications appelantes peuvent associer un rejet à l’opération soumise. La version met également à jour les valeurs par défaut du signataire distant et ajoute un relais indexeur.

Ensemble, ces corrections préservent l’attribution dans les deux sens : un enregistrement de permission reste utilisable lorsqu’un champ optionnel est absent, et un refus reste lié à la demande qui l’a provoqué. Les changements de relais par défaut affectent la découverte, mais ils ne remplacent pas la décision d’autorisation locale du signataire.

En développement

Zap Cooking affiche les références NIP-27 avec indications de relais

La fusion du 4 septembre permet à Zap Cooking d’afficher les références nostr:npub et nostr:nprofile dans les articles, les recettes, les aperçus de l’éditeur et les vues d’impression. Les identifiants invalides restent du texte, la résolution est non bloquante, et l’éditeur affiche un aperçu du Markdown qui sera signé. Lorsqu’une information de relais existe, un npub seul devient un nprofile avec les relais outbox et une balise p correspondante.

La même semaine a corrigé les lectures du kind 30023 limitées à l’auteur, ajouté des relais de recherche NIP-50 vérifiés avec déduplication et protections contre les requêtes obsolètes, et réparé les appels de portefeuille NIP-47 après que des changements de dépendances ont cassé les soldes et l’historique.

Conduit réconcilie les préférences signées de relais et Blossom

Conduit a fusionné l’édition des préférences Blossom le 2 septembre et la réconciliation des préférences signées le 7 septembre. Market et Merchant conservent la dernière liste de relais kind 10002 valide et la déclaration de boîte de réception kind 10050, préservent une liste signée utilisable lorsqu’un événement plus récent est malformé, distinguent une liste explicitement vide d’une recherche indisponible, et ne remplacent pas les relais déclarés en échec par des valeurs par défaut codées en dur.

L’éditeur de kind 10063 permet à un utilisateur de charger, réordonner, vérifier, signer en externe, publier et relire une liste ordonnée de serveurs multimédias HTTPS sans contacter ces serveurs ni insérer de valeur par défaut non déclarée.

Les cibles de paiement NIP-A3 atteignent trois clients

Du 1er au 3 septembre, Amethyst, Grimoire et Pollerama ont implémenté les cibles de paiement NIP-A3 de kind 10133. Amethyst propose une passation opt-in uniquement lorsqu’une cible compatible existe et ne la transforme pas en zap ; Grimoire utilise un registre fixe avant de construire les URI de portefeuille ; Pollerama valide les adresses Monero et récupère la liste de relais de l’auteur avant d’interroger les cibles. Chaque client a toujours besoin d’une méthode de paiement autorisée, d’une route de relais et d’un affichage exact.

Ditto étend le repli Blossom et les intégrations en direct

Ditto a fusionné un repli et une mise en miroir Blossom étendus le 6 septembre. Les avatars, badges, bannières, images de communauté, emoji personnalisés et icônes d’application essaient désormais les serveurs déclarés avec le même hachage de blob ; les téléversements miroirs utilisent un jeton d’autorisation BUD-11 standard. Un changement du 4 septembre a ajouté des intégrations compactes de diffusions en direct kind:30311.

Travaux sur le protocole et les spécifications

Nostr Implementation Possibilities

NIP-01 clarifie désormais le filtre limit: 0, fusionné le 4 septembre. Un relais DOIT ne retourner aucun événement stocké, DOIT envoyer EOSE lorsque les requêtes initiales sont terminées, et DOIT maintenir l’abonnement actif pour les nouveaux événements correspondants. Les clients peuvent ouvrir un abonnement réservé au direct avec un seul champ de filtre tout en conservant l’historique local. La clarification consigne un comportement compatible entre plusieurs implémentations de relais et relais publics.

NIP-78 a gagné une exigence d’authentification pour les données d’application, fusionnée le 3 septembre. Les relais DEVRAIENT exiger une authentification NIP-42 pour les kinds 78 et 30078 et DEVRAIENT ne les servir qu’à l’auteur authentifié de l’événement. Il s’agit d’un DEVRAIT, et non d’une garantie de confidentialité : les clients ne peuvent pas considérer des relais arbitraires comme un stockage privé. La fusion décourage également les kinds de données d’application personnalisés comme format d’échange public générique.

NIP-AC a été ouvert le 4 septembre comme une proposition de signalisation WebRTC explicitement ouverte. Il utilise des kinds éphémères provisoires pour le ping, les demandes de connexion, les offres, les réponses et les candidats ICE, adressés avec p et regroupés par une balise de session e ; le kind 30600 prend en charge la découverte. Les relais DEVRAIENT diffuser et ne DOIVENT PAS stocker ces événements de signalisation pendant que les pairs se connectent directement. Les numéros restent provisoires, les clients DEVRAIENT utiliser les listes de relais NIP-65, et les applications nécessitant la confidentialité DEVRAIENT chiffrer le contenu des offres, des réponses et des candidats avec NIP-44.

Analyse approfondie d’un NIP : liens URI et références dans le texte des événements

Un identifiant Nostr a besoin d’une signification transportable avant qu’une autre application puisse l’ouvrir. NIP-21 place un identifiant NIP-19 après le schéma d’URI nostr:, offrant aux navigateurs, systèmes d’exploitation et applications une forme unique et distribuable. NIP-27 définit ce que ce même URI signifie à l’intérieur du content lisible d’un événement. NIP-21 franchit une frontière applicative ; NIP-27 conserve une référence de profil ou d’événement dans une prose signée. Aucun des deux ne crée un kind d’événement ni ne modifie les messages de relais ; les deux spécifications définissent uniquement le comportement de liaison et d’affichage.

Routage des URI et sémantique de NIP-19

La grammaire de NIP-21 se compose de nostr: suivi d’une entité bech32 NIP-19. nsec est exclu, car il encode une clé privée. Il n’y a aucun composant d’autorité, de chemin ou de requête. Un lien conforme est donc nostr:npub1..., et non nostr://npub1.... Une plateforme ou un client peut s’enregistrer comme gestionnaire. La spécification ne choisit pas l’application installée et ne définit pas de solution de repli vers le Web.

Le préfixe indique au client ce qu’il doit décoder. npub contient une clé publique et note un identifiant d’événement. nprofile ajoute à un profil des indications facultatives de relais. nevent ajoute des relais, un auteur et un kind à un identifiant d’événement. Enfin, naddr contient l’auteur, le kind et l’identifiant d d’un événement adressable, avec des relais facultatifs. Ces formats utilisent les champs type-longueur-valeur de NIP-19. Les indications facilitent la recherche, mais ne prouvent ni que le relais possède l’événement ni que l’auteur le contrôle. Pour chaque événement récupéré, il faut toujours recalculer l’identifiant et vérifier la signature.

Le format de profil donné dans la spécification NIP-21 est le suivant :

nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9

NIP-21 définit également des passerelles HTML : une page qui fournit un événement Nostr peut placer son naddr dans <link rel="alternate">, tandis qu’un profil peut placer un nprofile dans <link rel="me"> ou <link rel="author">.

Affichage selon NIP-27 et tags facultatifs

NIP-27 s’applique au contenu lisible des événements, comme les notes de kind 1 et les articles de kind 30023. Un outil de rédaction peut afficher @name, mais publie nostr:nprofile1... dans la chaîne signée. Un lecteur analyse l’URI, décode son entité NIP-19, récupère la cible et peut afficher un nom, une carte, un aperçu ou un lien local. Si le décodage échoue, l’URI reste du texte ordinaire. Le contenu brut ne doit pas être réécrit : toute modification change la sérialisation NIP-01, l’identifiant et la signature.

Les références dans le contenu et les tags remplissent des fonctions liées, mais distinctes. NIP-27 décrit les tags facultatifs p et e, ainsi que le tag q de NIP-18. Un client peut afficher une référence sans créer de notification ni de relation de fil de discussion. Pour permettre la découverte d’une citation, il convient d’écrire à la fois l’URI et un tag q. L’implémentation de Zap Cooking du 4 septembre suit cette distinction en conservant l’URI tout en ajoutant des indications de relais et un tag p correspondant. L’ajout de p ou de q ne rend pas l’URI privée, et NIP-27 ne prévoit aucun mode de mention masquée.

L’événement de kind 1 suivant a été récupéré depuis wss://nos.lol et vérifié avant d’être inclus comme exemple concret de référence NIP-27. Son content contient un naddr correspondant à un événement adressable indépendant de sa version. Le décodage donne le kind 30402, l’auteur 91036d...310a, l’identifiant d du cahier d’exercices et une indication wss://nos.lol/. Les tags q, p, t, zap et client relèvent de choix applicatifs et ne sont pas exigés par NIP-27.

{
  "id": "cbf64aa95627f3722915e9aad29d905ddac9b09e7a8808a7594732d90deaa6bb",
  "pubkey": "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
  "created_at": 1788953511,
  "kind": 1,
  "tags": [
    [
      "p",
      "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
      "wss://multiplexer.huszonegy.world/"
    ],
    [
      "t",
      "archetype"
    ],
    [
      "q",
      "30402:91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a:Archetype-Workbook-Companion-Meet-your-King-Warrioir-Magician-Lover-today-oejbwe",
      "wss://nos.lol/"
    ],
    [
      "zap",
      "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
      "wss://multiplexer.huszonegy.world/",
      "0.9"
    ],
    [
      "zap",
      "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
      "wss://relay.nostr.band/",
      "0.1"
    ],
    [
      "client",
      "Amethyst"
    ]
  ],
  "content": "You can check, read and use this Workbook already! You can also support and get it for few sats and support us in this project.\n\nI hope it'll help you in your Archetype Journey :)\n\n#archetype\n\nnostr:naddr1qpgyzunrdpjhg7tsv5k4wmmjdd3x7mmt94pk7mtsv9hxjmmw94xk2et594uk7atj949kjmn894tkzunjd9hkju3df4skw6trd9skut2vdamx2u3dw3hkgcte94hk26nzwajszrnhwden5te0dehhxtnvdakz7q3qjypkmmqcaetrcpld4m27la946cch2hrk7qr8xjehsu5j5h3uxy9qxpqqqpmvyqnrm7n",
  "sig": "aa9592e7c773271b9e9f980c8a7e17fda2ffd5a4483a1789e5dd4c4a83018ac576c5202b21b33b08770dcabe023f93998a41f1a0be4bf00e36cdde611d07915e"
}

Confiance, comportement en cas d’échec et implémentations clientes

Un lecteur sûr repère un jeton nostr: complet, valide bech32, décode NIP-19, rejette nsec, ignore les types TLV inconnus et laisse inchangé tout texte mal formé ou trop volumineux. npub et nprofile conduisent à des requêtes de profils ; note et nevent identifient des événements immuables ; naddr sélectionne le dernier événement adressable valide pour son kind, son auteur et son tag d. Les indications de relais réduisent le champ de recherche, mais n’étendent pas la confiance. Selon les règles de NIP-01 relatives aux événements, le client vérifie l’id d’un nevent récupéré et contrôle la signature de chaque candidat naddr avant d’appliquer les règles de remplacement des événements adressables.

L’affichage d’aperçus intégrés relève du choix du client et a un coût en matière de confidentialité et de ressources. Récupérer chaque référence révèle les centres d’intérêt du lecteur et peut provoquer une avalanche de requêtes. Les clients peuvent donc utiliser un cache, différer les récupérations jusqu’à ce que les références soient visibles, limiter les accès simultanés et exiger un clic pour les médias inconnus. Selon NIP-27, un aperçu doit rester distinct du texte signé par l’auteur actuel. Un échec doit apparaître comme du texte non résolu ou une carte indisponible, et non être silencieusement traité comme du contenu vérifié.

La confiance varie également selon le type d’identifiant. Un nevent désigne des octets immuables, de sorte qu’un client peut rejeter un événement récupéré dont l’id sérialisé diffère de l’id demandé. Un naddr désigne une coordonnée remplaçable. Le client doit donc vérifier chaque candidat et appliquer les règles relatives aux événements adressables avant de décider quelle version afficher. Une indication de relais est utile pour la première requête dans les deux cas, mais elle ne constitue pas une approbation du relais ni du contenu renvoyé. La définition TLV de NIP-19 fournit les données nécessaires pour rendre ces vérifications explicites.

NIP-21 définit un lien portable qui peut être ouvert depuis l’extérieur de Nostr, tandis que NIP-27 rend ce même lien durable au sein d’un texte signé. Un client qui implémente uniquement NIP-21 peut ouvrir un URI collé, mais ne peut pas afficher les références intégrées. Une prise en charge complète de NIP-27 ajoute la détection, le décodage sécurisé, une politique de récupération, le rendu local et un choix explicite concernant les tags de notification et de citation. L’URI commun assure l’interopérabilité de ces différentes couches sans obliger les clients à les présenter de manière identique.Damus représente les références intégrées sous forme de mentions typées. Son code de gestion des mentions associe npub et nprofile à des références de profils, note et nevent à des références d’événements, et naddr à des références d’adresses ; NostrLink les dirige vers la destination appropriée. Primal Android analyse le protocole et les formes collées, valide bech32 et extrait les indications de relais, puis associe les références à des modèles de contenu de note. Zap Cooking affiche les mêmes références dans les articles, les recettes, les aperçus de l’éditeur et les vues d’impression.

Envoyez un DM NIP-17 pour partager un projet ou une actualité par l’intermédiaire du projet Nostr Compass.