Payment streams overhaul

[sidvishnoi]

This is relevant when the page has more than one wallet address.

Current state:

• We pay all wallet address together on page load, and then compute a wait time for future payments.
  • With many wallet addresses on page, a website can take a lot of money out of user's wallet on page load (as we pay a minimum 2c (when USD-USD wallets) on each session and we pay all the sessions). We don't skip any wallet addresses or use staggered/alternate payments to respect the payment rate set by user. There's no max limit on payment sessions as of now.
  • e.g. If user visits 2 websites with 100 wallet addresses, user loses $2 on just their page load (well takes around 1-4s to setup all sessions).
• For iframes, we grab only the first link tag found on page load time, to prevent abuse by iframes adding many link tags.
  • If link tag is added dynamically, it's ignored. If first link tag is removed or new one prepended, it's not monetized. We consider this as a known bug.
• This payment model is bit rudimentary (overpays, doesn't respect rate of pay correctly), but still complex, specially when it comes to iframes.

Target:

• We want to monetize all wallet addresses found on a page and in all iframes.
• We want to respect user's set payment rate more strongly and prevent overpaying any website.
• We don't want iframes to add 100 links and take from main website's share.

Tasks:

• Monetize all wallet addresses found on a page and in all iframes.
• Add a concept of payment queues which allow sending payments for different sessions in a staged/staggered manner (queue, one after other), to prevent overpaying on page load.
• Split amount such that:
  • For the host website, all wallet addresses get equally split amount from total amount that will be sent according to rate of pay.
  • Each iframe is treated as a single payment stream (gets treated as if a single wallet address on main page), and all link tags in iframe get an amount split from iframe's entitled amount and use staggered payments within itself.

Note

This section needs more planning and reasoning first, but here's a rough idea:

e.g. the website (W) has 4 link tags (W1...W4), there's 1 iframe (IA) with 2 link tags (IA1, IA2), and 1 iframe (IB) with 1 link tag (IA1).

• amount (as per rate of pay) will be split into 6 parts
• Website (W) gets 4/6 of the amount: 1/6(W1) + 1/6(W2) + 1/6(W3) + 1/6(W4)
• Iframe 1 (IA) gets 1/6 of the amount: 1/12(IA1) + 1/12(IA2)
• Iframe 2 (IB) gets 1/6 of the amount: 1/6(IB1)
• Now that 1/6 or 1/12 of amount maybe too small to be sent. So, we will try to first send 4/6 of amount to W1, then another 4/6 to W2 and so on. The delay between payments will be larger this way.
• Similarly, if 1/12 is too small to be sent to IA1, we sent 1/6 to IA1, and then send 1/6 to IA2.

If we can't really send as amount is really small, we fallback to sending minimum payable amount with much longer delays.
Also, we might need to skip certain link tags entirely if amount is too small to be split.

The queue idea will be extend to one time payments as well - specially the spliting amount parts.

Related issues: #842, #905, #920, #921
interledger/open-payments#491 would be very helpful, as then we'd efficiently have a min-sendable amount handy.

[ioana-chiorean]

Older proposal: https://webmonetization.org/docs/guides/set-up-probabilistic-revenue-sharing/

[pp-koch]

Postpone an iframe's monetization until the user focuses on it?
Doesn't solve everything, may solve part of the issue.

[sidvishnoi]

Let's discuss ideas in #978. Will keep the issue focused on decisions.