Author: Nicol Wistreich

MOVA

A CiviCRM extension to generate – and pay out – Revenue Sharing Language plans

Written by Nicol Wistreich on November 25, 2021. Posted in Blog.

CiviCRM is regular used to received payments in – donations, ticket sales or membership fees – but what about automating payments out?

CiviSplit is a set of three new beta extensions to let CiviCRM admins automate paying income out to multiple parties based on a set of pre-defined rules. It could split the income from a fundraising campaign between multiple charities; or share ticket sales for an event between a band and an NGO after the organiser’s costs are deducted; or even automate the payout of dividends within a worker cooperative after expenses.

The work is being done by Matthew Wire of MJW Consulting, with support from Rich Lott of Artful Robot, and has been funded by Grant for the Web as part of a broader project looking at how to fund and support independent film online (my personal passion on the web since 1999).

The heart of CiviSplit

CiviSplit components will first let admins create a revenue sharing plan, then save this in a form that can’t be changed later once income arrives, then periodically check the balance of an account, and pay out what’s in there according to the plan. To achieve this there’s a few new concepts:

We’ve created a YAML based syntax called Revenue-sharing Langauge (RSL), to describe CiviSplit agreements in a human-readable form; that can also be the basis of payout calculatations. This is how we can ensure that a payout plan that’s agreed on is the same that’s paid-out in the futture by CiviCRM. As well as feedback from Matthew and Rich, am grateful for the input of Aidan Saunders, lawyers Silvia Schmidt and Andrew Katz, and comunity-ownership expert Dave Boyle in preparing this.
These RSL agreements are built in CiviSplit using a drag-and-drop builder called Waterfall (a term used in the film world to determine the order people get paid). This (right) has been implemented as a standalone script so it could work with other systems – and has been built first in a framework-free native-JS by Mark Boas and then with Svelte JS by Rich Lott.
We register negative payments on a Civi contact record’s contribution screen to denote payments to someone, rather than from someone.
We’re using a third party digital wallet system (Uphold) to create a unique collecting ‘account’ for every CiviSplit agreement, so that monies received are ring-fenced before being split out. A new Uphold processor will manage this, and make payouts to any IBAN bank account number.

How will this all work?

Create a payout plan: After setting up an online wallet address in their settings, users should be able to create a new CiviSplit agreement. Each step in an agreement executes sequentially with all payees at each step paid pari passu (at the same time until all are paid). So, for instance, a charity fundraising event may first want to pay back expenses to three people who are out of pocket; then they will split the income 50-50 with the promoter until the promoter has earned a pre-agreed $500 fee; and then they will take 100% of the income. This would be built by the drag-and-drop builder, creating some RSL that looks something like this:

---  
name: “Fundraising event share”
currency: USD
steps:
  - 
    type: fixed
    payee:
      - [ "Venue hire balance", 1234 5678, IBAN, 250]
      - [ "Catering company", 1234 5678, IBAN, 150]
      - [ "The DJ", name@example.com, paypal, 200]
  -
    type: percent
    cap: 1000
      - [ "Charity", 1234 5678, IBAN, 50]
      - [ "Promoter", 1234 5678, IBAN, 50]
  -
    type: percent
    payee:
      - [ "Charity", 1234 5678, IBAN, 100]

Save and generate a Plan. After adjusting the agreement to ensure everyone is happy with it, the CiviCRM admin ‘generates’ it, which makes it uneditable, and creates a wallet address for the agrement, which is then saved in the RSL. Finally a cryptographic hash of the agreement is made, which will change if anyone tried to alter the agreement. A copy of the plan can then be saved as a PDF, and revisited online at a URL based on the hash. This adds some means of protection – future payouts can be checked they are still being applied to the same RSL plan, and hashes can be compared to ensure they mayvch and no changes or errors have been made.
Use a scheduled job to trigger payouts. At regular intervals defined by a Civi Scheduled job, the wallet will be checked for a balance, and provided it’s greater than the minimum payout amount (currently €10/£10/$10) it will be split out between the payees as defined in the agreement. The next time it’s triggered payments will pick up where they left off. Pending and unresolved payouts will be held until resolved. Payouts will be trackable as entities so reports and notifications can be made to recipients of their income.

How could this potentially be used?

