Going into the future of Bitcoin adoption and development there is one issue of software interacting that is coming to the forefront of roadblocks developers must deal with: compatibility. As applications and protocols in this space become more complex and featureful in order to meet the needs of actual users and use cases, this presents a dilemma that fundamentally has only two real answers; either an application or wallet must internally integrate every protocol and feature necessary to meet the requirements of its purpose, or different applications must be able to talk to each other.
One example of where this issue crops up is the integration of Lightning into different applications and software tools. Lightning is a very complicated protocol stack to implement, involving numerous sub-protocols dictating how to coordinate and process updates to the state of a Lightning channel. This involves the transaction structure for each channel state and what it is enforcing, the order in which each step of crafting and signing new transactions is conducted to guarantee safety of user funds, and functions to watch the blockchain to react in the appropriate way automatically if invalid states are ever submitted to the blockchain.
This is a lot of complexity for a single application developer to take on themselves directly integrating to their project. The obvious conclusion if that requires too much effort is to depend on already produced software handling the problem of implementing Lightning, and simply build your application to talk to that external software. That leads to the next problem: what if your application’s users don’t use that particular Lightning implementation or wallet?
Even by outsourcing that functionality of an app the development team still hasn’t fully escaped the complexity problem. While they don’t have to fully implement Lightning on their own, a developer taking this route now has to handle incorporating API support for any Lightning wallet the user of their application could potentially be using. This necessitates keeping up with any changes or alterations to multiple Lightning wallets, their API, how the internal features of that wallet works and which ones they support. Not keeping up with any changes in a particular wallet would break their application for users of that wallet.
Some standardized mechanism needs to exist for software on both sides of that gap to simply be able to implement that one thing for all of these different tools to talk to each other. This would allow each application developer, and each Lightning wallet developer, to all simply integrate and maintain one single protocol that would enable their applications to communicate with each other.
Nostr Wallet Connect is a protocol making the attempt at being a truly generalized mechanism for fulfilling this need. When seeking to embed Lightning payments into Nostr, all of these complexity issues arriving from how to do it cropped up.
The team behind Amethyst, a Nostr client, and Alby, the web based Lightning wallet, created NWC in order to solve the problem of Nostr users wishing to integrate Lightning into their Nostr experience without having to use a special purpose wallet. The application/protocol is based on Nostr’s identity architecture where every message (event) sent over Nostr is signed by a cryptographic keypair functioning as your identity on Nostr. This allows an application to simply generate a Nostr keypair, and from that alone have a cryptographic authentication mechanism to use in communicating with an external Bitcoin wallet to fulfill the functionality of the app.
[INSERT INFO HERE]
Using the keypair to register the external application with the Lightning wallet, the application can now ping your wallet to initiate a payment. The specification currently supports paying BOLT 11 invoices, making keysend payments (invoiceless payments made to a node’s public key), paying multiple invoices simultaneously, generating an invoice to present to someone else to pay you, and a few other functionalities to allow payment history and wallet balance queries from the external application.
All of this is coordinated over Nostr, allowing for a very redundant means of communication not dependent on a single centralized messaging mechanism or the user needing to depend on complicated software such as Tor or other protocols to facilitate the network connection between an application and wallet software or infrastructure running on their home network. Nostr also supports encrypted direct messages, meaning the communication between the wallet and the application is entirely private, revealing no details about payments being coordinated to the Nostr relays used to communicate.
On the wallet side of the NWC bridge, security restrictions can be implemented to prevent the external application from having unfettered access to wallet funds in the case the Nostr key used to communicate with the wallet was compromised. Restrictions on the amounts allowed to be spent, as well as the frequency of payments, are configurable on the wallet side of the connection.
NWC is useful for far more than simply integrating Lightning into Nostr applications as well. The entire design philosophy of Nostr itself as a protocol was centered around keeping it simple enough that the entire protocol could be easily implemented correctly by any developer with minimal time and resources. Applications that have nothing to do with Nostr can easily integrate NWC or similar protocols with almost no overhead or complexity to address the underlying issues of how to connect a Bitcoin wallet with their application without having to build it directly into the app.
The potential for a protocol like NWC to provide massive value to wallet and application developers goes far beyond integrating Lightning wallets into special purpose applications. The entire long term direction of interacting with Bitcoin, short of some mind blowing fundamental breakthrough no one has yet realized, is towards interactive protocols between multiple users.
Multiparty coinpools are a perfect example. Most of the specific design proposals like Ark or Timeout trees are built around a central coordinating party or service provider, which can easily facilitate a means of message passing between users wallets, but this hamstrings the design space with a single point of failure. If a hundred users are packed into a coinpool together on top of a single UTXO, the security model is based around each user having a pre-signed pathway to withdraw their coins unilaterally on-chain. This mechanism can be exercised in the event of any failure or disappearance of the coordinator to ensure their funds are not lost, but this is the least efficient way to handle such a worst case scenario.
If users were able to find a mechanism to communicate with each other in the absence of the service provider or coordinator, much more efficient on-chain exits could be achieved by using the larger group multisig to migrate their funds elsewhere with a much more efficient (and therefore cheaper) on-chain footprint. NWC and Nostr are a perfect fit for such a scenario.
Collaborative multisignature wallets between multiple parties could also benefit from such a protocol. In combination with standards like PSBT, a simple Nostr communication mechanism could drastically simplify the complexity of different wallets with multisig support coordinating transaction signing in a smooth and user friendly way.
Discreet Log Contracts (DLC) are another amazing use for such a protocol. The entire DLC scheme relies on both parties being able to access oracle signatures to unilaterally close a contract correctly if both parties will not cooperate to settle it collaboratively. Nostr is the perfect mechanism for oracles to broadcast these signatures, and allow for a simple subscription to their Nostr key in users wallets to automatically track and acquire signatures when broadcast by oracles.
As time goes on and more applications and protocols are built on top of Bitcoin with the requirement of interactivity between users, and between different applications, a general purpose communication mechanism to facilitate that without relying on a single point of failure is going to be sorely needed.
Nostr is the perfect underlying protocol to facilitate that given its incredible simplicity and the redundancy of a large set of relays to utilize. NWC is the perfect example of that being a viable solution.
One example of where this issue crops up is the integration of Lightning into different applications and software tools. Lightning is a very complicated protocol stack to implement, involving numerous sub-protocols dictating how to coordinate and process updates to the state of a Lightning channel. This involves the transaction structure for each channel state and what it is enforcing, the order in which each step of crafting and signing new transactions is conducted to guarantee safety of user funds, and functions to watch the blockchain to react in the appropriate way automatically if invalid states are ever submitted to the blockchain.
This is a lot of complexity for a single application developer to take on themselves directly integrating to their project. The obvious conclusion if that requires too much effort is to depend on already produced software handling the problem of implementing Lightning, and simply build your application to talk to that external software. That leads to the next problem: what if your application’s users don’t use that particular Lightning implementation or wallet?
Even by outsourcing that functionality of an app the development team still hasn’t fully escaped the complexity problem. While they don’t have to fully implement Lightning on their own, a developer taking this route now has to handle incorporating API support for any Lightning wallet the user of their application could potentially be using. This necessitates keeping up with any changes or alterations to multiple Lightning wallets, their API, how the internal features of that wallet works and which ones they support. Not keeping up with any changes in a particular wallet would break their application for users of that wallet.
Some standardized mechanism needs to exist for software on both sides of that gap to simply be able to implement that one thing for all of these different tools to talk to each other. This would allow each application developer, and each Lightning wallet developer, to all simply integrate and maintain one single protocol that would enable their applications to communicate with each other.
Nostr Wallet Connect is a protocol making the attempt at being a truly generalized mechanism for fulfilling this need. When seeking to embed Lightning payments into Nostr, all of these complexity issues arriving from how to do it cropped up.
Lightning And NWC
The team behind Amethyst, a Nostr client, and Alby, the web based Lightning wallet, created NWC in order to solve the problem of Nostr users wishing to integrate Lightning into their Nostr experience without having to use a special purpose wallet. The application/protocol is based on Nostr’s identity architecture where every message (event) sent over Nostr is signed by a cryptographic keypair functioning as your identity on Nostr. This allows an application to simply generate a Nostr keypair, and from that alone have a cryptographic authentication mechanism to use in communicating with an external Bitcoin wallet to fulfill the functionality of the app.
[INSERT INFO HERE]
Using the keypair to register the external application with the Lightning wallet, the application can now ping your wallet to initiate a payment. The specification currently supports paying BOLT 11 invoices, making keysend payments (invoiceless payments made to a node’s public key), paying multiple invoices simultaneously, generating an invoice to present to someone else to pay you, and a few other functionalities to allow payment history and wallet balance queries from the external application.
All of this is coordinated over Nostr, allowing for a very redundant means of communication not dependent on a single centralized messaging mechanism or the user needing to depend on complicated software such as Tor or other protocols to facilitate the network connection between an application and wallet software or infrastructure running on their home network. Nostr also supports encrypted direct messages, meaning the communication between the wallet and the application is entirely private, revealing no details about payments being coordinated to the Nostr relays used to communicate.
On the wallet side of the NWC bridge, security restrictions can be implemented to prevent the external application from having unfettered access to wallet funds in the case the Nostr key used to communicate with the wallet was compromised. Restrictions on the amounts allowed to be spent, as well as the frequency of payments, are configurable on the wallet side of the connection.
NWC is useful for far more than simply integrating Lightning into Nostr applications as well. The entire design philosophy of Nostr itself as a protocol was centered around keeping it simple enough that the entire protocol could be easily implemented correctly by any developer with minimal time and resources. Applications that have nothing to do with Nostr can easily integrate NWC or similar protocols with almost no overhead or complexity to address the underlying issues of how to connect a Bitcoin wallet with their application without having to build it directly into the app.
Beyond Lightning
The potential for a protocol like NWC to provide massive value to wallet and application developers goes far beyond integrating Lightning wallets into special purpose applications. The entire long term direction of interacting with Bitcoin, short of some mind blowing fundamental breakthrough no one has yet realized, is towards interactive protocols between multiple users.
Multiparty coinpools are a perfect example. Most of the specific design proposals like Ark or Timeout trees are built around a central coordinating party or service provider, which can easily facilitate a means of message passing between users wallets, but this hamstrings the design space with a single point of failure. If a hundred users are packed into a coinpool together on top of a single UTXO, the security model is based around each user having a pre-signed pathway to withdraw their coins unilaterally on-chain. This mechanism can be exercised in the event of any failure or disappearance of the coordinator to ensure their funds are not lost, but this is the least efficient way to handle such a worst case scenario.
If users were able to find a mechanism to communicate with each other in the absence of the service provider or coordinator, much more efficient on-chain exits could be achieved by using the larger group multisig to migrate their funds elsewhere with a much more efficient (and therefore cheaper) on-chain footprint. NWC and Nostr are a perfect fit for such a scenario.
Collaborative multisignature wallets between multiple parties could also benefit from such a protocol. In combination with standards like PSBT, a simple Nostr communication mechanism could drastically simplify the complexity of different wallets with multisig support coordinating transaction signing in a smooth and user friendly way.
Discreet Log Contracts (DLC) are another amazing use for such a protocol. The entire DLC scheme relies on both parties being able to access oracle signatures to unilaterally close a contract correctly if both parties will not cooperate to settle it collaboratively. Nostr is the perfect mechanism for oracles to broadcast these signatures, and allow for a simple subscription to their Nostr key in users wallets to automatically track and acquire signatures when broadcast by oracles.
As time goes on and more applications and protocols are built on top of Bitcoin with the requirement of interactivity between users, and between different applications, a general purpose communication mechanism to facilitate that without relying on a single point of failure is going to be sorely needed.
Nostr is the perfect underlying protocol to facilitate that given its incredible simplicity and the redundancy of a large set of relays to utilize. NWC is the perfect example of that being a viable solution.
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
