Nostr Wallet Connect (NWC) est un ensemble de règles communes décrites dans le document NIP-47. Il permet à une application d’envoyer des demandes à un portefeuille Lightning via Nostr. Le serveur de transport, appelé relais, transmet des instructions et réponses chiffrées, pas les bitcoins eux-mêmes. Le service du portefeuille gère les autorisations et exécute les paiements.
Anna écoute un podcast et souhaite envoyer une petite somme à son auteur via le Lightning Network. Avec NWC, le lecteur peut demander directement le paiement à son portefeuille. Le service du portefeuille vérifie les droits de la connexion avant d’exécuter une demande autorisée. NWC ne détermine pas qui détient les clés des bitcoins : à l’autre bout peut se trouver le nœud d’Anna ou un service qui conserve les fonds pour elle. Un même bouton « Connecter le portefeuille » peut donc correspondre à des niveaux de contrôle très différents. Selon les droits accordés, l’application peut aussi agir sans nouvelle confirmation pour chaque paiement. [1] [2]
Le portefeuille fournit généralement un code QR ou une chaîne de connexion, techniquement une URI. Elle contient la clé publique du service, l’adresse d’un relais et secret, la clé privée de cette connexion cliente. Ce n’est ni le seed du portefeuille, sa valeur secrète de départ, ni sa Seed Phrase, les mots de récupération. Ce n’est pourtant pas un simple lien public : une personne disposant d’une copie utilisable peut exercer les mêmes droits. Les conséquences dépendent des fonctions et limites autorisées. Des connexions distinctes pour chaque application permettent de les identifier et de les révoquer séparément, tout en réduisant les possibilités de les relier entre elles. [1]
Une application peut avoir seulement besoin de lire le solde, ou aussi de dépenser. Ces autorisations sont différentes. L’événement public info annonce les capacités du service ; get_info indique les méthodes disponibles pour une connexion précise. Une méthode est une commande nommée : pay_invoice demande un paiement, make_invoice crée une demande de paiement, lookup_invoice en consulte l’état et get_balance lit le solde. get_info fait aussi partie du socle. L’historique, keysend — un paiement sans facture créée à l’avance — et les notifications sont des extensions facultatives. La présence d’une commande sur le serveur n’autorise donc pas toutes les applications à l’utiliser. [1] [3] [5]
Anna peut vouloir accorder un budget limité au lecteur. Si le service propose des plafonds de dépenses, des restrictions de méthodes ou une durée de validité, il doit les imposer lui-même. Un montant simplement affiché dans le lecteur ne protège pas contre une application qui envoie une autre demande. Vérifiez aussi si le budget est unique ou renouvelable et comment les frais sont comptabilisés. Lorsqu’Anna cesse d’utiliser l’application, elle doit révoquer ses droits auprès du service du portefeuille. Supprimer l’application ou sa connexion locale ne prouve pas que l’accès a été retiré. La révocation bloque les futures demandes ; elle n’annule pas un paiement déjà terminé. [1]
Une facture Lightning est une demande de paiement, par exemple au format BOLT11, pas la preuve d’un paiement. NIP-47 exprime montants et frais en msat, des millièmes de satoshi : 1000 msat = 1 sat. Confondre les unités multiplie ou divise donc le montant par mille. make_invoice crée uniquement la demande. Un pay_invoice réussi renvoie une preimage. On en calcule le hash, une courte valeur de contrôle. Celui-ci doit correspondre au hash de paiement de la facture ; la preimage renvoyée sert ainsi de preuve que le paiement est terminé. Une réponse d’erreur utilise error. lookup_invoice permet de retrouver l’état. L’application doit traiter le résultat réel, pas annoncer le succès dès qu’elle a envoyé un message. [1]
Anna appuie sur Payer, mais aucune réponse ne revient. Un timeout, c’est-à-dire l’expiration du délai d’attente, ne dit pas ce qui est arrivé à l’argent. NWC utilise des événements éphémères pour les demandes et réponses ; un relais déconnecté ou un service indisponible peut faire perdre un message. Mais seule la réponse à un paiement déjà effectué a peut-être disparu. Vérifiez d’abord l’état avec lookup_invoice ou dans le portefeuille. Le silence ne confirme pas un échec. Une nouvelle demande n’est pas automatiquement une répétition sans risque de l’action précédente ; il faut d’abord en connaître le résultat. [1]
Application et portefeuille échangent des messages chiffrés. La négociation actuelle privilégie nip44_v2 ; l’ancien nip04 reste pour la compatibilité. L’absence de balise encryption indique l’ancien mode. NIP-44 n’offre toutefois pas de forward secrecy, la protection des communications passées si une clé durable est compromise plus tard. Un relais peut aussi voir les types d’événements, balises, clés publiques de connexion et horaires. NWC ne devrait donc pas employer la clé principale utilisée pour publier sur Nostr. Des clés distinctes réduisent les liens entre paiements et profil public, sans garantir un anonymat complet. [1] [4]
Il n’est pas nécessaire de mémoriser les numéros des messages pour utiliser NWC, mais ils comptent lors d’une intégration. Info utilise kind 13194, les demandes 23194 et les réponses 23195. kind désigne le type d’événement. La balise p identifie l’autre partie ; la balise e de la réponse renvoie à la demande initiale. Le client vérifie la signature, la clé attendue du service, cette association et result_type, le nom de la commande concernée. Il ne doit pas accepter n’importe quel message du relais comme confirmation. Sinon, une réponse d’un autre expéditeur ou concernant une autre action pourrait passer pour le résultat de ce paiement. [1]
Pour une vision complète, lisez aussi Nostr, Lightning Network, BOLT 11, Portefeuille, Private Key, Satoshi. Cette entrée est également citée par Nostr, BOLT 11.