Nostr Wallet Connect (NWC) es un conjunto de reglas compartidas descritas en el documento NIP-47. Permite a una aplicación enviar solicitudes a una cartera Lightning a través de Nostr. El servidor de transporte, llamado relay, lleva instrucciones y respuestas cifradas, no los bitcoins. El servicio de la cartera gestiona permisos y ejecuta los pagos.
Anna escucha un podcast y quiere enviar una pequeña cantidad a su autor por Lightning Network. Con NWC, el reproductor puede pedir directamente el pago a su cartera. El servicio comprueba los permisos de la conexión antes de ejecutar una solicitud autorizada. NWC no determina quién guarda las claves de los bitcoins: al otro lado puede estar el nodo de Anna o un servicio que custodia sus fondos. El mismo botón «Conectar cartera» puede implicar grados de control muy distintos. Según los derechos concedidos, la aplicación también puede actuar sin una nueva confirmación para cada pago individual. [1] [2]
La cartera suele proporcionar un código QR o una cadena de conexión, técnicamente una URI. Contiene la clave pública del servicio, la dirección del relay y secret, la clave privada de esa conexión cliente. No es el seed de la cartera, su valor secreto inicial, ni su Seed Phrase, las palabras de recuperación. Aun así, no es un enlace público inocuo: quien consiga una copia utilizable puede ejercer los mismos permisos. El daño posible depende de las funciones y límites autorizados. Usar conexiones separadas por aplicación permite distinguirlas y revocarlas individualmente, además de reducir las relaciones identificables entre ellas. [1]
Una aplicación puede necesitar solo consultar el saldo, o también enviar dinero. Son permisos diferentes. El evento público info anuncia las capacidades del servicio; get_info devuelve los métodos disponibles para una conexión concreta. Un método es una orden con nombre: pay_invoice solicita un pago, make_invoice crea una petición de pago, lookup_invoice consulta su estado y get_balance lee el saldo. También get_info forma parte del conjunto básico. El historial, keysend —pagar sin una factura creada previamente— y las notificaciones son extensiones opcionales. Que el servidor admita una orden no autoriza a cualquier aplicación conectada a ejecutarla. [1] [3] [5]
Anna quizá quiera asignar al reproductor un presupuesto limitado. Si el servicio ofrece límites de gasto, de métodos o de vigencia, debe aplicarlos él mismo. Una cifra mostrada solo en el reproductor no protege frente a una aplicación que envíe otra solicitud. Comprueba también si el presupuesto es único o se renueva y cómo se contabilizan las comisiones. Cuando Anna deje de usar la aplicación, debe revocar sus permisos en el servicio de la cartera. Borrar la aplicación o su conexión local no demuestra que el acceso esté revocado. La revocación bloquea solicitudes futuras, pero no revierte un pago completado. [1]
Una factura Lightning es una petición de pago, por ejemplo en formato BOLT11, no una prueba de que alguien haya pagado. NIP-47 expresa importes y comisiones en msat, milésimas de satoshi: 1000 msat = 1 sat. Confundir unidades cambia el importe por un factor de mil. make_invoice solo crea la petición. Un pay_invoice correcto devuelve preimage. A partir de ese valor se calcula un hash, un dato corto de comprobación. Debe coincidir con el hash de pago de la factura; la preimage devuelta sirve así como prueba de que el pago se completó. Una respuesta de error utiliza error. lookup_invoice permite consultar el estado. La aplicación debe interpretar el resultado real, no mostrar éxito simplemente por haber enviado un mensaje. [1]
Anna pulsa Pagar, pero no llega la respuesta. Un timeout, el fin del tiempo de espera, no aclara qué ha pasado con el dinero. NWC usa eventos efímeros para solicitudes y respuestas; un relay desconectado o un servicio no disponible puede perder un mensaje. Pero también puede haberse perdido solo la respuesta a un pago ya completado. Primero consulta el estado mediante lookup_invoice o en la propia cartera. El silencio no confirma un fallo. Una nueva solicitud no es automáticamente una repetición segura de la acción original; antes hay que averiguar su resultado. [1]
La aplicación y la cartera intercambian mensajes cifrados. La negociación actual prioriza nip44_v2; el obsoleto nip04 se conserva por compatibilidad. Si falta la etiqueta encryption, se interpreta el modo antiguo. NIP-44 no proporciona forward secrecy, la protección de comunicaciones pasadas si una clave duradera se filtra después. El relay también puede ver tipos de eventos, etiquetas, claves públicas de conexión y horarios. Por eso NWC no debe usar la clave principal con la que una persona publica en Nostr. Separar las claves reduce la vinculación entre pagos y perfil público, pero no garantiza anonimato total. [1] [4]
No hace falta memorizar números de mensajes para utilizar NWC, pero sí importan al desarrollar una integración. Info usa kind 13194, las solicitudes 23194 y las respuestas 23195. kind identifica el tipo de evento. La etiqueta p señala a la contraparte y la etiqueta e de la respuesta apunta a la solicitud original. El cliente comprueba la firma, la clave esperada del servicio, esa relación y result_type, la orden a la que corresponde el resultado. No basta con aceptar cualquier mensaje del relay como confirmación. De lo contrario, una respuesta ajena o relativa a otra acción podría confundirse con el resultado de este pago. [1]
Para obtener la imagen más completa, lee esta entrada junto con Nostr, Lightning Network, BOLT 11, Cartera, Private Key, Satoshi. También enlazan con esta entrada Nostr, BOLT 11.