Nostr Wallet Connect (NWC) est un protocole ouvert, défini dans le NIP-47, qui permet à n’importe quelle application de contrôler un wallet Lightning en échangeant des messages chiffrés via des relays Nostr — sans clé d’API dépositaire, sans connexion à un exchange, et sans abandonner le contrôle de vos fonds. Un service de wallet et une application cliente détiennent chacun leur propre paire de clés secp256k1 et communiquent par l’intermédiaire d’un relay partagé : l’application demande « paie cette facture » ou « quel est mon solde », et votre wallet répond, tandis que vous conservez la garde du node et des pièces. Parce que chaque connexion est un secret unique et révocable, avec son propre budget de dépenses et son ensemble de permissions, vous pouvez donner à un client Nostr, une page de paiement ou un script d’automatisation un accès étroit et bridé à votre propre wallet sans jamais exposer vos clés.
Le problème que NWC résout
Pendant la plus grande partie de l’histoire de Lightning, laisser une application dépenser depuis votre wallet impliquait l’un de deux mauvais compromis. Soit vous gériez un compte dépositaire et remettiez à l’application une clé d’API (le service détenait votre argent et votre clé pouvait tout déplacer), soit vous copiez-colliez factures et codes QR à la main pour chaque paiement. Ni l’un ni l’autre ne convient à la façon dont les gens utilisent réellement Nostr, où un « zap » — un petit pourboire Lightning — doit se déclencher en une fraction de seconde depuis l’intérieur d’un fil social.
NWC, proposé à l’origine par l’équipe d’Alby avec la communauté plus large des développeurs Nostr et normalisé sous le NIP-47, fait le pont. Il définit un langage commun pour qu’une application cliente puisse piloter un wallet qu’elle ne contrôle pas, sur une infrastructure qu’aucune des deux parties n’a à héberger en privé, le propriétaire du wallet fixant d’emblée des limites strictes. Le résultat est une connexion unique et portable qui fonctionne avec des dizaines d’applications et de wallets — vous vous connectez une fois et vos zaps, paiements et automatisations fonctionnent tout simplement, tandis que vos clés ne quittent jamais votre wallet. C’est le même réflexe d’autosouveraineté qui sous-tend l’usage de votre propre appareil de signature Bitcoin : utilisez les outils que vous aimez, mais conservez les clés vous-même.
Comment fonctionne NWC : l’architecture
NWC comporte deux rôles. Le wallet service est le logiciel qui détient réellement les fonds et peut déplacer des sats — par exemple un node auto-hébergé ou un wallet hébergé. Le client est l’application qui souhaite demander des actions — un client social Nostr, une boutique web ou un script. Chaque côté possède sa propre paire de clés Nostr (clés secp256k1 standard, la même courbe que Bitcoin), et ils ne partagent jamais de clé privée. Ils communiquent exclusivement par des events Nostr chiffrés relayés via un ou plusieurs relays accessibles aux deux.
Le protocole utilise quatre kinds d’events :
- Kind 13194 — info event. Un event remplaçable que le wallet service publie pour annoncer quelles commandes et notifications il prend en charge, et quels schémas de chiffrement il accepte.
- Kind 23194 — request. Un event chiffré envoyé par le client, nommant une méthode (comme pay_invoice) et ses paramètres.
- Kind 23195 — response. Le wallet service déchiffre la requête, vérifie si cette connexion est autorisée et dans le budget, exécute l’action, et répond par un résultat ou une erreur.
- Kind 23197 — notification (kind 23196 pour le chemin hérité), permettant au wallet d’envoyer des events tels que « paiement reçu » au client.
Le contenu des messages est chiffré. Le NIP-47 privilégie le chiffrement NIP-44 (version 2) et ne conserve l’ancien schéma NIP-04 que pour la compatibilité ascendante ; l’info event porte une balise encryption listant ce que le service prend en charge. Pour une carte plus détaillée de la façon dont ces blocs s’assemblent, consultez la référence des NIPs Nostr.
La chaîne de connexion
Tout ce dont une application a besoin pour joindre votre wallet est regroupé dans une seule URI utilisant le schéma nostr+walletconnect://. L’hôte est la clé publique du wallet service, suivie de paramètres de requête :
- relay — l’URL d’un relay où le wallet service écoute (par exemple wss://relay.example.com). Vous pouvez en spécifier plusieurs.
- secret — une chaîne de 32 octets, générée aléatoirement et encodée en hexadécimal. C’est la clé privée du client pour cette connexion ; le client l’utilise pour signer et chiffrer ses requêtes.
- lud16 (optionnel) — une adresse Lightning, utilisée par certains wallets pour préremplir les détails de profil.
Une chaîne de connexion ressemble donc à nostr+walletconnect://<wallet-pubkey>?relay=wss%3A%2F%2Frelay.example.com&secret=<32-byte-hex>. Traitez ce secret comme un mot de passe : quiconque le détient peut envoyer des requêtes à votre wallet dans les limites du budget et des permissions que vous y avez attachées. Le choix de conception crucial est que chaque application reçoit sa propre chaîne de connexion. Vous ne réutilisez jamais un secret d’une application à l’autre, de sorte que révoquer une application compromise signifie supprimer une connexion, et non faire tourner tout votre wallet.
Les commandes
Le NIP-47 définit un ensemble ciblé de méthodes. Un wallet annonce le sous-ensemble qu’il implémente dans son info event, et une connexion n’est autorisée à appeler que les méthodes que vous lui avez accordées.
| Commande | Ce qu’elle fait |
|---|---|
| pay_invoice | Paie une facture Lightning BOLT-11. |
| multi_pay_invoice | Paie plusieurs factures en une seule requête. |
| pay_keysend | Envoie un paiement keysend spontané à un node, sans facture requise. |
| make_invoice | Crée une nouvelle facture Lightning pour recevoir un paiement. |
| lookup_invoice | Récupère le statut et les détails d’une facture ou d’un paiement par hachage ou par chaîne. |
| list_transactions | Liste les factures et paiements passés, avec filtrage et pagination. |
| get_balance | Retourne le solde du wallet, exprimé en millisatoshis. |
| get_info | Retourne les informations du node ainsi que les méthodes et notifications prises en charge par le wallet. |
La spécification inclut aussi des méthodes de hold-invoice (make_hold_invoice, settle_hold_invoice, cancel_hold_invoice) pour les flux avancés, ainsi que des notifications optionnelles : payment_received, payment_sent et hold_invoice_accepted. En cas de problème, le wallet renvoie une erreur structurée telle que INSUFFICIENT_BALANCE, QUOTA_EXCEEDED (un budget a été atteint), RESTRICTED ou UNAUTHORIZED (la connexion n’a pas la permission), RATE_LIMITED, PAYMENT_FAILED ou NOT_FOUND — afin que les clients puissent réagir de façon sensée au lieu de deviner.
Permissions et budgets : la laisse
La raison pour laquelle NWC est sûr à utiliser avec des applications tierces, c’est que l’autorité est délimitée par connexion. Parce que chaque connexion est une clé distincte assortie de « contraintes arbitraires », un wallet peut y attacher :
- Une liste de méthodes autorisées — par exemple, n’accorder à un tableau de bord en lecture seule que get_balance et list_transactions, sans capacité de payer.
- Un budget de dépenses — un montant maximum, souvent avec une fenêtre de renouvellement (quotidienne, hebdomadaire, mensuelle ou annuelle). Une fois qu’une connexion a épuisé son budget, les paiements suivants renvoient QUOTA_EXCEEDED jusqu’à la réinitialisation de la fenêtre.
- Une date d’expiration — la connexion cesse simplement de fonctionner après un moment choisi.
- Des permissions de notification — quels events, le cas échéant, l’application peut recevoir.
Si une application se comporte mal, est compromise, ou si vous cessez simplement de l’utiliser, vous supprimez cette seule connexion. Votre wallet, vos autres applications et vos fonds restent intacts. Cette révocabilité est le cœur du modèle de confiance de NWC.
Wallet service auto-hébergé vs hébergé
NWC ne rend pas un wallet dépositaire non dépositaire, et il ne rend pas un node auto-hébergé dépositaire — c’est un protocole de contrôle superposé au wallet vers lequel vous le pointez. La question de la garde est tranchée par le wallet service que vous utilisez.
| Approche | Qui détient les fonds | Exemples | Compromis |
|---|---|---|---|
| Node auto-hébergé | Vous — votre propre node Lightning | Alby Hub (LDK intégré, ou backends LND / Core Lightning / Phoenixd), les applications NWC autonomes pour LND et CLN | Souveraineté totale ; vous exploitez et maintenez le node et ses canaux. |
| Wallet dépositaire hébergé | Le fournisseur | Coinos, Primal Wallet | Le plus simple pour démarrer ; vous confiez vos sats à l’opérateur. |
| Wallet ecash | Le mint (dépositaire), via Cashu Wallet Connect | Cashu.me, Minibits | Rapide et privé entre utilisateurs ; le mint peut toujours censurer ou faillir. |
Pour ceux qui veulent « utiliser les applications mais détenir les clés », Alby Hub est un point de départ courant : il tourne sur un ordinateur de bureau (macOS, Windows, Linux), un serveur via Docker, ou un hébergeur infonuagique, et il peut piloter un node LDK intégré ou se connecter à votre LND, Core Lightning ou Phoenixd existant. Depuis son tableau de bord, vous générez des secrets de connexion NWC, chacun avec sa propre liste de méthodes, budget max_amount, période de renouvellement et expiration. Des plateformes d’auto-hébergement comme Umbrel et Start9 peuvent aussi héberger un wallet compatible NWC sur un node que vous conservez déjà à la maison. La voie ecash — via Cashu Wallet Connect, une extension NWC pour l’ecash chaumien — est couverte dans notre guide ecash, Cashu et Fedimint (publié en parallèle de celui-ci).
Applications et wallets qui parlent NWC
La valeur de NWC croît avec chaque projet qui l’adopte, et la liste ouverte maintenue par la communauté est vaste. Côté wallet service, on trouve Alby Hub, l’extension de navigateur Alby et Alby Go, Coinos, Primal Wallet, LNbits (via son greffon NWC), et les wallets ecash Cashu.me et Minibits. Zeus a ajouté NWC à la fois comme client et comme wallet service, de sorte qu’un node Zeus auto-gardien peut servir des zaps à vos applications sociales. Côté client, des applications Nostr comme Amethyst, Damus, Primal, Snort, noStrudel, Nostur et d’autres vous permettent d’attacher un wallet via NWC, aux côtés d’utilitaires comme Zapple Pay, Zap Planner, Zap Stream et Wavlake. Deux SDK rendent l’intégration directe pour les développeurs : le SDK JavaScript Alby (@getalby/sdk) et une implémentation Rust dans les bibliothèques Nostr. Comme le support évolue rapidement, confirmez le statut actuel d’une application précise avant de vous y fier.
Cas d’usage concrets
- Zaps. Le cas d’usage signature — pourboire une note ou un créateur instantanément depuis un client Nostr, payé par votre propre wallet sous un budget quotidien.
- Paiement e-commerce. Une boutique web peut présenter une facture que votre wallet paie dans l’application, sans balayage de QR ni redirection.
- Automatisation et DVM. Les scripts et les Nostr Data Vending Machines peuvent payer du calcul ou des données à la demande dans une allocation plafonnée, de sorte qu’une tâche emballée ne puisse jamais vous vider.
- Tableaux de bord en lecture seule. N’accorder à une application de surveillance que get_balance et list_transactions pour observer les flux sans aucune autorité de dépense.
Cette composabilité est exactement le type d’interopérabilité sans permission autour duquel s’articule la boîte à outils de souveraineté numérique plus large — et elle s’associe naturellement aux couches de transport souveraines comme celles couvertes dans notre guide du réseau Reticulum.
Le modèle de sécurité et de confiance — et ses limites
Les forces de NWC sont réelles mais bornées, et il vaut la peine d’être lucide sur les deux. Du côté positif : les clés maîtres de votre wallet ne quittent jamais le wallet ; chaque application ne détient qu’un secret délimité, budgété et révocable ; et les payloads sont chiffrés de bout en bout avec NIP-44 entre les deux paires de clés. Le wallet service est l’autorité finale — il vérifie indépendamment chaque requête par rapport aux permissions de cette connexion avant de déplacer le moindre sat.
Les limites : un secret de connexion est une autorité au porteur jusqu’à son budget, donc quiconque l’obtient peut dépenser dans ce plafond jusqu’à ce que vous le révoquiez — gardez des budgets serrés et des expirations courtes. Le relay voit que deux clés échangent des events NWC chiffrés et peut observer le minutage et les métadonnées, même s’il ne peut pas lire le contenu ; exploiter ou choisir votre propre relay réduit cette exposition. Et NWC hérite du modèle de garde du wallet qui se trouve derrière : pointer une connexion vers un service dépositaire signifie que ce service contrôle toujours vos fonds. Utilisé délibérément — un node auto-hébergé, des budgets étroits, un secret par application, votre propre relay — NWC vous permet de profiter de la commodité des applications tierces tout en détenant véritablement vos propres clés. Parcourez les données et outils sous-jacents de l’écosystème dans notre hub de données ouvertes.
Foire aux questions
Nostr Wallet Connect est-il dépositaire?
NWC en soi n’est ni dépositaire ni non dépositaire — c’est un protocole de contrôle. La garde dépend entièrement du wallet service auquel vous vous connectez. Pointez une connexion vers votre propre node auto-hébergé (par exemple via Alby Hub exécutant LDK, LND ou Core Lightning) et vous restez pleinement auto-gardien. Pointez-la vers un service hébergé comme Coinos ou Primal Wallet et ce fournisseur détient vos fonds.
Ai-je besoin d’un compte Nostr pour utiliser NWC?
Non. NWC réutilise les relays et le format d’event de Nostr comme transport, mais la connexion est établie avec une paire de clés dédiée générée à cette fin. Vous pouvez connecter une application à votre wallet sans jamais créer ni lier une identité sociale Nostr, bien que beaucoup de gens utilisent précisément NWC pour alimenter les zaps dans les clients Nostr.
Comment limiter ce qu’une application peut dépenser?
Lorsque vous créez une connexion dans votre wallet service, vous fixez un budget — un montant maximum, habituellement avec une fenêtre de renouvellement comme quotidienne, hebdomadaire ou mensuelle — et vous choisissez quelles méthodes la connexion peut appeler. Une fois le budget atteint, le wallet renvoie une erreur QUOTA_EXCEEDED et refuse les paiements suivants jusqu’à la réinitialisation de la fenêtre. Vous pouvez aussi fixer une date d’expiration et révoquer la connexion à tout moment.
Que se passe-t-il si une application connectée est compromise?
Les dommages sont plafonnés au budget de cette connexion, et vos clés maîtres ne sont jamais exposées parce que chaque application ne détient que son propre secret délimité. Vous révoquez la connexion concernée dans votre wallet, ce qui coupe immédiatement l’application, et vos autres applications ainsi que vos fonds restent intacts. C’est pourquoi la pratique recommandée est une connexion par application, avec des budgets serrés et des expirations courtes.
Quels wallets et applications prennent en charge NWC aujourd’hui?
Côté wallet, Alby Hub, Coinos, Zeus, Primal Wallet, LNbits et les wallets ecash Cashu.me et Minibits prennent en charge NWC, et des options auto-hébergées existent pour les nodes LND, Core Lightning et Phoenixd. Côté application, des clients Nostr comme Amethyst, Damus, Primal, Snort et noStrudel, plus des outils comme Zapple Pay et Zap Planner, agissent comme clients NWC. Le support évolue rapidement, donc vérifiez le statut actuel d’un projet avant de vous y fier.
En quoi NWC diffère-t-il d’une clé d’API Lightning (clés LNDhub ou LNbits)?
Une clé d’API traditionnelle est typiquement un identifiant unique et durable contre un service précis, souvent avec un accès large. NWC, lui, émet une paire de clés unique et révocable par connexion, transportée via des relays Nostr ouverts plutôt qu’un point de terminaison privé, avec des budgets par connexion, des permissions de méthodes et des expirations intégrés au protocole. L’effet pratique est un contrôle plus fin et plus portable qui fonctionne de la même façon sur de nombreux wallets et applications.
