How npub.cash could help onboard the next generation of Lightning users

When I woke up one day only to see that npub.cash went "public" overnight I was stunned. It has been an amazing journey so far and I am so grateful for all the feedback I got so far. Building this was fun but seeing people use it daily is wild. Thank you

However today npub.cash is not what I envisioned it to be. It is not even close to its final form ;) This blog post strives to lay out the vision that I have and what might already be possible today.

Nostr-native authorization and identifiers

npub.cash offers many benefits over traditional Lightning Addresses. Because it is built on Cashu its users can receive sats more privately. While it remains custodial the custodian does not have access to your financial activity. But I think that alone is not what makes npub.cash so special. What makes it special are nostr identities. The most obvious part is that, even though you get a personal address, there are no accounts that need to be created. Every nostr user has an npub.cash address by default. But there is more. npub.cash is a centralized service, but its authorization is not proprietary. There are no API keys, no user accounts, and no sign-up. Just nostr identities and signatures. Anyone can build a npub.cash client and start communicating with the server today. The API is public and the authorization is not "gated". Which makes the perfect segway into the main part of this article

npub.cash is for everyone to use and implement

Right now all npub.cash users use the project's website to interface with their npub.cash wallet. While this does work (mostly) it was never meant that way. This website was never supposed to be the main gateway, it was supposed to be a demo. A simple interface to get started and to play around in. While it offers all the required features, it adds unnecessary friction to the whole experience. Where npub.cash could shine is a programmatic implementation that hides details from the end-user. Because the auth schema is based on nostr signature, every application that has access to a nostr privatekey can already access all endpoints. When I started working on npub.cash I wanted to build a simple Lightning Address provider for offline-first wallets. Below are two examples of how I think npub.cash would be way more useful than it is today.

Example 1: A npub.cash enabled Cashu wallet

Cashu wallets began to implement nostr as a social layer long ago. eNuts for example lets you add your private key to send ecash to your peers via nostr DMs. Because of the fact that eNuts already has access to a user's private key, it is the perfect example of a low-hanging fruit. It would be a piece of cake for eNuts to use this key to create NIP-98 events to automatically claim a user's npub-cash balance and add it to the local wallet balance, effectively adding a Lightning Address to the wallet. Right now I am working on enabling WebSocket connections on npub.cash, meanwhile my good friend and co-founder Starbuilder is already playing with the thought of an npub.cash PR for eNuts. Maybe soon we can see how npub.cash can provide a Lightning Address for an offline first wallet like eNuts.

Example 2: A npub.cash enabled nostr client

This is where things get spicy... When new people create a nostr identity for the very first time, they might not have a Lightning address. But not having a Lightning Address means not being able to receive Zaps, which arguably makes the whole experience less fun. I mean without Zaps nostr is just a decentralized information network, right?... But if you read carefully thanks to npub.cash there really isnt any nostr profile that has got no Lightning Address, as anyone has at least a npub.cash address. Clients could offer users a "default" address which is their npub.cash address. As outlined above, clients already have everything that is required to interface with the npub.cash API on behalf of the user. Because npubcash-server is open source, they can even host the service themselves to reduce third-party dependencies. We could even take this a step further and simply assume npub.cash as given. Gigi proposed something very interesting for Amethyst a couple of weeks ago. If clients implement npub.cash as a given, there wouldn't be a "unzapable" user left. And honestly, I think this is how we onboard the next generation of Lightning users. Of course for this to work all the complexity of claiming ecash and redeeming it needs to be abstracted away. But again, because of the way npub.cash is built, any nostr client could do that easily today.

Final thoughts

I think this brief outline of what I imagine npub.cash could become, makes it pretty clear that there is still some distance ahead. I will continue to work on this vision over the next couple of weeks and months. While there is a huge backlog of enhancements for npubcash-server that I am working to get through, I will spend more time working on client-side libraries to make the integration into other projects easier. If you feel like I might be on to something here, and you want to help us get there, please reach out to me!