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 monetizationprogress event 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.
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.
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
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
For further actions, you may consider blocking this person and/or reporting abuse
A place to discuss all things Interledger