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

Docs: web monetization api #406

Merged
merged 4 commits into from Mar 6, 2018

Conversation

Projects
None yet
4 participants
@sharafian
Contributor

sharafian commented Feb 26, 2018

Closes #405 . Further discussion can be done on this PR.

@emschwartz

If the only purpose of this API is to give you a payment pointer to pay to, couldn't we just use the Web Payments API? That may have been intended for more discrete payments but there's nothing in this spec that really relates to the fact that the payment may be ongoing.

- Should give users a choice about how much to spend, and which sites to support.
- Should give advanced webmasters a way to associate payments with their users, in order to unlock premium experiences.

### Relation to Other Protocols

This comment has been minimized.

@emschwartz

emschwartz Feb 26, 2018

Member

What's the relation between this and the W3C Web Payments API?


### Relation to Other Protocols

Web Monetization makes use of [Payment Pointers](../0026-payment-pointers/0026-payment-pointers.md) and [SPSP](../0009-simple-payment-setup-protocol/0009-simple-payment-setup-protocol.md).

This comment has been minimized.

@emschwartz

emschwartz Feb 26, 2018

Member

"makes use of" is a little too vague. What does it use them for?

- The user's browser or Web Monetization extension decides whether to pay the page.
- If the user's browser decides not to pay, an error is thrown from the `monetize` promise.
- If the user's browser pays, the `monetize` promise resolves.
- The webpage may run some code in order to thank the user or offer them additional content.

This comment has been minimized.

@emschwartz

emschwartz Feb 26, 2018

Member

Unclear from this description how the website knows if they've actually gotten paid and, if so, how much

@sharafian

This comment has been minimized.

Contributor

sharafian commented Feb 26, 2018

couldn't we just use the Web Payments API?

I think this is aimed at a different problem. Web Payments is for payments, while monetization is intended to replace what ads are doing right now.

  • Web payments is more geared towards discrete payments, as you pointed out
  • Web payments require user interaction (as far as I understand)
  • We may require additional parameters that are specific to the problem of monetizing a page (i.e. the page could express that it's playing audio content and needs to be paid even when its in the background)
  • We don't want one page to be able to monetize itself multiple times; the object based API of web payments makes this harder to constrain and more confusing to use
  • The site doesn't know how much it wants to get paid (or they may give an amount but only as a guideline); it's up to the user agent.

@sharafian sharafian requested a review from emschwartz Feb 26, 2018

@michielbdejong michielbdejong referenced this pull request Feb 27, 2018

Open

Phase 1: Browser Flatrate (Mario) #6

4 of 9 tasks complete
@emschwartz

This comment has been minimized.

Member

emschwartz commented Feb 27, 2018

@adrianhopebailie Is this true? "Web payments require user interaction"

The site doesn't know how much it wants to get paid (or they may give an amount but only as a guideline); it's up to the user agent.

Not sure that's true. If they're charging you for content, or for an ad-free experience, wouldn't there be a specific amount they expect to get (possibly per time) in order to keep giving that to you?

@adrianhopebailie

This comment has been minimized.

Member

adrianhopebailie commented Feb 27, 2018

@adrianhopebailie Is this true? "Web payments require user interaction"

Currently yes

@sharafian

This comment has been minimized.

Contributor

sharafian commented Feb 27, 2018

Not sure that's true. If they're charging you for content, or for an ad-free experience, wouldn't there be a specific amount they expect to get (possibly per time) in order to keep giving that to you?

Potentially, but that really just depends on their current business model. Youtube doesn't refuse to show you content if you don't view their ads, and most sites don't either. In general it's better to make an impression on a user even if you get no revenue because it increases the chance they'll share it.

Today, a site that charges a fixed price for content would sell it using an online payment method like paypal. That particular case might be better served by web payments.

@emschwartz

This comment has been minimized.

Member

emschwartz commented Feb 27, 2018

Today, a site that charges a fixed price for content would sell it using an online payment method like paypal. That particular case might be better served by web payments.

Why? If you already have payments set up and ready to stream automatically, why shouldn't I be able to say "this is how much you need to send in order to get the improved experience"? If there's no way to express that, the extension will need to guess how much you need to be sending to see some different experience. If the Web Payments API isn't a good fit for the whole monetization use case because it requires user interaction, I don't see why it would be any more appropriate for the case of "you need to give me at least $0.25 (or $0.001 per second) in order to have an ad-free experience".

@sharafian

This comment has been minimized.

Contributor

sharafian commented Feb 27, 2018

If you already have payments set up and ready to stream automatically, why shouldn't I be able to say "this is how much you need to send in order to get the improved experience"?

If that were an option, it would lead to one of three scenarios:

  1. The user is willing to pay more than you asked for, and so you're getting less money than you could.
  2. The user is not willing to pay that much, so you need to bother them to turn up the amount of money they can pay. What's more likely is that they'll just leave your page and pay nothing.
  3. The user's maximum is perfectly matched to the amount you ask for.

3 is the most desirable scenario, so why wouldn't the API always do that (i.e. always just ask the browser to pay the maximum it's willing to pay)? It's not like there's a fixed cost associated with distributing your content that needs to be recouped. The user's agent can just decide how much to pay based on static settings and/or data that it builds up on the user's browsing habits.

@sharafian

This comment has been minimized.

Contributor

sharafian commented Mar 5, 2018

Can we merge this so it can be linked to from other sources? We can make this the first draft but I'd like to be able to reference it from several different places.

| Name | Type | Description |
|:---|:---|:---|
| opts | `Object` | The options for monetization. |
| opts.receiver | `String` | The payment pointer or SPSP endpoint to which ILP payments should be sent. |

This comment has been minimized.

@michielbdejong

michielbdejong Mar 6, 2018

Contributor

"SPSP endpoint" should link to IL-RFC-9, draft 4
"payment pointer" should link to IL-RFC-26, draft 1

Otherwise, LGTM

@emschwartz emschwartz requested a review from ukstv Mar 6, 2018

@emschwartz

In the future we may want to add an alternative to payment pointers that doesn't require the round trip(s) for the HTTP call (e.g. just passing the ILP address and secret to the monetize function).

@sharafian sharafian force-pushed the bs-web-monetization branch from 7d61244 to 6428911 Mar 6, 2018

@sharafian sharafian merged commit df3e413 into master Mar 6, 2018

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@sharafian sharafian deleted the bs-web-monetization branch Mar 6, 2018

@@ -69,7 +69,7 @@ will have to be queried in order to confirm how much has been paid to a specific
| Name | Type | Description |
|:---|:---|:---|
| opts | `Object` | The options for monetization. |
| opts.receiver | `String` | The payment pointer or SPSP endpoint to which ILP payments should be sent. |
| opts.receiver | `String` | The [payment pointer](../0009-simple-payment-setup-protocol/draft-4.html) or [SPSP endpoint](../0026-payment-pointers/draft-1.html) to which ILP payments should be sent. |

This comment has been minimized.

@michielbdejong

michielbdejong Mar 6, 2018

Contributor

looks like the payment pointer link points to the spsp spec and vice versa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment