Pedro 🧨

Show thread history

Pedro 🧨

3d ago

Nice summary

See translation

Do you have thoughts?

Replies

Rizful.com (zap tester)

@Rizful.com (zap tester)

3d ago

Testing zaps for this note… we made six attempts to⚡zap this note, at pedromvpg@btcpay989117.lndyn.com, over a period of 19 minutes. In each case, we found that your lightning address server did not respond correctly. (The failure point was when we did a GET request to your specified callback URL: https://btcpay989117.lndyn.com/BTC/UILNURL/pay/lnaddress/pedromvpg.) Your server did not produce an invoice, thus the zap failed. We recommend that you use a cloud-based Lightning node which is optimized for Nostr zaps, to get your zaps working.

See translation

Rizful.com

@Rizful.com

2d ago

The place for you to start is this step in NIP-57 ..https://github.com/nostr-protocol/nips/blob/3e8c33ee79e3d2eb46ca498eddadcc6ef1ef7329/57.md?plain=1#L19 .. anyway you can test it with the LONG & FAILING url I provided previously....

See translation

Rizful.com

@Rizful.com

2d ago

I actually ran into this error myself previously! I think this part of the spec is not well-worded: https://github.com/nostr-protocol/nips/blob/3e8c33ee79e3d2eb46ca498eddadcc6ef1ef7329/57.md?plain=1#L124 "the generation of the description hash invoice" .... I think that your implementation is actually putting the entire Nostr event (as a string) into the the description of the invoice... and for example LND won't allow a description over a certain number of characters! (It's a DOS vulnerability if its too long)...... So your implementation just needs to put the HASH of the nostr event into the description, not the full NOSTR event!

See translation

Rizful.com

@Rizful.com

2d ago

This is why it "works in the browser" -- because using, for example, Yakihonne, it only adds like 3 to 5 relay URLs... but in my URL, I am adding like 20 relay URLs.....

See translation

Rizful.com

@Rizful.com

2d ago

I think your "callback url" implementation is rejecting encoded nostr events which are too long ... these events can get too long (in characters) if there are a lot of relays.... the relevant part of the spec is here: https://github.com/nostr-protocol/nips/blob/3e8c33ee79e3d2eb46ca498eddadcc6ef1ef7329/57.md?plain=1#L31

See translation

Sjors Provoost

@provoost

2d ago

I assume it's a bug in the @BTCPay Server plugin? Either that or in my nginx redirect rules.

See translation

Rizful.com

@Rizful.com

2d ago

Look at the "protocol flow" here and you'll see actually to pay a zap, you need to make TWO get requests... https://github.com/nostr-protocol/nips/blob/master/57.md

See translation

Rizful.com

@Rizful.com

2d ago

See translation

Rizful.com

@Rizful.com

2d ago

And yes, the failing URL shows the error: "Lightning node could not generate invoice with description hash:" ... basically, your lightning node is refusing to generate the invoice because it doesn't like the description you provided.... I think it's because it is too long...

See translation

Sjors Provoost

@provoost

2d ago

I'm confused about the URL, why doesn't it start with pay . sprovoost . nl?

Will look into it more tomorrow(ish) after the conference...

See translation

Rizful.com

@Rizful.com

2d ago

There are two URLs in the Nip-57 dance.... the first URL... https://btcpay989117.lndyn.com/.well-known/lnurlp/pedromvpg .. and then you use the "callback" url provided in this response.... and you shove an entire NOSTR event onto that URL! It's pretty ugly but it works!

See translation