Web Monetization Community

loading...
Cover image for Introducing Revenue Sharing Language – a Web Monetization answer to Hollywood accounting?
MOVA

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

Nic
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.
Updated on ・7 min read

Scarlett Johansson's recent contract dispute with Disney and their thunderbolt response that she had 'callous disregard for the suffering of the pandemic' showed Hollywood's power players on the brink of civil war. The LA Times suggested the fight, and Disney's diss at Marvel's biggest female star, was really about a bigger question: "how should stars and filmmakers be paid for movies and TV shows now that the business model is shifting quickly from one based on box office and television ratings to one reliant on online subscriptions?". It's easy to calculate how to earn a cut of ticket or DVD sales for a film, but what about 'all you can eat' flat-fee subscription video services where some people watch one film a month - and others dozens a week?

To those in the Web Monetization (WM) community, the answer is maybe simple – they could get a share of every second that a subscriber is watching for. A Coil.com plugin in the subscriber's browser, streams $0.36/hour to the website's Payment Pointer for the first 12 hours each month, and tapers off after that. Amazon Prime also pays filmmakers per seconds viewed, tho at a much lower and well-guarded, rate. Problem solved? Web Monetization could turn subscription income into profit-share for every second viewed of any film that works for all but the biggest platform users.

However, a Payment Pointer only points to one wallet, in reality, the premiere of Scarlet Widow 2: Implausible Resurrection on Cinnamon in 2024 would want to pay out to many different wallets: the website, the production company, Marvel and all the stars guaranteed a share of the profits.

Sharing Web Monetization payouts precisely

Probabilistic Revenue Sharing is WM's answer to this, which works by letting the hosting website list a number of payment pointers and a value for what percent of visits each pointer should be the receiving wallet for. If it's 50% Disney and 50% Scarlett; every other view of the page would load each payment pointer, so the amount paid out should be largely equal after a few hundred views. But for videos with a dozen or more payees, or feature films with 120 minutes per view and only a few dozen views, it's easy to imagine how quickly probabilistic payouts become less than precise.

In our Grant for the Web project, MOVA we're taking another approach – with a CiviCRM tool to log into the wallet behind a payment pointer, check the balance, then distribute payments to multiple parties depending on a set of pre-agreed rules. This opens up the possibility of more creative repayment structures that take account other obligations – like paying back the drone hire company for your shoot and the cinematographer's deferred fee, then the loan from your rich great-aunt, before splitting what's left fairly between the production cast and crew. And how much easier might it be to get that rich great-aunt's loan if she doesn't have to depend on her nephew's accounting skills to get repaid?

Once we started exploring the tool we hit a question: how can payees be sure that they are receiving the right amount? Even ignoring fraud, how could the system check that payouts are accurate? Could there be a machine- and human- readable version of the revenue split that could be hashed/printed out and also used as the basis for payouts? This idea of a human and machine readable agreement is sometimes known as a Ricardian contract. This would have the benefit of letting us develop something that other systems could read and produce; using, like Web Monetization, Interledger and Payment Pointers, a decentralised approach. Researching the space it soon appeared that while there is a sophisticated machine readable rights language – Open Digital Rights Language; and there are multiple systems for writing up contracts with machine readable syntax, including Smart Contract templates, and the Accord Project, we've not found a syntax for revenue sharing agreements.

Introducing RSL

Revenue-Sharing Language (github.com/openvideotech/rsl) is a proposed YAML-based vocabulary and syntax to describe how revenues received at a wallet, pointer or account should be distributed. It uses YAML to make it easier for non-developers to read, with agreements structured as a series of steps. MOVA's revenue-sharing-agreement builder will output this syntax, which will then be used as the basis for payment distributions on an ongoing basis by the CiviCRM extension we're building.

Each step in an RSL agreement pays out either fixed amounts or a percentage split - before flowing onto the next step. Steps could have one payee or hundreds; and each payee can be identified with an ILP payment pointer (or a bank account, wallet address or other payee address). RSL isn't intended to generate or implement the agreements – that's the next task in our project – but rather to provide an open serialisable basis for structuring them.

In the spec for RSL - which we are inviting comments and feedback on – we have six examples of different kinds of payout structures. For instance, the below YAML maps a traditional publishing advance deal where a writer gets 25% of royalties, of which 10% goes to their agent, after they've repaid their advance to the publisher in the first step.

---
name: "Best of times, Worst of times"
description: "Book deal for the new novel by Charlene Dickens"
pointer: ilp.uphold.com/191320x91
currency: EUR
steps:
  -
    type: fixed
    payee:
      - ["PRNG House", $ilp.example.com/prng, ilp, 40000]
  -
    type: percent
    payee: 
      - ["Charlene Dickens", 12345678/12-34-56, uk-ac, 22.5 ]
      - ["Internet Aritsts Management", payment@example.com, paypal, 2.5]
      - ["PRNG House", $ilp.example.com, ilp, dbse, 75 ]
Enter fullscreen mode Exit fullscreen mode

Of course these agreements could get very complex and RSL probably wouldn't be able to accommodate sophisticated, high-end royalty agreements. Gerard Butler's contract payout dispute over Olympus has Fallen, for example, appeared a few days after Johansson's and "entitled him to 10% of net profits, plus 6% of domestic adjusted gross receipts above $70 million and 12% of foreign adjusted gross receipts above $35 million… [plus] 5% of net profits" to his production company and "certain bonuses for hitting box office thresholds".

Hollywood accounting

