The currently drafted Web Monetization Spec is certainly a good first step into the right direction. However, if we want to use it as a viable addition to the Micrio business model some changes need to be made to fit our vision of the product. We like to share our thoughts & ideas with you. Hopefully sharing this helps to strengthen the spec.
The problem of a fixed payment stream rate
The current Coil implementation features a fixed payment stream that can not be influenced by the user of a website. While this might be a secure implementation (the stream can not be tampered with), it also has some implications.
First it implies that every type of content has the same value. It doesn’t matter if it’s a video, a game or a large research blogpost. Although the costs for the content creator might differ a lot, they receive the same amount of money. We think that this is not a healthy situation for the content creator.
Second, the Web Monetization API can be used worldwide. A content creator in the USA will have the same stream rate compared to a content creator in for example Cambodia. Although the same rate will give you way more purchasing power in Cambodia. So globally seen, we think this is not sustainable.
We feel like that the API should have more options to customize the payment behavior, like setting an amount per time-unit, the currency and maybe a maximum amount. By adding more tags, the customization of payment options would be possible and the API is suited for more scenarios.
Suggested API changes
In the process of making up suggestions for the API, we looked as much to the underlying Interledger protocol as possible.
monetization:asset
<meta name="monetization:asset:amount" content="125" />
The amount tag defines the price per minute in the currency calculated by the code and scale tag. This replaces the fixed rate set in the current implementation.
<meta name="monetization:asset:scale" content="4" />
The scale tag defines the scale of the payment. The scale divides the amount and max_amount by 10 to the power of the value (e.g. amount / 10 ^ scale).
<meta name="monetization:asset:code" content="EUR" />
The code tag defines the currency following the ISO 4217 spec in which the payment should be done.
<meta name="monetization:asset:max_amount" content="250" />
One of the most important changes would be to add an extra monetization:asset:max_amount or "price" meta-tag that hooks into the monetizationprogress event. The value of the content attribute should be a numeric value which corresponds with the price of that web-page. When that specific value is reached, the monetization stream should stop automatically.
Suggested supportive browser changes
By unlocking the payment stream, we also expose the user to more risk. What if someone is asking 100 dollars per minute, without users’ explicit consent? Regardless of whether this is possible within the concept / regulations of ‘micro payments’. Therefore we suggest a feature in the browser where you can set a rate limit for the maximum amount per minute without consent. If the user navigates to a website where the asked rate is above the threshold, you will first have to give your consent for a one-time exception for the rate limit.
We are curious about what you think of our suggestions and hope this (and the discussion) will strengthen Web Monetization as a concept.
In the next post is serie you can see it in action and play with it yourself.
Top comments (6)
Thanks for this, @roelfjan .
Invoking @adrianhopebailie and @sid 's attention here. They may kindly request some of these suggestions also be added within other platforms where spec discussions are happening.
Thanks for sharing your use case and idea, @roelfjan . But I think this can potentially be abused by websites. In short, a website will try to reach the maximum amount a user can pay, and with it comes tracking, fingerprinting and more friction to the end user. Let me explain how:
Consider a user who has configured a rate lower than the website has asked for, so they're prompted for their consent. If the user declines, a website can know this potentially via
monetizationprogressevent not being fired. So, next time, it'll ask for a lower value until user is happy (or it can start with a lower value and raise it until the user declines). Now every website does the same to get maximum revenue, leading to either nearly same amount getting paid to each site, or more sites getting blocked by user - both adding to the annoyance for the user. Websites may also start tracking user's "potential to pay" across sessions or different websites. So, this moves control away from the user.Thanks for your feedback! That's clear, I didn't think of that. Although finding the correct price is also how it works in the offline world when you buy a newspaper for example. But on the internet there are more tools off course to find a price.
What I like in you answer that this is all about what's good for the user, but I miss something from the point of view of the content creator.
What I read in the GitHub thread is something that the provider should fix this. I'm really curious about how this can work, because I don't see it at the moment. And if then the problems we see, stated in the paragraph 'The problem of a fixed payment stream rate', can be fixed with it.
IMO, it looks like price negotiation is not something websites should do, so we need other ways to satisfy needs of content creators. Some alternatives/workarounds we've have considered about non-fixed payment stream rate:
Personally, I see WM as an alternative to ads, and not subscriptions. Websites don't ask users to click an ad N times to reach an acceptable amount of money, so I think its fair that websites don't set a rate for WM. Though, the idea of consent-less micropayments needs more exploration.
Yeah, it's a challenge to find the correct solution (if there is a solution anyway)...
I really like the consent-less idea behind WM. That's what we tried to keep in our suggestion.
One-time tipping is already possible via other ways, although it probably could be improved to make the bar lower. I'm curious if this would work for a content creator to have a sort of stable revenue.
I think the challenge with setting weight/rate by user/provider is, that they don't know the costs for a content creator. For example the costs for a 'simple' blogpost compared to the results of an extensive investigation might look the same in terms of length, visitors, etc.. but an extensive investigation might cost 10 times more to create. If the content creator wants to continue making those investigations, it should earn enough.
I could see WM as an alternative to some subscriptions, I'm then thinking about newsarticles. I find it very frustrating that I can't read/buy a single article. I'm not going to take a subscription on all newspapers... An alternative might be to have a wallet in your browser, so it could be very easy to pay the content creator. But then you have a consent back again...
What I don't know is what websites nowadays earn via ads and if WM is actually in terms of the current payment rate an alternative to ads.
I'll keep thinking about this.. if any idea pops up I'll share it
Also came across a relevant discussion:
Should there be support for specifying a rate? Some sites may want more than 1e-9 (edit: arbitrary illustrative figure, not what providers currently pay) USD a second for their content.