search

Podcastindex-org / podcast-namespace

A wholistic rss namespace for podcasting
Creative Commons Zero v1.0 Universal
381 stars 115 forks source link

<podcast:monetization> Create tag to support Web Monetization on podcasts apps #132

Open benjaminbellamy opened 3 years ago

benjaminbellamy commented 3 years ago

I would like to suggest the creation of the \ tag in order to support Web Monetization (see https://webmonetization.org/ ).

Web Monetization just requires an Interledger Payment Pointer (like a wallet address) and that’s it!

Services such as https://uphold.com/ provide Interledger Payment Pointers in many currencies (you may choose USD, Euro, BitCoin…)

Services such as https://coil.com/ allow users to pay seamlessly. (Coil is $5/mo, no more, no less. $0.0001/second is sent to the podcaster.)

So you can get paid with "real" money.

So far Castopod is Web Monetization compliant (when users go to the web site).

Adding \ to the RSS feed would allow Web Monetization to work also on podcasts apps.

The \ value is not compatible with Web Monetization because "method" and "suggested" are mandatory and it requires elements. The two systems (Lightning and Web Monetization) are really different so having different tags makes sense.

For a web page, the tag is \ so we would keep it alike.

I suggest the following:

Channel

(optional | single)

This element defines the Interledger Payment Pointer for Web Monetization.

jamescridland commented 3 years ago

I'd not heard of this before - thanks so much for sharing. I've just added the monetization tag to all Podnews network websites. See it, for example, in https://pod.events

I'd really like to see whether we can get this to work somehow with an existing funding tag. Might I suggest...

<podcast:value type="webmonetization">[one "Interledger Payment Pointer" element]</podcast:value>

or

<podcast:funding type="webmonetization" pointer="[one "Interledger Payment Pointer" element]"></podcast:funding>

The latter would make more sense, perhaps. In this example, it doesn't have a url attribute, so the UI knows that there's no button and no link visible.

I'm already a bit grumpy of the existence of :funding and :value without the addition of :monetization - do you think the current ones are extendable?

brianoflondon commented 3 years ago

I think the <value> tag has more than enough scope for this.

Even though there are no clients or infrastructure to support this yet, my feed has the following in it for distributing Hive Blockchain Dollars (a USD linked stable coin within the Hive blockchain). My address is simply @brianoflondon which makes things very readable:

        <podcast:value type="HBD" method="transfer" suggested="0.05">
            <podcast:valueRecipient name="podcaster" type="account" address="brianoflondon" split="95" />
            <podcast:valueRecipient name="host" type="account" address="threespeak" split="3" />
            <podcast:valueRecipient name="podcastindex" type="account" address="podcastindex" split="2" />
        </podcast:value>

I will write further elsewhere, however, about what we do about non-human readable crypto addresses which is something I don't like.

jamescridland commented 3 years ago

Oh, this is interesting. So perhaps...

<podcast:value type="webmonetization" method="interledger">
<podcast:valueRecipient name="podcaster" type="pointer" address="$ilp.uphold.com/nQPbmrYK979K" split="95" />
<podcast:valueRecipient name="podcastindex" type="pointer" address="[Another Interledger Payment Pointer]" split="5" />
</podcast:value>

This is nice.

brianoflondon commented 3 years ago

Exactly. The spec as it is right now is wide open. It's up to all of us to start building the infrastructure to use it.

I think there is plenty of flexibility around "method" for many different use cases.

daveajones commented 3 years ago

This is good. I like the flexibility here to be able to put anything in there. I’m working on the logistics of episode level value tags right now for testing different splits per episode. I think that really unlocks the potential here. Not sure how that would translate to webmonetization.

MartinMouritzen commented 3 years ago

Does the webmonetization standard allow for splits? I looked in the "Draft Community Group Report" but it did not look like it. - This would be quite crucial to be able to have adoption from Podcast Apps I'd say.

benjaminbellamy commented 3 years ago

From what I understood (correct me if I’m wrong), Web Monetization is just a way to send money to Interledger Payment Points. They suggest Probabilistic Revenue Sharing: https://webmonetization.org/docs/probabilistic-rev-sharing (They write “ONE WAY is through probabilistic revenue sharing ”) But I guess we can do whatever we want to with it as long as we specify (and develop…) very precisely what should be done and how. If we want to share, let’s share!

daveajones commented 3 years ago

This value block showed up in the index:

https://api.podcastindex.org/api/1.0/podcasts/byfeedid?id=779873&pretty

But, it doesn't seem to have any recipients attached. I think it belongs to @benjaminbellamy . If we make the "split" attribute optional, then it can be assumed to be 100% if it's all alone by itself. Save's space.

dellagustin commented 3 years ago

Just great to see this discussion is already happening here, I was about to create an issue about it. Thanks to the Castopod mastodon account for sharing this, I want to experiment with it.

dellagustin commented 3 years ago

Terminology

Useful Links

dellagustin commented 3 years ago

So, my thoughts, Web Monetization is only one of the ways of sending funds to a Payment Pointer, I think the type here should be Open Payments, which is more generic, as Payment Pointers are actually related to Open Payments.

A podcast app can decide to support Web Monetization, but as far as I understood, this would only apply for Web Applications, native apps would need to send funds in a different way using these Open Payments (I am still trying to understand how everything is connected together).

My suggestion would be something on the line:

<podcast:value type="openpayments" suggested="<amount>" currency="<ISO 4217 currency>">
    <podcast:valueRecipient name="podcaster" address="$ilp.uphold.com/nQPbmrYK979K" split="95" />
    <podcast:valueRecipient name="podcastindex" address="[Another Interledger Payment Pointer]" split="5" />
</podcast:value>

value's method and valueRecipient's type would be omitted in this case.

As this is quite generic, It would be suitable for Web Monetization, but also for applications directly implementing Open Payments.

One thing that will get confusing on the long run, but I don't know how to address, is how should apps react if they support more than one type of monetization (i.e. Open Payments and Lightning Key Send).

dellagustin commented 3 years ago

From what I understood (correct me if I’m wrong), Web Monetization is just a way to send money to Interledger Payment Points. They suggest Probabilistic Revenue Sharing: https://webmonetization.org/docs/probabilistic-rev-sharing (They write “ONE WAY is through probabilistic revenue sharing ”) But I guess we can do whatever we want to with it as long as we specify (and develop…) very precisely what should be done and how. If we want to share, let’s share!

If using Web Monetization, there isn't many other options for splitting the monetization, the main reason being that a single payment pointer can be set per Web Page, so it is necessary to "rotate" this pointer overtime, as it cannot stream payments in parallel to multiple payment pointers.

What is not clear to me, but I should read the spec, is how the browser and extensions should react to a change in the meta tag after the site is loaded (i.e. Single Page Applications, update when you load a new blog post or a podcast from another author).

It is also not clear if Browsers should monetize content consumed on the background (i.e. audio is normally playing on an unfocused tab).

dellagustin commented 3 years ago

If we make the "split" attribute optional, then it can be assumed to be 100% if it's all alone by itself. Save's space.

Or split evenly in case there are two or more entries.

daveajones commented 3 years ago

One thing that will get confusing on the long run, but I don't know how to address, is how should apps react if they support more than one type of monetization (i.e. Open Payments and Lightning Key Send).

Do you mean if there are two different blocks in the feed? That shouldn't be possible, if the spec is followed. Maybe I'm misunderstanding.

dellagustin commented 3 years ago

One thing that will get confusing on the long run, but I don't know how to address, is how should apps react if they support more than one type of monetization (i.e. Open Payments and Lightning Key Send).

Do you mean if there are two different blocks in the feed? That shouldn't be possible, if the spec is followed. Maybe I'm misunderstanding.

@daveajones yes, you are right, currently, as per the spec it is only possible to have one podcast:value tag. Neverthless, I think we should discuss the possibility to have multiple value blocks to accommodate different types of monetization.

Let's say a podcast wants to accept value in form of BTC through the lightning network, but also any other currency through Open Payments (i.e. using Web Monetization). I can't see both accommodated in a single podcast:value block right now, as it has a specific type.

benjaminbellamy commented 3 years ago

My 2 cents, I think it would make sense to have different types of monetization: When you go to a local store they accept different CC, cash, checks… Not all stores accept all of them… Not all customers have all of them…

So I think it should be the same here. Allow a podcast to accept multiple payment systems. Allow podcast apps to accept multiple payment systems. Allow user to chose their payment system.

It won’t work 100% but you will increase that percentage.

benjaminbellamy commented 3 years ago

If using Web Monetization, there isn't many other options for splitting the monetization, the main reason being that a single payment pointer can be set per Web Page, so it is necessary to "rotate" this pointer overtime, as it cannot stream payments in parallel to multiple payment pointers.

@dellagustin Revenue sharing with current version of WebMonetization is just a bad joke… It is really inadequate to podcasts (long content). I would not even try to implement it…

benjaminbellamy commented 3 years ago

A podcast app can decide to support Web Monetization, but as far as I understood, this would only apply for Web Applications, native apps would need to send funds in a different way using these Open Payments (I am still trying to understand how everything is connected together).

@dellagustin I am not sure if that’s what you’re asking here, but webmonetization can work in app (not only web). For instance, Coil.com provide an oAuth API to do that: https://docs.coil.com/oauth-api

dellagustin commented 3 years ago

If using Web Monetization, there isn't many other options for splitting the monetization, the main reason being that a single payment pointer can be set per Web Page, so it is necessary to "rotate" this pointer overtime, as it cannot stream payments in parallel to multiple payment pointers.

@dellagustin Revenue sharing with current version of WebMonetization is just a bad joke… It is really inadequate to podcasts (long content). I would not even try to implement it…

@benjaminbellamy It is not as good as sending the payments to all parts in parallel, but actually I think the probabilistic model would work if you have enough monetized listeners.

I have asked the coil.com support, you can update the meta tag and the monetization will be updated, so let's say my app is playing an episode, I can run the probabilistic code every minute, or every 5 minutes, and update the payment pointer, this would make the distribution reach an average faster then if I pick a pointer only once per episode play, for instance.

dellagustin commented 3 years ago

A podcast app can decide to support Web Monetization, but as far as I understood, this would only apply for Web Applications, native apps would need to send funds in a different way using these Open Payments (I am still trying to understand how everything is connected together).

@dellagustin I am not sure if that’s what you’re asking here, but webmonetization can work in app (not only web). For instance, Coil.com provide an oAuth API to do that: https://docs.coil.com/oauth-api

@benjaminbellamy Thanks for bringing the API to my attention, I was not aware of it. To my understanding the APIs + the OAuth Web Monetization Script serve the purpose of "emulating" Web Monetization for websites that want to provide it when used in browsers that do not yet support Web Monetization, nor have the Coil Extenstion installed (which is, most browsers today).

Web Monetization is a Web Standard, in the sense that it is made for browsers to provide monetization for websites and web applications.

Other app types could also monetize using Open Payments, but they would be using Web Monetization exactly, but they can emulate a similar functionality.

I have to say, I am not exactly sure on how this works, but the code for the OAuth Web Monetization Script are available here. At a first quick inspection I had the impression the amount that is transferred/streamed to the monetized web site is calculated on the client side, but I assume they have validations on the server side too.

In other words, I think we are agreeing, but using different terms 😃

As a side note, I cannot understand their business model, as they charge 5$/mo, but pay $0.36 per hour of content..., so ~15h of content for month, without taking into account the operational expenses, this does not seem to add up, or at least it does not look like it would scale if more website were monetized...

dellagustin commented 3 years ago

Regarding monetization of background content (i.e. podcast being played on an unfocused tab), I got a reply from coil:

Monetization of background content is on our roadmap but we're taking a careful approach as we want to prevent abuse of the feature. Current thinking is that we would use a permission model where a site can prompt to allow background monetization. This is being tracked in Coil's extension here https://github.com/coilhq/web-monetization-projects/issues/387 and on the WM standards here https://github.com/WICG/webmonetization/issues/17

dellagustin commented 3 years ago

I found this related discussion in the webmonetization github: https://github.com/WICG/webmonetization/issues/70

One suggestion was to use atom:link for monetization:

<rss xmlns:atom=http://www.w3.org/2005/Atom">
  <channel>
    <atom:link rel="monetization" href="https://wallet.example.com/example-website-wallet"/>
    <item>
      <atom:link rel="monetization" href="https://wallet.example.com/author/81"/>
    </item>
  </channel>
</rss>

It does not address the split though. I am more in favor of using the value block for webmonetization, just wanted to bring this FYI.

benjaminbellamy commented 3 years ago

I updated https://lespoesiesdheloise.fr/@heloise/feed.xml so that it meets <podcast:value> current requirements:

<podcast:value type="webmonetization" method="" suggested="">
   <podcast:valueRecipient name="Héloïse" type="ILP" address="$ilp.uphold.com/b7XRWWPW8aDn" split="1"/>
</podcast:value>

What do you think?

daveajones commented 3 years ago

Looks good. I think your split would be 100 in this case though.

benjaminbellamy commented 3 years ago

I updated split to 100 (although I guess the sum for all split should not necessarily be equal to 100). How do we say that we’d like to give 50% (for instance) to the podcast app (if we don’t know its payment address)?

daveajones commented 3 years ago

That’s an unknown. The app is expected to take 1% based on the current best practices. Having that split explicit in the value block shouldn’t be necessary. We’re anticipating there will be a free market that evolves around apps competing based on split percentage.

benjaminbellamy commented 3 years ago

Would that make sense to leave the complement to 100 to the App? For instance, if I have:

<podcast:value type="webmonetization" method="" suggested="">
   <podcast:valueRecipient name="Héloïse" type="ILP" address="$ilp.uphold.com/b7XRWWPW8aDn" split="98"/>
</podcast:value>

that would mean that the app can take 2% What do you think?

daveajones commented 3 years ago

That’s an interesting idea. I like it.

dellagustin commented 3 years ago

I implemented support for WebMonetization and this kind of block (https://github.com/Podcastindex-org/podcast-namespace/issues/132#issuecomment-739416709) in https://podstation.app, I am not sure it is working tough, let's see. image

benjaminbellamy commented 3 years ago

I implemented support for WebMonetization and this kind of block (#132 (comment)) in https://podstation.app, I am not sure it is working tough, let's see.

@dellagustin did you see that I updated the syntax so that it matches the <podcast:value> syntax? (There is no content attribute anymore):

<podcast:value type="webmonetization" method="" suggested="">
   <podcast:valueRecipient name="Héloïse" type="ILP" address="$ilp.uphold.com/b7XRWWPW8aDn" split="98"/>
</podcast:value>
dellagustin commented 3 years ago

@benjaminbellamy , yes, I saw it, I am getting it from the value block on the index API, I am not parsing the feeds myself there.

benjaminbellamy commented 3 years ago

Oooooh, of course.

daveajones commented 3 years ago

For the record, I’ve just been watching the discussion here in this thread to see where people’s needs are before making modifications to the actual spec as written. I’ll do that once there seems to be some consensus on the tweaks needed.

I’m thinking this is probably a Phase 3 tag since it’s complicated/important. And we know that we will probably need some type of signature hash in here as well for security.

AverageRandomJoe commented 3 years ago

Sorry I am butting in but I think that any unallocated (if it doesn't equal 100%) then the unallocated portion should be placed back pro rata in at the ratio the allocated is in there. So if it is 81%|9% is the split in the feed, (say the other 20% was just deleted because they aren't a part of the operation any more - that error is going to happen often I expect, especially if a show gives a cut to guests.) the net amount sent would actually 90%|10%.

The app should be able to place the amount they want to take on the back end and the allocation in the feed is how the remaining should be sent, the net remaining. Some apps may have more features and overhead while others will take less. Leaving it to the apps allows users to decide what features they essentially are willing to pay for as long as the cut is transparent. I am thinking about an app that gives a cut, say 1%, to playlist curators or jockeys. So I want to hear all the Godcasts that @daveajones absolutely loves. It could be all the feeds or his favorite episodes. He gets a cut for curating a list I enjoy so I don't have to go through thousands of podcasts and even more episodes to find what I want. I can find a jocky that has similar tastes. I don't think the feed should dictate how much the app gets nor should the standard.

You are also going to give a hurdle for apps if they have to support every value possibility, why not allow multiple with a hierarchy of preferences. Actually that sounds really complicated. But the issue stands what if I don't yet support every monetization/value method available in the standard and a feed uses it as their one and only? Act as if it doesn't exist and give them nothing? Sounds like a coincidence of wants sort of problem - but worse we only get one shot to see if there is that coincidence. It just creates a barrier to entry to entrants for apps and as more and more are adopted into the standard, the higher that barrier, which seems to be the opposite to the real goals here.

Just my two cents for what it is worth.

sharafian commented 3 years ago

Hi there, I'm one of the people developing Web Monetization and I just read over this thread. I want to offer any support you need on the Interledger/Web Monetization side as this would be a really cool use case!

One thing I want to comment on is the split revenue use case. While probabilistic revshare works when there are many users who are all paying about the same amount, there are other options. For example, a wallet could implement a feature where received money is split up and sent out to multiple wallets. This is nice because it doesn't put any extra load on the client to send all those extra payments. I believe this is a feature on the roadmap for https://vanilla.so/ which is currently an experimental project.

I personally think it's easiest to solve this at the payment pointer level as it removes the need for the podcast:valueRecipient to support all the different types of revenue sharing one could imagine and all the edge cases there. But it's still possible to implement what's being proposed.

To my understanding the APIs + the OAuth Web Monetization Script serve the purpose of "emulating" Web Monetization for websites that want to provide it when used in browsers that do not yet support Web Monetization, nor have the Coil Extenstion installed (which is, most browsers today).

Our OAuth-based Web Monetization script is intended to emulate Web Monetization, but the OAuth API itself just requests an auth token to our payment infrastructure and sends payments using Interledger.

So while it's possible to use on the backend we're thinking about how to make a nicer API to grant coil/interledger access in more comments. And this discussion is a helpful data point for that effort!

As a side note, I cannot understand their business model, as they charge 5$/mo, but pay $0.36 per hour of content..., so ~15h of content for month, without taking into account the operational expenses, this does not seem to add up, or at least it does not look like it would scale if more website were monetized...

Right now we pay $0.36/hr for the first ~15 hours and then spread out the last 50c at a much lower rate so that a user keeps having access to WM but cannot pay out more than they've paid in (we had issues with fraudulent users in the past). Today hardly anyone reaches that ~15 hours point, but we'll have to address this once there's more WM'ed content out there.

justmoon commented 3 years ago

As a quick update to what @sharafian was saying: We just started working on a new open-source project called Rafiki that wallet providers can deploy which would provide more general ILP access (not just $0.36/hr but pretty much any amount/schedule you want).

Here is more information: https://write.as/coil/introducing-rafiki-an-all-in-one-solution-for-interledger-wallets

cc/ @uchibeke

kookster commented 2 years ago

Hey folks - we're working on releasing web monetization support both to our RSS / podcast publishing, and in our new embed player, consistent with the way it is used and described by @dellagustin and @benjaminbellamy

I wrote up a description, largely based on their work and this ticket, and I was wondering what to do next? Maybe I could create a PR for the value specification with some version of these notes included in it? Would that be welcome @daveajones ?

i.e. I put a bit of a write up with references here: https://gist.github.com/kookster/cecb37d82b4dba2768997aca8b7a20e0

but maybe instead of a gist, a PR to this page to show how web monetization can be supported by these tags? https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md

daveajones commented 2 years ago

@kookster If you can do it as a PR with a separate file in the "proposals" directory that would be good. You can look at examples of other proposal docs like this one to get an idea. It doesn't have to be super formal. We can always do that part later.

Look forward to seeing what you have in mind.

To be clear, your solution is based on the <podcast:value> tag correct?

kookster commented 2 years ago

yes, exactly, it is using the podcast:value and podcast:valueRecipient tags, but this is proposing a standard way to use them for web monetization instead of lightning.

I thought maybe it would be good to PR the value proposal, and add to the "Supported Currencies and Protocols" (https://github.com/Podcastindex-org/podcast-namespace/blob/main/value/value.md#supported-currencies-and-protocols) ...but if you think this would be better in its own proposal, that's great.

I saw other proposals were often for additional tags, and this is an another use of an existing (proposed) tag, so I wasn't sure the best way to contribute something.

daveajones commented 2 years ago

@kookster Sounds great. I'm about to start adding links to the other currencies/protocols in the appendix section. Each link will be to it's own document. This will be some house cleaning as part of the opening up of Phase 6 of the namespace in the next week or so. Just write it up however makes sense given that paradigm and I'll clean up the organization when I do the Phase 6 work.

kookster commented 1 year ago

https://github.com/Podcastindex-org/podcast-namespace/pull/409

^^^^ Hey @daveajones I probably wrote this up in a terribly non-standard way, but here's a PR with a proposal of how to use WebMonetization with podcast:value.

FWIW - we have implemented and deployed this method of using podcast:value in our open source web player (https://github.com/PRX/Play-Next.js), but of course if the proposal lands differently, happy to go back and refactor our implementation.

Thanks for your time, guidance and help, -A

jamescridland commented 1 year ago

PRX have just announced support for web monetization in the podcast:value tag. This is great news. It's live in the Song Exploder podcast, and the PRX embedded player supports it (as above).

@daveajones - the podcast:value tag says in the spec that it may only be in there once. However, a use-case here is that you may wish to indicate that you accept payment via web monetisation $ilp.uphold.com/nQPbmrYK979K or via streaming sats. How much would it break things if we were to make this tag be allowed multiple times, once for each payment option?

Later: looks like this Castopod podcast has both options; and therefore the Podnews Daily does too.

adamc199 commented 1 year ago

The value tag signals payment amounts that are open, not restricted to set amounts. The genesis is value4value Is this possible with webmonetization?

If not, it needs to be be it's own tag in my opinion

adamc199 commented 1 year ago

Additionally, the lack of split capability removes the podcast apps from the value chain. V4V was purposely designed to bring them in.

kookster commented 1 year ago

The value tag signals payment amounts that are open, not restricted to set amounts. The genesis is value4value Is this possible with webmonetization?

The web monetization / interledger standards are not restricted to set amounts The rate and amount of payments are based on the web monetization agent, and it would be fine for an agent to allow custom rates and one time amounts.

The current coil agent implementation, which is the one most folks use now, does use a set amount, but they don't plan on staying with that, and have already implemented "tipping", including this test of the system with the Mozilla festival: https://community.interledger.org/interledger/announcing-a-tipping-experiment-at-the-mozilla-festival-4h58

kookster commented 1 year ago

Additionally, the lack of split capability removes the podcast apps from the value chain. V4V was purposely designed to bring them in.

Splits are supported in webmonetization e.g. alice gets 50%, bob gets 40%, connie 9.5% and dave only gets .5% in this example of how to do it: https://webmonetization.org/docs/probabilistic-rev-sharing

I'd prefer to see a built-in way to do this with their API, and I expect that will mature, but they get this is important and show how to support it right now.

kookster commented 1 year ago

I can't speak for coil like @uchibeke or @justmoon who commented above, but coil's OSS Rafiki project implements an ILP wallet to support more than just a standard rates, and which could be used more like v4v, including native app integrations and more V4V like payments: https://dev.to/coil/interledger-2022-the-year-of-rafiki-3b71

The direction this is headed does seem to me like it will overlap even more with the intent of the podcast:value tag, so I think it still makes sense to use that for ILP and web monetization.

uchibeke commented 1 year ago

@kookster you're right. The Rafiki project will enable wallets to support different interledger methods like accepting and sending different payment amounts ({value, currency}).

A new wallet is being built with Rafiki, which will enable more people to get access to Interledger

adamc199 commented 1 year ago

"Tipping".

Sigh

brianoflondon commented 1 year ago

@kookster who is working on Podcasting Apps that will use this?