LUD-18 Service Support #518

SatsAllDay · 2023-09-24T20:24:00Z

This PR implements LUD-18¹, namely incorporating payer data in payRequest invoices.

I have made all identification methods optional (mandatory: false), this can change over time if needed.

LUD-18 Spec ↩

SatsAllDay

It feels weird not doing anything with the payer data, but I guess that's not really part of the spec. Just hashing it into the invoice, if provided. Let me know what you think!

SatsAllDay · 2023-09-25T16:04:15Z

next.config.js

@@ -62,17 +66,15 @@ module.exports = withPlausibleProxy()({
      {
        source: '/.well-known/:slug*',
        headers: [
-          ...corsHeaders
+          ...corsHeaders,
+          noCacheHeader


I set no caching here since we include a k1 in the response payload that's unique for each request.

SatsAllDay · 2023-09-25T16:04:24Z

next.config.js

@@ -83,7 +85,8 @@ module.exports = withPlausibleProxy()({
      {
        source: '/api/lnurlp/:slug*',
        headers: [
-          ...corsHeaders
+          ...corsHeaders,
+          noCacheHeader


Same as above

SatsAllDay · 2023-09-25T16:05:41Z

pages/api/lnurlp/[username]/index.js

+  k1Cache.set(k1, username)
+  // Invalidate the k1 after 10 minutes, if unused
+  setTimeout(() => {
+    k1Cache.delete(k1)
+  }, 1000 * 60 * 10)
+


I went with an in-memory cache because it felt like overkill to store this in the DB. However, I am not certain of SN's deployment architecture (i.e. are there several server instances behind a load balancer?), so if we need to push the k1 cache to the DB to share across instances, I can make those changes. Just let me know.

Yes we have serveral servers behind a load balancer

OK, I'll move it to the DB, then. Thank you for the confirmation.

huumn · 2023-09-26T21:52:19Z

It feels weird not doing anything with the payer data

Is the intent to extend this to do more? Because I agree. I'm not sure we're gaining anything here yet

SatsAllDay · 2023-09-26T23:38:33Z

It feels weird not doing anything with the payer data

Is the intent to extend this to do more? Because I agree. I'm not sure we're gaining anything here yet

I didn't have any specific plans. I think what we gain with this is spec compliance, so the question may really be, what does the spec give us? My understanding is that there's value is hashing payer identifying data into the invoice so that you can provide proof of payment, should you need to (meaning, alice payed this invoice, not bob).

We could store the payer data as a string in the invoice table and show it to the payee on the invoice instance page, tucked in an accordion or something. But I'm not sure we should, because I'm not sure wallets indicate whether this information is exposed to the payee like they do with LUD-12 comments. See Open Bitcoin Wallet for an example of this, I found this on DarthCoin's substack. Alby doesn't seem to make this distinction in their UX, so it's hard to say...

huumn · 2023-09-27T00:23:37Z

I could see this being more useful in the other direction: when someone goes to pay SN, we give them a photo and stats and stuff so they can verify it's going to the right place ... or when someone is paying out of SN, we give them a photo and stuff about the person they're sending to.

SatsAllDay · 2023-09-27T00:40:09Z

I could see this being more useful in the other direction: when someone goes to pay SN, we give them a photo and stats and stuff so they can verify it's going to the right place ... or when someone is paying out of SN, we give them a photo and stuff about the person they're sending to.

I need to think about this some more, but this sounds more like recipient (of the sats) validation vs sender (of the sats) validation, which, AFAICT, isn't really what LUD-18 is about? I might just need to re-read the above a few times for it to click...

huumn · 2023-09-27T02:01:45Z

Yeah it's probably another spec item.

Darth-Coin · 2023-09-27T12:15:15Z

Here you can test LUD-18 very nice.
https://chat.blixtwallet.com/
Is a very cool and useful feature for a wallet or service.
Blixt wallet have it also implemented.
Hampus (Blixt dev) is actually the one that create this LUD-18

SatsAllDay · 2023-09-27T13:39:08Z

Here you can test LUD-18 very nice. https://chat.blixtwallet.com/ Is a very cool and useful feature for a wallet or service. Blixt wallet have it also implemented. Hampus (Blixt dev) is actually the one that create this LUD-18

Thank you Darth, that is a neat place to experiment. I used Alby to send and I can see my LUD-12 message (comment) and also the name I sent along (LUD-18).

So from the SN perspective, perhaps we could store the identification info in our invoice DB, and extract any human-readable identification methods and include those in invoice notifications and listings? I was just concerned about privacy, exposing payer data to the payee, but I guess that's the point?

Let me know what you think, @huumn , I can update the PR to reflect those changes to make this more useful!

huumn · 2023-09-27T13:47:21Z

Privacy was my concern as well, but if the payer is opting in I guess it's what they want.

we could store the identification info in our invoice DB, and extract any human-readable identification methods and include those in invoice notifications and listings

Let's do it

hsjoberg · 2023-09-27T16:28:39Z

what does the spec give us?

@SatsAllDay So I think for stacker.news, it could be nice to have the payerdata visible in the transaction log, as you guys have already talked about. Specifically, name and identifier(meaning Lightning Address) has some support across the ecosystem with OBW, Blixt, etc supporting name and Alby, BitBanana (and probably others) supporting identifier too.

Another neat thing would being a consumer of LUD-18.
Meaning that when you pay out to a Lightning Address or LNURL-pay code, you could provide the @stacker.news Lightning Address (at user's discretion of course) to the payer.
As far as I understand, this current pull request covers being a LUD-18 service (in LNURL terms). you can also be a wallet. Just a friendly suggestion for the future.

As @Darth-Coin mentioned, supporting LUD-18 name as a wallet could be tried on https://chat.blixtwallet.com, paying via Lightning Address [email protected].
Hmm I should actually look into supporting identifier & email too there!

I could see this being more useful in the other direction: when someone goes to pay SN, we give them a photo and stats and stuff so they can verify it's going to the right place ... or when someone is paying out of SN, we give them a photo and stuff about the person they're sending to.

@huumn If I understand you correctly, these things can be provided by the normal LUD-06 LNURL-pay protocol.
Specifically an image/jpeg or image/png entry can be provided in the metadata prop.

huumn · 2023-09-27T16:51:42Z

@hsjoberg you rock!

Darth-Coin · 2023-09-27T17:27:14Z

@hsjoberg you rock!

LNURL Mafia Boss is here!

SatsAllDay · 2023-09-27T20:40:10Z

So I think for stacker.news, it could be nice to have the payerdata visible in the transaction log, as you guys have already talked about. Specifically, name and identifier(meaning Lightning Address) has some support across the ecosystem with OBW, Blixt, etc supporting name and Alby, BitBanana (and probably others) supporting identifier too.

👍

Another neat thing would being a consumer of LUD-18.
Meaning that when you pay out to a Lightning Address or LNURL-pay code, you could provide the @stacker.news Lightning Address (at user's discretion of course) to the payer.
As far as I understand, this current pull request covers being a LUD-18 service (in LNURL terms). you can also be a wallet. Just a friendly suggestion for the future.

Yea, that would be a good enhancement. You're correct that this PR is really just covering the service aspect. I think to cover the wallet aspect, we probably need to revamp our UX in that area before adding more options, like these. The biggest thing I think we should do is allow a user to enter the lightning address recipient, then we go and query capabilities, then update the UI form accordingly, based on what's accepted by that provider. Right now we just show all fields all the time, and let the request fail if e.g. the user sends a comment but the recipient doesn't accept them. It would be nice to have the form be dynamic based on what's allowed for the specified recipient.

* don't cache the well-known response, since it includes randomly generated single use values * validate k1 from well-known response to pay URL * only keep k1's for 10 minutes if they go unused * fix validation logic to make auth object optional

* move k1 cache to database * store payer data in invoice db table * show payer data in invoices on satistics page * show comments and payer data on invoice page

…on, wallet history

SatsAllDay · 2023-09-29T00:43:28Z

Some updated screenshots...
LUD18 data now reflected in:

notifications for invoices deposited
wallet history
Invoice page (LUD-12 comments, too!)

SatsAllDay · 2023-09-29T00:55:14Z

I think this is ready for review now. I would like to do the wallet side in a separate PR, based on the above discussion.

SatsAllDay · 2023-09-30T23:47:16Z

For those following along, I've worked up the LUD-18 wallet implementation in #531

huumn · 2023-10-03T17:23:16Z

What's the purpose of our use of the challenge k1? The only thing it seems to do right now is verify the wallet hit the .../lnurlp/[username]/index.js endpoint first within the last 10 minutes, right?

I guess we could eventually use it to auth the sender but without a way to verify with the wallet couldn't they still send arbitrary payer data? Is there another LUD that would help us ask the wallet if the payer data is legit?

SatsAllDay · 2023-10-03T17:27:10Z

What's the purpose of our use of the challenge k1? The only thing it seems to do right now is verify the wallet hit the .../lnurlp/[username]/index.js endpoint first within the last 10 minutes, right?

It's used here to validate the supplied signature. It is only used if you supply the auth payer data entry. None of the other payer data fields make use of it.

I guess we could eventually use it to auth the sender but without a way to verify with the wallet couldn't they still send arbitrary payer data? Is there another LUD that would help us ask the wallet if the payer data is legit?

AFAIK any payer data aside from auth can be "spoofed". A successful auth entry can give you proof of ownership of a public key, which is useful if the key is associated to an account. At least, that's my understanding. I'm not aware of any other LUDs to ensure other payer data is legit.

huumn · 2023-10-03T17:47:10Z

A successful auth entry can give you proof of ownership of a public key

I believe it's ownership of a linking key (which is derived from an arbitrary pubkey but is irreversibly hidden from us when generating the linking key) and cannot be independently verified.

Just trying to figure out if we should use auth if we can't really use it to authenticate payer data.

SatsAllDay · 2023-10-03T17:53:30Z

Yes I think you are right.

We certainly could remove auth for now and reconsider including it later on. It would considerably simplify things in this PR. I have yet to encounter another service that supports it. I added it because it was in the spec ¯\_(ツ)_/¯

huumn · 2023-10-03T18:09:36Z

I'm going to work on removing it fyi. I already have it going locally.

huumn · 2023-10-03T19:35:44Z

Nice work! Other than removing auth, the only other significant change was using changing the payer data to be stored as JSONB. I regretted not doing this for nostr zaps.

SatsAllDay · 2023-10-03T20:27:39Z

Awesome, thanks!

SatsAllDay marked this pull request as ready for review September 25, 2023 16:03

SatsAllDay commented Sep 25, 2023

View reviewed changes

SatsAllDay changed the title ~~WIP: LUD-18 Support~~ LUD-18 Support Sep 25, 2023

SatsAllDay force-pushed the lud-18 branch from 3bc6e36 to 18d36a5 Compare September 25, 2023 16:08

SatsAllDay marked this pull request as draft September 27, 2023 15:13

SatsAllDay changed the title ~~LUD-18 Support~~ LUD-18 Service Support Sep 28, 2023

SatsAllDay added 9 commits September 28, 2023 19:57

first pass of LUD-18 support

a41bd51

Various LUD-18 updates

ff89900

* don't cache the well-known response, since it includes randomly generated single use values * validate k1 from well-known response to pay URL * only keep k1's for 10 minutes if they go unused * fix validation logic to make auth object optional

Various LUD18 updates

9dc9ff8

* move k1 cache to database * store payer data in invoice db table * show payer data in invoices on satistics page * show comments and payer data on invoice page

Show lud18 data in invoice notification

2fbb93b

PayerData component for easier display of info in invoice, notificati…

1382332

…on, wallet history

payerData -> invoicePayerData in fact schema

10e4f59

Merge prisma migrations

a2c3b62

lint fixes

6fe9a93

worker job to clear out unused lnurlp requests after 30 minutes

0b7f711

SatsAllDay force-pushed the lud-18 branch from 676094a to 0b7f711 Compare September 29, 2023 00:02

SatsAllDay added 2 commits September 28, 2023 20:05

More linting

1a64d84

Move migration to older

f1838de

SatsAllDay marked this pull request as ready for review September 29, 2023 00:54

huumn and others added 2 commits October 2, 2023 19:43

Merge branch 'master' into lud-18

1ad0505

Merge branch 'master' into lud-18

a614ced

WIP review

3e0f031

Merge branch 'master' into lud-18

e80cadd

huumn added 2 commits October 3, 2023 14:14

enhance lud-18

df9173c

refine notification ui

533850f

huumn merged commit 3acaee3 into stackernews:master Oct 3, 2023
1 check passed

SatsAllDay deleted the lud-18 branch October 4, 2023 19:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LUD-18 Service Support #518

LUD-18 Service Support #518

SatsAllDay commented Sep 24, 2023 •

edited

Loading

SatsAllDay left a comment

SatsAllDay Sep 25, 2023

SatsAllDay Sep 25, 2023

SatsAllDay Sep 25, 2023

huumn Sep 27, 2023

SatsAllDay Sep 27, 2023

huumn commented Sep 26, 2023

SatsAllDay commented Sep 26, 2023

huumn commented Sep 27, 2023

SatsAllDay commented Sep 27, 2023

huumn commented Sep 27, 2023

Darth-Coin commented Sep 27, 2023 •

edited

Loading

SatsAllDay commented Sep 27, 2023 •

edited

Loading

huumn commented Sep 27, 2023

hsjoberg commented Sep 27, 2023 •

edited

Loading

huumn commented Sep 27, 2023

Darth-Coin commented Sep 27, 2023

SatsAllDay commented Sep 27, 2023 •

edited

Loading

SatsAllDay commented Sep 29, 2023

SatsAllDay commented Sep 29, 2023

SatsAllDay commented Sep 30, 2023

huumn commented Oct 3, 2023 •

edited

Loading

SatsAllDay commented Oct 3, 2023 •

edited

Loading

huumn commented Oct 3, 2023

SatsAllDay commented Oct 3, 2023

huumn commented Oct 3, 2023

huumn commented Oct 3, 2023

SatsAllDay commented Oct 3, 2023

LUD-18 Service Support #518

LUD-18 Service Support #518

Conversation

SatsAllDay commented Sep 24, 2023 • edited Loading

Footnotes

SatsAllDay left a comment

Choose a reason for hiding this comment

SatsAllDay Sep 25, 2023

Choose a reason for hiding this comment

SatsAllDay Sep 25, 2023

Choose a reason for hiding this comment

SatsAllDay Sep 25, 2023

Choose a reason for hiding this comment

huumn Sep 27, 2023

Choose a reason for hiding this comment

SatsAllDay Sep 27, 2023

Choose a reason for hiding this comment

huumn commented Sep 26, 2023

SatsAllDay commented Sep 26, 2023

huumn commented Sep 27, 2023

SatsAllDay commented Sep 27, 2023

huumn commented Sep 27, 2023

Darth-Coin commented Sep 27, 2023 • edited Loading

SatsAllDay commented Sep 27, 2023 • edited Loading

huumn commented Sep 27, 2023

hsjoberg commented Sep 27, 2023 • edited Loading

huumn commented Sep 27, 2023

Darth-Coin commented Sep 27, 2023

SatsAllDay commented Sep 27, 2023 • edited Loading

SatsAllDay commented Sep 29, 2023

SatsAllDay commented Sep 29, 2023

SatsAllDay commented Sep 30, 2023

huumn commented Oct 3, 2023 • edited Loading

SatsAllDay commented Oct 3, 2023 • edited Loading

huumn commented Oct 3, 2023

SatsAllDay commented Oct 3, 2023

huumn commented Oct 3, 2023

huumn commented Oct 3, 2023

SatsAllDay commented Oct 3, 2023

SatsAllDay commented Sep 24, 2023 •

edited

Loading

Darth-Coin commented Sep 27, 2023 •

edited

Loading

SatsAllDay commented Sep 27, 2023 •

edited

Loading

hsjoberg commented Sep 27, 2023 •

edited

Loading

SatsAllDay commented Sep 27, 2023 •

edited

Loading

huumn commented Oct 3, 2023 •

edited

Loading

SatsAllDay commented Oct 3, 2023 •

edited

Loading