The Interledger Community 🌱: Nic

Web Monetized Open Video to help filmmakers and CiviCRM at MozFest 2022

Nic — Wed, 09 Mar 2022 13:31:35 +0000

We've two Grand Experiment actions: one to support filmmakers, and one to support an open source project used by 1000s of non-profits.

Support filmmakers… On our PeerTube instance open.movie, using Miles DeWitt's PeerTube Web Monetization plugin there's a few really great documentaries revisting recent history and battles in open culture. Watching them pays the filmmakers directly (when you click play). If these go down well we'll keep adding more.
Support CiviCRM… We've collected together some in-depth video about CiviCRM, the non-profit open-source CRM used by Wikimedia, EFF, Greenpeace, Amnesty, the Royal Television Society, the New York State Senate, Humanists UK, and many more.

Support filmmakers…

Good Copy Bad Copy

This fantastic but little-seen documentary by Andreas Johnsen, Henrik Moltke and Ralf Christensen takes us around the world in 2007 to look at different sides of the piracy/open culture movement. We go from DJ Dangermouse in New York talking about creating the Gray Album - which can never be released but everyone's heard - thru to Brasil where a producer is remixing his Gnarls Barkley's Crazy to a Tecno Brega beat so he can sell it at huge favela parties. From Girl Talk and the Pirate Bay to the MPAA's CEO, the Nigerian film industry and Russian pirates this film really covers the breadth of the debates that shaped much of the early web worldwide and still linger today. Watch/monetize here.

The Pirate Bay: Away from Keyboard / TPB: AFK

Simon Klose's story of the Pirate Bay as they face legal threats and global fame/infamy - was the first Creative Commons film co-funded by the BBC, as far as I know. I first met Simon at the same Mozfest London in 2011 that I met Henrik Moltke and Brett Gaylor (and opened a Github account!). Mozfest clearly has long lasting ripples so it's good that the digital edition this year might impact more than just those who can travel to London. Watch/monetize here

RIP: A Remix Mainfesto

Brett Gaylor, director of the brilliant GFTW project Discriminator and former Mozilla fellow - dives deep into remix culture. If you've seen Girl Talk awkwardly explain how he remixes music in Good Copy Bad Copy - it's quite something to see him just a year later as DJ superstar. Watch/monetize here.

NB: We're experimenting with PeerTube, and adjusting server resources in response to demand… if for some reason these films don't load or give an error, please send an email to openmovie@openvideo.tech.

Support CiviCRM...

CiviCRM was co-founded in 2004(!) by Yahoo! employee number 5 Donald Lobo (who now runs the Chintu Gudiya foundation which funds open tech projects in India). It's an open source CRM, used by over 11,000 non-profits/NGOs/arts orgs/coops/political-parties/advocacy groups/FOSS projects - and integrates with WordPress, Drupal, Joomla and Backdrop. It's got a really friendly international community, but because it's PHP, old, large and works with traditional CMSs rather than modern Javascript frameworks, isn't hugely well known among younger devs.

All the CiviCRM videos are being monetized with a Payment Pointer collecting for CiviCRM (via $ilp.uphold.com/eW49pxPQh8N4) - which is sustained by community funding. Some use Hyperaudio (GFTW awardee) to create an interactive transcript.

CiviCRM films include:

Introducing CiviCRM, a 5 minute film we made in London and Belgium introducing the community.
Amnesty International Flanders Case Study, case study of a charity adopting open source and using monthly sprints to improve their fundraising.
Beginners Guide to CiviCRM by Rose Lanigan in Bradford, UK
Using WordPress and CiviCRM by Dana Skallman and Kevin Christiano in New York, USA
Staff scheduling with CiviCRM & Drupal Webform and Views by Karin Gerritsen in Calgary, Canada
The new Mutual Aid Extension by Björn Enders in Cologne, Germany
Personal Campaigns for Peer to Peer Fundraising by Alejandro Salgado & Carolina Bardisa in Barcelona, Spain
A uncut 30 min interview with co-founder Donald Lobo by me in Brussels, Belgium. I'm very embarassed by my early morning interview voice and stumbling questions - which would normally be cut - but am sharing the entire video on the principle of openess!
Coordinating bulk purchasing and distribution of food by Eric Goldhagen, Amy Rebecca Marsico & Jacob Missen in Flatbush NYC, USA

Ways these are being Monetized…

These are all open, Creative Commons videos, so are accessible with or without Web Monetization. But the CivCRM videos will display both a thank-you message and download link if you watch them with a Coil subscription.

Thanks

Thanks in advance to anyone who engages with and promotes these. Also to the filmmakers for taking a chance - and to Erika Lee and Mariana Perez at (GFTW awardee) New Media Rights for really helpful advice.

More info

OpenVideo.tech came out of the GFTW-funded MOVA project. We're new, small and very open to collaborations and knoweldge sharing! You can reach us via hello@openvideo.tech or @openvideotech

Monetizing Open Video Assets — Grant Report Final

Nic — Mon, 14 Feb 2022 17:11:27 +0000

Project Update

MOVA started with a relatively simple goal: to provide a way to connect a video with a Payment Pointer, which would share out income received to multiple parties –such as the creative team, funders, or influencers– in a precise, highly configurable way. It's got three parts which I'd like to introduce, presenting the challenges we faced with each and our respone:

1: MOVA

The first part of this project, which connects a video with an ILP Payment Pointer (as well as a license and almost any kind of metadata) is done with a new Mac, Windows & Linux app called mova (with website: mova.claims). It lets filmmakers generate a fingerprint for their work, called an ISCC, which is a new open protocol somewhat similar to YouTube's Content ID, and that's currently going through standardisation approval with the ISO.

mova then registers these claims on a decentralised database co-owned and hosted by all users of the app, using a new technology called Holochain that, despite the name, isn't a blockchain. While it shares some similarites - it's a closed distributed database between only the app's users, without mining or Proof-of-work/stake and a much lower energy footprint.

The challenge. Hands up, my understanding of distributed ledger technology was insufficient when this project started, especially this new and even more innovative system called Holochain. mova needs to work towards not just accurate copyright/ownership claims but handling legal (and moral) obligations around GDPR, hate-speech, pornography, extremist content, libel, and so on. With each area we've been struck regularly by the difficulty in not having a central point of total control over the dataset. We've built in basic moderation tools for administrators, but can't avoid the fact that once something 'illegal' is on any DHT, it's stuck there.

Our response There are techical sollutions on the horizon: Holochain is working on 'withdraw and 'purge' functions to erase claims from the DHT; meanwhile we've added a prototyype verified credentials layer to let 'certifiers' approve specic claims (below), we've also added domain-level verification of users (e.g. 'verified by filmcompanywebsite.com' will appear besides a name). We could also implement URL proxying by default. But for now we've taken a simple approach of shifting from a permissionless DHT open to all, to a permissioned DHT – in other words we're restricting access to publish with mova. For now that's people in our immediate network, but we will open applications to be a founding test user as soon as possible. Best to join our mailing list to hear about it first.

2: Revenue Share Language, Cascade & CiviSplit

The second part of this project produces, stores and then pays out a precise and flexible revenue sharing plan for any income at an ILP Payment Pointer, and is a collection of technologies together presented at revenuesha.re. These include:

