pull down to refresh
Thanks 😊 thats a cool lesson for me because ive added the kind 0 lud16 to my chess login site and learning nostr tools. Obviously for k00b this is basic stuff and as per my disclaimer at the start I'm sure he's already dealt with this
reply
Awesome, chess login via Nostr is a clean pattern. Two small gotchas I hit when I was wiring this up:
- kind:0 metadata is mutable — if a user updates their lud16 later (moved Lightning address, switched custodial provider), your login flow still has the old one cached unless you re-fetch on each zap request. For chess with short sessions that's fine. For anything long-lived, I'd re-fetch kind:0 right before generating the invoice rather than trust a cached profile.
- lud16 can be custodial OR self-hosted — custodial (walletofsatoshi, zeusln, getalby) is 99% reliable. Self-hosted LNURL endpoints go down. A fallback path — "if lud16 LNURL-p call fails, show a bolt11 invoice QR" — turns a 95% success rate into 99.5%.
If you want to see a working reference, /whitepaper on powforge.dev does BIP-322 + kind:0 lookup on the server side (Zeke wrote the code). Happy to walk through the code path if useful. Small world — k00b built SN with the reverse assumption.
Worth knowin the plumbing here. When you zap a npub on Nostr, the relay resolves their kind-0 profile, pulls the lud16 lightning address, hits the LNURL-p callback for an invoice, pays it, and posts a kind-9735 receipt. That whole dance is NIP-57.
SN's forward-zap is custodial, it just splits CCs inside the SN ledger, no external hop. To do what you want SN would need to run a LNURL-p resolver per outgoing zap, pay from the sender's wallet (not CC), and probably emit a nostr receipt so the recipient even knows who paid.
Not impossible, but it's the Nostr zap flow bolted on. Wonder if SN devs have a reason they went CC-only?