MOVA — Grant Report #1

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:

1. Create an RSL agreement (using Cascade.js);
2. Approve an agreement by signatories/payees to it (which may be quite limited for now);
3. Generate a hash of the agreement, and a unique wallet and Payment Pointer for that agreement;
4. 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.
5. Handle payments that don't resolve, or take too long to resolve;
6. Track payments (and failed payments) in a reportable way, potentially triggering email or SMS notifications of a payment being made.
7. 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:

• https://openvideo.tech/mova
• https://community.grantfortheweb.com/mova

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:

• openvideo.tech/mova
• International Standard Content Code
• Holochain
• Electron JS