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.
Co-founded Netribution.co.uk to help indie filmmakers in 1999. Co-writer of the Film Finance Handbook (fundyourfilm.com), web designer for non-profits, CiviCRM community member & occasional filmmaker.
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.
For further actions, you may consider blocking this person and/or reporting abuse
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.
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.
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.
Ah I see, thanks - my misunderstanding.