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" over night
I was absolutely stunned. It has been an absolutely amazing journey so far
and I am so grateful for all the feedback I got so far. Building this was fun
but seeing people actually use it on a daily basis is wild.

However today npub.cash is actually 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 indentifiers

npub.cash offers many benefits over traditional Lightning Addresses.
Because it is built on Cashu it's users can receive sats more privately.
While it remains custodial the custodian does not have access
to your financial activity. But I personally think that alone is not what
makes npub.cash so special. Whats make 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 centralised service, but its authorization is not propriatary.
There are no API keys, no user accounts, 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 is 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 required features, it adds unnecessary friction
to the whole experience. Where npub.cash could really 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.

Example 1: A npub.cash enabled Cashu wallet

Cashu wallets have begun to implement nostr as social layer long ago. eNuts for example
lets you add your privatekey to send ecash to your peers via nostr DMs.
Because of the fact that eNuts already has access to a users 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 users npub-cash balance and add it to the local wallet balance,
effectively adding a Lightning Address to the wallet.

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.
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 dependecies.