Allow multiple podcast:value tags per podcast/item

[dellagustin]

Moving forward, it is possible that a podcast is able to receive value-for-value support using other means then Bitcoin over lightning.

A simple example would be Litecoin over lightning.
I think this could be funcional already if there is tooling to support it, as existing nodes (lnd at least) are already capable of operating with Litecoin.

One consideration is priority and fallback strategy i.e. which one should be used if both sender and receiver support more then one method.

[brianoflondon]

The standard already allows multiple value blocks with different crypto or other options.

At the present Time, however, PodcastIndex ONLY ingests Lightning and as far as I know all the players look only to the PodcastIndex to get value block info, they don't read the RSS direct (I might be wrong on this bit).

[dellagustin]

Hello @brianoflondon ,

The standard already allows multiple value blocks with different crypto or other options.

The spec here states:

Currently, there can be only a single copy of this element at each level.

---

Regarding:

At the present Time, however, PodcastIndex ONLY ingests Lightning and as far as I know all the players look only to the PodcastIndex to get value block info, they don't read the RSS direct (I might be wrong on this bit).

podStation actually reads from the RSS and fallsback to the index in case there is not a value block on the RSS.

[francosolerio]

Castamatic too reads the value block from the feed and falls back to Podcast Index if there is none.

[brianoflondon]

The spec here states:

Currently, there can be only a single copy of this element at each level.

Interesting, I remember discussing multiple value blocks and I had a Hive block in my feed for a while but had forgotten it got set to allow only one.

I would be in favour or multiple but I'm also cognizant that at this stage with such thin adoption, it might not help to spread us even thinner.

[dellagustin]

Hello @brianoflondon ,

I would be in favour or multiple but I'm also cognizant that at this stage with such thin adoption, it might not help to spread us even thinner.

I don't think that making it official in the standard will spread us thinner. Most people will, in my opinion, follow with Lightning if that is what is easier to adopt (and in the current ecosystem, that is the case, to my best knowledge).

The main benefit I see in making it official in the specification that multiple podcast:value tags are allowed, despite not having other type then lightning at the moment, is that client developers will already design their clients in a future proof way.

That is what I did when designing podStation, I already consider podcast:value as a zero-to-many tag in my internal data model, and I filter for lightning when using it.

[dellagustin]

Related thread on mastodon: https://podcastindex.social/@RyanHirsch/107124783465739824