Enable custom records on podcast:valueRecipient

[dellagustin]

Lightning payment messages allow the inclusion of custom records that can be used for experimental and application-specific messages.

Custom records are a key-value pair, where the key is a 64bit integer >= 2^16.

At this moment I have considered two use cases for the usage of custom records:

1. A podcaster produces multiple podcasts but receives payments for all podcasts in a single lightning node. The podcaster could use a custom record to add an identifier of the podcast that is sending the payment.
2. Virtual wallets layered on top of a shared node (i.e. lnpay.co) could use a custom record to identify the wallet that is receiving the payment (when payments are received by invoice, the invoice contains information that can be mapped to the virtual wallet).

Example of how the tag could look like (use case for identifying a virtual wallet on top of a shared node):

<podcast:value type="lightning" method="keysend" suggested="0.0000005">
    <podcast:valueRecipient name="Recipient 1" type="node" address="02919fe9fb94eec6401ecf3e7b99afb4472378f0c0551851e092c2ff814224fc37" split="70">
        <podcast:customRecord type="696969">wal_nZDVDNY91Md<podcast:customRecord>
    </podcast:valueRecipient>
    <podcast:valueRecipient name="Recipient 2" type="node" address="0216682f5c0cf226ae803f7746f8555a65cb04a1291647c7b9e229dcc7564189ad" split="30" />
</podcast:value>

the default value of the tag would be string following the character encoding of the xml document, but if required in the future we could add an additional attribute like encoding, that could be set to hex or base46 in case packaging binary data is required.

References:

• https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#type-length-value-format

[dellagustin]

I got news yesterday from Tim (LNPay creator), on LNPay's telegram group (https://t.me/paywallers), that he will turn on inbound KeySend payments. Wallets must be identified with custom record 696969, example: 696969=wal_nZDVDNY91Md.

[daveajones]

Can we make this an attribute of the valueRecipient element. Digging down another level feels like too much. I'd love to avoid that if possible.

Maybe:

<podcast:value type="lightning" method="keysend" suggested="0.0000005">
    <podcast:valueRecipient name="Recipient 1" type="node" customRecordKey="696969" customRecordValue="wal_nZDVDNY91Md" address="02919fe9fb94eec6401ecf3e7b99afb4472378f0c0551851e092c2ff814224fc37" split="70">
    </podcast:valueRecipient>
    <podcast:valueRecipient name="Recipient 2" type="node" address="0216682f5c0cf226ae803f7746f8555a65cb04a1291647c7b9e229dcc7564189ad" split="30" />
</podcast:value>

[dellagustin]

Would work for cases where the wallet can be resolved with a single custom record key:value pair, which is the case for LNPay. Any use case I think for having more then a single key:value pair is a bit of a stretch, so I think that is good enough until we see a really useful use case for having more key:value pairs. If that happens, it can be extended in a backwards compatible way.

[daveajones]

Yeah, there is that aspect.

@brianoflondon What about Hive in this regard? Does it need (or could it benefit from enabling) multiple key value pairs in the split definitions?

[brianoflondon]

@brianoflondon What about Hive in this regard? Does it need (or could it benefit from enabling) multiple key value pairs in the split definitions?

Short answer, no, I don't need more in the value block because Hive will allow as much meta data accompanying value transfers as we like.

My current thinking is that we put all this kind of extra information in the api calls which generate the custom-json posts (which are public) on the Hive blockchain. We can put any extra info there episode ID (hence my issue #186 ) and the exact time.

Once that information is on the chain it is up to whatever podcaster wallet / podcast data mining systems are built to tell podcasters info about where their transfers came from. For example there is an entire level 2 system of extra tokens on Hive called Hive-Engine. Transactions are written to Hive as custom-jsons but it is up to various different front ends to interpret them.

My current block (for Hive) looks like this:

        <podcast:value type="lightning" method="keysend" suggested="0.00000005000">
            <podcast:valueRecipient name="podcaster" type="node" address="036d33fbd386acc37577a6d72fea0e893e94a915139508d52a0395a930e1a6b613" split="99" />
            <podcast:valueRecipient name="podcastindex" type="node" address="036557ea56b3b86f08be31bcd2557cae8021b0e3a9413f0c0e52625c6696972e57" split="1" />
        </podcast:value>
        <podcast:value type="HBD" method="transfer" suggested="0.05">
            <podcast:valueRecipient name="podcaster" type="account" address="brianoflondon" split="95" />
            <podcast:valueRecipient name="host" type="account" address="threespeak" split="3" />
            <podcast:valueRecipient name="podcastindex" type="account" address="podcastindex" split="2" />
        </podcast:value>

This is a mock up (which I did post into the live Hive blockchain) of the kind of data I foresee podcast player apps putting on the chain either directly or via an API call).

