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.