Custom HTLC TLVs

[TheBlueMatt]

Probably a bit annoying to plumb through, but people keep coming up with uses for payment messages, so we really need to support this.

[moneyball]

What are some example use cases we've heard of?

[TheBlueMatt]

I believe the commonly described use-cases today are only the "podcasting extra data" bLIP - sending extra data with a keysend payment to indicate that you're tipping while listening to a podcast with metadata about the current timestamp. If you're doing it via invoice data you should probably do it using the new payment metadata info instead, but for application-specific keysend it may make more sense.

[andozw]

Hey @TheBlueMatt, I am interested in working on this. Do you have an idea in mind for the data structure to use or any other ideas for guidance? Thanks!

[TheBlueMatt]

I think the way we should go about this is to do what I mentioned at #1221 (comment) In order words, taking #1221 and rebasing it, but also taking the new payment_metadata parameter and replacing it (and the existing payment_secret parameter) with a PaymentMetadata (or another name? maybe RecipientInfo?) struct that contains both.

From there it'll be a relatively lighter lift to add custom onion TLVs - we'll need to tweak our TLV serialization logic as well, but likely with a new macro variant or new macro.

I'd suggest doing the two in separate PRs, as it provides a logical split point.

[andozw]

Was a bit tricky but I finally rebased 1221.
The changes are on my remote and I'll open a new PR after working on the next step to create the struct to hold the payment_metadata and existing payment_secret.