Explain how browsers should handle multiple or dynamic meta tag for monetization

[fred-wang]

https://webmonetization.org/specification.html#flow says

There MUST be only one tag at any given time

so I assume that when there are multiple tags, monetization should just be ignored. However, there are probably alternatives e.g. consider multiple monetizations or just the first one found. I guess it would be worth getting feedback from browser developers about the easiest option to implement.

Similarly, I'm not sure what happens when the meta tag is added/removed dynamically via javascript after page load... Should only a meta tag at page load considered?

Note: If both meta and link elements are supported ( #19 ), one can also specify multiple monetizations with different elements, so that would need to be clarified too. I guess some page authors would like to specify both versions for better interoperability and just ignoring everything seems wrong in that case.

[sublimator]

Hi @fred-wang

I can't speak to future plans, but currently with the proof-of-concept working implementations ( polyfill script and extension) we:

• handle only <meta> tags, not <link>s
• track monetization meta[name=monetization] with a MutationObserver on the head and if there is more than one it will throw an Error ( read: silently do nothing except log to the console )
• support dynamic meta tags

[fred-wang]

Thanks for the explanation @sublimator ; this matches how I understood the current status.

Reading https://webmonetization.org/specification.html#flow again, one can put a <meta name="monetization" content="URL1">, remove it, then add a new <meta name="monetization" content="URL2">. And this will trigger two payment requests for URL1 and URL2. Is it intended? Why not allow multiple meta tags at page load in the first place, then?

I think mechanism will have to be implemented in the UI to avoid too many noise for users in any case and allow them to discard or accept several payments in one go. From my quick look at chromium's code, each meta tag has their content parsed independently, so it's probably easier if the 'There MUST be only one meta name="monetization" tag at any given time' condition is dropped and the multiple requests handle specially (just a guess though).

Additionally, IIUC the spec allows this flow:

A. The user agent sets document.monetization.state to started (for the URL1 request)
B. The user agent sets document.monetization.state to started (for the URL2 request)
C. The user agent sets document.monetization.state back to pending (for the URL1 request)
D. The user agent sets document.monetization.state back to pending (for the URL2 request)

So between steps C and D, request for URL2 is still running but document.monetization.state is pending, which is probably not intended. I think either document.monetization should be a map from URLs to states or requests should be queued and executed one-by-one at step 3.

[sublimator]

Yes, currently the spec/impl supports only ONE request at a time and the document.state matches that one request. It's a limitation I've also pondered.

Personally I would be supportive of multiple requests at once. I think there was some talk of revenue sharing being easier on the backend, though that would not be as flexible.

[sublimator]

document.monetization should be a map from URLs to states

Potentially a map of requestId -> state ?

[fred-wang]

document.monetization should be a map from URLs to states

Potentially a map of requestId -> state ?

Again, I didn't implement anything and just read the spec, but I understand that if one adds a tag with a content="URL", removes it from the doc and appends it again then step 3 is executed twice with the same URL but with different generated UUIDs. So I guess it depends on whether we want to allow multiple requests for the same URL or not. If so, then using requestId -> state would work too yes.

We can also add more members to MonetizationState in order to store the associated URL or requestId, it really depends on what web developers want...

[sublimator]

Interesting, thanks for sharing your food for thoughts!
There are privacy concerns re: the requestId/url mapping others are likely better to weigh in on :)
cc @sharafian @adrianhopebailie

[totorogendut]

Would sharing revenue with dynamic tag that changes every few seconds disrupt payment streaming?

Something like this:

• Website gets 40% revenue -> point meta tag to website owner's receiver address for 4 seconds
• Content creator gets 50% revenue -> meta tag changes again for 5 seconds
• Referral (affiliate marketing, if any) gets 10% revenue -> meta tag changes for 1 second
• repeat until page closed

If it works I think it's a reasonable workaround until one meta tag limitation being lifted

[matdehaast]

@ProgNovel
That would in theory work but has some drawbacks:

• Context switching to new payments pointers has a high cost (~1-4s though this is being worked on to reduce the overhead)
• It would mean that the sharing is not exact as it would depend on where in the lifecycle of the context switching a user leaves the site. ie If a user is the site for only 8s the website would get the bulk of the revenue and the affiliate none.

My opinion is that complex scenarios like the one you describe is best addressed at the digital wallet level. IE I can configure my payment pointer to do the rev sharing at my wallet when funds come in.

For me the complexity of multiple payment pointers is scenarios when you have an embedded object that you also want monetization to occur on. An example would be that I have a webmonetized blog and embed a webmonetized video from another site and creator. How do we deal with monetization in this scenario?

[totorogendut]

I wasn't aware the overhead could be that long. If that the case then indeed revenue sharing with the method I'm talking about is a bit tricky to implement. I might experiment with it later if the overhead reduced to a reasonable level.

Though doing revenue sharing in digital wallet level seems more reasonable and can be a very nice feature, I don't think it should the final solution either, since web monetization should be open, and by doing this more or less force the revenue sharing receivers to have accounts on the same digital wallet providers--which isn't ideal, since different digital wallet providers have different policies and different availability based on countries (Stronghold, for example, hasn't yet available in my country).

---

For embedded webmonetized contents, I do think the permission to stream payment toward third-party creators should fall to website owners and developers, not the users. Something like setting CORS, the third party content can only be embedded if the developer put a relevant attribute on the HTML element to allow switching pointer to third party content creators.

For third-party videos, the flow I could thinking of is like this:

1. Website owner gives permission for webmonetized video to get streamed
2. The video gets embedded, waiting for user interaction
3. Upon clicking the video, a modal will pop-up that overlay the page except for the video (force focus on the video)
4. Waiting for web monetized to connect to video creator's address, upon succeeding, play the video
5. If the video finished or the modal closed, connect back the web monetized stream address to original website owner's

It's not ideal, but that's the flow I could thinking of if considering web monetization doesn't support concurrent payment streaming.

[tobie]

Worth looking at how other meta tags are specified in the HTML spec, and being consistent (if there is consistency).

[jameshartig]

If you have a SPA you might need to swap out the meta tag if they switch pages. For instance, if you operate a video service you might want to pay out to the creator while you're watching a video. If they switch to a different video you would want to stop the previous stream of payments and switch the meta tag to point to the new creator. Even if the video service is the owner of both payment destinations they would need a way to differentiate which destination maps to which creator.

[sidvishnoi]

Worth looking at how other meta tags are specified in the HTML spec, and being consistent (if there is consistency).

Meta tags:

• First wins (or, "there can be only one"): application-name, description, theme-color, color-scheme
• Last wins: referrer (allows fallback for legacy browsers; unsupported values are ignored, previous supported values are not overwritten)

Link tags:

• First wins: manifest
• Last wins: icon

Rest are either not spec'ed, or allows multiple instances.

Re: multiple tags

What are the use cases for multiple tags that are not covered by Probabilistic Revshare or dynamic tags?

From implementation perspective, each has its benefits and trade-offs:

• First/last:
  • on each change (append/prepend/attributeChange), browser will have to search the DOM tree for the first/last valid tag and if there is a change, stop previous stream and optionally start a new one. This supports SPA use case also.
• Multiple tags:
  • they're independent so browser maintains lesser state and has to do lesser tree traversal;
  • ...while also a little more state (document.monetization.state)
  • more communication with WM agent,
  • more impact on performance (what if we also support payments in background tabs),
  • might need to define relative weights (more complexity, unless we treat each equal).
  • and also handle mutations?

[sublimator]

It's currently prototyped as 'first wins', in the sense of 'first added', though not specified as such. If you add more than one tag at a time (anywhere in the head), it just logs an error for the tags added last.

Note that with the extension, we have prototyped iframe monetization so we currently do support/have experience with, multiple streams. We currently have no encoded limit on the number of iframes or any particular weighting strategy. Performance isn't spectacular as you add more and more (primarily, I'm guessing, cause of throttling on the backend).

[sidvishnoi]

If you add more than one tag at a time (anywhere in the head), it just logs an error for the tags added last.

@sublimator
So, if we remove the first one, does the second one become "first" and switches the payment stream? If not, I think this should be supported.

Note that with the extension, we have prototyped iframe monetization so we currently do support/have experience with, multiple streams.

How does it play with document.monetization.state at present?

---

Also from #41 (comment), I'm really interested in a discussion about:

What are the use cases for multiple tags that are not covered by Probabilistic Revshare or dynamic tags?

The issues I can see right now are that the prob revshare has a server dependency, and dynamic tags have a context-switching delay.

[tobie]

If you add more than one tag at a time (anywhere in the head), it just logs an error for the tags added last.

I think it's important to follow whatever conventions there are for link tags here, unless you have really strong reasons not to do so.

[sublimator]

@sidvishnoi @tobie

You guys are raising some good points/issues. Note before I was simply stating how it was currently implemented, not advocating that it SHOULD be like that.

So, if we remove the first one, does the second one become "first" and switches the payment stream? I

No, I don't believe it does.
We do have plans to tighten up the handling of tags (handling combinations of deprecated meta and link tags for example) , to handle more edges cases but because in practice it isn't really an issue, it has't been given priority.
It's one of those "just don't do that" type things.

I'm recovering from some illness at the moment so will hold off on advocating for any particular scheme.

How does it play with document.monetization.state at present?

Each iframe has its own independent document.monetization.state and events from child frames aren't emitted in ancestor frames. Note also that there is talk of deprecating document.monetization.state, start/stop events, and simply emit events on each payment. I imagine an issue will be created on that topic soon if it hasn't already been done.