lightning
lightning copied to clipboard
ElementsProject
Display TLV data in listinvoices
When receiving a keysend payment I can see it under listinvoices. But this doesn't show any custom TLV fields.
I'm particularly interested in the fields used by Podcasting 2.0: https://github.com/satoshisstream/satoshis.stream/blob/main/TLV_registry.md#field-7629169
We have one issue with this, namely that despite the name, TLV fields are not typed as such. They are just blobs of binary data, that are interpreted as integers, hashes, signatures, etc by any program that has more knowledge about the T in the acronym.
So a generic implementation would just show type, length (redundant really in JSON results) and a hex-encoded binary value. Would that still be acceptable?
It's a start. I could probably pipe that through JQ and then some tools to decipher the hex value. Maybe plugins can do that too.
We have one issue with this, namely that despite the name, TLV fields are not typed as such. They are just blobs of binary data, that are interpreted as integers, hashes, signatures, etc by any program that has more knowledge about the
Tin the acronym.So a generic implementation would just show type, length (redundant really in JSON results) and a hex-encoded binary value. Would that still be acceptable?
The hex encoded strings are what we are parsing when pulling out the tlv payload on incoming keysend transactions for the Podcast Index node. It’s not difficult (bin2hex —> json_decode) and provides tremendous listener stats to see what podcast/episode was being listened to, and exactly what time stamp within it that the payment was sent.
The podcast industry currently works on “download stats” which are highly inaccurate. It’s basically guesswork. This would revolutionize that as a standard for listener metrics.
#4610 is the first step towards this. It adds experimental support for extratlvs, i.e., hex-encoded TLVs that are not interpreted and stored internally yet, with opt-in to even TLV types on the command line. They are currently only being exposed in the invoice_payment hook for testing, but if the format looks ok to users we can add them to the corresponding notification, and start storing them in the DB as well, so listinvoices can retrieve and display them.
a generic implementation would just show type, length (redundant really in JSON results) and a hex-encoded binary value. Would that still be acceptable?
I think that would be fine. It should be easy for consuming apps to interpret the TLV type and decode the hex values accordingly.
They are currently only being exposed in the invoice_payment hook for testing
That's already really helpful -- thanks for that! :)
I've written a small plugin for lightningd that watches for Podasting 2.0 TLVs in the invoice_payment hook and stores them in a local db so that they can be retrieved again later on: cln-podcast-payments.
It's not much but should be an acceptable workaround until Core Lightning can natively do that.
but if the format looks ok to users we can add them to the corresponding notification, and start storing them in the DB as well, so listinvoices can retrieve and display them.
That'd be great, imo! As I said, I feel like the binary format is fine enough. Having access to TLVs in listinvoices would make the use of a separate plugin obsolete and by that make everything easier for people to use.
I wonder if this can now be considered as solved by https://github.com/ElementsProject/lightning/pull/5619. That PR adds the longest string extracted from TLVs into the invoice we use to track spontaneous payments.
Great news, looking forward to integrate this into our BTCPay Lightning lib.
I wonder if this can now be considered as solved by https://github.com/ElementsProject/lightning/pull/5619
@cdecker As far as I see, the description with the keysend: part contains only the 133773310 TLV key. Is there a way to also get access to the other custom TLV records?