NIP-47 Simplifica su Especificación Base y Añade un Repositorio de Extensiones
Un pull request fusionado reduce NIP-47 a tres tipos de evento y cinco métodos centrales, moviendo notificaciones, pagos keysend, facturas retenidas, el listado de transacciones y el manejo de metadatos a un repositorio de extensiones separado.
Nostr WoT Newsroom
Elaborado por la Redacción de Nostr WoT a partir de las fuentes primarias citadas, y publicado automáticamente sin revisión humana individual.
NIP-47 define Nostr Wallet Connect (NWC): una forma en que un cliente Nostr accede a una wallet Lightning remota a través de relays, para pedir pagos, consultar un balance o crear facturas sin custodiar los fondos él mismo. El 2026-08-01, el PR #2419, de frnandu, se fusionó en la especificación y reescribió 47.md reduciéndolo a un núcleo mucho más pequeño, moviendo la mayor parte de lo que describía a un nuevo repositorio dedicado de extensiones de NWC. El cambio tocó un solo archivo, con 19 líneas agregadas y 332 eliminadas, por lejos la reescritura de un solo archivo más grande cubierta aquí para este NIP.
Lo que se mantiene en el núcleo
Se mantienen tres tipos de evento: el evento de información (kind 13194), el evento de solicitud (kind 23194) y el evento de respuesta (kind 23195). Cinco métodos conservan su definición completa de solicitud y respuesta en 47.md: pay_invoice, make_invoice, lookup_invoice, get_balance y get_info. La negociación de cifrado entre cliente y wallet service (NIP-44 con reserva a NIP-04, anunciada mediante la etiqueta encryption del evento de información), la lista de códigos de error, el flujo de ejemplo para pagar una factura y la nota sobre usar un relay dedicado se mantienen igual.
Lo que se movió afuera
Todo lo demás perdió su texto de especificación en 47.md. El tipo de evento de notificación, kind 23197 (con el kind 23196 conservado en la versión anterior por compatibilidad con NIP-04), desaparece de la lista de tipos de evento del núcleo, y toda la descripción de "Notification Events" junto con la sección "Notifications", que detallaba la forma JSON de los eventos payment_received, payment_sent y hold_invoice_accepted, fue eliminada por completo.
El método pay_keysend, con su formato completo de solicitud y respuesta, desapareció. También list_transactions, incluidos sus parámetros de paginación y filtrado. Los tres métodos de facturas retenidas, make_hold_invoice, cancel_hold_invoice y settle_hold_invoice, se eliminaron junto con el recorrido paso a paso del apéndice "Example Hold Invoice Support Flow". La sección de Metadata, que definía el límite de 4096 caracteres para metadatos y documentaba convenciones que algunos clientes usan para comentarios LUD-12, datos de pagador y receptor LUD-18, solicitudes de zap NIP-57 incrustadas y registros TLV de keysend, también desapareció. La sección de deep links que describía el esquema de URI nostrnwc://connect y sus parámetros appicon, appname y callback para el emparejamiento de wallets también fue eliminada.
La etiqueta de capacidades cambió de forma
Esto no es solo una cuestión de texto eliminado: una parte de la especificación que afecta el formato en la red también cambió. El 47.md anterior hacía que el evento de información anunciara soporte de notificaciones mediante una etiqueta notifications (por ejemplo payment_received payment_sent), y la lista de capacidades en el campo content del evento podía incluir la palabra notifications junto a los nombres de métodos. La nueva versión elimina esa etiqueta por completo. En su lugar, el evento de información ahora lleva una etiqueta extensions que enumera qué identificadores de extensión opcionales soporta un wallet service (el ejemplo de la especificación usa 02 03 04), y dice que cualquier método proveniente de esas extensiones debería seguir reflejándose en la lista de capacidades del campo content. El ejemplo desarrollado en el apéndice lo muestra de forma concreta: el evento de información de ejemplo anterior anunciaba once capacidades incluyendo notifications; el nuevo anuncia cinco, pay_invoice get_balance get_info make_invoice lookup_invoice, con una etiqueta extensions que enumera por separado 02 03 04 06 07 08. Ni el diff ni la descripción del PR indican qué identificador de extensión corresponde a cada funcionalidad eliminada.
A dónde va el texto eliminado
Una nueva sección "Extensions" reemplaza la mayor parte de lo recortado. Establece que NIP-47 ahora define solo el protocolo central y un conjunto pequeño de comandos comunes, y que métodos adicionales, convenciones de metadatos, flujos de emparejamiento y comportamientos de autorización más granulares pueden definirse en especificaciones de extensión opcionales de NWC, mantenidas en https://github.com/nostr-wallet-connect/nwc. Ese repositorio, según la nueva sección, reserva 01.md para la especificación central correspondiente a este NIP-47 simplificado, con funcionalidades opcionales que empiezan en 02.md.
¿Se rompen las wallets existentes?
Nada en el diff toca el formato en la red de los cinco métodos que permanecen en el núcleo, ni los números de kind de los tres tipos de evento centrales. Una wallet o cliente construido contra el 47.md anterior que implemente pay_invoice, get_balance, make_invoice, lookup_invoice y get_info sigue funcionando exactamente igual que antes. El PR tampoco reescribe los cuerpos de solicitud y respuesta de las funcionalidades que elimina, como pay_keysend o los métodos de facturas retenidas, así que su forma en la red previamente documentada tampoco cambia retroactivamente con este diff: simplemente ya no está especificada dentro de 47.md.
El único punto concreto de compatibilidad es la etiqueta de capacidades del evento de información: la etiqueta notifications ya no aparece en la especificación, reemplazada por el esquema de etiqueta e identificadores extensions. Las implementaciones nuevas escritas solo a partir del 47.md actual cubrirán los cinco métodos centrales, a menos que también consulten el repositorio de extensiones.
Por qué la división
Según la descripción del PR, el objetivo es mantener 47.md pequeño, estable y fácil de implementar, dando a las funcionalidades opcionales de NWC un lugar dedicado para evolucionar de forma independiente. El autor describe el trabajo como relacionado con ideas del proyecto matbalez/universal-lightning-wallet, y alineado con una dirección acordada en una discusión previa en el repositorio de NIPs: dejar espacio para una futura especificación de wallet más simple, reconociendo que NIP-47 ya podía reducirse moviendo funcionalidad menos común fuera de su núcleo.
Fuentes
Toda afirmación de este artículo enlaza a una fuente primaria.
- NIP-47: simplify core spec and introduce extensions — nostr-protocol/nips (1 de agosto de 2026)