Collective fundraising. Tythe.org is a fundraising protal for nine small charities. The founders recognised that many small charities spend a lot of money and energy on fundraising; while many people who want to donate struggle to choose between multiple causes. Tythe simplified the process by selecting 9 charities, and donors pay a standing monthly payment and can choose how they want their payment split. CiviSplit could make it easier to create and automate these kind of groupings of related campaigns and causes, while deducting costs before the split (ie hosting, marketing or an accountant).
Peer-to-peer fundraising When Northbridge Digital built a large Civi/Drupal site to manage a large sponsored walk; donors could choose which charities from a select group they wanted their money to go to. This was calculated at the end by adding up the different fields users had entered; this approach could automate that.
Cooperatives and ‘informal cooperations’. CiviCRM is already used by a number of cooperatives; some of whom track dividends to workers/users in the app. An automated payout processor could also accomodate other less formal cooperations. For instance where three Civi agencies share the cost of building an extension, then run a fundraiser to continue its development (or operate a ‘donate here’ button after launch). Make it Happens could be tied to specific CiviSplit plans so donors can see exactly how their money will be spent, and track those payouts.
Independent creatives. Independent creators of films, art, events, books or music – like many open source developers are driven by a passion or itch, more than the (highly unlikely) goal of getting rich. For many, managing the finances is a burden; at the same time for collaborations like film productions or recording an album there can be a mix of debts, deferred fees and promises to pay someone back, which especially matter in the event a project earns something. The indie film world is littered with stories of people who worked for free on the promise of a deferred fee or profit share in the event of success, only to see nothing – and these stories inspire some of the original motivation here. But we also know, from LiveAid and Peter Pan/Great Ormond Street Hospital to Warchild and Comic Relief/Fantastic Beasts there’s long been very successful collaborations between the creative and charitable worlds, so perhaps this could support some new ones.

Shifts to automation in many areas of technology are full of problems, and it’s important to stress that we’re not proposing charities ditch their accountants for an experimental CiviCRM extension just yet. At the moment the wallet address created by the agreement will only receive one type of income stream – micropayments using Web Monetization, which is a new protocol streaming money from web users to websites as they browse the web, designed to improve how news and media is supported online. It will not be until next year that normal one-off and recurring card payments to wallets from non-Uphold users should be available. But these tiny payouts – a few cents or pennies from lots of people regularly – is where automation saves time and seems a safe place to experiment.

Online video’s carbon footprint could be bigger than aviation. What can we do?

Written by Nicol Wistreich on September 30, 2021. Posted in Blog.

Of this carbon footprint, the biggest impact by far (excluding non-web activities like blockchain mining or buying a new phone every year) is streaming video. The IEA claims streaming services from video and games will account for 87% of consumer internet traffic next year (2022), with video doubling to 2.9 zetabytes of data by then from only 2019. The rate of growth seems exponential – and video is 2-3 times worse than conventional broadcast TV.

This is bad news for creators: the bigger your audience, the more viral your videos, the worse the climate impact.

Dryden Williams, founder of website footprint optimiser EcoPing estimated that the global carbon footprint of just one adult video site is over 580,000 tonnes of CO2 each year – more than the entire footprint of Gibraltar, Granada or the Seychelles.

It’s not only CO2, data centres want water…

Worse, in the rush to cut CO2 emissions, big data centre owners like Google have switched from energy-intensive air conditioning for cooling, to water cooling. This has created a new demand for billions of gallons of water, which is particular problematic given data centres are often built in hot, dry regions. Time magazine found that in some places the demand for water for data centres could be from 10% up to 50% of a district’s water needs. “In Red Oak, Texas, a town about 20 miles south of Dallas, Google wants as much as 1.46 billion gallons of water a year for a new data center… Ellis County, which includes Red Oak and roughly 20 other towns, will need almost 15 billion gallons for everything from irrigation to residential use.”

This is why climate researchers specialising in ICT increasingly say we can’t only focus on CO2 but must look at full life-cycle impacts. It’s not only water usage, but resources in the equipment from data centres and consumer devices – as well as the energy source itself.

“In France, we tend to follow a Life-Cycle Assessment (LCA) approach that includes four factors: GHG emissions (CO2eq), water consumption (Litres), abiotic resources consumption (Sbeq. or Antimony equivalent) and energy consumption (MJ). Like everybody else we measure these impacts on three different poles: data centers, networks and end-user equipment… So what’s the difference with the English-speaking approach? The main focus seems to be on reducing carbon emissions through the vector of electricity.”
Gauthier Roussilhe – gauthierroussilhe.com/post/digital-sustainability-french.html

