Overhaul payment streams with queues

[sidvishnoi]

Let's discuss ideas regarding #976 here and keep the issue for final decisions only.

[sidvishnoi]

The approach with splitting into small amounts when multiple wallet addresses has a weakness: the transaction fee in each transaction might compound, with each wallet address getting a smaller amount compared to what they would've gotten if we didn't split but just payed them one after other.

For example, we want to pay 3 wallet addresses $0.06 and there's a $0.01 transaction fee. With split, each wallet gets $0.01 ($0.03 in fee), and without split one wallet address gets $0.05 ($0.01 in fee) while others wait for their turn.
If selection is random (not in order of link tag listing in DOM), that might be more equitable.

[jeremiahlee]

Quoting from the text in #976

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.

Agreed

• We don't want iframes to add 100 links and take from main website's share.

I disagree. If I put an iframe on my website, I am responsible for whatever consequences there are for my action. I can use the sandbox attribute to isolate an iframe's capabilities. Web Monetization does not have an allow-monetization property defined in its spec, but that would be the platform-aligned method for doing so. Otherwise, I think we should treat everything in an iframe as if it were an element directly on the page.

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.

If we can't really send as amount is really small, we fallback to sending minimum payable amount with much longer delays.

I agree with these points. It seems like the best option when using a streaming payment model.

Different wallet addresses may have different minimum payments. This might need to be implemented as 2 processes. One process adds value to a wallet address to be paid out every second. Another process checks if the minimum amount has been reached, attempts to send the payment if so, decrements the amount sent. The second process could only be triggered once the first process completes and shouldn't be invoked again until it gets thru all of payments to be sent.