The Interledger Foundation Community

Cover image for Monetizing Open Video Assets — Grant Report Final
Nic for MOVA

Posted on • Updated on

Monetizing Open Video Assets — Grant Report Final

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.

the mova app generating an ISCC code

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.

Screengrab of mova app, publish your claim

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.

screengrab of the mova app third-party certification screen

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.

Screengrab of CiviSplit Agreement Builder - build mode using Cascade

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.

Screengrab of CiviSplit Agreement Builder/Processor report view

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.

Screengrab of screen.is archive of interview assets

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.

Screengrab of open.movie Peertube instance for creative commons videos

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

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)

And also:

Discussion (0)