Bolt11Payment::receive* methods should accept a Bolt11InvoiceDescription instead of a &str

[tvolk131]

This is needed for Fedimint lightning gateway to support creating invoices with description hashes

[tnull]

This is needed for Fedimint lightning gateway to support creating invoices with description hashes

Unfortunately we can't do this (at least directly), as Bolt11InvoiceDescription wouldn't be exposable via our bindings. I'm also not the biggest fan of complicating the API too much here.

As other users had similar requirements (i.e., support for description hashes for longer strings), we so far had planned to simply default to a description hash if the provided string was too long (see #312).

Would this cover your use case, too?

[m1sterc001guy]

Yes, I believe we can simply always hash it if that's supported

[tnull]

Yes, I believe we can simply always hash it if that's supported

It would default to hashing whenever the description string length surpasses the maximum size of 639 bytes, and would include the description string otherwise. Just to make sure, this would work for your use case?

[joschisan]

Actually the reasons we even have description hashes was on request of @benthecarman so he would have to answer if this is sufficient for his uses case - iirc it was nostr related.

[benthecarman]

For lightning addresses it is needed. Would be weird for me that ldk node doesn't expose the description hash, lots of different things use this.

[joschisan]

Could you please elaborate how it is used in lightning addresses?

[benthecarman]

The lnurl pay spec and nostr zap spec requires that the description hash is a hash of some of the data to make sure you're getting a valid invoice

[joschisan]

If I understand correctly than the hashed metadata in knurl pay is not necessarily longer than 639 bytes, hence the above proposed solution would not work for knurl pay and therefore lightning addresses - correct?

[benthecarman]

The hash and description are separate fields so you can't really just put the data from one in another

[joschisan]

I think @tnull proposed that ldk would hash a description longer then 639 bytes internally and then put the hash into the description hash field, leaving the description field empty.