Probabilistic revenue sharing is probably unnecessary

[jeremiahlee]

The past

An earlier version of the Web Monetization specification and implementation by Coil permitted only one monetization link on a page. Coil addressed this limitation with probabilistic revenue sharing and offered a JavaScript library to implement the idea.

The basic idea is that one wallet address would be randomly picked from a list of possible wallet addresses. With enough visitors, the distribution of payments would be evenly split. Using algebraic weighting, a wallet address could be made more or less likely to be picked randomly. With enough visitors, the distribution of payments would be similar to the weighted random selection of a wallet address.

The present

The Web Monetization specification and implementations now support multiple monetization links on a page.

How a Web Monetization client (the software that runs in the paying user's browser) decides to handle multiple links on a page is up to the client to decide. The Interledger Foundation's Web Monetization extension has complex logic for this, but the most basic idea is that it cycles through all monetization links on a page and pays them sequentially. The result is that all wallet addresses on a page should get an equal split from a user.

The question of continued relevance

I believe support for multiple monetization links on a page is adequate for the majority of people who wish to split their Web Monetization payments with others.

I believe we should retire probabilistic revenue sharing as a core concept for Web Monetization. It should only be mentioned if someone has the distinct desire to control the payment distribution, but not ensure it in any way. Treat it as a footnote, not a primary tool.

1. We should limit the number of complex concepts associated with Web Monetization because there is a heavy cognitive load already. Probabilistic revenue sharing is a concept that must be explained. It’s not intuitable. It then has limitations that require explaining and accepting.

   • Probabilistic = probably what happens, but not guaranteed

   • Efficacy determined by the number of Web Monetized users visiting the page. Low traffic volume = low probability of meeting desired weighting.

2. Any level of required revenue splitting requires the ability for recipients to verify they are receiving their expected proportion of payments. If people don't care about ensuring the split and are willing to blindly accept a best effort attempt, then it's not actually a requirement and the simpler solution is to put multiple tags on a page.

   • The only way to meet a required revenue split is for one receiver to be responsible for tracking received payment and then sending a subsequent payment to the other parties. This would be a useful tool to build, either at the wallet level or as a third-party service using the Open Payments API.

[jeremiahlee]

Related: Probabilistic revenue sharing does not belong in the Web Monetization spec

People have proposed adding an attribute for declaring the split for a Web Monetization payment. It seems straightforward, but quickly runs in complex questions. I think the complexity of the various scenarios that must be accounted for exceeds the benefit of having the feature.

• Should the weight apply to only the links that have weighting specified?
• How should links without weighting be handled?
• What happens when one of the weighted links is not able to be sent to?
• What happens when an iframe has a monetization link with weights defined that then influence the weighting of the parent frame?

Web Monetization is a best-attempt, voluntary payment. If someone needs weighting, the appropriate solution is server-side from a single wallet address that sends payments according to a split agreement when new payments are received.