JupiterBroadcasting / jupiterbroadcasting.com

JupiterBroadcasting.com, hugo-based and community-driven!
https://jupiterbroadcasting.com
99 stars 50 forks source link

Integrate V4V aka Boosts functionality #36

Open StefanS-O opened 2 years ago

StefanS-O commented 2 years ago

Just a placeholder, needs more detail and investigation

https://github.com/podverse/webln-v4v

kbondarev commented 2 years ago

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

kbondarev commented 2 years ago

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"
        }
    ]
}
kbondarev commented 2 years ago

@gerbrent any feedback on this?

Also should it be part of Milestone 1.0?

gerbrent commented 2 years ago

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...

gerbrent commented 2 years ago

I think part of my questions become:

noblepayne commented 2 years ago

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.

gerbrent commented 2 years ago

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.

ChrisLAS commented 2 years ago

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.

gerbrent commented 2 years ago

...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.

kbondarev commented 2 years ago

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.

reesericci commented 2 years ago

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

gerbrent commented 2 years ago

wes:

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

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