I will look into this over the weekend and experiment a little

I started work on this in #112
Needs some feedback on the items under todo there. Most important question is this:

One of the inputs for the form is a JSON which is equivalent to the <podcast:value> tag in the RSS (example below). Where should it be defined as it has slightly different implications then. Should it be for each episode, or for each show? Or maybe both and using the value in the episode as an override if it exists, otherwise fallback on the show?

The Podcasting 2.0 spec supports this tag in both places, I'm not sure how do the apps implement them and differentiate between the two levels:

This element can exist at either the or level.

{
    "method": "keysend",
    "suggested": 5e-8,
    "type": "lightning",
    "recipients": [
        {
            "address": "03cf7e9b79a3230749db642ad690889065ec35b9ded184266d4fce424ab75470fc",
            "customKey": "",
            "customValue": "",
            "fee": false,
            "name": "Brent",
            "split": 50,
            "type": "node"
        },
        {
            "address": "037d284d2d7e6cec7623adbe600450a73b42fb90800989f05a862464b05408df39",
            "customKey": "",
            "customValue": "",
            "fee": false,
            "name": "Podcaster",
            "split": 50,
            "type": "node"
        },
        {
            "address": "03ae9f91a0cb8ff43840e3c322c4c61f019d8c1c3cea15a25cfc425ac605e61a4a",
            "customKey": "",
            "customValue": "",
            "fee": true,
            "name": "Podcastindex.org",
            "split": 1,
            "type": "node"
        }
    ]
}

@gerbrent any feedback on this?

Also should it be part of Milestone 1.0?

Should it be for each episode, or for each show? Or maybe both and using the value in the episode as an override if it exists, otherwise fallback on the show?

this sounds like a great approach. I think I'll loop in @ChrisLAS for more on this one...

I think part of my questions become:

• If these splits are presumably defined elsewhere with more authority - Podcast Index? - shouldn't we scrape those on a per-show and/or per-episode basis?

Should it be for each episode, or for each show? Or maybe both and using the value in the episode as an override if it exists, otherwise fallback on the show? The Podcasting 2.0 spec supports this tag in both places, I'm not sure how do the apps implement them and differentiate between the two levels

Looks like the spec suggests that things at the item level are to override the channel settings:

The value tag, when it exists at the <channel> level, designates the payment scheme for the entire podcast. When it exists at the <item> level, it is intended to override the channel level tag for that episode only.

Sounds like the ideal end goal would be to have these splits defined in the RSS feed eventually, but for now the Podcast Index is a good source-of-truth for splits.

Per episode is my strong preference because it allows us to do splits with guests, or a project we mention, or even a specific listener for that episode.

As far as source of truth ideally before the end of the year we'll be specifying the splits directly in our RSS feed with per-episode split set in there. This gives us the broadest compatibility with podcast apps, and accommodates people directly adding the feed and bypassing the podcast index.

But we're not ready for that yet, so the next best source of truth would likely be the podcast index.

...should it be part of Milestone 1.0?

My personal opinion: I don't think it should be part of JB.com 1.0 Milestone. This is a perfect example of a feature not currently in the JB WP site, and a nice-to-have, yet would take away precious resources from other essential tasks that are a hard requirement for the deadline.

Thanks!! This is all very helpful, and clarifies the greater vision.

@gerbrent you’re right, main goal of 1.0 is to move away from scale engine. This does fall in there.
We will deal with this after.
Implementing it in incremental steps as @ChrisLAS suggested: (1) read data from podcastindex first, (2) then make JB as the source.

Just had a quick idea: The website should play a boost sound effect from @ChrisLAS 's soundboard after you boost into the show

wes:

it would be great to have the boosts show up on the site

as in, perhaps via https://github.com/Podcastindex-org/helipad