-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<link>
vs <meta>
#19
Comments
Can you expand upon this? I'm not super familiar with |
Correct, it wouldn’t... but it could cover any preconnection to a monetization server, for instance. Dynamic includes would be covered separately. |
Sure, each tag has very specific behavior in the browser. In particular https://github.com/mozilla/gecko-dev/blob/master/dom/html/HTMLLinkElement.cpp |
Lol, cheers, grabbing dinner this side of the world :) I will look later. Keen to see how this fits in with potentially dynamic (read JS injected) When I think of “parser” I am imagining you are referring to the bytes to |
Should this also be supported as an HTTP header? Imagine a user visits Example apache impl.: <IfModule mod_headers.c>
Header set Link "<https://secure-wallet.example.com/alice>; rel=monetization"
</IfModule> Unfortunately that means only web authors with access to the server-side will be able to make sure they're properly monetized for all their content. Perhaps by adding an inline |
Seems like another good argument for using |
While thinking about this, I noticed that Web Monetization does have some behaviors that are similar to how browsers handle
I think overall I'm convinced that it would be desirable to change the standard to:
Is |
Hate to also bikeshed but "monetization" is a bit of mouthful :) Seems like "wallet" might be good fit. |
https://www.iana.org/assignments/link-relations/link-relations.xhtml There is already a "payment" rel link registered which has no reference and appears to have very little prior use. It is also defined in the registry as doing exactly what we need and the details suggest our usage fits with the intent. |
👍 I like the idea of using something pre-existing. I have little attachment to the name "monetization" other than an aversion to breaking changes but it sounds like we'll get our fair share of those in the future anyways |
I’d just like to share some thoughts on this from my blog:
Semantically, The most important difference is that the On a more trivial note, |
@da2x wrote,
@da2x, you are definitely not wrong. However, there are a few additional "moving parts" with link that are governed by the HTML spec. They relate to the interaction between
Put differently, do we want what is currently going into the "content" (e.g., "$example.com") attribute to be an actual URL? What's the protocol? And would it have any interaction with the If the answer is "not a URL" and "no interaction", then |
It's a slight trade-off in my opinion. The reason the payment pointer spec uses "$example.com" in the first place, instead of "https://example.com/.well-known/pay" is to allow payment pointers to appear in things like chat messages and be accurately recognized the same way, e.g. email addresses are. If we stick with the current If we change to the
I think similar to how other link tags work, the browser could use the Accept header to indicate what types of file it understands. For example, CSS is the de-facto standard format for stylesheets. For Web Monetization, we effectively have such a de-facto standard (SPSP) as well. This might still evolve somewhat as adoption grows and more use cases become supported but there are already enough sites using it that we would want to maintain backwards compatibility. |
I added a preview implementation of the link tag in (the yet to be published) version 0.0.51 of the extension. |
@sublimator is it possible to know if the website returned a link header in the original response? i.e. Could we also support this? |
we could (99% sure) but it would be an extra permission (we already have
full content ...)
I can look into it anyway
|
yeah I think that would require us to intercept all requests (because any request could have a link header in it). Let's see if there's anything else we can do but if that's the only way to implement it we should probably hold off on that feature for now. |
It may make more sense to support this when WM is baked into browsers because it seems like asking for the extra permissions is a big change for minimal gain. |
I’ve been researching the challenges outlined in this bug for a few weeks as part of a Grant for the Web project - and in consultation with @marcoscaceres on Firefox internals. I'll try to summarize my findings in relation to the above discussions, and expand on a few bits for the community’s consideration. Ultimately, I’d like us to settle the debate around
|
Sounds great! Good to hear you are implementing WM in Gecko!
Don't let meta vs link hold you back :) |
Thanks for this analysis @sidvishnoi. The Coil extension already ships with support for both tags so we're well on our to migrating.
Payment Pointers are URLs. But I am nit-picking and I agree with your suggestion that we use the full URL form (and not the shortened form with the
I'm interested to explore this more. We won't encourage websites to use headers yet as these wouldn't be accessible from extensions (the only implementation we have available today) but there is some interesting potential and use cases to look at down the road.
We'd like to maximise on privacy here.
|
So is it time to switch the recommendation in https://webmonetization.org/docs/getting-started/ ? |
If we want to keep using payment pointers for display purposes, I wonder if there should be a static method defined somewhere to do the conversion to (or from?) a URL? Like |
That makes sense. We might want to have a balance between privacy and security here though, as it may be helpful for WM receivers to know what sites are sending requests in order to prevent abuse. Edit: Gave it more a thought. Let's stick with Additionally, I'm a bit concerned about allowing URL parameters in the
From browser implementation perspective, I'd say it's a significant part 😅 |
From web-monetization created by marcoscaceres: adrianhopebailie/web-monetization#15
Semantically, the web monetization meta information seems to form a
link
relationship. Should we use link instead?The text was updated successfully, but these errors were encountered: