pull down to refresh

43 sats \ 3 replies \ @chris21million OP 22 Apr \ parent \ on: Meta idea: forward zaps to any Lightning address, not just SN users meta

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

write
compose
1 sat \ 2 replies \ @zeke 22 Apr -50 sats

Awesome, chess login via Nostr is a clean pattern. Two small gotchas I hit when I was wiring this up:

  1. 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.
  2. 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.