When delving into the future of Bitcoin adoption and development, there is one software interaction issue that is at the forefront of the roadblocks developers must address: compatibility. As applications and protocols in this area become more complex and feature-rich in order to meet the needs of actual users and use cases, this presents a dilemma that essentially has only two real answers; 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 where this issue arises is the integration of Lightning into various applications and software tools. Lightning is a very complex protocol stack to implement, and includes many sub-protocols that dictate how updates to the state of the Lightning channel are formatted and processed. This includes the transaction structure of each channel state and what is executed, the order in which each step of crafting and signing new transactions is performed to ensure the safety of user funds, and blockchain monitoring functions to react in the appropriate manner automatically if invalid states are sent to the blockchain.
This is too complex for a single application developer to directly integrate with their project. The obvious conclusion if this requires a lot of effort is to rely on already produced software that handles the Lightning implementation problem, and simply build your own application to talk to that external software. This leads to the following problem: What if your app users are not using the Lightning app or the specific wallet?
Even by outsourcing this application-specific functionality, the development team does not completely escape the complexity issue. Although they don't have to fully implement Lightning on their own, a developer going this route will now have to deal with integrating API support for any Lightning wallet a user of their app is likely to use. This requires keeping up with any changes or modifications to multiple Lightning wallets, their API, how the internal features of that wallet work, and the features they support. Not keeping up with any changes in a particular wallet may result in their app crashing for users of that wallet.
There has to be a unifying mechanism for software on both sides of that divide so that you can simply implement this one thing for all of these different tools to talk to each other. This would allow every app developer, and every Lightning wallet developer, to integrate and maintain a single protocol that would enable their applications to communicate with each other.
Nostr Wallet Connect is a protocol that attempts to be a truly generalized mechanism to meet this need. When looking to include Lightning payments in Nostr, there were all these complex issues of how to do it.
Lightning and NWC
The team behind Amethyst, a Nostr client, and Alby, a web-based Lightning wallet, created NWC in order to solve the problem of Nostr users who want to integrate Lightning into their Nostr experience without having to use a special-purpose wallet. The application/protocol is based on the Nostr identity architecture where every message (event) sent through Nostr is signed by an encrypted key pair that acts as your identity on Nostr. This allows the application to simply generate a Nostr key pair, and through that alone have a cryptographic authentication mechanism to use in communicating with an external Bitcoin wallet to achieve the application's functionality.
By using the key pair to register the external app with your Lightning wallet, the app can now ping your wallet to initiate the payment. The specification currently supports paying BOLT 11 bills, making key payments (non-invoice payments made on the node's public key), paying multiple bills at once, creating an invoice to present to someone else to pay you, and some other functions to allow payment history and wallet balance inquiry. From external application.
All of this is coordinated via Nostr, allowing for a redundant means of communication that does not rely on one central messaging mechanism or the user needing to rely on complex software like Tor or other protocols to facilitate network communication between the app and the wallet software. Or the infrastructure running on their home network. Nostr also supports encrypted direct messaging, which means the communication between the wallet and the app is completely private, revealing no details about the payments being coordinated with the Nostr relays used to communicate.
On the wallet side of the NWC bridge, security restrictions can be implemented to prevent an external application from unrestricted access to the wallet funds if 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 useful for more than just integrating Lightning into Nostr applications, too. The entire design philosophy of Nostr as a protocol was to keep it simple enough that the entire protocol could easily be implemented correctly by any developer with a minimum of time and resources. Applications unrelated to Nostr can easily integrate NWC or similar protocols with almost no overhead or complexity to address the basic issues of how to connect a Bitcoin wallet to their applications without having to build it directly in the application.
Beyond lightning
The potential for a protocol like NWC to provide tremendous value to wallet and application developers goes far beyond integrating Lightning wallets into special-purpose applications. The entire long-term trend of Bitcoin interaction, other than some amazing fundamental breakthroughs that no one has yet realized, is toward interactive protocols between multiple users.
Multilateral coin pools are a perfect example. Most specific design proposals such as Ark or Timeout trees are built around a central coordination edge or service provider, which can easily facilitate a means of passing messages between user wallets, but this clutters the design space with a single point of failure. If a hundred users in a coin pool are grouped together over a single UTXO, the security model relies on each user having a pre-signed path to withdrawing their coins unilaterally on the chain. This mechanism can be exercised in the event of any failure or disappearance of the coordinator to ensure that his money is not lost, but this is the least efficient way to deal with such a worst-case scenario.
If users can find a mechanism to communicate with each other in the absence of a service provider or coordinator, more efficient on-chain exits can be achieved by using the larger multisig pool to migrate their funds elsewhere in a more efficient (and thus cheaper) on-chain footprint. NWC and Nostr are well suited for such a scenario.
Collaborative multi-signature wallets between multiple parties can also benefit from this protocol. In combination with standards like PSBT, Nostr's simple communication mechanism can greatly simplify the complexity of various wallets with multisig support for seamless, user-friendly transaction signing coordination.
Secret ledger contracts (DLC) are another great use of such a protocol. The entire DLC scheme relies on both parties being able to access oracle signatures to validly conclude the contract unilaterally if both parties do not cooperate to settle it cooperatively. Nostr is the ideal mechanism for oracles to broadcast these signatures, and allows a simple subscription of their Nostr key to users' wallets to automatically track and obtain signatures when broadcast by oracles.
As time goes by and more applications and protocols are created on top of Bitcoin with requirements for interaction between users, and between different applications, there will be a critical need for a general purpose communication mechanism to facilitate this without relying on a single point of failure. .
Nostr is the ideal underlying protocol to facilitate this due to its incredible simplicity and redundancy for a wide range of relays to take advantage of. The National Water Company is the perfect example of this being a viable solution.