So cancel film & TV then?

If all the different impacts could be tallied precisely, then given that many environmentalists call for us to reduce not offset – is the conclusion for filmmakers to stop making videos people want to watch and share online? Perhaps to ditch cliffhanger episodic TV for a feature film of the same story or preferably a short film or radio play? Must we add ‘Netflix and chill’ to the things to feel bad about?

Given the pushback against relatively simple behavioural changes like refill stations, it’s hard to imagine enough people wanting to ‘stop watching video online’. The only option therefore – until the grid is fully decarbonised – would seem to be climate impact offsetting.

This does three things:

It first works to force us to quantify video’s impact as it moves from servers, across Content Delivery Networks through an ISP into homes and offices, which in turn lets us see what parts of the lifecyle has the most emissions;
It generates finance for useful CO2eqv removal, environmental preservation, transition and restoration projects;
This cost also incentivises and rewards us for adopting cleaner architectures, while penalising dirtier ones;

It’s like a self-imposed, voluntary carbon-tax. There’s fair criticism of offsetting being used for greenwash, such as when Leon claimed their beef burger was carbon neutral because they’d paid some farmers to not burn down rainforest; but for impacts we’re stuck with until we’re on fossil-fuel free infrastructure, it seems a lot better than doing nothing.

What if you could pay to ‘offset’ as you browse?

Web Monetization (WM) is a new web protocol that streams every second tiny micropayments between a website owner, and someone browsing their site for as long as they’re on it. WM’s designers wanted to ‘stream payments’ in the same way the Internet streams data whenever an email, file or website is loaded. So given every byte of data has a potential carbon footprint – could streamed payments be used to offset streamed data in real-time?

In other words, what if Web Monetization could compensate exactly for the environmental impacts of data consumed online?

For example, suppose we want to offset a 90 minute documentary feature streamed online.

If we agree that streaming one hour of video is responsible for 100g of CO2eqv emissions –which is the rate given by research group DIMPACT, backed by Netflix, ITV and the BBC– we know that streaming the full film would release 150g. We then need to find a cost for taking this much CO2 out of the atmosphere irreversibly. Using the expensive, over-engineered, but reliable Orca project that would be $0.096 / 100g or $0.144 for the full film. This is well below Coil.com’s payout of $0.36/hour.

What’s unique about Web Monetization is, as a protocol for streaming micropayments, it could pay out, say, $0.015 for someone who only watched 10 minutes of the film, or $0.003 for a 4 minute music video – while handling each transaction invisibly in the background.

The footprint of 60 episodes of Battlestar Galactica streamed at 4k to a flatscreen TV is obviously much higher than a dozen Tik Tok videos on a phone. Web Monetization, coupled with analysis of the user-agent and location, could ensure that offsetting costs are proportional to media-type, energy mix and use, while protecting privacy.

Who might sign up for that? It could be done at consumer, platform or creator level. For e.g.:

a climate committed consumer or employer, who wants to track and offset their online footprint. This could bring a new group of users to Web Monetization;
a platform wanting to offer viewers 100% compensated videos, adjusting the cost-per view relative to device and geographic location of the viewer;
a filmmaker wanting to ensure that their film is 100% offset across its full lifecycle. Organisations like We Are Albert currently focus on production.

How to do this? Three initial inquiries

Before this kind of approach can be taken seriously there are three research-heavy questions that need to resolved around monitoring, methodology and how to compensate:

