nak 0.21.0 lit les listes de relais et résout les chemins de petnames

Une commande pour les listes de relais NIP-65

55707c26 ajoute relays.go, un fichier de 58 lignes qui enregistre une nouvelle sous-commande de premier niveau. Sa chaîne d'usage en déclare la portée : prints the nip65 relays for a given pubkey, one relay per line.

Elle prend une clé publique en argument ou sur l'entrée standard et écrit une URL de relais par ligne. Deux drapeaux restreignent la sortie, chacun avec un alias nommant l'autre moitié du vocabulaire de NIP-65 :

--inbox, --read     only print relays marked as inbox/read
--outbox, --write   only print relays marked as outbox/write

Il vaut la peine de lire la logique du filtre à la lettre, car le cas combiné n'est pas une union. Passer les deux drapeaux exige les deux marquages sur le même relais :

if wantInbox && wantOutbox {
    if !(rl.Inbox && rl.Outbox) {
        continue
    }
}

Ainsi --inbox --outbox n'affiche que les relais servant les deux directions, ce qui sous NIP-65 correspond à une balise r sans marquage, alors que n'en passer aucun affiche la liste entière. Ensemble, les deux drapeaux resserrent l'ensemble au lieu de l'élargir, ce qui compte quand la sortie alimente une étape de publication.

Les noms de direction correspondent aux rôles décrits dans le guide de routage NIP-65 publié le jour même : c'est depuis les relais de sortie d'un auteur que ses événements sont récupérés, et c'est vers les relais d'entrée d'un destinataire que sont livrés les événements qui le mentionnent. La commande rend les deux cibles scriptables sans analyser à la main un événement de kind 10002.

Les chemins de petnames, dans l'analyseur partagé

Les chemins de petnames de NIP-02 arrivent en deux étapes, et la seconde corrige la première. C'est la fonctionnalité ajoutée à NIP-02 dans la révision rapportée le 20 septembre, puis restreinte à l'ASCII dans le suivi trois jours plus tard.

4011cba5 n'ajoute pas de commande. Il modifie l'analyseur partagé : parsePubKey reçoit un second argument, une clé publique depuis laquelle résoudre, et renvoie tout ce qui commence par un tilde vers un nouveau resolvePetnamePath.

func parsePubKey(value string, from nostr.PubKey) (nostr.PubKey, error) {
	value = strings.TrimPrefix(value, "nostr:")

	if strings.HasPrefix(value, "~") {
		return resolvePetnamePath(value, from)
	}

Cet auxiliaire appelle sys.ResolvePetnamePath avec un délai de cinq secondes. Son commentaire de documentation énonce le mécanisme et donne la forme mixte que NIP-02 autorise : le chemin ~erin/david/frank parcourt la liste d'abonnements de chaque nom de la chaîne, et le premier nom peut être à la place un identifiant NIP-05, comme dans [email protected]/david/frank. Comme la recherche de profil sous-jacente masque les erreurs NIP-05, une résolution ratée est revérifiée avec nip05.QueryIdentifier, afin qu'un problème de DNS ou de HTTP soit signalé pour ce qu'il est et non comme un petname irrésoluble. Le commit met à jour chaque point d'appel et ajoute 239 lignes de tests.

Ce que cette étape ne tranche pas, c'est la clé depuis laquelle part un chemin relatif. La pull request #220, intégrée le 25 septembre, ajoute petname_cli.go et une enveloppe parsePubKeyForCommand qui classe la racine :

absolute := hexErr == nil || nip05.IsValidIdentifier(parts[0]) ||
    (nip19Err == nil && (prefix == "npub" || prefix == "nprofile"))

Un chemin enraciné dans une clé publique hexadécimale, dans un identifiant NIP-05 valide ou dans un npub ou nprofile est absolu, et un commentaire consigne pourquoi le cas est séparé : Absolute roots must also work without access to a signing key. Seul un chemin relatif appelle gatherKeyerFromArguments et prend la clé publique de ce signataire comme point de départ. Lire vers l'extérieur à partir de quelqu'un que l'on peut nommer ne demande donc pas de clé, tandis qu'un chemin partant de ses propres abonnements en demande une.

La même pull request corrige un problème d'ordre des arguments. Un appel dans init applique deferPetnameFlags à tout l'arbre des commandes et remplace chaque drapeau porteur de clés publiques par une enveloppe qui conserve la chaîne brute et ne la résout qu'une fois tous les drapeaux analysés. Le commentaire en donne la raison : un drapeau de signataire tel que --sec peut apparaître après le drapeau de petname sur la ligne de commande, et la résolution a besoin du signataire. Elle ajoute 169 lignes de tests supplémentaires.

La complétion, et trois corrections plus modestes

5f28b21c règle EnableShellCompletion: true sur la commande racine, ce qui expose nak completion bash, zsh et fish. Le README gagne les trois chemins d'installation pour les interpréteurs dont le paquet ne s'en charge pas.

Trois correctifs de comportement sont étroits, mais chacun ferme un cas où l'outil faisait quelque chose d'inutile au lieu de signaler un problème :

• 30551476 ajoute --github à nak event, et sa ligne d'usage en donne la raison : treat empty stdin as no stdin at all, as GitHub Actions always opens it. Dans cet environnement, une entrée standard toujours ouverte mais vide était indiscernable d'une entrée par tube.
• nak key encrypt avec un seul argument échoue désormais avec no password given or key piped on stdin quand l'entrée standard n'est pas un tube, au lieu de lire cet unique argument comme un mot de passe sans clé à laquelle l'appliquer.
• blossom retire Required: true de son drapeau --server, de sorte que le serveur peut être fourni par sous-commande, et son absence produit maintenant no server specified. blossom upload gagne --auto, qui résout les serveurs de médias annoncés par l'utilisateur courant. nsite download accepte un pointeur nevent1 ou naddr1 en plus d'une URL de site, en récupérant depuis les relais d'écriture de l'auteur et les indices que porte le pointeur.

Ce que cela change en pratique

Les deux ajouts suppriment chacun une étape faite à la main pour quiconque écrit des scripts contre Nostr. Répondre à la question de l'endroit où publier ou lire ne passe plus par la récupération et l'analyse d'un événement de kind 10002, et un chemin d'abonnements peut s'écrire là où allait auparavant une chaîne hexadécimale de 64 caractères. Aucun des deux ne modifie de spécification : c'est un outil qui rattrape NIP-02 et NIP-65 tels qu'ils existent déjà. La règle de la racine absolue est le détail à retenir, car un chemin de petname partant de ses propres abonnements réclamera une clé.