Suggestion: Use a dedicated custom record to identify podcasts

[dellagustin]

Hello, I would like to recommend you to use a dedicated custom record to identify podcasts. My suggestion would be to keep 7629169 for analytical reasons and use another custom record key for identifying which podcast is receiving the payment (i.e. using the feed address).

The reason for this suggestion is that users may want to disable analytics, or some players may even not want to implement it. On the other hand, the podcast namespace defines a single custom record key-value pair as part of the podcast:valueRecipient tag: https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md#value-recipient-element.

This is not yet supported on https://podcasterwallet.com/, but I just asked Dave and it is on their plans. https://podcastindex.social/@dave/106020042742247962

[satoshisstream]

I see, and understand what you are trying to do I think. Thanks the suggestion.

I feel 7629169 could do what you describe, right? Just fill in the url key and you are done, leave the rest blank :).

Feels a bit like duplicating efforts. What I maybe should do is make ONLY a podcast-identifier (feedID, url or podcast (title)) mandatory.

Would that work? I think all other fields can be optional? Wonder what you think.

[dellagustin]

Yes, 7629169 can do I described.

The thing is that I have the strong feeling that the way we identify a value recipient should be completely defined in the podcast:valueRecipient tag, so that identifying a recipient does not depend on a standard defined externally to the podcast namespace.

The option here to ensure that the recipient is fully defined for satoshis.stream in the feed would be to include a fixed custom record like this:

 <podcast:value type="lightning" method="keysend" suggested="0.00000015000">
            <podcast:valueRecipient name="Host" type="node" address="03c457fafbc8b91b462ef0b8f61d4fd96577a4b58c18b50e59621fd0f41a8ae1a4" customKey="7629169" customValue="{\"url\"=\"<feed url>\"}" split="100" />
        </podcast:value>

This way it would not depend on the player additionally supporting the spec for 7629169.

[satoshisstream]

Right. Then a separate tag might be better indeed, because players will/should overwrite 7629169.

What about:

<podcast:valueRecipient name="Host" type="node" address="03c457fafbc8b91b462ef0b8f61d4fd96577a4b58c18b50e59621fd0f41a8ae1a4" customKV="{1337:\"somevalue\"}" split="100" />

People can set a customKV field for players to add?

Don't really see the added value yet, IF players use "the standard", if they don't it might help, but will they choose this way over "the standard"...?

[dellagustin]

Hi, I don't see much difference in having a separate tag, at the end customKV has almost the same function as customKey + custom Value, except that customKV could have multiple key value pairs, while customKey + customValue accomodate a single value pair.

The added value of adding this to the feed is that the recipient could be fully identified with this information without having to know about the additional standard, it would simply take the information from the podcast:valueRecipient tag and add to the transaction. This is expected of players to be conformant with the namespace spec.

Of course, players that also implement "the standard" would then overwrite the information from the feed in case customKey = 7629169.

[daveajones]

I can see it going either way really. We can always add an attribute to the recipient tag in the xml. Or, we can append the value spec white paper with an implementation note to app developers on what to send in 7629169. The distinction here is fuzzy.

If just appending an implementation note to the spec keeps from needing to parse values out of an attribute value then I probably lean toward that.

Let me know if I’ve misunderstood.

[satoshisstream]

I see @daveajones merged customKey/customValue. Too bad... It's limiting in the amount of Keys/Value ;)