Tipping should trigger 'monetizationprogress' event?

[justmoon]

Currently, leaving a tip issues a non-standard event tip. (Which as a side-note should probably have a vendor prefix since it's non-standard, like coilTip or coiltip. For an example how different browser vendors handle vendor prefixes for JS events, see CSS3 Animation Events.)

I think it's fine to have a separate event for tipping but I think a monetizationprogress event should be triggered also. For instance, if a page is unlocking a reward when I pay a certain amount of money, my tips should count towards that.

That does require that the receipts for the tip are somehow passed from the Coil tipping service back to the client I suppose?

Lmk if you think I'm way off here or - if you agree - how we might implement this.

[sublimator]

I vaguely recall us discussing this and asking the same question.

What about setting the document.monetization.state? One would assume that other payments have already started. Some consideration would have to be paid to forward thinking concerns like the ability to start/stop streams (be it manually or via Maxwell Smart)

The receipts never show the total for the current requestId anyway, only for the current STREAM connection/stream. It wouldn't be that confusing to just inject an extra 'monetizationprogress'

[sublimator]

@sabinebertram

Any recollections/insights ?

[justmoon]

What about setting the document.monetization.state?

Hmm, that feature is an aspect of the spec that may not make sense anymore.

In my opinion, Web Monetization is a combination of:

• A declarative tag for the website to tell the user agent how to pay it
• A JavaScript API for the user agent to tell the website when (and how much) it has paid

The most definitive thing that the JavaScript API can say is how much it has paid, i.e. monetizationprogress. And with STREAM receipts, it can even provide proof.

Beyond that, I guess what the monetizationstart event is supposed to do is to provide a hint that the browser is planning to pay in the future. But it doesn't really tell you how much it is trying to pay or when. For example, suppose I'm a user agent and I want to pay each website out at the end of the month. Would I emit a monetizationstart event or not? What about a user agent who is planning to pay, but very, very little? How would the site know that the promised payment won't be enough to not load the ads for instance? And of course the user agent might outright lie and never actually pay.

When we originally came up with Web Monetization, we imagined it as this smooth stream of money of a constant amount. I.e. it was relatively consistent both across time and across users. But since then:

• We've received feedback from Brave that they prefer to pay asynchronously (e.g. at the end of the month.)
• We've received feedback from mobile browser vendors that they want to minimize the number of times the radio is active. (And to address that we came up with the model where you pay with an exponential backoff period. E.g. you pay $0.01 immediately. Then, at t=1, you pay $0.02. At t=3, you pay $0.04. At t=7, you pay $0.08. At t=15, you pay $0.16. And then you pay $0.16 every sixteen time units. That way, the amount paid still approximates the time spent on page, but battery usage is much, much lower for long-lived sessions like watching a video or listening to a podcast than when you're paying during every time unit.)
• We got more interested in tipping and monthly subscriptions as a use case for Web Monetization.

So without the notion of a consistent "stream of money", it doesn't really make sense to talk about a "monetization state" anymore. Some related issues on the spec:

WICG/webmonetization#45 WICG/webmonetization#46 WICG/webmonetization#23

I should probably add my two cents to those issues or make a new one to further elaborate on how I would propose generalizing the spec. But yeah, I think it would involve deprecating monetization.state.

The main use case for the state seems to be that a website might not want to load a bunch of ads and trackers if the user is going to be a paying user. The best you can do with that is to trust the browser's initial hint, not load the trackers, and then if the payment doesn't come through, you timeout and load the ads and trackers. But in the "user agent pays but not enough" and "user agent lies about planning to pay" cases, you would have rather loaded the ads right at the beginning, so websites may not be willing to implement this method long-term. Perhaps a more promising avenue would be for the user agent to provide evidence that it is going to pay. For instance, Coil members could prove their membership via something like the Trust Token API and websites would see over time that Coil members tend to pay at a certain rate and then turn off ads and tracking for them right away. Maybe "promising to pay" is simply out of scope for the Web Monetization spec or the spec would specify how a user agent should utilize trust tokens to make their future payment behavior predictable to the website in a trustworthy way.

Another thought that might be relevant: For the case where payments happen when the browser isn't actually on the page at all, it might be nice to have a difference way to notify the website instead of JavaScript, such as a webhook There are precedents for this, such as the CSP report-uri. You could imagine something like <meta name="monetization" value="$example.com; report-uri=https://example.com/wm-reports">. The JS API is of course still really nice to have not just for streaming but also for tipping, giving the website an easy way to react to receiving money in real time.

[sharafian]

Agreed that this should be a monetizationprogress event. I also agree that we're probably close to outliving the usefulness of the monetization state.

I'll think about what we can do there, I like the simplicity of WM as a single event stream of payments rather than this somewhat convuluted state machine we've ended up at.

Maybe just checking for presence of the WM API is an acceptable stand-in for the pending state? It could bridge the gap until we introduce some trust-token attestation from the provider. It does seem important that sites have an opportunity to delay the loading of ads and trackers

[sublimator]

Logging a slack discussion here:

@sublimator

Could/should this be implemented as a “burst” on an existing monetization stream? Would you even need a “tip” event in that case? Integrations could simply look at amounts ?

ponder

@sharafian

Yeah it should just emit a monetization progress event and the site can look at amount

[sabineschaller]

Any recollections/insights ?

I think we made it an extra event (and I agree that tip was probably not the greatest name for that) because tipping performs a GraphQL mutation instead of an immediate payment via a STREAM connection.

But maybe that was just my justification. I don't recall a lot of discussions tbh.

[sublimator]

I don't recall a lot of discussions tbh.

I recall waiting for receipts.

There's a languishing tip PR here that I need to finish up, we can add it in that.

[sharafian]

Yeah, I think how we landed on the tip event isn't such a big deal if we agree it should be a monetizationprogress event. Although I guess one wrinkle to it is that the tip doesn't use the Web-Monetization-Id and it won't provide receipts. Maybe that was the reason we didn't use monetizationprogress?

[sublimator]

Sounds about right ?

[sublimator]

Would it be a huge amount of backend work to somehow implement tips as a "burst" on an existing STREAM ? Of course that might mean the payment will be "chunked" so you may not necessarily get one nice event.

[sabineschaller]

tip doesn't use the Web-Monetization-Id and it won't provide receipts

Now that tips will have receipts, what are our latest thoughts on whether tips should be monetizationprogress events? The decision will influence the widgets we want to build.

[sublimator]

The new implementation of tipping will be sending the actual payments async so it will be hard to present a receipt