The Interledger Community 🌱

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

 
nicol profile image
Nic

Thanks for adding it @radhyr . To be honest I hadn't seen the detail of Dividend Revenue Sharing - but realise it has much in common, and likewise from what I can see of webfunding.js it shares this idea of an unknown payee (such as website owner). I'd have thought it shouldn't be too hard for our UI to output something compatable with it.. maybe we should have a chat to show our different approaches? We're going the CiviCRM root because of payment tracking, reporting, notifications, and other CRM benefits - but a pure-JS approach makes a lot of sense too.

Thread Thread
 
radhyr profile image
Radhy

I haven't had the plan to make the idea on Dividend Revenue Sharing post into something practical due to KYC issues make Interledger supported wallets unavailable for me. Maybe I'll visit it later when Interledger ecosystem much more mature.

likewise from what I can see of webfunding.js it shares this idea of an unknown payee (such as website owner). I'd have thought it shouldn't be too hard for our UI to output something compatable with it.. maybe we should have a chat to show our different approaches? We're going the CiviCRM root because of payment tracking, reporting, notifications, and other CRM benefits - but a pure-JS approach makes a lot of sense too.

Yes, while I haven't finalized the details I think affiliate link (paying the unknown payee) in Webfunding.js shouldn't be complicated. Webfunding.js read payment pointer from query string in URL which will later be stored in browsers' IndexedDB database for future payment. The UI in my project is somewhat like this:
Affiliate

For example, if I need to allow influencers to generate their own affiliate link for page https://example.com/my-novel, then I'd need to output a link that generate something like https://example.com/my-novel?affiliate=%24wallet.com%2Fexample, which will point out to $wallet.com/example a user generate on the UI above. At this point there shouldn't be a need to use Webfunding.js since vanilla JS is already more than enough to generate query string on URL. However, to store the payment pointer and use it for future payment there's a need to run new WebMonetization().registerDynamicRevshare("my-novel-title", "10%").start() from Webfunding.js in https://example.com/my-noveland any other relevant pages.

This is the most straightforward implementation I thought of at the moment since there will little to no set up previous to installing Webfunding.js through NPM to use the feature (or put script tag from CDN and use directly without JS bundlers). I haven't thought of affiliate "terms and rules" or any other details like more persistent database than IndexedDB, but since this is only an experiment for me I'm plenty satisfied with my progress currently.

Thread Thread
 
nicol profile image
Nic

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

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.