LUD-18 Wallet implementation #531
Conversation
Query the lightning address provider client-side to learn of capabilities Conditionally render LUD-12 and LUD-18 fields based on what the remote server says is supported Allow identifier, name, and email to be sent from the SN side during the withdrawal flow. Auth seems too complicated for our use case, and idk about pubkey?
I haven't looked at the code yet, but I'd prefer this be optional.
Hmmm I don't even know what this refers to. I'll take a look tomorrow. |
|
Every piece of payer data is opt in by default. Lightning address providers can specify whether certain pieces of payer data are required, but it's still ultimately up to the sender if they want to satisfy those requirements by supplying payer data or not. I have yet to encounter a lightning address provider that requires any payer data. Regarding auth, it is whether you want to sign the random challenge provided by the lightning address provider with your private key. Very much like LNAuth. Since stacker news does not manage private keys for users, I don't think it's worth trying to implement Wallet implementation for auth payer data. |
* dynamic client-side validation for required payer data * don't re-init form state on error * correct min and max amount values * only send applicable data to graphql api based on payerdata schema * input type for numeric values (amount, max fee) * update step for amount and max fee
|
I'll record a demo of this a little later on and attach it to this PR for reference. I think that would help to review, once it's ready. |
|
Two recordings to show functionality. I partially mocked the API response in the shorter recording to simulate the Alby supports name, email. WoS doesn't support any LUD18 fields. You can also see the dynamic LUD12 comment length when I switch between different lightning address providers. The stacker.news.lud18.wallet.movstacker.news.lud18.wallet.2.mov |
|
This looks great! |
|
I think this is ready for review now. Of course, now that I've marked it as such, I'll probably realize something else that I want to do with it 😅 |
|
FYI, I've added |
|
darth coin is going to be so happy |
Now I can send sats "from" Christine Lagarde :) |
Query the lightning address provider client-side to learn of capabilities
Conditionally render LUD-12 and LUD-18 fields based on what the remote server says is supported
Allow identifier, name, and email to be sent from the SN side during the withdrawal flow. Auth seems too complicated for our use case, and idk about pubkey?