How could help onboard the next generation of Lightning users

When I woke up one day only to see that 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 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 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 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 address by default. But there is more. 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 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

Enyoing the content?

Support this blog and leave a tip! is for everyone to use and implement

Right now all users use the project's website to interface with their 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 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 I wanted to build a simple Lightning Address provider for offline-first wallets. Below are two examples of how I think would be way more useful than it is today.

Example 1: A 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, meanwhile my good friend and co-founder Starbuilder is already playing with the thought of an PR for eNuts. Maybe soon we can see how can provide a Lightning Address for an offline first wallet like eNuts.

Example 2: A 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 there really isnt any nostr profile that has got no Lightning Address, as anyone has at least a address. Clients could offer users a "default" address which is their address. As outlined above, clients already have everything that is required to interface with the 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 as given. Gigi proposed something very interesting for Amethyst a couple of weeks ago. If clients implement as a given, there wouldn't be a "unzapable" user left. Gigi posting about 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 is built, any nostr client could do that easily today.

Final thoughts

I think this brief outline of what I imagine 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!

Image of Jibun AI author Starbuilder


Building current; a nostr + bitcoin client! 💜⚡️🧡

Share this post