If we want webmonetization to be a standard, we cannot expect that (at best) only 2% would use it.
That is correct, but I think we can overcome this limitation with default browser extensions as I explained in the post. This doesn't mean I am advocating the extension approach over PaymentHandler, just sharing the trade-offs and limitations of each.
I wonder why you haven't gone that road with a different browser if Mozilla doesn't support it?
I am more aware of the internal working of Firefox than of Chrome, and compiling Firefox locally is faster, which is good for prototyping. Besides, the grant was legally between me and Mozilla, so switching to different browser would've meant a lot of paperwork in the middle of the project, leaving behind at least half the progress already done in Firefox, if even possible.
Also, what would be your way forward in case of using a Payment handler API on Chrome for example?
There are two major differences with how the PR/PH APIs currently work that we would need to change:
allow payments without user interaction, and
do not show the UI (it's kinda same as previous point, but different).
I think there are two ways we can go ahead with the PaymentHandler approach. One way is similar to how the PR/PH work presently: expose a new payment handler method to the websites that guarantees no UI for small payments and let websites handle them, as described in this GitHub discussion. What counts as small payments worthy of no UI (or no consent) is a point of debate, and as its own issues. If we want the websites to specify the rates, that has its own issues.
Other way would be to keep the payment method exposed only to browser internals and let the browser (or some other WM agent) control the payment rate. This would mean browsers can reuse the PR/PH architecture.
Above also implies we can have two WebMonetization APIs that support payments over ILP. One is how the current WM works (users pay as they see fit), and the other is similar to PaymentRequest (websites ask how much they want).
For further actions, you may consider blocking this person and/or reporting abuse
That is correct, but I think we can overcome this limitation with default browser extensions as I explained in the post. This doesn't mean I am advocating the extension approach over PaymentHandler, just sharing the trade-offs and limitations of each.
I am more aware of the internal working of Firefox than of Chrome, and compiling Firefox locally is faster, which is good for prototyping. Besides, the grant was legally between me and Mozilla, so switching to different browser would've meant a lot of paperwork in the middle of the project, leaving behind at least half the progress already done in Firefox, if even possible.
There are two major differences with how the PR/PH APIs currently work that we would need to change:
I think there are two ways we can go ahead with the PaymentHandler approach. One way is similar to how the PR/PH work presently: expose a new payment handler method to the websites that guarantees no UI for small payments and let websites handle them, as described in this GitHub discussion. What counts as small payments worthy of no UI (or no consent) is a point of debate, and as its own issues. If we want the websites to specify the rates, that has its own issues.
Other way would be to keep the payment method exposed only to browser internals and let the browser (or some other WM agent) control the payment rate. This would mean browsers can reuse the PR/PH architecture.
Above also implies we can have two WebMonetization APIs that support payments over ILP. One is how the current WM works (users pay as they see fit), and the other is similar to PaymentRequest (websites ask how much they want).