Clarification of fee in podcast:value

[jooray]

In section "Value Recipient Element", all the attributes are described by their meaning. For fee, there is only:

fee (optional) If this attribute is not specified, it is assumed to be false.

It should qualify what is the meaning of this attribute, not only the default value, as with all other attributes.

For the description of the fee parameter further down the specification:

The fee attribute tells apps whether this split should be treated as a "fee", or a normal split. If this attribute is true, then this split should be calculated as a fee, meaning its percentage (as calculated from the shares) should be taken off the top of the entire transaction amount. This is the preferred way for service providers such as apps, hosting companies, API's and third-party value add providers to add their fee to a value block.

It should provide some clarification. I do not understand what is the difference of "on top" and how is the fee amount calculated differently.

Maybe with the example further down with 190/152/38 split could describe how would the calculation be different if the 38 share was fee=true. I honestly do not understand the difference.

[daveajones]

If fee is "true" then you treat the split attribute to mean it's a percentage of the entire payout. So, if one of the splits is a fee and it's split attribute is "5" you would add up all the payouts to get a total and then first multiply that amount by .05 to get the amount to send to the fee split's node. Then subtract that amount from the total and calculate the other split shares on that remaining amount. That's what is meant by "taken off the top".

Does that make more sense?

[jooray]

Yes, just one more clarification and I will try to create a pull request for the wording.

If fee's split attribute is 5 and other splits add to let's say 200, is the fee:

a.) 5/(200+5) meaning adding all the shares including the fees) and then calculating a fee
b.) 5/200 meaning adding all the non-fee shares and calculating a fee
c.) or 5% meaning the shares do not matter it the split is percentage regardless of anything else

If I understand correctly, this fee is then taken off the sent amount and then it would be share/200 (a particular share / non-fee shares) out of the remaining amount.

[theDanielJLewis]

I believe C is correct. But let me see if I can explain it correctly to save @daveajones some time. (I will edit or delete this if it's incorrect.)

Let's say your split is 3 and your cohost's is 1, and the fee is 3. Then you receive 100 sats.

The 3% fee would be taken from the 100 sats, leaving 97 left to be split.

Since your split of 3 is 75% of the calculated split total of 4, you would get 75% of the sats (73 sats). And since your cohost's split of 1 is 25% of that same calculated split total, their share would be 24 sats (25%).

[jooray]

If this is like this, I suggest including this example (you have a typo there, split of 1 is 25%).

Then I suggest editing this part:

The fee attribute tells apps whether this split should be treated as a "fee", or a normal split. If this attribute is true, then this split should be calculated as a fee, meaning its percentage (as calculated from the shares) should be taken off the top of the entire transaction amount. This is the preferred way for service providers such as apps, hosting companies, API's and third-party value add providers to add their fee to a value block.

And adding something like "if this parameter is true, the value is treated as a percentage, value of 5 meaning 5%". Right now the "as calculated from the shares" is misleading, it is not calculated from the shares, but from the whole payment amount as percentage.

[jamescridland]

@jooray (and others) - please feel free to submit a pull request if you believe you can make the documentation clearer. :)

[jooray]

Well, we can, but we need to know how it should be first. We are still not 100% clear on what the calculation should be.

@daveajones could you have a look if @theDanielJLewis got it right? If yes, I'll make a pull request.

[keunes]

@jooray, based on the recent conversation between Adam & Dave (e.g. in Ep. 120), I do believe indeed that C is correct.

How I would explain a fee: it's roamed off of the total amount. Whatever is left, is divided among the splits. E.g.

• Boost = 300 sats
• App takes fee of 1% (= 3 sats)
• Whatever is left (300-3=297), is split according to the value block:
  • Host split is 3 (= 75% of total splits) --> 0,75*297 = 222,75 (rounded down to 222 sats)
  • Co-host split is 1 (= 25% of total splits) --> 0,25*297 = 74,25 (rounded down to 74 sats)

What I don't know, is what happens if there's multiple fees. E.g. the app claims 1% and then the payment provider claims 1% - will 2% roamed off of the total (6 sats) or 1% (3 sats) and then 1% of what's left (1% of 297 = 2 sats). Guess it depends on how the process is set up (e.g. if the app 'tells' the payment provider to give them 1%, or if it takes 1% and then gives the payment provider the rest).

[jamescridland]

This is a really clear way of explaining it, thank you.
As for where all other fees come from - I think it's where you have them for the app.

So...

• Boost = 300 sats
• App fee = 1% of above (3 SATs)
• Payment fee = 1% of above (3 SATs)
• leaves 294 SATs for the splits

[francosolerio]

I remember we already agreed from previous discussions + comments on the show by @daveajones and Adam that the fees imposed by the app should be kept out of the total the user specifies.

