> You can adjust how much you want to pay the site per hour and also send one-time payments. The money is "streamed" every minute, which you can observe in DevTools.
I guess the era of being able to leave a tab open without worrying about it is long over. Now you'll need to be careful to close every tab the moment you're done with it - perhaps after taking a screenshot of the page so you can read it more cheaply.
It only streams money when the tab is in the foreground and active. But yes, if you are on a monetized tab, get called for lunch, and don't lock your computer (what's wrong with these people , it could be that you stream all your funds to that one tab. I think the extension and the final browser UI once it's natively supported needs a way to let you limit the maximum amount of money, and also show you stats about where your money went so you can more easily adjust each site's amount.
When Coil did their demos years ago the payment streaming examples were videos and music. A pay per minute kind of deal. Payment streaming for read content does sound abusive especially for slow readers.
Web Monetization supports multimedia content monetization as well (you place the `link` in your `audio` or `video`). Don't forget that you are in control. If you're a slow reader, adjust the site's amount, so when you spend a long time on a page they don't get excessive payments.
I guess if it would reach the higher level of adoption there would be a very easy way to charge back for the auto- requested stuff.
Also there could be mandatory confirmation required for any amount set.
Want to remove ads? Click and confirm.
For just donating 1c per minute of reading you could have those queued somewhere and still have a chance to explicitly approve it once a month / a week / a day
Web monetization looks so promising. The big hang up for it to work is users have to have an account somewhere shared or penny transactions and payment streaming are too expensive. The cost of bank transfers kills it otherwise.
Does this require a GateHub account to send and receive? The benefit of Coil was that there was no central account issuer. It works directly with the XRP ledger. The catch with that one is payments in anything other that XRP must be tokens on the ledger.
I like the idea but so far I keep seeing lack of adoption, in the case of Coil, or a shared institution requirement. If either of those get fixed web monetization will take off like wild fire.
This is the first time I've heard of this standard and it looks interesting, but it doesn't seem like the payment processing is well standardized. I see in the W3C draft that the "Interledger Protocol" should be utilized, but looking at the wallet limitations (https://webmonetization.org/wallets/#limitations) it seems like there are no wallets that allow cross-wallet payments. Is that something thats planned in the future, or will wallets be allowed to lock down who can pay who?
> You can adjust how much you want to pay the site per hour and also send one-time payments. The money is "streamed" every minute, which you can observe in DevTools.
I guess the era of being able to leave a tab open without worrying about it is long over. Now you'll need to be careful to close every tab the moment you're done with it - perhaps after taking a screenshot of the page so you can read it more cheaply.
It only streams money when the tab is in the foreground and active. But yes, if you are on a monetized tab, get called for lunch, and don't lock your computer (what's wrong with these people , it could be that you stream all your funds to that one tab. I think the extension and the final browser UI once it's natively supported needs a way to let you limit the maximum amount of money, and also show you stats about where your money went so you can more easily adjust each site's amount.
Here's the docs for how and when continuous payments are being sent: https://webmonetization.org/developers/link-element-webpage/....
When Coil did their demos years ago the payment streaming examples were videos and music. A pay per minute kind of deal. Payment streaming for read content does sound abusive especially for slow readers.
Web Monetization supports multimedia content monetization as well (you place the `link` in your `audio` or `video`). Don't forget that you are in control. If you're a slow reader, adjust the site's amount, so when you spend a long time on a page they don't get excessive payments.
Here's the docs for this: https://webmonetization.org/developers/link-element-webpage/.... You can monetize `audio`, `video`, and `picture` as well.
For the sake of completeness, you can also monetize your Atom, RSS, and JSON feeds: https://webmonetization.org/developers/rss-atom-jsonfeed/.
I guess if it would reach the higher level of adoption there would be a very easy way to charge back for the auto- requested stuff.
Also there could be mandatory confirmation required for any amount set.
Want to remove ads? Click and confirm.
For just donating 1c per minute of reading you could have those queued somewhere and still have a chance to explicitly approve it once a month / a week / a day
This makes it obviously a pain in the ass that nobody normal will tolerate; dead on arrival, waste of time
What happens if you block network for the tab once it's finished loading? Does it delete the page if payments aren't going through anymore?
I think this would technically be possible, but less practical once it's supported natively in the browser.
You can also add OpenAlias DNS TXT record with your cryptowallets, also web monetization of another kind.
https://openalias.org/
Not to be confused with the already existing Payment Request API: https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...
Web monetization looks so promising. The big hang up for it to work is users have to have an account somewhere shared or penny transactions and payment streaming are too expensive. The cost of bank transfers kills it otherwise. Does this require a GateHub account to send and receive? The benefit of Coil was that there was no central account issuer. It works directly with the XRP ledger. The catch with that one is payments in anything other that XRP must be tokens on the ledger.
I like the idea but so far I keep seeing lack of adoption, in the case of Coil, or a shared institution requirement. If either of those get fixed web monetization will take off like wild fire.
still, the problem is people have to implement it and people have to assign wallets and the like. wrong idea for the problem at hand.
This is the first time I've heard of this standard and it looks interesting, but it doesn't seem like the payment processing is well standardized. I see in the W3C draft that the "Interledger Protocol" should be utilized, but looking at the wallet limitations (https://webmonetization.org/wallets/#limitations) it seems like there are no wallets that allow cross-wallet payments. Is that something thats planned in the future, or will wallets be allowed to lock down who can pay who?
This is not a "standard." From their documentation[0]:
And nothing about the "Web Monetization" primary intent[1] is appealing as a standard worthy of being adopted: 0 - https://webmonetization.org/developers/link-element-webpage/...1 - https://webmonetization.org/