[dellagustin]

@daveajones, I'll answer here about https://podcastindex.social/@dave/105781413369091130

I was talking to paul (@sphinx_chat@podcastindex.social) yesterday and he mentioned embedding the "routing hint" directly in the payment address, sort of like HTTP basic auth in a url.So like: "wal_blahblahblah@<nodepubkey>" as the address in the split.

So like: "wal_blahblahblah@" as the address in the split.

I have mixed feelings. In one way, having custom record attributes makes it easier for apps to parse the feed, but in the other hand it adds a "lightning flavor" to the tag.

If we opt to add the "routing hint" to the payment address, we will need a spec the the address format that is valid for lightning, as apps need to parse the address and use its content when performing payments, for instance, "<custom record key>:<custom record value>@<nodepubkey>" (for LNPay this would be "696969:<wallet id>@033868c219bdb51a33560d854d500fe7d3898a1ad9e05dd89d0007e11313588500").

Personally I prefer the attributes, as it makes my life easier for parsing.

We also need to decide on the encoding of the custom record value. This is a tricky topic, custom record value is in its nature raw binary data, the safest would be to use base64 or hex as default encoding, as it avoids string encoding conversions (i.e. the feed is encoded in UTF-16 but the recipient expects the custom record value to be a string encoded in UTF-8).

[daveajones]

Let me throw this at Paul/Evan and see what they say. This will affect them as well, so best to have one workable format than two.

[daveajones]

I've thought more about this. And, we have a type property in the <podcast:valueRecipient> tag. Currently it's set to "node" always. But, in this instance it could be set to "wallet". And, in that circumstance, the address would be expected to be of a different format.

So, if the tag looked like this:

<podcast:value type="lightning" method="keysend" suggested="0.00000015000">
    <podcast:valueRecipient
        name="Host"
        type="node"
        address="02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52"
        split="100"
    />
</podcast:value>

The address would be expected to simply be a lightning node pubkey.

But, if the block looked like this:

<podcast:value type="lightning" method="keysend" suggested="0.00000015000">
    <podcast:valueRecipient
        name="Host"
        type="wallet"
        address="696969:wal_j0dn3l393u9f9@02d5c1bf8b940dc9cadca86d1b0a3c37fbe39cee4c7e839e33bef9174531d27f52"
        split="100"
    />
</podcast:value>

The app would know that the address format would contain a routing hint in the key:value@address format.

Thoughts?

[daveajones]

Actually, I retract this suggestion. I'm not liking the way it feels.

[brianoflondon]

Just a very quick observation slightly tangential to this Lightning specific routing stuff, I've changed the language in my version so I'm using shares and split.

shares are the number of shares split is the % which I calculate on the fly and frankly don't really need to be in the value block as I'm always going to take the real calc from the shares.

That's what I'm doing internally and may make more sense now we've decided not to force everything to add to 100.

<?xml version="1.0" encoding="utf-8"?>
<podcast@value type="HBD" method="Hive" suggested="0.05">
    <podcast@valueRecipient valueRole="Host" name="Brian of London" address="brianoflondon" shares="85" split="36.48068669527897"></podcast@valueRecipient>
    <podcast@valueRecipient valueRole="Index" name="Podcast Index" address="podcastindex" shares="63" split="27.038626609442062"></podcast@valueRecipient>
    <podcast@valueRecipient valueRole="Co-Host" name="Flyingboy" address="flyingboy" shares="37" split="15.879828326180256"></podcast@valueRecipient>
    <podcast@valueRecipient valueRole="Producer" name="Value 4 Value" address="v4vapp" shares="16" split="6.866952789699571"></podcast@valueRecipient>
    <podcast@valueRecipient valueRole="Gateway" name="" address="" shares="15" split="6.437768240343347"></podcast@valueRecipient>
    <podcast@valueRecipient valueRole="Guest" name="surfingboy" address="surfingboy" shares="15" split="6.437768240343347"></podcast@valueRecipient>
    <podcast@valueRecipient valueRole="App" name="" address="" shares="2" split="0.8583690987124464"></podcast@valueRecipient>
</podcast@value>

[dellagustin]

This topic is now addressed in the value whitepaper, initially committed with 1502caaf4649c0574c9acc44aa4d0de7cb219941