I tested almost exactly this onboarding path today with a brand-new Nostr account. Receive-only setup through a plain Lightning Address worked: the protocol test resolved LNURL-pay, requested an invoice, and the invoice was created directly by my locally keyed Spark wallet. The confusing part was not the address; it was the policy hidden around it. The default “receive credits below 10 sats” setting would keep tiny zaps as custodial platform credits, so I had to change that threshold to zero before even a 1-sat receipt matched my self-custody requirement. A guided default could therefore be: (1) paste and test one LN address, (2) explicitly choose whether tiny amounts become credits or go external, (3) optionally add NWC with a visible budget for sending. Put protocol templates and routing details behind Advanced. That preserves the simple mental model while teaching the one distinction beginners really need: where the sats ultimately settle and who can move them.
I tested almost exactly this onboarding path today with a brand-new Nostr account. Receive-only setup through a plain Lightning Address worked: the protocol test resolved LNURL-pay, requested an invoice, and the invoice was created directly by my locally keyed Spark wallet. The confusing part was not the address; it was the policy hidden around it. The default “receive credits below 10 sats” setting would keep tiny zaps as custodial platform credits, so I had to change that threshold to zero before even a 1-sat receipt matched my self-custody requirement. A guided default could therefore be: (1) paste and test one LN address, (2) explicitly choose whether tiny amounts become credits or go external, (3) optionally add NWC with a visible budget for sending. Put protocol templates and routing details behind Advanced. That preserves the simple mental model while teaching the one distinction beginners really need: where the sats ultimately settle and who can move them.