Web Monetization Community

Discussion on: Introducing Revenue Sharing Language – a Web Monetization answer to Hollywood accounting?

nicol profile image
Nic Author

Your approach sounds really good. The affiliate link page is great in its simplicity.

make Interledger supported wallets unavailable for me

Partly because we're waiting to see what Rafiki has in store, and partly because Civi already has a bunch of payment processor extensions available (Stripe, Paypal, iATS, etc) we'll let people chose between payout to a payment pointer for an ILP wallet, or another payment processor. That could handle use cases like your own (which sounds frustrating), and also payees who've not completed the wallet signup (or don't want to). But because the transaction fees are lower I think (ie uphold doesn't charge to receive money, just to pay it out into a bank account?) people would prefer to have ILP payouts.

I'd need to output a link that generate something like example.com/my-novel?affiliate=%24...

So when someone adds an affiliate link, are you creating an entire new ILP pointer for the new 'contract' between the author and the new affiliate? And that's set to split the payout as you've established it? ie when they've given you their wallet ID, you will give them back a new payment pointer for their page that will always give them X%?

tbh I can't really see how else you'd do it in a way that protects privacy.. you could perhaps record that 20% of your income (or whatever) is going to affiliates, and then look at what % of streams are coming from different URLs but it seems imprecise.

it's probably not a huge leap to make that work with RSL.. maybe it would be helpful then to call the output a template, and it's the template that is hashed (we want to hash it so that all the parties know it doesn't change with each payout, part of the appeal of a serialisable format). The template includes alliases like {{affiliate.wallet}} - someone requesting a new affiliate account would trigger a job to create a new Agreement with the new address, which gets hashed and sent to both parties. Then they would need a video (or book) embed code that includes the new ILP pointer.

This is when it gets tricky in my head.. they could, theoretically swap out the Agreement pointer at this stage for their own and take 100% of the income. Perhaps that's just a built in risk - and would just make that wallet/url a 'bad community actor' - but if you wanted to avoid it, I guess there would need to be another step to limit streams/embeds only to URLs with a Payment Pointer that matches the list of internal generated PPs. Which I guess is possible if the embed script is checking the page headers and calling home, but it feels like it's somewhat fragile.

Thread Thread
radhyr profile image
Radhy

So when someone adds an affiliate link, are you creating an entire new ILP pointer for the new 'contract' between the author and the new affiliate? And that's set to split the payout as you've established it? ie when they've given you their wallet ID, you will give them back a new payment pointer for their page that will always give them X%?

No, what I did is just an extension to Probabilistic Revenue Sharing in the client-side, which splits revenue just before creating/modifying monetization meta tag. There's almost no option to do more strictly with browsers' JS capability. I'm currently using public payment pointers for testing my JS library so I haven't go beyond that. If you want to hide payment pointers to public, there should proper solutions to reverse proxy payment pointers for that.

it's probably not a huge leap to make that work with RSL.. maybe it would be helpful then to call the output a template, and it's the template that is hashed (we want to hash it so that all the parties know it doesn't change with each payout, part of the appeal of a serialisable format). The template includes alliases like {{affiliate.wallet}} - someone requesting a new affiliate account would trigger a job to create a new Agreement with the new address, which gets hashed and sent to both parties. Then they would need a video (or book) embed code that includes the new ILP pointer.

Most cost-effective and neutral solution I thought of previously on this issue is by creating a "ledger" of revenue share on a static document on IPFS, and make a smart contract (preferably a host that could also act as reverse proxy for payment pointers). But without Codius and Rafiki still haven't got their official public release yet I think it is still too soon to dig on that.

This is when it gets tricky in my head.. they could, theoretically swap out the Agreement pointer at this stage for their own and take 100% of the income. Perhaps that's just a built in risk - and would just make that wallet/url a 'bad community actor' - but if you wanted to avoid it, I guess there would need to be another step to limit streams/embeds only to URLs with a Payment Pointer that matches the list of internal generated PPs. Which I guess is possible if the embed script is checking the page headers and calling home, but it feels like it's somewhat fragile.

Affiliate referrer shouldn't have the capability to attach something on their affiliate link beyond pointer to their wallets. I guess since mine is a client-side JS library the one who has the power to set the revshare rate is owners and the website developers (anyone who has access to the website javascript basically). At this point I haven't decided how to make them more trustable for future affiliate referrer, this is still in my homework list for future projects.

Thread Thread
nicol profile image
Nic Author

No, what I did is just an extension to Probabilistic Revenue Sharing in the client-side, which splits revenue just before creating/modifying monetization meta tag.

Ah I see, thanks - my misunderstanding.