Monitoring. First, we need to assess what impacts can be known and tracked per stream and what must be averaged or guessed at. While adjusting for variables per stream is much more work (and processing, which has its own cost) – it could incentivise more responsible behaviour. Variables that make a big difference include:
- Screen size: a 50-inch LED television consumes 100 times more electricity than a smartphone and 5 times more than a laptop (IEA): “because phones are extremely energy efficient, data transmission accounts for more than 80% of the electricity consumption when streaming.”
- Device type & age: Every year that equipment is kept and repaired/upgraded rather than replaced its embedded resource impact declines. “Before you start using a piece of electronic equipment, it has already emitted 70% of its lifetime CO2” François Zaninotto.
- Geography. Carbon intensity is deeply tied to the country of origin – for nuclear France and renewable Norway, the CO2eqv emissions per KwH of energy is under 60g, while the European average is 300g (electrictyMap) and in the US it’s 417g.
- Media production intensity. An average feature film generates 2840 tonnes of CO2 according to 2000’s Arup/BFI/Albert Screen New Deal study – equivalent to 150 transatlantic flights. This is sometimes offset before release; but often isn’t. A viral video filmed in the park on a phone obviously emits close to nothing.
Methodology. ie, decide an impact model and scope to give a resource and carbon intensity figure per hour of streaming. The scope might include production impacts or ignore these given the difference between a superhero movie and a chat to webcam. Once a model is chosen, it should give a baseline impact which could then be adjusted by variables wherever they are known. Modelling only CO2 isn’t straightforward:
- at one extreme is the Shift Project who suggest a carbon intensity of 400g of CO2 / hour of video.
- at the other the much more conservative IEA, estimate it to be 36g of CO2 / hour of video.
- between these is DIMPACT, a research project of Bristol University supported by the UK TV and streaming industry has settled on ~100g CO2/eqv per hour. However, this excludes equipment manufacturing and the media production impacts.
Compensation. The final step is deciding on a price for these impacts – ie what does it cost to ‘offset’ them? Of all the new areas in this research, the offsetting industry seems the one with the strongest views and divergence on methods and costs – which I’m still trying to grasp. Looking just at CO2, for instance:
- at one extreme there are projects that meet the minimum BSI PAS 2060 standard, which can include ‘forest preservation’ offsetting where loggers and landowners can get paid an income by agreeing not to chop or burn trees down. There’s also tree planting, that might mature in 40 years if they don’t combust first. IHS Market put this at $34.99/tonne in May 2021 (ie $0.0035/hour) but there are ‘gold standard’ schemes that are even cheaper.
- At the other extreme, there’s physical CO2 removal and burial with a project like ClimeWorks’ Orca for $0.096/hour ($960/tonne). Orca’s offsetting is considered to be one of the costliest around, but would still be comfortably under Coil’s $0.36/hour payment.
- In between there’s a number of experimental but unproven CO2eqv removal projects – which if successful could take CO2, methane and other climate gasses out of the atmosphere. Carbon Plan.org has a good list they’ve built up from helping assess projects for Stripe and Microsoft.

To answer these questions there’s a big shortfall in data as companies like Google, Amazon, Apple and Facebook aren’t required to make public their full use of resources, energy and water, and most of them don’t.

While this all points to the importance of rapidly decarbonising the energy grid everywhere, of the legislative low-hanging fruits to be sought at COP26 in Glasgow, a cheap-but-impactful one is to mandate that large technology and web companies publish full life-cycle data on carbon, resource, energy and water (CREW) use. This would allow individuals and business to make informed choices about where to host, stream and watch video – and provide the needed data to let them offset/compensate that impact if they want. If the data was audited, it could help ‘the market’ reward companies who improve their impact – on the assumption any consumers, platforms or filmmakers wanting to reduce their own impact would favour them, even with higher costs.

Could streamed micropayments offset other processes?

Maybe streamed micropayments –aka Web Monetization– that flows like data for the duration of an activity, has other applications during the fast decarbonisation our societies and economies need to meet the 1.5C goal of the Paris Agreement. Perhaps you could have streamed micropayments for every KwH of solar energy generated, or for web hosting in a fossil-fuel-free energy country?

Or perhaps micropayments go back to consumers for every minute listening to music online with the screen dark, or for watching lower-resolution video, or using a refurbished older model phone, or streaming off-peak when energy demands are lower. Or even for pricing in the impacts from different parts of network infrastructure as data moves around the world between countries with different energy mixes – with a different cost if your video CDN is using a server cluster in coal heavy Poland over nuclear-France or hydro-Norway. It’s an carbon accountant’s dream, although potentially an engineering heavy answer to the problem.

Ultimately, the work coming out of communities like ClimateAction.Tech is inspiring because small changes can have big impacts:

“Just last week I reduced global emissions by an estimated 59,000 kg CO₂ per month by removing a 20 kB JavaScript dependency in Mailchimp for WordPress. There’s no way I can have that kind of effect in other areas of my life.”
Danny van Kooten – https://dannyvankooten.com/website-carbon-emissions/

So while the data is incomplete, and the divergence in opinion from experts can be dizzying and make it tempting to give up for fear of getting it wrong – the scale of the climate crisis and the growing impact of online video towards that makes it feel that doing anything is better than nothing. Mistakes can be corrected, models and estimates can be adjusted as more data is made available. The key thing is to start.