the base syntax Revenue Sharing Language;
Cascade a Javascript drag and drop RSL builder (available both framework free and in Svelte JS), and
CiviSplit – three new CiviCRM extensions to build & store revenue sharing agreements, then connect them with Uphold to generate a unique ILP payment pointer for it, then track the balance and pay it out according to whatever the rules of the agreement, while reporting on it.

The challenge. Early on it became clear that much payout functionality would be better handled by the full Interledger Protocol once it's delivered by Rafiki in the coming months. We focussed on Uphold but just before New Year got the news that short-notice changes by the UK Financial Services Authority, meant that our application for an API key was being suspended until the end of March this year.

Our response. We've had to finish development of the create sub-account/check balance/pay contacts features with the Uphold API sandbox, which has limits on how much we can test integration with IBAN accounts and real Web Monetization balances. To handle this, Rich Lott (who wrote all the unit tests for CiviSplit and Cascade) - created a 'mock' for Uphold to test against what we think should be API returns. But as a result we're releasing now CiviSplit Agreement Builder and Processor - and holding back on CiviSplit Uphold until we've got a working API key and re-tested. If you want to be the first to know when that happens, join the mailing list.

3: open.movie (a PeerTube instance for Creative Commons work)

This part of the project was originally designed to showcase the other two, and we planned to use full-length interview rushes from documentaries to encourage a new form of Creative Commons Web Monetization for documentary makers around their unused assets (if they won't make their finished films Creative Commons, at least they could release the 'cutting room floor'. We built a demo site using Hyperaudio at screen.is/video - with rushes I'd filmed available under a CC license, all relating to CiviCRM - which we then shared with the community with Web Monetization.

The challenge. Our attempts to persuade documentary makers to release their rushes wasn't successful. In depth conversations with two quite prolific production companies in London and New York – even with the offer of an advance on the income they might make thru WebMonetization led to resistence: including about whether their licenses would cover it, lack of understanding around the tech, the effort of rewatching those videos to check there was nothing legally problematic, as well doubt in the business model and potential viability of the approach. It was a reminder that the film and video sector famously often takes a 'jump second' approach to new technology-led business models; only when something is proven will they take a chance.

Our response. Given the difficult of finding Creative Commons video online (many of the more famous CC films are only available via a low-res download on archive.org) - we decided to focus on the rich library of potential CC material where we don't need to ask permission first. With the launch of Miles de Witt's GFTW-funded Peertube Web Monetization extension, and following our tests with the platform, we decided to focus on PeerTube instead. Open.Movie is designed to showcase Creative Commons video, giving 100% of the WebMo income to the filmmaker (or less if they want to donate towards our windmill-powered hosting). Our initial batch of videos are all focussed on open source technology and copyright, and we hope to keep curating the space thematically.

This led to another challenge - on testing PeerTube we early got two signups from users; the first uploaded a Slavic copy of the latest Maze Runner; the second a perfect hi-def version of Dune, one week before it's US & UK cinema release. Thankfully we didn't have auto-publish turned on, but it highlighted the challenges of decentralised video, and reinforced some of the motivations around mova.

Bridging these: OpenVideo.Tech

Linking these projects together is a fourth new website - OpenVideo.tech - to support and discuss open video, which has felt to me somewhat homeless since the last Open Video Conference in New York in 2011.
OVT has a Gitlab and Mattermost discussion server - we're definitely not evangelical about our own tools, so if anything we're doing resonates with you (even if it just makes you say, that's daft) then please say hi!

Progress on objectives

To use Web Monetization to provide a new revenue stream for independent filmmakers, videographers and video archives. With mova filmmakers can associate a Payment Pointer with their work on an account-wide and individual film basis. They can declare a minimum fee per hour they are prepared to earn (from $0.00 to $0.36).
To use this new revenue stream to encourage more diverse and rich video to become available under a Creative Commons license. In mova filmmakers can choose a Creative Commons license. They can also specify different licenses for specific territories.
To use ISCC to provide filmmakers, videographers, libraries and rightsholders with reassurance around the new technology by helping associate wallet, license, payment and other key metadata with their file. This is what mova does.
To help support an ecosystem around Web Monetization-funded open video, including creation, discovery, re-use, annotation, and discussion. We think content provenance and identification could become an increasingly important part of any Web Monetization-based open system – which we hope to contribute to.
To use this combination of technologies to help develop and strengthen a decentralised and independent rich media distribution architecture. We hope so, and now we've got working software, are looking forward to presenting to potential partners and collaborators (in film, creative, tech, civic/commons) to gain their feedback.
To facilitate transcribing and translating open video assets to increase accessibility and broaden media participation. Both systems were designed multi-lingual, using Transifex for the CiviSplit extensions in Revenue Share, and a new Holochain translation system for mova. This needed custom admin-configured multilingual fields, allowing for multilingual inputs that can be registered on a DHT – but aggregated at a central API endpoint allowing search on any field; and appears noteworthy new work from Connor and Wesley Finck at Sprillow.
To present these new workflows, methodologies and technologies in clear plain-language for creative and not technically-savvy end- users. We've created git editable documentations sites for both systems using Hugo/GetDoks (which is a multingual system, tho we currently only use English).
To understand the remaining barriers to deliver on these goals. Each project has led to vastly increased understanding, which is outlined above. To recap:
- mova.claims taught us about the legal, compliance and community challenges with any kind of decentralised DHT dataset.
- revenuesha.re highlighted limitations with the current Interledger API, which makes Rafiki all the more interesting
- open.movie highlighted the caution and hesitation around new technology-based business models in the film & TV sector, and the challenge of illegal submissions in any self-managed system. We also recognised that the governance issues around a media registry demand a broad, diverse and representative governance and moderation structure - which we don't have in place. We don't want to grow much bigger than we are without the basis of that underway. For now that could take the shape of an advisory group.

Key activities

Development an app to generate ISCCs for large uncompressed video assets. Done
An interface and method to first register ISCCs on a distributed ledger with an ILP wallet payment pointer. Done
A CiviCRM extension to associate contact records with ILP Payment Pointers or web wallets, and generate ‘agreements’ between them. Done
To publish these agreements in printable and shareable machine and human-readable HTML/RDFa (implemented as a new YAML-subtype - Revenue Sharing Language). Done.
To trigger payment distributions from a host payment pointer based on the rules of these agreements using CiviCRM scheduled jobs. Done.
A WordPress instance configured to share publicly the video database with Monetization wallet, metadata, and licenses (WP2). Evolved. Early on we created a Joomla video database (https://screen.is/videos) - and had planned to move this to WordPress. However, after the release of a PeerTube Web Monetization plugin, we found PeerTube far more appealing for several reasons:
- PeerTube integrates transcoding of uploaded media, and handles large files well.
- It offers peer-to-peer streaming, to reduce bandwidth costs and improve fees.
- It's built with ActivityPub, so works across the full 'fediverse' such as Mastodon servers. In other-words, millions of users on 1000s of other instances can subscribe to specific open.movie users and channels, and then see new works appear their own stream elsewhere.
An interface to associate this and other key metadata with the ISCC code at a single URL publicly: e.g. license, transcript, Hyperaudio transcript, and attribution credits (WP3). Evolved. We have developed a full open API endpoint on the Holochain DHT which mova manages and publishes to. The creation of this required a bit of thinking, and Connor Turland designed a four-part system:
- h-app node. An always-on mova instance (which also ensures the database is always accessible during low-usage), which supports a…
- Crawler. A runner which looks thru the published Claims and tracks new and updated listings, writing these to an…
- Index. For speedy search and access by the…
- Public API. Allowing for searches by partial and whole ISCC codes, and terms from any published string. The public API is the place where the legal challenges around mova.claims becomes real, and is one of the reasons we're going so slowly with rollout - we wouldn't be able moderate that API if it was flooded with data, but it's important it stays on to demonstrate how mova could integrate with the wider web.

Communications and marketing

Both our projects have been technically demanding and our focus has been on getting to the point where we can demonstrate them publicly and let people test them independently. In other words, our comms plan is largely just beginning (this article will be first Tweet from @openvideotech, for e.g.).

We have done some limited marketing, including:

There's also been some broader blogging around Web Monetization on Netribution:

What’s next?

Immediately

This week we're opening up mova testing outside our team. You can learn more about it at mova.claims.
Cascade Native, Cascade Svelt, CiviSplit Agreement Builder and CiviSplit Processor extensions are available to download via the links above. The docs for using them are at RevenueSha.re/docs.
I will approach the filmmakers on open.movie to invite them to add a payment pointer for their work.

Soon

In the coming weeks/months we'll open up the founding test user programme wider thru an online application. To stay updated on this, join our Mailing List
Likewise if you want to learn when the Uphold CiviCRM extension is available.
- Personally I'm really looking forward to presenting the projects to people in film, docs, tech and civic tech and will be reaching out to many (feel free to reach out to me too - nic@netribution.org).
We want to test out combining Creative Commons-NC with Web Monetization on Open.Movie (CC+/CC-WM?). In other words to allow filmmakers who don't want their Creative Commons video used by the ad/big-data industry, but who'd be happy to earn from Web Monetization income. We will be speaking this month with New Media Law, thru their GftW award, on any legal issues around this (in case the commercial nature of Web Monetization creates a conflict). In this way mova, could let CC filmmakers declare both a CC-BY-NC license and the minimum Web Monetization income they are prepared to be paid. If it's $0.18/hour, for instance, that would let Cinnamon host their work, and know who to pay.

And beyond

Both projects can, of course, be developed much further and we've started drafting roadmaps for each.
We're also interested in exploring a Creative Commons model where filmmakers publish their film's budget as an RSL agreement, with the promise that when the debts and expenses have been repaid the work will be made available under a Creative Commons license. We think this could bring more good films into the Commons, and progress the conversation around filmmaker compensation towards sunk and deferred costs. Most filmmakers expect to make their money in the first few years paying back any investors so they can get funding to produce future films. The amjorityy of feature films older than five years have value only in aggregate in a library, most are not even watchable. So if a commitment to release the film in the long-term under a CC license would encourage more people to donate/tip/WebMo - and this could be setup easily - then maybe it would encourage more filmmakers to adopt this strategy
Streamed Climate Compensation. Last year I wrote about the idea of using a share of Web Monetization income to realtime offset the climate impact of data consumed online - potentially with savings for accessing cleaner and greener hosts and CDNs or with more efficient technology. During the project we've reached out to several researchers in the green-tech space, including members of ClimateAction.tech, EcoPing, the new Greening of Streaming CDN lobby group, and have also had positive feedback to the idea. We also funded the translation of some work by French digital climate impact researcher Gauthier Roussilhe on the impact of the web and video in particular. This remains a pretty central interest given the rising climate impact of the web, of which video makes up the vast majority. Our conclusions and research in this space so far are written up here.

What community support would benefit your project?

If anything we've written resonates with your projects or interests, do say hi.. in the comments, on Twitter @openvideotech, on our (currently empty) Mattermost discussion server or by email - hello@openvideo.tech.
In particular we'd like to chat with
- tech-comfortable filmmakers & rightsholders who might want to try out either mova or revenuesha.re;
- Creative Commons filmmakers with work to show on open.movie;
- curators interested in contributing to open.movie;
- developers working on decentralised media or streaming
- community builders and participants.
Also, sign up to our very occasional mailing list if you want to stay updated.

Additional comments

I'm very grateful to the GftW team for their support throughout this process, and for making the award. The tech projects and libraries we're building on are many – and my gratitude there runs really deep. I'm also in awe of the work of our team - and indebted to many people who've helped along this journey, which goes back some years.

Relevant links/resources (optional)

https://openvideo.tech (parent organisation)
https://mova.claims
https://revenuesha.re
https://open.movie

And also:

lab.openvideo.tech (our gitlab for internal development)
github.com/openvideotech (our github for distributions)
matter.openvideo.tech (our Mattermost discussion server )
crm.openvideo.tech/mailing-list (our crm for signing up to our mailing list or waiting lists)
twitter.com/openvideotech

Revenue Sharing Language for Web Monetization, coming soon to CiviCRM

Nic — Fri, 26 Nov 2021 14:03:56 +0000

Since introducing the idea of Revenue Sharing Language (RSL) here, we've built the drag-and-drop builder for RSL payout plans, first with Mark Boas as a native JS framework-free version, Cascade, and now, branched and remade in Svelte JS to support broader unit testing, multiple builds and realtime RSL generation, by Rich Lott. This will exist as both a standalone script, and integrated into CiviCRM.

Matthew Wire has been building this CiviCRM integration – like Rich he's a big contributor to CiviCRM (he maintains the Stripe Payment Processor; Rich maintains GoCardless) and the builder is now integrated into a CiviSplit extension, screen-recorded below:

Here you can see extension reference CiviCRM Contact records, which hold the payout information (e.g. an ILP address or bank account number). Once agreed upon, the payout plan is saved and made uneditable, with the RSL hashed for security, and viewable at a fixed URL, with an ILP address generated to receive Web Monetization.

A second extension, CiviSplit Processor is triggered with a scheduled job to check the ILP account balance, calculate who is owed what – and provided they're owed more than a €10/£10/$10 minumum payout - trigger a payment. We've got this working in a form good enough to start writing unit tests against, which is a major job given one YAML syntax error could mean people are paid incorrectly. We also want payouts to be auditable, with processes for remainders (e.g. €10 split three ways) and hanging payouts. It's built as an API so should integrate with messaging, alerts and reporting inside CiviCRM. The third extension to come is an Uphold processor integration, which creates the Card / ILP, checks the balance and handles payments. Because of the forthcoming arrival and potential changes of Rafiki, we're saving this part until last.

To those new to CiviCRM, it's an open source CRM for the non-profit sector originally maintained by Donald Lobo – and unique in that it integrates fully with the three biggest Content Management Systems (WordPress, Drupal & Joomla) as well as Backdrop. It's been running since 2004 so has a big global community, dozens of languages, 1000s of extensions and is used at a vast range of scales – from the heart of Wikimedia's fundraising database, and charities like Greenpeace and Amnesty International, to tiny volunteer-run membership organisations. Even tho it handles everything from bulk email to fundraising to case, member, record management and event ticketing, it's not as well known as other open source projects. IMHO this is because, like Joomla, it's a non-profit itself, so has a very limited budget for marketing and outreach (unlike WordPress and Drupal, say, which both have well financed commercial 'parents' - Automattic and Acquia). Likewise agencies wanting to get rich in the tech-for-good space tend to end up pushing for Salesforce or Dynamics, given non-profits can pay millions for such setups.

CiviCRM is AGPL licensed, so of course can be used by a filmmaker wanting to profit from their work. But as it's largely built by and for non-profits, and this culture helps make the community feel so special – it's good to consider how Civi contributions can benefit the wider community. This week we published a blog for the community exploring some of the ways CiviSplit could potentially be used once built and well tested: (obvs none of this counts as legal or financial advice)

For joint-fundraising campaigns where a number of charities share income received.
For fundraising events where costs need to be repaid, and then a share of income given to an organiser.
To share the development costs and maintenance of open source extensions in the communmity.
Cooperative groups managing dividends and payouts (a number of coops use Civi, especially community/renewable energy coops).
Collaborations between creatives and charities. At least since JM Barrie gave the copyright for Peter Pan to Great Ormand Street Hospital, or the £1.4 billion raised by Comic Relief there's been many fruitful collaborations between musicians, writers, artists, filmmakers and the non-profit sector – and this perhaps could make it easier to set these up.

The climate impact of the web is big and growing fast. Could Web Monetization help?

Nic — Fri, 22 Oct 2021 17:17:26 +0000

In the days before signing the contract for our project MOVA, I came close to withdrawing. I'd made a commitment in the application —and to myself— to make sure our project minimised CO2 impact, which would then be offset. If successful the project's impacts would be monitored, reduced and offset too. But as we started turning functional specs into technical ones, the more clear it became how badly I was falling at this first hurdle of minimising impact.

A major part of MOVA was going to be installable only with Docker, a 580mb download, requiring gigabytes of hard-drive space – both being energy intensive. It was set to write data to Ethereum once the more efficient proof-of-stake Bloxberg academic blockckhain we'd chosen turned out to be unsuitable. A single Ethereum transaction at present uses as much energy as a US household uses during a working week. With fires and floods raging across the world I came close to cancelling our application altogether, before delaying the start a month to re-design the architecture – after finding the great new team of Pegah and Connor of Sprillow, in Canada. We'd swap Docker for Electron.js and Ethereum for the more-efficient ledger Holochain.

While this was a big step forward for the software - we'd gained a native desktop app for Mac, Linux and Windows – in the course of looking at the question of measuring and mitigating the project's environmental impacts, I'd made a much more unsettling realisation. It's one that impacts anyone who creates, hosts or even watches video online. But maybe Web Monetisation could offer a solution. As the world prepares for the COP26 climate conference in Glasgow UK (pictured above), it seemed a good time to dive into the research.

Worse than flying, and growing much faster

“There are no passengers on Spaceship Earth. We are all crew.”
Marshall McLuhan, via Branch

If the Internet were a country, it would be the sixth largest in terms of electricity use. ICT doesn’t just produce between 2.1% and 3.9% of global greenhouse gas (GHG) emissions – more than aviation or shipping – but as more of the world get online at faster speeds, watching more video for longer, this share is rising fast.

Of this carbon footprint, the biggest impact by far 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 worrying news for creators building a following: the bigger the audience, the more viral the videos, the bigger the climate impact.

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 (because, ironically, drier climates make them easier to cool). 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 CO2 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.

Many thanks to the researchers and members of ClimateAction.tech, especially Dryden Williams and Gauthier Roussilhe for taking time to speak. Header photo of Glasgow exhibition centre, home for COP 26, by Nicol Wistreich, Creative Commons, BY NC.

MOVA — Grant Report #1

Nic — Fri, 08 Oct 2021 15:14:49 +0000

Project Update

MOVA is designed to help filmmakers and video rights-holders explore and adopt Web Monetisation and open video through several activities. Cascade and CiviSplit hopes to incentivise wallet creation by automatically paying out royalties and expenses, like a virtual collection agent. MOVA is a desktop app, running a shared database/ledger to support the goal of ensuring the right person is being paid for a video. Alongside this are a number of smaller activities that overlap these core developments.

In the days before signing our contract, we actually came close to pulling out. I'd made a commitment in our application —and to myself— to make sure the project minimised and tracked CO2 impact and that this was then offset. But as we turned the functional specs into a technical spec, it became clear we weren't minimising – but the reverse. MOVA was going to require lots of bandwidth to download, encouraging people to use even more bandwidth and CPU processing in its use, and then looked increasingly likely to depend on a blockchain with a power consumption greater than Bangladesh, a country of 161 million people.

The project was in jeopardy, until we found a new Canadian team – Pegah Vaezi and Connor Turland of Sprillow, environmentally committed and expert in a new distributed ledger Holochain as creators of Acorn. We delayed by nearly a month for re-architecting – swapping Docker for Electron.js and Ethereum for this more energy-efficient blockchain alternative. Together this pause and reworking provided a number of advantages – we should now have a cross-platform standalone desktop app – and I'm grateful for the GftW team's support as we adjusted.

So our first four months has been more of an intense three months since signing – but we didn't want an extension to the mid-term review date as there's currently some momentum, and it's good to be able to share our progress. However, my apologies for a long 20+ minute read; in other situations I might have split it across several blog posts – so it may benefit from being read over several sittings as there's a quite a bit to digest.

Progress on objectives

Turning back to our original project goals...

To help support an ecosystem around Web Monetization-funded open video, including creation, discovery, re-use, annotation, and discussion.

This is the overarching goal of the Open Video Architecture we are working towards. Open Video Architecture is a loosely defined concept but broadly means decoupled hosting, search/recommendation and playback similar to the web's decoupled server+HTML/DNS+search/browser+device structure. In other words the idea that media can be hosted anywhere, and recommended and rewatched anywhere, provided it meets the license requirements of the original filmmaker or rights-holder. We are building two components of this architecture around Web Monetization focussed on incentive and provenance – so the success of this driving objective will be best assessed at the end of the project and after.

Our starting point was to map the current ecosystem, which has changed a lot since the Open Video Conferences, which predated but overlapped Mozfest. Those conferences first impressed on me the potential of decoupled online video architecture for both creatives and fans and up-ended my view of needing strictly controlled end-to-end spaces, which I'd written about in a book on Digital Asset Management for Informa.

Output 1. Digital garden

research.screen.is

This first step, which began within days of being notified of our proposal's success and continued long before ink finally hit contract, was to start aggregating research around open video, tools and 'net-zero online video', in a 'digital garden'. Maggie Appleton has written a very good illustrated history and overview of the digital gardening; it's a way to structure links and research differently to the linear nature of blog or social media feed.

This uses the concept of double bracketed bi-directional links pioneered by Roam Research making a network or mind-map of knowledge, rather than a directory tree structure. Setting this up was a fun learning curve for me as it was my first dive into Static Site Generators - after 15 years using content management systems. Testing out 11ty, Jekyll, Hugo and Next, and liking differences in all of them, I settled on Gatsby because of the existence of a beautiful theme for digital gardening based on Andy Matuschak's working notes - which as a browser-tab addict is one of the nicest new interfaces I've seen.

I chose Obsidian to write the research as Markdown text files locally as it supports the [[double square brackets]] pioneered by Roam to create bi-directional links. I like it enough to now draft blogs on it too, such as this report. Finished research notes are pushed to Gitlab which then turns it into a working React site – research.screen.is – with all the changes, typos and mistakes publicly visible in the Git repo (which of course anyone can contribute to, or fork).
Highlights for me have included learning about Hollywood's growing involvement in open source, creating the Academy Software Foundation; and realising how far Activity Pub, the underlying technology of Mastodon, FunkWhale and Peertube, has come.
This was my first personal experience of automated pipelines as part of a Git workflow and combined with the ability to write offline, track changes and share progress I am converted – although am still using WordPress for the project website as I'm not sure every future user will be comfortable with a git workflow.

To present these new workflows, methodologies and technologies in clear plain-language for creative and not technically-savvy end- users.
To use this new revenue stream to encourage more diverse and rich video to become available under a Creative Commons license.

Output 2. Open Video website & logo

openvideo.tech
We created a website to describe Open Video, spotlight the Mova project, and aggregate our blogs. The key concept we wanted to communicate on first visit is the distinction between

Open Source tools for video like FFMPEG, Storyboarder or Pixar's OpenTimeline,
Open licensed video (e.g. Creative Commons and public domain), and
Open Video Architecture - our focus. All could count as 'open video' but given that a proprietary Hollywood film might use an open source toolset in post-production; or a Creative Commons film is edited with proprietary software - the distinction is important as not every part of the process needs to be open, which some people assume ('oh this can't be Open Video as I used After Effects').

Gradually information from the digital garden should work its way onto this site, for instance moving notes around 'Net Zero' Online Video into an overview here openvideo.tech/Green/.

To use Web Monetization to provide a new revenue stream for independent filmmakers, videographers and video archives
To facilitate transcribing and translating open video assets to increase accessibility and broaden media participation.

Output 3. Prototype documentary assets microsites:

screen.is/testing &

At screen.is I've created a couple of demonstration spaces of repositories of videos that use Web Monetization, alongside a searchable synched transcript, and a download link that appears if you view the pages with a Coil wallet. This was built with YooThemePro, Hyperaudio and Joomla, because it has built in custom fields and internationalisation. At the moment I'm using video assets I had locally available under a Creative Commons license on my computer – presentations from an event I co-organised during lockdown about how CiviCRM was helping Covid responses, and from a documentary I made about CiviCRM several years ago. There are three layouts setup:

A list of all videos: screen.is/video
Grouped collections of videos, as a repository for a specific documentary or event: e.g. screen.is/civicrm & screen.is/civilive
An individual video page (below), featuring a Hyperaudio time-synched transcript, for e.g. screen.is/videos/five-case-studies-using-civicrm-to-support-communities-during-covid-19 Visitors with a wallet in their browser see "Thank you for supporting the Open Web with Web Monetization" and on the individual asset pages are offered a download link for the full video file.

On another prototype site - mova.watch – we've used WordPress, Advanced Custom Fields and a pre-built YooTheme film directory template – and have also tested showing a notice to visitors without a wallet encouraging them to get one.

To use ISCC to provide filmmakers, videographers, libraries and rights-holders with reassurance around the new technology by helping associate wallet, license, payment and other key metadata with their file.
To use this combination of technologies to help develop and strengthen a decentralised and independent rich media distribution architecture.

Output 4. MOVA:

openvideo.tech/mova
MOVA is a proof-of-concept app to help filmmakers and rightsholders publicly claim authority over a video against a 'lightweight fingerprint' of it, alongside the license, payment pointer, metadata and usage conditions. The ambition is to help both platforms and video viewers fairly share, attribute and reward this work. This part of the project uses two recent technologies:

International Standard Content Code (ISCC) (iscc.codes/) – an open source Python library to generate a soft fingerprint for any media, and which should recognise the media after changes to metadata, file format, resolution, framerate and colour information (learn more).
Holochain (holochain.org/) – a distributed ledger technology built with Rust that allows apps to create their own shared ledger - a sort of personal blockchain. Rather than proof-of-work or proof-of-stake to verify that distributed data hasn't been changed, Holochain uses a 'gossip protocol' of sharing information with a much smaller set of random peers (learn more).

These will be combined in an Electron.js application which can be run on a Mac OS, Linux and Windows desktop. This part of the project has considerable challenges:

technically, given the foundation technologies are new;
user-experience, given the number of new concepts being introduced;
legal, governance and moderation, in particular.

After a long and comprehensive series of wireframing and conceptual workshops, Pegah Vaezi created dozens of mockups and established a design language (see screengrabs). Connor has been focussed on the technical implementation, handling in recent weeks the requirement for the application to be both fully translatable and allowing for administrators to add new custom fields for metadata. The app's language is likely to keep being tweaked in response to test feedback, but we're increasingly satisfied with the design - which is screengrabbed in this report.

The questions of legal compliance and good governance are intertwined and fundamental to any success of this MOVA app. Broadly speaking they can be divided over five areas (CLAIR), some of which are achievable, others more aspirational and some barely possible outside of the digital space, yet nevertheless important:

Control. Establishing that a media file is controlled by, and paying out to, the correct claimant.
Legal. Establishing information provided is legal. This could include that other people's copyrights aren't infringed, besides fair-use provisions, as well as compliance with privacy (GDPR/CIPA/etc), decency, defamation, harassment, harm, equality, accessibility and other laws.
Accurate. Ensuring the metadata is accurate and not misleading.
Informative. Establishing that there are adequate notices around any other aspects of the media (for e.g. distressing, advertorial, over-18 or misleading content).
Regionally aware. National and regional rules differ considerably, and change all the time with changing legislation. For instance, the new Marvel film the Eternals is PG13 in the USA but certificate 18 in Russia because it is illegal to present homosexuality to under-18 year olds in Russia.

These issues are not new to anyone providing open platforms online and are normally resolved by allowing for edits, corrections and full moderation after submissions and publication. However, the use of a distributed hash table (DHT) creates an extra layer of complexity because everything written to it is permanent. This is perhaps a bit like a tree where the outside bark is immediately visible; but as someone slicing thru the tree trunk can see old rings of bark; the DHT will contain old versions of the data – which cannot be redacted because the dataset is distributed. What this means for GDPR and other legal obligations is still uncertain amongst lawyers because of limited precedent - but is a challenge common to blockchain spaces, and indeed in any open source system with a public repository and shared archive, such as on Github/Gitlab.

Distributed datasets are designed to protect against data loss and corruption, but perhaps provide a challenge in governance somewhat similar to the print industry – once something is printed it's impossible to remove it from circulation, even with bonfires of books. However print publishers need to pay for ISBN codes, which are only available to legal entities, which would be legally liable in the event of, say, defamation – while our current goal is that anyone can publish data about their own films. This is because not every indie filmmaker has established a company – indeed how many YouTube and TikTokkers have?

So given we know that widely-used open systems eventually attract misuse, and if redaction of wrongful data is impossible in a DHT, only obfuscation – this leads inevitably to the question: why should this be a decentralised database? For us it's because we want to investigate the potential of a filmmaker/rights-holder owned- and controlled- database. The concept is a shared dataset that's not controlled by a single all-powerful service company or technology giant, but that's created and co-owned by the media creators who will benefit from a shared repository – and who want that dataset to be good and reliable. A distributed ledger when ringfenced in the way Holochain does, has the possibility of offering a new form of shared data ownership and stewardship, similar to cooperative ownership, especially open data coops. However, it may be that we find this creates more problems than it solves; that filmmakers can't be bothered with data governance and provenance questions; or even just that it is highly inefficient from a technical, energy, cost and labour perspective. But for now we want to fully explore this hypothesis of shared data governance, while keeping an open mind as we start to discus this with potential stakeholders.

This means a growing part of this project has been widening discussions with experts beyond our project team and lawyer – from community governance specialist Dave Boyle of the Community Shares Company (who has written about the BBC becoming a cooperative); to Andrew Katz, a leading open source lawyer and fellow GftW awardee. In the next round of work, as well as building a technically demanding application, in discussion with more experts we hope to map the full scope of legal and governance challenges, to propose solutions and to create an adaptive governance approach that can adjust as we move into a Proof of Concept/beta onwards through a release candidate.

To understand the remaining barriers to deliver on these goals.*

Increasing understanding could be a tagline for this first part of the project – from the technologies and legal requirements to the limits and needs of media makers. We've had regular conversations with people across the space from film distributors to lawyers and cinemas, film festivals and campaigners. Two of the biggest insights we've been left with:

The chief challenge with decentralised video is the moderation/censorship paradigm. Fully open spaces need moderation to handle both illegal and 'legal but harmful' work. However at scale automated moderation systems risk censoring legitimate works while human moderation is costly and time-consuming - so need a business model to sustain.
'Carbon-neutral online video' is a big topic in climate tech spaces given the quantity of bandwidth, storage and processing video requires from delivery to viewing. A viral video can potentially emit thousands of tonnes of CO2 and some estimates of data-centre growth in response to increased online video demand forecast video growing to 14% of 2016's global greenhouse gas emissions by 2040. However, we've started to explore the idea that because Web Monetization pays per-second viewed, it potentially offers way to build in an offsetting cost for this climate impact while streaming media.

Key activities

Development of the an app to generate ISCCs for large uncompressed video assets (ie terabytes of video) on a local machine. This programme can also be hosted on a web server, but that's better suited to smaller files given bandwidth costs (WP1).
An interface and method to first register ISCCs on a distributed ledger (Holochain) and register an ILP wallet payment pointer to this ISCC code (WP1).
An interface to attach this agreement to the ISCC code on a distributed ledger in an authoritative way (WP1).

See Output 4: Mova above.

A WordPress instance configured to share publicly the video database with Monetization wallet, metadata, and licenses (WP2).
An interface to associate this and other key metadata with the ISCC code at a single URL publicly: e.g. license, transcript, Hyperaudio transcript, and attribution credits (WP3).

See Output 3: Prototype microsites above.
We have also created a sandpit PeerTube instance and have tested the PeerTube Web Monetisation plugin (finding an issue, which @samlich debugged). I've been impressed how easily PeerTube subscriptions integrate with other Activity Pub services like Mastodon.

A CiviCRM extension to associate contact records with ILP Payment Pointers or web wallets, and generate ‘agreements’ between them (WP2).
To automatically trigger payment distributions from a host payment pointer based on the rules of these agreements using CiviCRM scheduled jobs, sending receipts to recipients (WP2).
To publish these agreements in printable and shareable machine and human-readable HTML/RDFa, following the definition of Ricardian Contracts (WP2).

These activities together make up the second main work package of our project – Cascade & CiviSplit. The goal is to make it easier for creatives to share their Web Monetization income across a team, potentially after paying back expenses and debts. It was inspired by my own experience in self-publishing a film finance handbook over a decade ago, where the monthly income from sales had to be split between three authors, after each of our exepnses had been repaid – we just tried to keep track in a spreadsheet. The book itself had a section on recoupment waterfalls – a fundamental part of film financing and distribution, managed at considerable cost by collection agents and it seemed there was a large gap missing between the two.

To do this, a CiviCRM extension will distribute income received at a wallet with a unique Payment Pointer, according to user-defined, multi-step rules, as a penny/cent-accurate alternative to Web Monetization’s probabilistic revenue sharing. This also allows for multi-stage payouts, for e.g. first pay one person a fixed fee, and then split the money between two other people.

Building on CiviCRM allows integration with the big CMS (WordPress, Joomla, Drupal 7 to 9, Backdrop), as well as integrated reporting and tracking, and integration with Civi's other extensions like SMS notifications. However to support people creating integrations with other systems and maintain interoperability – we're building the agreement generator as a small lightweight native-Javascript script called Cascade.js, which in turn is producing and storing the structured agreements in a serialisable human- and machine- readable YAML-based format we've created called Revenue Sharing Language. So there are three outputs around this:

Output 6: Revenue Sharing Language

Revenue-Sharing Language (github.com/openvideotech/rsl) is a YAML-based vocabulary and syntax to describe how revenues received at a wallet, pointer or account should be distributed, with payouts structured as a series of consecutive steps. Using YAML it should be easier for non-developers to read than other serialisable structured formats like JSON.

The reason for creating RSL is to offer a syntax that could be appended to contracts, which payment systems could then use to payout whatever revenue distribution is defined. A hash could then be generated from this machine-readable version of the agreement, so that if any changes are made to the implemented agreement later, the hash would change. This allows for a check against potential changes because payout systems using the RSL as their input should be able to demonstrate it's the same RSL that was originally agreed, by comparing the SHA-256 hash (which anyone can generate). This idea of a human and machine readable agreement is sometimes known as a Ricardian contract – the human-readable aspect is what makes it different from Smart Contracts.

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 potentially a bank account, or other payee address). RSL isn’t intended to generate or implement the agreements – that’s Output 7 & 8 – but rather to provide this open and serialisable basis for structuring agreements.

---  
name: “Abi's Road”  
description: “Record deal for the band Be At Less”
url: beatless.example.com/deal
pointer: $ilp.example.com/pN3K3rKULNQh
contact: Big Lawyers Inc.
email: big.lawyers@example.com
currency: EUR
steps:
  -
    type: fixed  
    payee: 
      - [“Orange Records”, ID001, dbse, 5000 ]
      - ["Georgina Martina", producer@example.com, paypal, 5000 ]
  -
    type: percent
    cap: 1000000  
    payee: 
      - [ "Joan", $ilp.example.com/joan, ilp, 25 ]  
      - [ "Paula", 12345678/12-34-56, uk-ac, 25 ]  
      - [ "Georgie", $ilp.example.com/georgie, ilp, 25 ]  
      - [ "Reena", NO 93 8601 1117947, iban, 25 ]
  -
    type: percent
    cap: null
    payee: 
      - [ "Unicef", $ilp.example.org/unicef, ilp, 100 ]

The spec for RSL – which we are still inviting comments and feedback on – has had input from a number of developers and legal experts in finance, media and IT. It includes six hypothetical examples of different kinds of payout structures from a book publishing advance and record deal, to a feature film to filmmakers cooperative – you can read more about the idea here.

Output 7: Cascade

While discussing how to get CiviCRM to build these RSL agreements, it was decided to separate the agreement construction from the logic which CiviCRM needs to implement. From there it was a relatively small step to decide to build the agreement builder as a standalone native-Javascript mini application.

As a standalone app (which 'cascades' income step by step) we could more quickly debug issues within the builder; make it easier for people to read our code; and support other implementations with other systems, either under AGPL (ie GPL with the requirement to make public any changes or additions, like CC-BY-SA) or a commercial license without that requirement.

Mark Boas, pioneer of Hyperaudio, and another GftW awardee, developed the Javascript to turn my html/css mockups into a functioning app that can generate RSL output. An initial development requirements was to write this in native javascript without any Javascript framework. This was because:

no risk of conflicts with javascript libraries inside CiviCRM or its enclosing CMS – which might include old versions of Angular or JQuery.
a smaller overall file - cascade.js is 26kb uncompressed
no dependencies creating potential future vulnerabilities for anyone not updating the script.

This requirement increased the workload but also forced us to rely more on native web and HTML components, for instance using <details> and <summary> tags rather than an accordion library, and using CSS icons rather than an icons font.

The current version is downloadable from github.com/openvideotech/cascade and there is a demo for strictly demonstration and testing purposes here: openvideo.tech/cascade.

Output 8: CiviSplit, CiviPayout & CiviILP

The final – and most complex – step is the payment distribution for these agreements. There's several stages to this:

Create an RSL agreement (using Cascade.js);
Approve an agreement by signatories/payees to it (which may be quite limited for now);
Generate a hash of the agreement, and a unique wallet and Payment Pointer for that agreement;
Triggering a recurring job to check the wallet, get the balance and payout the balance according to the rules, based on whatever has been paid to date.
Handle payments that don't resolve, or take too long to resolve;
Track payments (and failed payments) in a reportable way, potentially triggering email or SMS notifications of a payment being made.
Having the potential for an audit-able trail so that if anyone disputes a payout, the RSL could be checked against the hash of the approved agreement to ensure it hasn't changed; as well as comparing the reported payouts against the wallet ledger.

The functional CiviCRM build is by Matthew Wire of MJW Solutions in Portugal. It will require a number of new CiviCRM extensions:

Civisplit: the implementation of Cascade which creates a CivisplitAgreement entity and loads/saves to that. It currently lets you load saved agreements by passing a URL parameter.
CivisplitUphold: This is what generates and checks the ILP address and provides interfaces with CivisplitProcessor.
CivisplitProcessor: This is what calculates and generates the payments in CiviCRM.
CivisplitPayouts: Currently implements an API to indicate what is completed/pending for each contact. This is what how incomplete payments are handled.
CivisplitPayoutWise: This will use CivisplitPayouts as the data source and Wise as the payment destination. This was added once we realised that the Web Monetization API doesn't yet handle payouts; with Rafiki not expected to be Uphold integrated during the timescale of our project.

Perhaps because of the requirement of making cascade.js dependency-free, the first step of porting it to CiviCRM was relatively quick. It required some changes to the HTML and stripped out most of the CSS, but the Javascript could remain intact. Our first CiviCRM extension doing this, creating an agreement and its RSL that is saved in the database and reloadable via a value in the URL is now working with CiviCRM across all CMSs. There's a demo below:

Communications and marketing

We follow a communications strategy of first blogging in 'beta' form in a low attention space at openvideo.tech to generate discussion and feedback from our team and network, which can lead to edits and changes. Then we post on community.grantfortheweb.com - to widen discussion out (and further iron out issues). We have then opened discussion up on LinkedIn and Twitter.

Blogs:

Introducing Revenue Sharing Language – a Web Monetization answer to Hollywood accounting? community.webmonetization.org/mova/introducing-revenue-sharing-language-a-web-monetization-answer-to-hollywood-accounting-1p6e (& https://openvideo.tech/introducing-revenue-sharing-language-a-web-monetization-answer-to-hollywood-accounting/)
What would a video Wikipedia look like? https://community.webmonetization.org/mova/what-would-a-video-wikipedia-look-like-1a0p (& https://openvideo.tech/what-would-a-video-wikipedia-look-like/)
The cutting room floor – open documentary with WM https://community.webmonetization.org/nicol/the-cutting-room-floor-open-documentary-with-wm-1b27
How big is web video’s carbon footprint? And is Web Monetization the answer? (beta blog) https://openvideo.tech/how-big-is-web-videos-carbon-footprint-and-is-web-monetization-the-answer/

There's also been some broader blogging exploring Web Monetization on Netribution, which re-opened with a new front page and Monetization tag for its 21st birthday (some of these pre-date the grant period):

Music streaming, monopolies, interoperability & the chaos monkey. https://www.netribution.co.uk/blogs/music-streaming-monopolies-interopability-the-chaos-monkey
Netribution is 21 today; expirements with Web Monetization. https://www.netribution.co.uk/blogs/editorial/netribution-is-21
"Old Man Shakes Fist at Algorithm", but Scorsese has a point, and is WebMo an answer? https://www.netribution.co.uk/blogs/old-man-shakes-fist-at-algorythm-but-scorsesee-has-a-point-and-webmo-could-be-an-answer

What’s next?

Cascade/CiviSplit is made up of several separate extensions so we hope to be able to bring each one to beta and start testing once they are ready. MOVA should also move to a closed beta test period – with public API.

Parallel to this, my focus is opening and continuing conversations with:

film industry practitioners - both curation spaces like film festivals, magazines and independent cinemas; to rights-holders including libraries, archives, distributors and producers.
legal experts.
community moderation and governance experts.

Starting these discussions at pre-demonstration stage gives some space to inform the direction of the build. I'm currently travelling in the UK for a month to begin these conversations. Already it's become clear that there is a huge hunger for new online subscription-video-on-demand service for independent producers who haven't sold to Netflix/HBO/etc. Amazon Prime UK recently kicked out many video distributors, with little notice – and the fee per hour was considerably lower than Coil's.

The final element which will take place after these conversations and the development is more advanced, is the build of prototype spaces shwoing the approach online, and we expect to have several sites reflecting the integration for both a filmmmaker and for a platform/curator – an aggregation space.

What community support would benefit your project?

We are very interested in speaking, and potentially working, with:

documentary filmmakers who want to explore putting their full interview assets online in a web monetised space, as discussed here. We could potentially help with this with web design/build/hosting support & advice.
open video people working on or researching any parts of the Open Video Architecture/ecosystem –to see if we can keep our projects compatible and explore ways to collaborate.
moderation and governance researchers, practitioners and exeperts in both moderation and community governance – we have some budget assigned for exploratory discussions around this in the coming two months so would welcome speaking with experts.
testers – anyone curious in what we're building and wanting to try it out early - testers are very welcome, so please get in touch. You can message me here or via hello @ openvideo.tech.

Relevant links/resources

Project digital garden:

https://research.screen.is

Project website:

Revenue Sharing Langue:

https://github.com/openvideotech/rsl

Cascade:

https://opnevideo.tech/cascade (demo)
https://github.com/openvideotech/cascade (library)
https://work.screen.is/lab/mova/civisplit (CiviCRM extension)

MOVA app:

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

Nic — Tue, 07 Sep 2021 14:59:06 +0000

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 Black 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 ]

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

What would a video Wikipedia look like?

Nic — Fri, 02 Jul 2021 16:17:00 +0000

I hope you forgive the clickbait headline, reader, as our project isn't a video Wikipedia. But the subject is a good thought experiment to introduce some of the motivations around 'open video', and explain some of the backstory to our project MOVA (Monetizing Open Video Assets), which has just started this week.

'Video Wikipedia' is a long-discussed concept that slams fast and hard into technical, social and funding questions: what is the interface for collaborative and transparent video editing that's as easy to use as a Wiki? How would you host and serve that much video? How could you moderate for quality, accuracy and legality of media? How would such a project be funded? What might motivate videomakers to contribute?

While Web Monetization may offer answers to the funding question, the scale of the other challenges, not to mention the carbon footprint of video online versus text, triggers an immediate question – why does the planet need a video wikipedia? Simply literacy: for the 773 million adults around the world who cannot read, two-thirds of whom are women, Wikipedia is useless – and that's before considering many people's low reading skills or learning styles. According to Wikimedia Sweden, a quarter of Wikipedia users prefer or need text in a spoken form. For as long as Wikipedia can't serve these people's needs, YouTube will – yet without an editorial process to ensure quality, accuracy or 'neutral point of view'.

Pratik Shetty, the co-founder of the most recent attempt to solve the problem, VideoWiki, was inspired after seeing the presence of mosquitoes near his building and warning the building's security guard they could cause dengue fever. The guard reassured him that he could treat dengue by himself without visiting a doctor, showing a YouTube video that listed five at-home remedies. When Pratik advised him to get his medical advice from Wikipedia not YouTube, the guard explained he cannot read.

Shetty and Hassan Amin's VideoWiki isn't the first attempt to solve the problem; the subject has a long history - WikiTV dates back to 2005, and in 2008 open source collaborative video editor Kaltura added a MediaWiki extension and announced a partnership with Wikimedia to bring rich media to pages. But it struggled to take off, and the VideoWiki lists under 150 articles articles made into rich, editable media. As Wikipedia itself says, the incorporation of video into wikipedia is still at 'a very early stage' and although there are 135,000 videos listed on WikiMedia Commons many seem likely to have been generated by the Open Access Media Importer project, a bot which imports public access scientific video from PubMed Central.

As I left the FOSDEM Videowiki session in Brussels in February 2020, I found myself wondering why there wasn't more open video on Wikipedia. Part of the answer is simple: money. It's far cheaper to write a Wikipedia entry or share a photo than produce a professional-quality video. Furthermore, Wikimedia's Creative Commons licensing doesn't allow for non-commercial, so filmmakers wanting to still sell their film to Netflix can't also share parts of it to Wikipedia without allowing someone else to then sell a version of it to Amazon.

As it happened I'd just that day filmed an interview with the co-founder and former 'Benevolent Dictator' of CiviCRM, Donald Lobo for an ongoing, somewhat neglected project of mine, making Creative Commons SA video around the CiviCRM community: screen.is/civicrm/. It had struck me that Lobo's interview would be interesting to people outside of CiviCRM as well: he was employee number five at Yahoo; and thru his Chintu Gudiya Foundation is involved in a range of transformational open source development projects in India. I'd been lucky to get the interview at short notice, so what gave me the right to exclusively own a 30 minute interivew, for the two minutes that might make its way into a final film of mine?

At another FOSDEM session on Wikibase, I learned of JSTOR's Interview Archive for Peter Kunhardt's HBO film about Martin Luther King's last three years: King in the Wilderness (pictured top). The film is a historical document, but so are the uncut testimonies of each of the interviewees. JSTOR labs created a searchable database of each interview for the documentary, complete with transcripts, tagging, metadata and background information from Wikipedia.

JSTOR's Ron Snyder talking thru the project explained how 'some of the best stuff ended up on the cutting room floor'. This is something I've mentioned before here and is well known to filmmakers but not necessarily viewers — just how much footage is never shared in order to make a tight and snappy final cut. Peter Kunhardt's Film Foundation, has since put the interview archives of more documentaries online but not with the JSTOR interface and it's not caught on further.

These three takeaways from my weekend in Brussels at FOSDEM were whirring around my mind as I got on the train back to London:

Wikimedia doesn't have enough good quality Creative Commons BY/SA licensed video;
Documentary filmmakers effectively bin millions of hours of footage that never makes their final cut each year;
For some cultural projects the full unedited video provides value and importance as a source text. If you're lucky as a filmmaker to interview a historically or socially significant figure – is there a responsibility to share their uncut story? It also can add context at a time when the stripping of context on social media is, in the words of Charlie Warzel, creating a 'one-dimensional space' for culture.

After the Grant for the Web first call was announced and I started testing Web Monetization, came an 'aha moment'. What if the potential for Web Monetization income could encourage filmmakers to open up more of their assets? More open assets could mean, eventually, better video on Wikimedia and more interesting works using those assets. Perhaps it can even share monetization between orginators and remixers, as Mark Boas has discussed with Hyperaudio.

Over two GftW application processes, the seed of an idea germinated into project MOVA, which I'm really excited to finally getting going on – with a great team and perhaps the most exciting technology – in Web Monetization – I've seen in 21 years thinking about filmmaking on the web. In the coming months I'll dive deeper into what we're building, and the surrounding questions around video rights, discovery, moderation and sustainability, but for now - hello – I'm really looking forward to this journey.

The cutting room floor – open documentary with WM

Nic — Tue, 16 Mar 2021 17:37:35 +0000

Overview

In the days when editors were splicing together celluloid film with tape, they'd throw on the floor anything that didn't 'make the cut'. Billions of hours of footage will have been lost on 'the cutting room floor' – a one hour documentary might have dozens of hours of interviews that are never seen, even tho to a fan, historian, or educator they could be of much interest.

We're exploring how to use Web Monetization to encourage filmmakers to release the unseen video assets that make up a finished documentary. As well as saving and showcasing video that might otherwise be lost, this opens up the potential for other people to re-use and remix bits of these interviews in their own work (if the interviews have a Creative Commons license).

What we're doing

Working with the Hyperaud.io lite library, we've made sites for two recent small catalogues of suitably licensed raw interviews/screenasts we had access to:

Introducing CiviCRM, a documentary about the open source CRM used by 1000s of non-profits around the world (CC-BY-NC): https://screen.is/civicrm
CiviLive, various video from a 2020 virtual event about CiviCRM's use in Covid-19 responses (CC-BY): https://screen.is/civilive

Not all of these videos have been transcribed, but some such as this, this, this and this have been. On those pages you can see the video working with the Hyperaudio library and the transcript so you jump through the video by clicking on words, search the transcript, and share clips of video on Twitter by selecting parts of the text.

We're playing with how this integrates with Web Monetization – for now we're displaying a Thank You notice and download button for those with a subscription (obviously as it's web video, anyone could right-click to download the video regardless). Web Monetization can cover hosting costs, potentially – we could use Hyperaudio with YouTube video, but then have less control over which type of Creative Commons license to attach, and cannot easily add a download link.

People involved / thanks

Nicol Wistreich (visuali.st) - designer
Mark Boas (Hyperaudio - transcript help and ideas bouncing
Silvia Schmidt (kalenea) - legal advice on rewording release forms for Creative Commons, and ideas bouncing
grateful to various people in the CiviCRM community, especially Erik Hommel of CiviCoop who commissioned the original documentary, and everyone in the videos.

Have a film you'd like to share in this way?

Say hello (hello @ screen.is). What we're doing should be easily recreatable on WordPress, Joomla, Drupal or other CMS, while Mark is working on a WordPress plugin. We'd be happy to help anyone share their film footage like this – or collaborate on ways to make this process better.

Similar projects / props

A pioneer in releasing the raw interview assets for documentaries of historical importance is Kunhardt Film Foundation's Interview Archive: https://www.kunhardtfilmfoundation.org/interview-archive
JSTOR Labs created a micro-site for one of these Kunhardt films, HBO's King in the Wilderness. Each interview is accompanied with a transcript, tags, and further metadata, using Wikidata: https://labs.jstor.org/interview/mlk/
When it comes to open video as a subject, inspiration remains from the pioneers from a decade and more ago, many of whom came together at several Open Video Conferences and subsequent MozFests, ie Brett Gaylor, Nina Paley, Ben Moskowitz, Nicholas Reville & Holmes Wilson of the Participatory Culture Foundation and many many more.

Those links again: https://screen.is/civicrm & https://screen.is/civilive.