105 sats \ 19 replies \ @DarthCoin 5 Oct 2023 \ on: SN release: nostr crossposting, symmetric lud18, quote replies, @ autocompletes meta
@WeAreAllSatoshi can you check the LUD-18 and LUD-12 option?
I tried to send some tests to chat@blixtwallet.com or darthcoin@ln.tips or darthcoin@getalby.com (all of them support LUD-18 and 12 and the modal for comment and name is not appearing in SN payment screen (using the LN address field).
If I want to send to chat@blixtwallet.com (https://chat.blixtwallet.com/) 10 sats it appear the comment and name but I get an error: Unexpected error value: [400, "expectedPaymentRequestToDecode"]
If I want to send to chat@blixtwallet.com (https://chat.blixtwallet.com/) 10 sats it appear the comment and name but I get an error: Unexpected error value: [400, "expectedPaymentRequestToDecode"]
expectedPaymentRequestToDecode appears to be coming the lightning npm lib, and is decoding an invoice.Perhaps the invoice request (i.e calling the callback in LNURL-pay) didn't work properly for some reason and did not return an invoice.
reply
@hampus I see this in the logs when trying to call the invoice request from my dev machine:
{ statusCode: 500, error: 'Internal Server Error', message: 'Could not parse query params' }
with a query param string of
?amount=10000&payerdata=%257B%2522identifier%2522%253A%2522SatsAllDay%2540stacker.news%2522%257DAn issue decoding the URI encoded param, maybe?
ETA: same thing when you send
name, as well. Are we doing the payerdata query param encoding incorrectly?reply
@hampus Taking a look at chat.blixtwallet.com's code, I don't see any explicit decoding of the query param: https://github.com/hsjoberg/lnurl-pay-chat-server/commit/a28f998675a675a835ea1a639be2ec1f1fdae0ec#diff-a2a171449d862fe29692ce031981047d7ab755ae7f84c707aef80701b3ea0c80L226
Perhaps we're double encoding when we shouldn't be?
reply
I don't see any explicit decoding of the query param:
It was some time ago I made this server, but I think Fastify is implicitly decoding the GET params. It makes it into an object.
It will naturally not attempt to decode twice, which is why the
JSON.parse() errors out.reply
Perhaps we're double encoding when we shouldn't be?
Yes, as far as I can tell, it seems to be double-encoded when it shouldn't be.
A quick look.
Yours require two
decodeURIComponents:// stacker.news decodeURIComponent(decodeURIComponent("%257B%2522identifier%2522%253A%2522SatsAllDay%2540stacker.news%2522%257D")); '{"identifier":"SatsAllDay@stacker.news"}' // blixt wallet decodeURIComponent("%7B%22name%22%3A%22Hampus%22%2C%22identifier%22%3A%22hampus%40blixtwallet.com%22%7D"); '{"name":"Hampus","identifier":"hampus@blixtwallet.com"}'
reply
Though I'm not sure who's in the wrong here. I'll investigate some more.
reply
We’re probably getting URI encoding for free with the native JS API that constructs the URL
reply
Perhaps we're double encoding when we shouldn't be?
Yes, my understanding after reading the specification again is that it should not be encoded twice.
reply
Yea that makes sense. I’ll work up a fix today!
reply
Great!
Cheers.
reply
I got this too. I’ll debug when at my computer
reply
If you don’t include your identifier, it seems to work.
reply
but that is just posting as anonymous
reply
Yea, I’m just trying to figure out what conditions cause the error. I’m still on mobile, I’ll dig into it further in a little while
reply
I just tried this and it seemed to work?
![]()
reply
For me appear for a second the fields and then disappear.
Only when I use chat@blixtwallet.com it stays.
Maybe after first use is something in the browser cache?
reply
We query the ln addr provider every time you change the address, character by character. We probably need to debounce this, because if you're on the second to last character, there won't be valid metadata (e.g.
darthcoin@stacker.new), so we default the form state. If these requests resolve out of order, you could end up in a state with no LUD-12 or LUD-18 options in the form. Debouncing should resolve it.cc @k00b
reply