feat(coil-extension): add accept-monetization via declarativeNetRequest #1916
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/coilhq/web-monetization-projects/4Nhv1k3XZ2nJHzF9SHPTzFHRYbUV |
| "action": { | ||
| "type": "modifyHeaders", | ||
| "requestHeaders": [ | ||
| { "header": "accept-payment", "operation": "set", "value": "webmon/*;q=0.8" } |
There was a problem hiding this comment.
Ideally this set would be an append but apparently there's an open bug that prevents that
There was a problem hiding this comment.
Will it matter much in practice do you think ?
There will be races for which extension gets to set it in the case of more than one enabled ?
There was a problem hiding this comment.
In the start it won't matter.
Eventually it could be a race condition. Ideally you'd want an adblock extension to be able to say "no ads" as well as what we have here. I'd think by the time those extensions implement and there's a supporting ux the bug would be fixed.
| "rule_resources": [{ | ||
| "id": "ruleset_1_accept_payment", | ||
| "enabled": true, | ||
| "path": "static/rules.json" |
There was a problem hiding this comment.
Not sure if this is the right place for the file. I saw a different approach in https://github.com/coilhq/web-monetization-projects/pull/1659/files, but it wasn't merged.
There was a problem hiding this comment.
static/rules.json seems good to me
There was a problem hiding this comment.
well, I mean I guess you could more specific than "rules", but inside static is good
There was a problem hiding this comment.
Updated rules.json -> acceptPaymentRules.json
|
Hey, so of course Firefox doesn't support the declarativeNetRequest api/permission :/ It's a pity cause it's a decent API with performance advantages (one assumes at least) |
|
@sublimator I could add back #1910 into this PR? I haven't looked into how the different builds happen, but you could branch if the browser has support? Or does this make the proposal DOA? |
|
Yes, we could make that work! :)
I can look into hacking the build for you.
I just forgot before its not impl on FF. A pity Mozilla is so against it.
|
| @@ -5,7 +5,7 @@ | |||
| "action": { | |||
| "type": "modifyHeaders", | |||
| "requestHeaders": [ | |||
| { "header": "accept-payment", "operation": "set", "value": "webmon/*;q=0.8" } | |||
| { "header": "accept-monetization", "operation": "set", "value": "webmon/*;q=0.8" } | |||
There was a problem hiding this comment.
It's been suggested that "monetization" is a better name, so updating to align with other documents
mankins
changed the title
|
@mankins Mozilla are implementing declarativeNetRequest :) edit: maybe they'll make it available in v2 extensions (as google does) in the near term? v3 support seems a long way out still |
Note this a different approach to #1910, as suggested in the comments by @sublimator #1910 (comment)
This PR proposes the addition of the
Accept-Monetizationheader which follows the Content Negotiation pattern used byAccept,Accept-Language, etc.If this PR is merged, the following header will be added to web requests from the client:
HTTP servers can then choose specialized content for the client, or issue a content negotiation sequence: a 402 status code followed by user-facing instructions on how they might pay for the site.
More on the Accept-Monetization proposal.
This is opportunistic and doesn't replace the client-side web monetization standard.
This is a signal, not a guarantee. Well behaved clients can get the benefit of individual content without having to wait for detection / complete page load.
Verify / QA
The see this in action you can build the extension and then inspect the outgoing http headers. There should be a new header:
To test how content negotiation might work you can run the express server at Accept-Monetization proposal and visit the pages referenced for web monetization.