search

WICG / webmonetization

Proposed Web Monetization standard
https://webmonetization.org
Other
457 stars 152 forks source link

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

Closed fred-wang closed 1 year ago

fred-wang commented 4 years ago

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 commented 4 years ago

Hi @fred-wang

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

fred-wang commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

document.monetization should be a map from URLs to states

Potentially a map of requestId -> state ?

fred-wang commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Something like this:

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

matdehaast commented 4 years ago

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

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 commented 4 years ago

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 commented 4 years ago

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

jameshartig commented 4 years ago

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 commented 3 years ago

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

Meta tags:

Link tags:

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:

sublimator commented 3 years ago

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 commented 3 years ago

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 https://github.com/WICG/webmonetization/issues/41#issuecomment-715541930, 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 commented 3 years ago

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 commented 3 years ago

@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.