So the example above should be:

• Boost = 300 sats
• Payment fee = 1% of above (3 SATs)
• leaves 297 SATs for the splits
• App fee = 1% of total (3 SATs)
• The user pays 303 SATs total

The rationale is that the user wanted to give 300 sats to the podcaster. The podcaster sets the splits for the hosts / guests, and chooses the services he uses fully aware of their fees, so he divides his compensation between this parties. The podcaster has no control on the app, which is chosen by the listener, so the fee for the app should not be taken from the podcaster's compensation but directly from the user.

Do we still agree on this?

[kidscallmeray]

@francosolerio et al, this is my first post in Github, so forgive me if I'm doing this in the wrong location. Also, recognize that I am not a designer / developer. That said, as a listener, paying subscriber to a 2.0 app, and content creator (podcast / valuecast), I do not like the extra "fees" that are put on "top" of a boost. I support including them IN the boost / payment, Additional fees are akin to taxes, baggage fees, service charges, etc. To me, they come across as a money grab - especially when you're already paying for a subscription. I am 100% in support of an app taking a split, extracting a fee from the boost, getting paid - whatever you all want to call it - but I believe it should only come from the boost amount. I can imagine a scenario in the future where individuals, companies - anyone who listens and boosts - will have to budget their boosts, and additional fees will cause them to lower their budgets. Second, as #sats become more valuable, I believe we will all see the size of the boosts decrease. If it's included in the boost, then the take is proportional, not extravagant. Lastly, I would point towards basic human behaviour (and 25+ years in sales). I can imagine users getting a bad customer experience when they see that they didn't boost 100 or 1,000 (as they intended), but 101, 110, or 1,150 (the total + the fee, whatever it is). I could be wrong, but I think users would quickly move to an app that doesn't tack on fees when they see that they've boosted more than they initially intended too (which goes back to my initial point).
Kind Regards,
Jim Costello, Nashville

[jamescridland]

@francosolerio That rings a bell. But how in the spec do you say "it's a payment fee" and "it's an app fee"? Aren't they both fees, and in which case, is the user paying 306 sats in total?

@daveajones helllp

[francosolerio]

@jamescridland Every split/fee that is in the RSS feed comes from the podcaster's choices. The listening app usually applies one more fee that is not specified in the feed.

[daveajones]

@jooray, based on the recent conversation between Adam & Dave (e.g. in Ep. 120), I do believe indeed that C is correct.

How I would explain a fee: it's roamed off of the total amount. Whatever is left, is divided among the splits. E.g.

• Boost = 300 sats

• App takes fee of 1% (= 3 sats)

• Whatever is left (300-3=297), is split according to the value block:

  • Host split is 3 (= 75% of total splits) --> 0,75*297 = 222,75 (rounded down to 222 sats)
  • Co-host split is 1 (= 25% of total splits) --> 0,25*297 = 74,25 (rounded down to 74 sats)

What I don't know, is what happens if there's multiple fees. E.g. the app claims 1% and then the payment provider claims 1% - will 2% roamed off of the total (6 sats) or 1% (3 sats) and then 1% of what's left (1% of 297 = 2 sats). Guess it depends on how the process is set up (e.g. if the app 'tells' the payment provider to give them 1%, or if it takes 1% and then gives the payment provider the rest).

This is the correct way to calculate, and the clearest explanation I’ve seen so far. Thanks for this writeup @keunes !

And, @francosolerio is correct about the app fee. It’s not in the feed itself (can’t be) but that’s how it is calculated based on the consensus we came up with in the board meeting and on podcastindex.social as it was talked through.

[daveajones]

What really might help here is a diagram.

[samsethi]

Not sure if this helps or not. I was very confused about the splits and fees. At first, because fees were optional I was ready to ignore them. Then after Podcasting 2.0 (show 120) - I think I understand the difference. I am treating splits for people and fees for services. I also prefer to treat splits/fees as a percentage of 100% and not have to calculate the sats with some crazy calculation.

In Podfans we have linked the Person tag to the Value4Value fields. So for any given podcast if you add more people or roles from the Podcast Taxonomy to a podcast metadata we will show more fields to enable you to choose if its a split or fee and set the %.

We are trying to pull these directly from the RSS feed but so many feeds are a total mess where services are set as splits and not fees and the percentage splits are over 100%.

[theDanielJLewis]

Yes, I think the publishing tools should present a simple percentage, and then it can use a 100-sum number for the splits.

So the podcaster would set 51% and 49%, and the publishing tool would set the splits to 51 and 49, respectively.

And for clarification, any publishing system could say, "The following splits are calculated after any fees are deducted."