As we move into the future of bitcoin adoption and development, there is one software interaction issue that is moving to the forefront of the hurdles developers must deal with: compatibility. As applications and protocols in this space become more complex and feature-rich to meet real user needs and use cases, this presents a dilemma that fundamentally only has two real answers; An application or wallet must internally integrate all the necessary protocols and functions to meet the requirements of its purpose, or different applications must be able to communicate with each other.
An example of where this problem arises is the integration of Lightning into different applications and software tools. Lightning is a very complicated protocol stack to implement, involving numerous subprotocols that dictate how to coordinate and process state updates from a Lightning channel. This involves the transaction structure for each channel state and what is applied, the order in which each step of creating and signing new transactions is carried out to ensure the security of user funds, and functions to observe for the blockchain to automatically react appropriately if invalid states are ever sent to the blockchain.
This represents great complexity for a single application developer to undertake direct integration into their project. The obvious conclusion, if that requires too much effort, is to rely on already produced software that handles the problem of implementing Lightning and simply build your application to communicate with that external software. That leads to the next problem: what if your app users don't use that particular Lightning implementation or wallet?
Even by outsourcing that functionality of an application, the development team has not yet completely escaped the problem of complexity. While they don't have to implement Lightning completely on their own, a developer taking this route now has to take care of incorporating API support for any Lightning wallets their app user may be using. This requires keeping up to date with any changes or alterations to multiple Lightning wallets, their API, how that wallet's internal features work, and which ones they support. Failure to keep up with changes to a particular wallet would break your app for users of that wallet.
There needs to be some standardized mechanism so that software on both sides of that divide can simply implement that so that all of these different tools talk to each other. This would allow each app developer and each Lightning wallet developer to simply integrate and maintain a single protocol that would allow their applications to communicate with each other.
Nostr Wallet Connect is a protocol that attempts to be a truly widespread mechanism to meet this need. When trying to integrate Lightning payments into Nostr, there were all these complexity issues around how to do it.
Rays and NWC
The team behind Amethyst, a Nostr client, and Alby, the web-based Lightning wallet, created NWC to solve the problem for Nostr users who want to integrate Lightning into their Nostr experience without having to use a special wallet. The application/protocol is based on the Nostr identity architecture, where each message (event) sent through Nostr is signed by a cryptographic key pair that functions as your identity in Nostr. This allows an application to simply generate a Nostr key pair and from that have a cryptographic authentication mechanism to use in communicating with an external bitcoin wallet to fulfill the application's functionality.
By using the key pair to register the external app with the Lightning wallet, the app can now ping your wallet to initiate a payment. The specification currently supports paying BOLT 11 invoices, making payments by key submission (invoiceless payments made to a node's public key), paying multiple invoices simultaneously, generating one invoice to present to another person to pay you and some other functionalities to allow payment history and wallet balance inquiries from the external application.
All of this is coordinated through Nostr, allowing for a highly redundant means of communication that does not depend on a single centralized messaging mechanism or the user needing to rely on complicated software like Tor or other protocols to facilitate the network connection between a app and wallet software. or infrastructure running on your home network. Nostr also supports encrypted direct messages, meaning communication between the wallet and the app is completely private, and does not reveal details about payments that are coordinated with 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 unlimited access to the wallet funds in case the Nostr key used to communicate with the wallet is compromised. Restrictions on the amounts allowed to be spent, as well as the frequency of payments, can be configured on the wallet side of the connection.
NWC is also useful for much more than simply integrating Lightning into Nostr apps. The entire design philosophy of Nostr as a protocol was focused on keeping it simple enough that any developer could successfully implement the entire protocol with a minimum of 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 problems of how to connect a bitcoin wallet to your application without having to build it directly in the application.
Beyond the lightning
The potential for a protocol like NWC to provide massive value to app and wallet developers goes far beyond the integration of Lightning wallets into special-purpose applications. The entire long-term direction of interaction with bitcoin, barring some mind-blowing fundamental advance that no one has noticed yet, is toward interactive protocols between multiple users.
Multi-party coinpools are a perfect example. Most specific design proposals, such as Ark or Timeout trees, are built around a central coordinating party or service provider, which can easily facilitate a means of transmitting messages between user wallets, but this paralyzes the design space with a single point of failure. If one hundred users are grouped into a coin pool on a single UTXO, the security model is based on each user having a pre-signed route to withdraw their coins unilaterally on the chain. This mechanism can be exercised in the event that the coordinator cannot guarantee that their funds are not lost or disappear, but this is the least efficient way to handle the worst case scenario.
If users could find a mechanism to communicate with each other in the absence of the service provider or coordinator, much more efficient chain exits could be achieved using the largest multi-signature pool to migrate their funds elsewhere in a much more efficient way (and therefore cheaper) footprint on the chain. NWC and Nostr fit this scenario perfectly.
Collaborative multi-signature wallets between multiple parties could also benefit from such a protocol. Combined with standards like PSBT, a simple Nostr communication mechanism could dramatically simplify the complexity of different wallets with multi-signature support that coordinates the signing of transactions in a seamless and easy-to-use manner.
Discrete ledger contracts (DLCs) are another surprising use of such a protocol. The entire DLC scheme is based on both parties being able to access Oracle signatures to unilaterally close a contract correctly if both parties do not cooperate to resolve it collaboratively. Nostr is the perfect mechanism for oracles to transmit these signatures and allows a simple subscription to your Nostr key in users' wallets to automatically track and acquire signatures when oracles transmit them.
As time goes on and more applications and protocols are built on top of bitcoin with the requirement for interactivity between users and between different applications, a general-purpose communication mechanism will be greatly needed to facilitate that without relying on a single point of failure. .
Nostr is the perfect underlying protocol to facilitate this given its incredible simplicity and the redundancy of a large set of relays to utilize. NWC is the perfect example of this being a viable solution.