Once we look at LaLa Land salaries and bonuses it may feel a little abstract – a company making billions in profits on one side and a star earning more per movie than any YouTube influencer will probably make in their lifetime. But Butler and Johansson are the tip of the iceberg of 'Hollywood accounting' long famed for finding creative ways to ensure that, for instance, Return of the Jedi, Spiderman, Batman and Harry Potter: Order of the Phoenix are all technically loss-making —despite huge commercial success— so never have to pay out profit shares to their cast and crew.

And many contract payment disputes outside of Hollywood involve regular creators who've hit it big. Consider Nomcebo Zikode, the singer of last year’s lockdown hit Jerusalema (440 million views on youTube for the original so far, and countless views for the tribute dances) and who claims to still have not been paid one cent because of a contract dispute with DJ Master KG who she made it with. KG counters that the issue is Zikode wanting a 70-30 split, not the 50-50 he claims they agreed. The lack of a documented agreement Zikode and KG can reference leaves it potentially down to whoever can afford the better lawyer. This is a sad outcome for a song that gave cheer to many millions of people during lockdown both listening and dancing to it.

Fenomenos do Semba, largely uncredited choreographers of 2020's viral hit Jerusalema

(Fenomenos do Semba, uncredited choreographers of 2020's viral hit Jerusalema)

The TikTok Dance Strike – credit… and payment?

Dance mashups brings up another question – that of unpaid and often uncredited choreographers of viral hits. For example Fenomenos do Semba – the Angolan dancers whose original eating-while-dancing choreography for Jerusalema doubtless helped the hit, and made it easy for others to copy the dance and make the countless remix videos.

This subject got attention this summer after a Jimmy Fallon segment where Addison Rae danced viral TikTok dances without crediting the choreographers. While Mya Johnson, the 15-year-old whose choreography to Cardi B's Up was performed on the show was gracious, this lack of due props drove this summer's Black TikTok Dance strike.

Attribution will doubtless improve (the Tonight Show and Rae both had to respond to the backlash) – but what if a hit songs' revenues could be shared with choreographers whose work goes viral?

In RSL we have proposed a 'Variable Syntax' which would allow making agreements with people who aren't known at the time the agreement is made. It was designed so that a filmmaker could share their Monetization income with a website or influencer who hosts their film, but it could maybe also work with future choreographers whose routines help a song go viral. Given the complexity of making that work accurately and securely, we aren't currebuilding out Variable Syntax during this round of work within MOVA, but it's included in RSL as it seems interesting – and as an open language maybe others will try to implement it.

So I'm very pleased to share RSL for feedback, criticism and review. It's been created with much helpful input from readers including Mark Boas, Laurian Gridinoc, Rich Lott, Aidan Saunders, Silvia Schmidt and Kevin Wittek — many thanks to them.

Discussion (10)

Collapse
radhyr profile image
Radhy

Great post Nic!

I'm also in progress of making something similar, though this is not something in the roadmap of my current grant project. I've been musing on an idea on distributing fund on a payment pointer's balance on my previous post, though that idea didn't fly off due to insufficient access to digital wallet provider (Uphold not supported in my country). My library github.com/prognoveljs/webfunding also has its own syntax for revenue share although that's likely to be consumed by developers due of it being a javascript library, and not to include metadata on other informations beyond the payment pointers and their weights to achieve lower learning curve for developers to try.

As for Variable Syntax you proposed, I also have similar feature I worked just recently into my library, though it's not yet published to public (happy to say I just got it working yesterday 😄). Previously I called it instant affiliate link that can be used for influencers to generate an URL linked to their payment pointer so they can be included in creators' revenue share pool. Nowadays I redesigned my library and plan to rename the affiliate link feature to Dynamic Revenue Share. I'm currently tidying up all this and (probably) will post something in the next few days.

Anyway, this post is very useful for me. Probably will adopt something similar from my learning on this. Many thanks for writing this Nic!

Collapse
nicol profile image
Nic Author

Hey Radhy,

Thanks alot for your comment and feedback. It's funny I had your previous revenue share mega thread bookmarked and just logged on now to go share a link to this there... but then saw this!

There's a few steps to what we're tring to do, of which RSL is just the first. The next is to create a small lite JS tool to generate RSL agreements based on any kind of structure. I've built the UI (below) and @maboa is building the JS – and we're hopefully not too far from being able to share something to try out.

sneap peak of agreement builder UI

This will then become a CiviCRM agreement builder extension, which Matthew Wire is building, and which is where balance checking and payment handling should hopefully be managed. The reason we didn't jump straight into the Civi extension and do these two other steps is to try and maximise compatibility of agreement syntax. So the JS tool should be usable by anyone to quickly generate the YAML for a structured agreement, and could be integrated into their (GPL) apps too.

One question we have is about making the tool as localisable as possible (recognising it doesn't just need to support different currencies, but formats for writing cash amounts, ie some countries use commas where others use periods and vice versa - it would be maybe helpful to get your feedback on this and making it easy to translate.

Collapse
radhyr profile image
Radhy

I'm putting the post link in the mega thread Nic, hopefully more experiments on revshare to come in the future.

If you want to go with localization, maybe I can help with testing since the local currency my country is using have different comma format from USD. I'll follow you up and see if you have something ready to try.

Cheers! 🙌

Thread Thread
nicol profile image
Nic Author

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 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.

Collapse
chrislarry profile image
Chris Lawrence

This is a great post!

Collapse
nicol profile image
Nic Author

thanks!