Hollywood's Byzantine Generals Moment: It's Time For A Decentralised Live P2P Movie Streaming Network

Hollywood's Byzantine Generals Moment: It's Time For A Decentralised Live P2P Movie Streaming Network

Amazon recently bought MGM, the last old-school studio in Hollywood. We're now in the laps of Big Tech: the kind of people who describe Friday night at The Pictures as "content". Our future as it currently stands is studios and production companies being commissioned to produce stale, woke garbage for trillion-dollar, ideological gatekeepers - like Apple, Google/YouTube, Netflix, Amazon, Hulu - to use as loss-leaders for their "platforms".

Screens started as theatre projections. Then they became TVs. Now we have smartphones. The cinema has moved into people's pockets; they carry it with them wherever they go. It used to be the cinema in your local town; now the screen is everywhere.

Start Here: Hollywood Is About Who Controls The Process

You lose count of the amount of tech nerds who turn up in Los Angeles with their bright new idea to fix all the dysfunction here. It seems so simple! You can fix this mess with a new web app.

They get the "Hollywood Yes" (i.e. it's a no and they just never get a call back to avoid confrontation) and salivate with eagerness to change the world. Because these people see two thousand hopefuls a week and are highly skilled at ingesting them.

They don't understand the basic premise: it's about who controls the process of film production.

Writers think they control it, because they create the stories; unions think they control it, because they own the writers; agents think they control it, because they control the business networks; producers think they control it, because they find the money; investors think they control it, because they provide the cash; lawyers think they control it, because they write the contracts; directors think they control it, because they make the film; casting directors think they control it, as they gatekeep the actors; stars think they control it, because they bring in the audience; distributors think they control it, as they promote it for exhibition; theatres and streaming networks think they control it, because they do the exhibition;. On, and on, and on.

This is the reason Hollywood is so spectacularly dysfunctional and you can't fix anything. What is in place here is only in existence because it is arranged to gatekeep and bottleneck control over the filmmaking process. Whomever controls the most effective bottleneck runs the game. And there are only two games in town: sex, and money.

There is only one left, and it's genuinely the most powerful one: the Law. Which is why nobody mentions it. More on that another day.

So, before we jump in to Changing the World with Blockchain theory, it's important to understand no-one wants the world changed. Mo-one wants their ability to gatekeep and bottleneck taken away. They don't want more efficiency or effectiveness. They want to be royalty.

Unfortunately, Big Tech companies are now worth trillions of dollars and more powerful than entire countries. And they have a whole new way of control: device app stores. If you want to get something on a device, where the crowd is, you need to get it through the store.

And that's bad, because if you thought Hollywood was communist, just wait until you get a load of these people.

App Store Checkpoints: Scratch A Leftie, Find A Maoist

Hollywood worsened when the maverick studios were taken over by the faceless corporations. Since the fifties, old-schoolers have complained the days of individual risk-taking adventurers have been superseded by bureaucratic studio executives. Before that, the power balance was controlled by influence over the theatre chains.

We're in a totally different world.

Fuck you. Just fuck you.

Big Tech are now the distribution network the theatre chains used to be. Art is subject to the "approval" of fragile Millennial/Zoomer censors in Silicon Valley and sociology graduates admitted to writers' rooms on the basis of their ideological possession matching the quota's groupthink. Put simply, these Gnostic, wannabe communists have bought out the Means of Production. FAANG are the studios' customers now; not the theatre chains, video rental stores, and Walmart.

It's all about the control of these app stores. They are embedded right into the hardware, and monopolise the audience.

Anyone can build an app (.apk file) for Android, as it's an open source OS. But to find it, install it, update it, or even display it, - on a wide scale at least - it has to go through the Google Play Store.

  • To get it on Apple TV or iOS, your film needs to go through Apple.
  • To get it on Fire TV or Amazon Prime, your film needs to go through Amazon.
  • To get it on YouTube or Android, your film needs to go through Google.
  • To get it on Netflix, Hulu , Spotify, Vudu, or any other app, the app has to go through Apple, Amazon, Google, Apple, or Roku, because it runs on their "platforms".
  • Host it by yourself and a) no-one will find it, and b) your bandwidth costs will exceed any revenue.

He who controls the device the movie plays on, makes the rules.

All of these would be fine if Big Tech were actually as objective as a museum curator, a maverick studio pioneer, a theatre chain, or even a cable TV network.

They're not. They've proved themselves over and over to be a complete political menace. If you were to arrange a line-up, these are the least appropriate choice for any situation involving decisions about art.

To be "platformed", art must conform to their worldview. Or, at least, not offend it.

Their "platforms" are virtualised, hyperreal communist dictatorships.

Just take a look at Google and Apple, for a start:

They cannot be trusted. Even Hollywood at its partisan worst is no match for the childish, petulant censoriousness and noxious sanctimony of these soulless creatures. Their ghoulish aspirations are Soviet; their hubris knows no bounds; moreover, they simply do not understand what art is.

Here's a sample from Apple's TOCs, which is ballsy enough to admit it is "highly-curated":

We strongly support all points of view being represented on the App Store, as long as the apps are respectful to users with differing opinions and the quality of the app experience is great. We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it.

This includes "commentary" which is mean; reckless use of weapons; "overtly sexual" imagery; "inflammatory" quotations of religious text, and more.

Google goes even further, to decide the law as it stands needs their own additions to it:

Hate Speech

We don't allow apps that promote violence, or incite hatred against individuals or groups based on race or ethnic origin, religion, disability, age, nationality, veteran status, sexual orientation, gender, gender identity, caste, immigration status, or any other characteristic that is associated with systemic discrimination or marginalization.

Examples of common violations

Content or speech asserting that a protected group is inhuman, inferior or worthy of being hated.

Apps that contain hateful slurs, stereotypes, or theories about a protected group possessing negative characteristics (e.g., malicious, corrupt, evil, etc.), or explicitly or implicitly claims the group is a threat.

Content or speech trying to encourage others to believe that people should be hated or discriminated against because they are a member of a protected group.

Content which promotes hate symbols such as flags, symbols, insignias, paraphernalia or behaviors associated with hate groups.

In other words, entirely distasteful-yet- lawful speech blue-haired Google employees don't like.

This is the equivalent of the theatre manager attempting to tell the movie studio what it may or may not put in the films which will be shown on their screen.

They think James Bond is good "content" from a "back-catalogue" they can make "spin-offs" and "derivatives" from. They even have the arrogance to think they could write a new "woke" franchise of Tolkien's Lord of the Rings.

At its heart, Hollywood is an anarchic, vainglorious, iconoclastic, moral cesspit; a free-for-all meritocracy where the most popular wins. A total chaos of artistic freedom, chasing audience dollars with ridiculous spectacles, lurid headlines of excess, and defiant political savagery. It makes for great art.

Not anymore.

This is Hollywood's fault. It always has been. Since file-sharing piracy emerged, the industry has arrogantly retreated into its own stubbornness and refused to respond to the Internet. It's refused to go outside of its own expertise and trespass into the tech nerds' domain. However, Silicon Valley has been all too happy to trespass into Hollywood and steal their lunch.

We're all paying for it. and subsisting in Leningrad for the foreseeable future.

For Developers: Understanding Filmmakers & Their Reticence

Films are unbelievably expensive to make. They are even harder to fund. A film can take 15 years to write and go thought hundreds of revisions. You don't get to compile your source code over and over, use a debugger, or Ctrl+R on the screen. The nearest you get is making illustrations and maybe, 3D CGI simulations.

On some productions, you could spend $1M/day. And within that, you have 300+ staff to deal with. All to lose everything when you release it and its panned by gatekeeper critics, after the cinema has taken 50% and everyone else has skimmed their own percentage. That doesn't even start with the politics of it.

It's a different art form to software. It's an unbelievably high risk activity: less than 0.1% of scripts written ever get made.

Once it's made, you spend at least 150% of your production budget marketing the movie to create buzz so people go to see it, and that's usually because of who is in it or the spectacle, rather than the story itself. 50% of those people go on the opening weekend. Then you have 50+ different sets of subtitles for those who don't speak English. Film festivals, previews, time windows, star interviews, and advertising materials all play a role.

Small filmmakers often invest their life savings of $10,000 - $250,000. Bands make money mainly through touring (ticket sales, not album sales); filmmakers make money only through licensing their work for exhibition.

Several things are absolutely critical in a movie distribution system of any kind:

  1. Filmmakers need a way to make their money back if they are to persuade the investor to volunteer the money in the first place. Someone has to pay for the camera hire, props, and food.
  2. Filmmakers need to retain control over their own work, even if they give it away for free. Imposters may fraudulently claim they are the author, and illegally re-sell it, for example.
  3. Filmmakers deal with an immensely complex web which needs extra work, because they have a huge amount of people to compensate in the copyright chain. for decades afterwards.
  4. Filmmakers need creative ways to get their work to people who might want to watch it, and generating excitement is difficult because those people are already overwhelmed with choice.

Once your film is out there, the only recourse is the law. Most filmmakers want their film as widely distributed as possible and won't fight you on it. But it comes with a deep terror about that happening.

Design Goals: What Needs To Be Built?

We're trying to achieve certain objectives here, and we need a development ethos to guide how we build. We're aiming to bring the cinema into people's homes.

The basic definition would be:

A global, decentralised, peer-to-peer film distribution network system available to anyone to publish to or stream from, which protects filmmakers and audiences from artistic/political interference and rewards them for their engagement with each other via an intelligent internal market.

The most crucial things to determine are what this product MUST do:

  1. It must evade gatekeeping bottlenecks which can facilitate political censorship: network ISP blocking and device app stores.
  2. It must not be vulnerable to gatekeeper capture or institutional/corporate takeover.
  3. It must solve the centralised streaming bandwidth cost/scaling problem.
  4. It must provide financial rewards and protections for filmmakers.
  5. It must make the filmmaker more money the more widely it is shared.
  6. It must be able to verify the publisher of a film is the legitimate copyright owner.
  7. It must protect children, and deal with abusive publishing and illegal/obscene video content we all agree upon is unacceptable regardless of political affiliation.
  8. It must be immune to deplatforming, boycotting, rigging, brigading, hacktivism, and other Maoist tactics inflicted upon it.
  9. It must not use techniques such as Operant Conditioning or echo chamber confirmation bias algorithms (filter bubbles), to show audiences art only featuring themes they already agree with.
  10. It must not push out badly-produced material and enforce quality control.
  11. It must perform equally to commercial services in resolution, reliability, and speed for viewers.
  12. It must avoid the "too much choice" problem, as suffered by Spotify.
  13. Its source code must be public, so viewers can trust it.

Next, we specify what we prefer by defining what it SHOULD do.

  1. It should assume bad behaviour is the default and not trust any participant.
  2. It should not require any setup by a viewer other than plugging it into an HDMI socket and entering Wifi credentials.
  3. Its UI should be beautiful.
  4. It should not require viewers to be personally identified, mandate account registration, or collect any personal information.
  5. It should only accommodate professional-grade HD video over 15 minutes in length, and not be a user-generated content service like YouTube.
  6. It should not stream from a centralised cloud which requires peering and scaling, but use encrypted peer-to-peer (P2P) distribution.
  7. It should allow anyone to publish a movie.
  8. Duplicate video files should not be published.
  9. It should require a filmmaker to receive payment for viewing their work, and reward peers for providing distribution bandwidth to serve it.
  10. Network consensus should automatically & intelligently set the price of the work, ensuring price rising slows with popularity.
  11. It should be able to perform age restriction.
  12. It should be able to detect and restrict deceitful publishing, spamming, and predatory practices;
  13. It should be able to identify and restrict abusive material which everyone agrees should never be viewed: child pornography, revenge porn, snuff/torture footage, gratuitous non-artistic garbage etc.
  14. It should be able to identify propaganda or score politicised material so audiences are aware of what they are watching.
  15. It should allow a movie publisher to withdraw publication of a film.
  16. It should allow severely abusive actors to be punished or banned, with complete transparency.
  17. It should protect a filmmaker's economic and moral rights during distribution and storage.
  18. It should allow viewers to rate and review films to crowd-source authentic public opinion which cannot be affected by brigading.
  19. A cinema theater should be able to be a network peer.
  20. It should allow re-viewing, replaying, pausing, and other typical player features which would be found on other distribution systems.

Is anyone doing this yet?

Close. Look up MovieCoin, SingularDTV, Cinezen, Vevue, FilmChain, and others. Nearly there, but not much understanding of Hollywood itself, as noted earlier.

It's time for an anti-Hollywood way of doing things.

Blockchain Primer: The Basics

Blockchain is a fashionable term. However, in this case, what we are looking to do is extremely similar to the banking system: we want to remove the gatekeeping and false consensus middlemen. It is a means of decentralising consensus through cryptographic verification. How do you get a group of people who don't trust each other to an agreement?

The Blockchain paper was a response to a question posed by Microsoft's research department, known colloquially as the Byzantine Generals Problem. It was first theorized by the mathematicians Leslie Lamport, Marshall Pease, and Robert Shostak.

We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement. The generals must have an algorithm to guarantee that:

A. All loyal generals decide upon the same plan of action.

The loyal generals will all do what the algorithm says they should, but the traitors may do anything they wish. The algorithm must guarantee condition A regardless of what the traitors do. The loyal generals should not only reach agreement, but should agree upon a reasonable plan. We therefore also want to insure that :

B. A small number of traitors cannot cause the loyal generals to adopt a bad plan.


The answer to this problem is each general must solve a puzzle. The answer provides "Proof of Work" or "Proof of Stake". Transactions made across the network are grouped into an ongoing chain, which forms a "block". That block is stored on a copy of a shared accounting ledger everyone has a copy of.

In this system, the Byzantine Generals Problem is solved by rewarding honest users (known as miners) who solve difficult math problems with powerful computers. Once the correct solution is verified, the miner receives a reward in the blockchain network’s native coin. Miners on the Bitcoin network, for example, receive 6.25 BTC per block (as of the time of this writing). The block is then mined, and the transaction is completed.

This is taken further with stake validation and delegated stakes. Rather than operating millions of dollars worth of energy-consuming computing hardware racing to solve complicated math problems in exchange for freshly-minted currency, nodes on the network post holdings as collateral at risk of forfeiture should they act dishonourably.

Unlike PoW-based networks, PoS-based networks don’t rely upon cryptocurrency mining. Instead, a process known as staking is used. In this system, users (known as validators) stake funds. Validators that stake more of a blockchain’s coins are able to validate more blocks and earn more rewards. Additionally, users who try to validate invalid transactions may lose their staked funds. Users can stake coins with basic home computers rather than needing to have specialized computers required for mining in a PoW-based network.

See Algorand, Cardano, Cosmos, and Tezos.

Blockchain is ever-evolving (see 51% attacks, double-spending etc), but one problem which has become apparent is the network offers zero anonymity by default. If your real-world physical identity can be linked to an anonymous wallet, everything you've done is as public as a postcard.

Solving that is no easy equation, but it's been accomplished in 2016 by Zcash (also forked to Ycash) using its custom ZK-SNARK ("Zero-Knowledge Succinct Non-Interactive Argument of Knowledge") protocol, which encrypts blockchain metadata in a way it can still be mathematically verified. Zero-knowledge-proofs allow one person to prove to another person that they know or have certain information, without revealing what that information is.

The acronym zk-SNARK stands for “Zero-Knowledge Succinct Non-Interactive Argument of Knowledge,” and refers to a proof construction where one can prove possession of certain information, e.g. a secret key, without revealing that information, and without any interaction between the prover and verifier.

“Zero-knowledge” proofs allow one party (the prover) to prove to another (the verifier) that a statement is true, without revealing any information beyond the validity of the statement itself. For example, given the hash of a random number, the prover could convince the verifier that there indeed exists a number with this hash value, without revealing what it is.

In a zero-knowledge “Proof of Knowledge” the prover can convince the verifier not only that the number exists, but that they in fact know such a number – again, without revealing any information about the number.


The current argument is Proof-of-Stake is a better approach over time for security and environmental reasons, with zk-SNARK integrated for privacy against Surveillance Capitalism.

P2P Audio/Video Distribution: The Basics

The oldest form of distribution is to host one copy of a video in a single central place, and send (stream) copies of it to people. If it's in one go, it's a download. If it's progressive, it's a stream. This is extremely expensive: a 1GB file given out to 100,000 viewers is 100TB of data. Most television networks receive tens of millions of viewers per program.

On closed networks, the first solution was to use a system similar to live broadcasting one transmission, which was known as multicast (https://en.wikipedia.org/wiki/IP_multicast). However, not everyone is on the same network (as it requires) and it's impossible to upgrade all networks on the Internet.

Solution two was specialised Content Distribution Networks (CDNs) with direct connections into local ISP offices (known as peering) to reach the viewer via the closest cable length. Providers like Akamai host the video file for you. This is the current  system used by Netflix, Hulu, and everyone else.

The third generation was a collection of software which aimed to let users (network peers) host their own copy of the video file, an serve it to others on your behalf. They began with Napster, and got to Bittorrent's ingenious web streaming (https://github.com/webtorrent/webtorrent).

The most recent incarnation (perhaps best labelled generation 3.5) is the HTML5 Real-Time Communication (RTC) specification (WebRTC: https://webrtc.org/), developed originally by Ericsson in 2011, which is designed to work in web browsers.

WebRTC (Web Real-Time Communication) is a free and open-source project providing web browsers and mobile applications with real-time communication (RTC) via application programming interfaces (APIs). It allows audio and video communication to work inside web pages by allowing direct peer-to-peer communication, eliminating the need to install plugins or download native apps. Supported by Apple, Google, Microsoft, Mozilla, and Opera, WebRTC specifications have been published by the World Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF)



With the other W3C standards queued up, web comms become a very interesting combination:

Special Mention: Popcorn Time & Zeronet

In 2015, a Hungarian developer named Tamas Kocsis published an alpha software written in Python which combined Tor, BitTorrent, and cryptocurrency which aimed to create a network which could never be censored. Using dotBit (.bit) blockchain DNS addresses, entire websites were copied onto users' local computers using Bittorrent downloading. As long as there was one copy in existence, websites become impossible to take down ("It's nowhere because it's everywhere!").

It's already hosting movies.

ZeroNet works in a similar way just like you share torrent files on the BitTorrent P2P network. The difference is that here a website is shared instead of pirated movies and tv shows. A website uploaded on ZeroNet isn’t hosted on a central server but by the users who access it, just like the torrent network in which the data is pulled from the machines which are downloading the torrent. A new user who wants to access the website gets the relevant files from existing users. So, if you’re accessing a website on ZeroNet, you’re simultaneously hosting the website on your machine.


Unfortunately, - as this author pointed out - it allowed child porn to be involuntarily copied onto people's computers just by visiting deceptively-described sites.

Before that, the infamous Popcorn Time sent Hollywood into a terrified panic in 2014 by allowing torrented movies to stream directly to the phone screen with a Netflix-style menu. It was abandoned with days by its Argentinian developer, who were hunted down by the MPAA It later became Time4Popcorn, then Porn Time.

Popcorn Time, the once-popular app that made watching pirated movies and television shows almost as easy as using Netflix, shut down. The app debuted in 2014 and within a year became one of the most popular services for accessing illegal video content. In 2015, Netflix Inc. warned investors about the rise of Popcorn Time in a financial report, and Chief Executive Officer Reed Hastings declared, “Piracy continues to be one of our biggest competitors.”


The theory was simple: streaming movie files using WebTorrent rather than downloading them. It's latest successors - other than torrent sites offering streaming links - are Torrents Time , Couch Potato, and Zona.

It Has To Be Hardware

There's no getting around this. All of the major Hollywood and Big Tech companies control distribution through their app stores pre-installed on devices which can function as cinema screens. It doesn't matter how cool the app you built is if it can only be distributed via an app store which can close you down.

People don't like watching movies on PCs, phones, laptops or tablets. They want to watch movies on their living room or bedroom flatscreen.

  • AMC, Odeon, Cinemark etc obviously all maintain their own infrastructure;
  • Apple controls the publishing of movies through its App Store on iPhones, iPads, Apple TV, and Macs;
  • Google controls the publishing of movies through its Play Store on Android phones, Android tablets, Android TV, Chromecast, and Chromebooks;
  • Amazon controls the publishing of movies through its Prime Store on Fire TV;
  • Microsoft controls software and other content through its App Store on Windows phones and Windows mini-PCs;
  • Roku controls channels and movies through its proprietary channel store;
  • All the other apps are subject to the device's app store.

Asking ordinary people to re-install a Google-free version of Android, format a mini-PC to run Linux, or set up something on a Raspberry Pi is too simply too much.

Progressive web apps are subject to ISP blocking and browser upgrades.

This is the route Gab TV originally took, but it appears that effort has now gone into the YouTube vein: https://tv.gab.com/channel/a/view/gab-tv-monetization-plan-for-creators-60ba711abc800c1c4b815307

Like Chromecast, it has to be a SD card wifi dongle + RC which is plugged into a 4k HDMI socket and costs Grandma less than $20. Preferably drawing power from the TV's USB socket for neatness.

Possibly something in the spirit of the Amlogic range, but smaller if possible:


Choose your chipset/board, and choose your OS. But there's no getting around it. If we want to get around Big Tech blockade, it has to be a new hardware device. And it can't be expensive. It needs to be easy to buy, easy to use, and easy to replace.

Also bear in mind the latest HDMI standard (1.4) includes Ethernet-over-HDMI:

HDMI Ethernet Channel adds high-speed networking to an HDMI link, allowing users to take full advantage of their IP-enabled devices without a separate Ethernet cable; a very important advantage with so many devices now connecting to the internet. This requires the use of the High Speed HDMI Cable with Ethernet.


For a base OS, there's going to be 2 main choices:

  1. A plain Linux distro optimised for TVs: https://linuxtv.org/
  2. Forking Android TV (open source): https://source.android.com/devices/tv

More: https://github.com/vitalets/awesome-smart-tv

However, the OS needs one app, and one app alone, which boots on startup. No confguration, no intervention, no loading. No other apps or interfaces.

It Has To Be Network-Obfuscated

Your IP address is your network location. Most IPs have geo-location attached to them by default, and every ISP knows the accounts and houses the modems accessing its trunk services are linked to.

VPNs are extremely common business tools and difficult to block or inspect. The only really ways are to steal cryptographic certificates (MITM), deep packet inspection, or to straight out block VPN traffic.

Tor - the worst enemy of GCHQ and the NSA - won't work, simply because it's too slow for video and not designed for streaming (it doesn't support UDP) even despite its helpfulness in OS distros like Whonix (https://www.whonix.org/).

Which leaves 2 options:

  1. A user purchasing their own VPN account and providing credentials;
  2. A decentralized (serverless) VPN system.
A VPN reroutes your connection between your ISP and the website through what’s called a secure tunnel. This allegedly secures your connection and, more importantly, changes your IP address to that of the server. However, there are some weaknesses in the way that VPNs work, the biggest one being the VPN itself. While the VPN hides your online behavior from your ISP and the sites that you visit, the VPN operator itself has the technical availability to see everything that you do.

A decentralized VPN—also known as a dVPN, a P2P VPN, or, more rarely, a DPN—gets around this issue by connecting you not to one proprietary server, but rather, to what’s called a “node.” A node could be a server, but could also be somebody’s phone or laptop, or even a desktop computer idling in an office somewhere. The dVPN gets access to these devices by giving their owners credit for the privilege. They can then use this credit to use the network themselves, making the whole thing self-sustaining. To break it down to an elementary level, Peter lets Paula reroute through his smartphone. In return, she can route through his laptop.

Then, of course, there's the issue of DNS leakage. Although the content you access over SSL may be encrypted (e.g. with Perfect Forward Secrecy), the metadata of the request is not.

That problem is solved by DNS Queries over HTTPS (DoH) and DNS Security Extensions (DNSSEC), but it's beyond the scope of this article.

DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it's not DNS queries and responses themselves that are cryptographically signed, but rather DNS data itself is signed by the owner of the data.


Baseline Architecture Summary

To put it into a smaller bitsize, our network system needs to:

  1. Be a cheap custom single-app hardware device for living rooms;
  2. Stack networking on a transparently-automatic serverless dVPN;
  3. Use a Proof-Of-Stake blockchain protocol for transactions, preferably employing ZK-SNARK;
  4. Stream via an encrypted WebRTC P2P video streaming protocol.

What follows is a conceptual high-level overview of what the network needs to do, but from a film distribution perspective.

When we look at the different chains we need, it looks like this:

  1. The dVPN chain for networking;
  2. The publisher/viewer transaction chain for movie/bandwidth payment, playback status, and access contracts;
  3. The content chain for hosting file segments;
  4. The meta chain for:
  • Reputations
  • Attestations
  • Bans / Penalties
  • Revocations
  • Verifications
  • Quality Assurance
  • Age Restriction
  • Network Information
  • Audience Reviews
  • Verifications
  • Meta-moderation (moderating the moderators)
  • Decisions / Appeals / Jury Service

Initial Setup For Grandma

All we should need to do after unpacking our $20 box is tell our device how to get out onto the network. For 95% of people, that's going to be Wifi.

  1. Plug in USB power lead to the TV USB socket.
  2. Plug in the HDMI cable into the HDMI port.

After our sexy UI loads....

We're going to need:

A. An IR/Bluetooth remote control, or
B. A Wifi network to connect to from a laptop, to access a Web interface.

Why do we have a Smartphone-As-TV-Remote problem here? Because the TV remote would need to be a smartphone app installed through the gatekeeper app store. We might get away with a progressive web app here.

In standard fashion, we enter our:

  1. Wifi network SSID
  2. Network username
  3. Network password, and
  4. A 4-digit PIN code for parental control.

At which point, our dVPN needs to connect as an anonymous peer, and security-test our setup to ensure we're not leaking things like real-world IP addresses.

Joining The Network

If there are no network credentials, we need to start fresh. And we'll need a local copy of the networks' ledgers, or to trust someone else who does.

We do not know whether it is a publisher of a movie, or a viewer. We don't care.

Every device who joins the network comprises a node, or peer. Which means we need to automatically allocate it both a private (shielded) address or wallet, and a transparent one. A peer can either be a "full" node (downloads the whole ledger) or a "lightweight" node.

These come in the form of keypairs, which must be stored locally on the device.

  • A film publisher or producer has an address, and
  • A movie has an address (but is not a peer), and
  • A movie consumer or audience viewer has an address.
  • These "types" of user (buyer and seller) are peers. Anyone can be a publisher, and anyone can be a viewer.

These modes are analogous to Bittorrent in some ways: movie viewers are also seeders and leechers in the distribution context.

We need to provide the new network peer the choice of saving the access credentials, or not. If a restoration is required, we need a secure way of reestablishing the keys from some external source.

During this process, we must verify:

  1. We are on the dVPN.
  2. We can reach the different chains to engage in transactions.
  3. We can reach other peers to stream video from them.

We also need to acknowledge bad actors repetitively rejoining the network at this point who need to be identified and rejected.

Publishing A Movie To The Network

Films are different to other digital goods: once they're out there, that's it. We cannot get around the need to do offline copyright verification. We might be able to include this in the meta chain's QA transactions, but for the sake of clarity, let's go through the practical steps which need to be taken.

Why? Because we need to ascertain the person attempting to publish a file (with its assets) actually made it, or has the right to distribute it. This isn't a JPEG or $5000 in a recording studio. It's millions and millions of dollars put into a single file.

A movie = a wallet

Viewers must be able to pay directly to the movie itself as a node participant, and not necessarily its owner. The movie is a network peer, conceptually speaking. Anyone can register a new movie.

Each movie has its own network address, or wallet. Publishing a movie means creating a new wallet.

A producer might have 10,000 different wallets/addresses. One for each of their 10,000 films.

Publisher Authentication

So how do you know a film publisher is the legal owner? This is the hardest part to automate, because it's intrinsically an offline-only situation. You cannot get around this.

Things get really messy here. When people upload someone else's films, litigation and FBI teams get involved. Bad actors need to be stopped in their tracks.

Movies don't have one copyright owner. They have a thousand different copyright agreements which we can't track on a chain. We have to assume that the producer must own this part of the process and put all its legal requirements under their banner.

Let's take an example movie: a documentary by ACME films. ACME creates a new movie wallet (address) on the network. It uploads all the parts of it: the video/audio files, subtitles etc. We are now in a conundrum: we have to be able to verify its claim to be the owner of what it is trying to publish.

This is essentially what happens when a company installs a TLS/SSL certificate. It is only trusted when a third party verifies it, who is, in turn, part of a hierarchical trust chain. SSL certificate verification is a racket, so we want to avoid that.

What could happen here?

  • The publisher could be distributing someone else's material (IP theft);
  • The publisher could be re-registering another address after a previous violation;
  • The publisher could be in a current or future legal dispute;
  • The publisher could be uploading a duplicate copy of the same film;
  • etc etc
How it's done with DKIM

So we need some way of tying the wallet and its file pieces to the real world. Perhaps we could start with their publicly-verified internet domain name, and SSL certificate.

  1. ACME films issues a unique identifier of the film, and a claim of its contents specified as a package manifest.
  2. The claim is published as a DNS record of type TXT, with its content resolvable through its public SSL certificate.
  3. During the publishing process, the application checks the movie package's identification and looks up its embedded claim, which can be found within the owner's official DNS records.

Let's say ACME gives its new movie package the unique identifier 3788f331-46fd-4941-9d37-ec3601f80396. And the address of its the movie on the network (the wallet) is 14qViLJfdGaP4EeHnDyJbEGQysnCpwk3gd .

ACME would then add this record to the DNS for acmefilms.com:

3788f331-46fd-4941-9d37-ec3601f80396.acmefilms.com.   IN   TXT   "14qViLJfdGaP4EeHnDyJbEGQysnCpwk3gd"

What this tells our video client is "the package with ID <uuid> corresponds to the wallet address <movie wallet>. To get the verified owner, use that wallet address for transactions alone and no other".

Someone like MGM might have to create 5,000 DNS records. Not the most practical way to do it. Maybe a URL to a registry would be more effective in build situations.

However, this does not stop someone else from fraudulently adding their own same DNS records to their own domain, claiming to be the owner. For that, the value in the DNS entry needs to be digitally signed. ACME could encrypt and sign the address of the wallet (the TXT record value) with its SSL credentials, if necessary.

The verification could also involve a third-party affirmer, if necessary.

Publishers without verified owners could be prevented from distribution.

It may be a Base64 string of 1000 signed claims for each piece of the package, or an URL of a larger digitally-signed manifest hosted on a web server., in the same vein as a progressive web app.

The TXT would need to be periodically verified, as the domain could be lost or expire - meaning the film itself would need to be placed into a pool of "unknown" packages.

Unpublishing A Movie From The Network

Rights move around. Someone who produces a film might not have the rights to distribute it. Someone might have the right to distribute it in one country, but not another. Or for a certain period of time. These are known as "windows".

What this means is movie publishers need the option for distribution to be time-limited.

Distributor 1 might have a movie from the 50s, which they have published. Then Distributor 2 might want to publish it. At that point, it might well be as easy as transferring credentials for the movie wallet from one company to another, over a glass of  in the office. Distribution needs to be transferable.

But distributor 2 might not want to use P2P distribution and remove the entire thing. Filmmakers are nervous creatures: they want to know they can remove it if they feel like it. They rarely do, but they want to know they can.

Which is where a "self-destruct" needs to exist on artistic material. For comfort. If you're making money, why would you stop?

Distributing The Pieces Of A Movie

Movies aren't one MP4 file. They are a package of things put together, which requires a manifest. In one package, we might have:

  • Multiple bitrate video encoding for different connection speeds
  • Trailers
  • Subtitles
  • 3D/360 spatial data
  • Audio tracks (e.g. narrations)
  • Video tracks (e.g. alternative camera angles)
  • Data tracks (for interaction)
  • Featurettes
  • Deleted clips & extras
  • Digital information packs

For more info: https://raindance.org/10-film-distribution-essentials/

Now, here's the rub. Downloading all these as part of a transaction so each peer has a full, permanent copy is a bad, bad idea.

So we need to split either the package, or the movie file(s), into small signed & encrypted chunks held by different peers. No one peer can have the full thing stored locally. Just like Bittorrent, but the process can never complete or allow someone to re-composite the movie locally to re-publish for themselves.

Sorry nerds, but if you want to get filmmakers on board, that's the least of it.

BitTorrent creates a folder on the local computer, like a file sync, with a final checksum hash. Probably not the best approach. An encapsulated format like .iso or such might be better.

Think of how HTTP Live Streaming works, and imagine as it streaming 5 chunks at a time from different peers, as a leecher. You can queue a chain of chunks to verify and decrypt them, but the movie needs to be re-composited from a big list of different "suppliers" across the network who are compensated for their bandwidth.

Video streaming via HLS works by chopping an MP4 video stream into short, ~10-second video chunks. Streams are described using M3U8 playlists that are created by the HTTP server. This playlist also called a manifest file, indexes the video chunks.


Once a publisher has submitted their package and manifest, it will need to be chopped up and encrypted/signed - for splitting up and spreading the pieces randomly across the whole network.

So'we at ingest, going to need an on-board video encoder, like FFMPEG. Not to re-compress the files, but to slice them at keyframes and apply the container properly for a checksum to be calculated.

If you were to do this manually for 15-second chunks for recombining into a transport stream (.ts), it would look like this:

ffmpeg -i /path/to/myfilm.mp4 -c copy -map 0 -f segment -segment_time 15 -reset_timestamps 1 -segment_format_options movflags=+faststart slice_%03d.mp4

### Output

At any one time, any node may have hundreds of  bittorrent-style seeder chunks stored locally to provide to other peers on demand. Each time a peer "agrees" to stream them at a code of its own bandwidth, it must provide the consumer with a fresh cryptographically signed, one-time encrypted payload.

Note: Setting up each node as an HLS server to do this automatically (e.g. Nginx using RTSP/RTMP/HLS) isn't going to be viable here, because we're back to the same problem: each peer would need a full copy of the file.

Verifying/Preparing A Movie For Circulation

Movies aren't made equal. And the people who distribute them aren't, either. The problems which infect pirate networks are generally solved by scoring, comments, or gatekeeping. We have a problem though: we're trying to get rid of gatekeeping.

If a new movie is published to the network and attached to a wallet/address, where anyone can publish, it could be:

  • Obscene (semi-legal) pornography
  • Child pornography
  • Terrorism footage or obscene gore (e.g. torture, snuff)
  • Spam (looping nonsense)
  • Someone else's movie
  • Overt propaganda
  • The same movie published somewhere else
  • Mislabeled (have a different name to its actual content)
  • Stolen material
  • Extremely poor quality (360k)

There's a critical need for quality control which presents an enormous problem. Nobody likes censorship, but nobody wants child porn. The first is legal speech, the latter isn't.

It also creates a dDos problem. The network could be flooded with junk, causing a bottleneck in integrity/verification consensus.

Useless social media companies who employ AI and snowflake milennials to deal with this name it something practiced by "moderators", when they are better classified as "censors". Removing child porn from the network to keep it healthy is not censorship. It is garbage disposal.

The part the Silicon Valley idiots haven't figured out yet - because they're censorious political apparatchiks - is people need to be able to see what has been thrown in the trash, and why.

Therefore, removal from the network needs to function conceptually like a "recycle bin" which can be inspected, with reasons attached which are clear. And conversely, queued verification needs to operate as visible, transparent triage.

Integrity Checkpoints

  1. Is this film what it claims to be?
  2. Has this film been published already?
  3. Is the publisher who they claim to be, and do they have the legal right to distribute it?
  4. Does it contain everything it needs to and pass the basic rules (e.g. HD resolution over 15 minutes with subtitles etc)?
  5. Should the movie be restricted from children?

And importantly, is this group of verifiers adjudicating this movie a maliciously censorious force acting out of partisan intent?

These must be objective attestations and not involve the content of the film. The publisher must also be able to appeal.

The Digital Jury Validation/Appeal System

As proposed by Twitter, and implemented by Minds, when a film is published to the network, a pseudo-randomly selected "jury" of 100 "verifiers" inspects the new payload to QA it.

Initially, the Jury System will be used for appeals on moderation decisions. Every time a post is moderated (such as being marked as NSFW or spam), the user will be properly notified of the specific action and provided with the ability to appeal to give additional context as to why the decision should be changed. The appeal will then be randomly sent to 12 unique active users on the site who are not subscribed to the reported channel. These users will be given the choice to participate, pass, or opt-out of all future jury events. If a user passes or opts-out, another random user will be notified until 12 unique channels have joined the jury and voted on the appeal.


There's an obvious parallel with the Proof-of-Stake idea of "validators" here.

Summarising, for film:

  • The reviewers' responses (scores,, attestations)  enter the network as transactions. If a consensus of 80% is reached, the film is "activated" for streaming to anyone else.
  • Verifiers receive a reward (earlier access, currency etc), and are scored for reputation.
  • A further meta-check of verifiers themselves is another process which could provide reward.

Again, we have a gatekeeping issue here. Theoretically, 90 of those 100 reviewers could conspire together to prevent the distribution of a film with politics they didn't like. There must be review of verification processes by the network, on a periodic basis.

Asset-Push Seeding + Super-Node Distributors

So, now assuming a movie package has passes its verification checks, been given a wallet/address, and is ready to stream, we hit the old problem: scale.

Imagine there is a small filmmaker, ACME Films, Inc, who creates a documentary for $50,000. It has to be published from somewhere and becomes extremely, ridiculously popular - maybe requests for 20 million streams. That small filmmaker can't serve 20 million streams.  It probably can't serve 20, reliably.

They need help. A lot of it.

We have to put the files somewhere: on a laptop, a server, or a CDN. And we need to chop it up into uniform slices and blocks, specified on a manifest.

This problem has been described as "decentralised content delivery", for example the Marlin Protocol, at Stanford: https://stanford.edu/~joshp007/Marlin_Pro_deck.pdf and CacheCash at Columbia: https://ghadaalmashaqbeh.github.io/slides/cachecash-thesis-defense.pdf

Perhaps the most established is MediaNetwork, which is a proof-of-stake system with "guards".

Anyone can set up new Media Edges and serve content without introducing trust assumptions or pre-authentication requirements. These participants earn MEDIA rewards for their bandwidth contributions. The protocol utilizes new mechanisms to encourage honest and collaborative work between network participants.


Which is great, but it doesn't reward the filmmaker. And the assets being distributed aren't free to the end user.

Our publisher needs to "broadcast" their package out onto the network, to an initial number of "hosts" or nodes who can be the first "beta" seeders of parts of the files, the same as Bittorrent.

The key here is instant playback speed. Less than 400ms for segment A, or the Boot Segment. Which might appear after the interstitial loader, or an preload advert.

Let's say the film is 110 minutes, for simplicity. We chop up 110 video slices, which we bundle into groups of 10. So that's 11 "blocks" of video slices. We might need to "seed" the network with at least 100 peers. That will require 500 nodes: each with at least 50mins - 5 different sets of slices - stored locally.

These "super nodes" can bid or offer to host the initial video/package chunks for a reward. Over a limited timeframe.

Each time they receive a request for a slice and are to be paid for it, they encrypt/sign a copy with the end user's public key and become an RTC peer. When that peer completes delivery, it then becomes a peer in turn. Almost like a virus, you could say.

To fortify this, you could of course have a master CDN of "root" nodes which host ALL films published to the network, ensuring high quality delivery.

However, it's key for the network to manage supply. A film must be able to be limited to X simultaneous streams or Y streams/day to avoid traffic blockages. The network must know how many copies are available from how many peers, and know not to process transactions for streams it can't provide reliably. This is wildly different to Bittorrent or CDNs, where you take your chances.

This is, of course, one of the core reasons for using the "elastic" capability of Kubernetes:

How Kube does it

Just as we use dynamic pricing, the network needs dynamic provisioning/availability. If one node can serve out 5 different chunks of 10mins each at once to 5 different peers (and also may be streaming inbound), and 10 nodes are required for the full 110mins of film (assuming one node only holds one individual time slice of video, which it may not),, we're looking at a minimum of 250 network nodes for a small-ish setup. That said, calculating network availability is within reach.

Dynamic provisioning leads to scheduling and queueing, which isn't necessarily a bad thing in terms of increasing anticipation for a new or popular release.

Choosing a Movie To Watch

Netflix works because it's beautiful. Popcorn Time was so threatening because it was so friendly to the ordinary person. Most UIs built by nerds are for nerds who understand them.

Clever "sci-fi" graphics which enhance the feeling of depth are extremely powerful. A great example is Pluto TV's loading/buffering animation. These can be downloaded in the background or loaded onto the device.

TV navigation isn't web navigation. Technically it is known as Spatial Navigation or Directional Navigation.  Norigin explains it well:

To interact with the elements on the screen we have to move the focus (navigate to) the element and press a selection button (OK button, Enter button etc.) when the element is focused. There should be only one focused element on the screen. As developers we have to implement the logic for this type of navigation ourselves, as there is no default implementation. At least not on the Web platforms. The complexity of this feature is often underestimated and it can be quite challenging in certain scenarios. There is always a risk of introducing bugs like having more than one focused element on the screen or losing focus completely. It requires you to have a strict and robust state management system to keep track of what is focused on the screen and how to transfer the focus when transitioning between screens or modal elements.


More: https://github.com/vitalets/awesome-smart-tv#navigation-libraries

Assuming we've come up with a fantastically smooth, fast, and easy way to get around, we need to look a the problems of the existing platforms.

  1. Too much clutter. There's just too much on screen and the information (genres, voice control, stats etc) is overwhelming. "Infinite scroll" is a disaster.
  2. Political engineering. Prioritizing films with a favoured worldview you "should" watch, over others. Silly "equity" games.
  3. Too much like a website or laptop. Prime is a serious offender here, with navigation bars and search boxes.
  4. Too little choice. Nothing to watch. Shit films with no information.
  5. Crappy suggestions. Algorithmic personalisation filter bubbles and "mothering" you into what to watch.
  6. Ever-changing libraries. It was there before, but now it's not.
  7. Clunky buffering. The audience will wait two seconds before they decide the stream has failed. They won't tolerate it happening more than twice.

A few things become apparent.

1. Strip it down bare to keep it simple.

We don't need 10,000 titles. We don't need personalisation. We don't need 100,000 micro-genres. We don't need 35 sorting options. And we definitely don't need f**king voice control.

People watch films because:

  1. They already know and like the actor(s) in them;
  2. Someone recommended one;
  3. They're searching out something they've heard about somewhere else;
  4. They're playing roulette.

Most of the time they know what they want. And it's not something with a description which starts with "One woman's journey....".

20 options is too much.

2. Audiences like schedules

TV is familiar. We switch on a channel and are already told what is playing or has been arranged for us. We don't need 15,000 machine-learning calculations to create hyper-personalised lists generated from what we've watched before.

We like to come back and spin the roulette wheel. As grotesque as Operant Conditioning (variable rewards) is, we want to pull the lever. And we don't mind as long as we know we're playing, and are in control.

So perhaps we have a new selection every day. Which is only available that day, and even maybe only at  a certain time.

3. We filter by rejecting what we don't like

Our brains only have so much RAM. What you're doing when browsing huge libraries is discounting and disregarding 99% to find the 1%.

Sadly, Silicon Valley's stupid idea we should all be "open-minded" also applies to our menus. Humans don't work like idiots in Palo Alto. We have lives. We don't have all day to pay $30.00 for adult-child superhero movies.

We're close-minded about what we watch. It's more important for us to exclude information. We're hunter-gatherers whose brains are wired for seeing the snake hidden within a million blades of grass.

4. The Hivemind beats professional political snobs

Every single time, the critic rating is inverse to the audience rating. You are more likely to see something because a friend you trust said to, over a champagne-drinking, pompous graduate snob "analysed" it in The Guardian. Critics are paid off by industry people to promote studio garbage.

Critics and reviewers are gatekeepers, like the app stores. Reviews are entirely subjective.

The hivemind is better. But how does the network create a market?

Given the chance, publishers will rig their own product and damage competitors' products. And given the chance, political activists will attempt to downvote the products of those they don't like.

We need reviewers who have seen the movie. And those scores must not be trusted, and have to be across different domains (story, cinematrography, sountrack etc).

Then, we need meta-functionality: reviewers of the reviews on the ledger, to detect patterns and identify bad actors.

We pay higher for things which:

A. Are new or exclusive.
B. Are perceived by others to be of high value.

A higher market value, or movie price, can be set by transparent/open averaging of a movie's scores across different lines (see reviewing, later). The two can correlate: the best films are those which audiences have rated highly across different areas, and command the highest prices.

Maybe the first thing we see is 10 new films which need to be quality-assured, for a reward of being able to watch our next 3 movies free.

5. Our movie choices are superficial

The cover image looks good. We know the actor. The name is stupid. We've seen it before. It's too long. It looks "woke". We're apt to judge a film by its cover.

The descriptions given on video platforms are appalling. 50% of retention could be fixed by removing the sociology graduates who are employed to fill out film descriptions, and replacing them with people who can write.

6. We like being in the exclusive club

There's no way of getting around this. Exclusive or time-limited deals are proven drivers of sales. We'r'e attracted to us getting something others don't have, or something we will only have access to for a short time.

7. AI suggestions of "similar to what you've watched before" are garbage

Art isn't supposed to confirm your pre-existing bias or keep you comfy. It's supposed to surprise and confront you. Watching the same thing over and over is depressing, and it's abused relentlessly by propagandists who want to use repetition for conditioning viewers.

It's important you watch what you haven't seen or don't agree with.

Back to traditional cinema theatre: push-schedule a roulette wheel of only 20 different movies a night, ranked by the market, or let peers playlist suggestions

There are many ideas here, but loyalty/familiarity is as important as discovery. This is entertainment: audiences don't want to work. What we can deduce is:

  1. Limited choice is cognitively easier than huge libraries.
  2. Schedules build anticipation and excitement (i.e. less work).
  3. Keeping the things we really don't like away makes choosing easier.
  4. Aggregate review scoring from audiences across domains is the most accurate predictor.
  5. Quality is better than quantity, and it needs time, which needs less volume.
  6. Exclusive and one-time-only are better than whenever/always.
  7. Art and computation are opposites.

Paying For The Movie

Filmmaking needs to be a profitable activity. Even more so, if it now becomes a more freely-open profession where distribution can be guaranteed.

The first question is how the price is set, and the answer has to be open and transparent algorithmic (dynamic pricing) methodology. Allowed to be arbitrary, filmmakers will simply rig the market or set unrealistic/deceptive pricing. For example, to garner more views, the price might be set at 0.02. Or for "arthouse" work, it might be set at 300.00.

One guideline is scale: the more popular the movie, the more peers it will require to stream smoothly. Which means any dividend reward for streaming to a peer will need to be shared more widely and experience diminishing returns. For example, a popular film with 100 viewers might need 50 peers in total. Priced at 10.00, 3.00 (30%) of reward already stretches to a reward of 0.06/peer. Priced at 20.00, it rises to 0.12/peer.

Dynamic pricing algorithms can take into account previous historical trends, publisher requests, peer availability, and many other factors. The subject is enormously complex, but can be studied extensively in the ML literature:

Dynamic pricing algorithms help to increase the quality of pricing decisions in e-commerce environments by leveraging the ability to change prices frequently and collect the feedback data in real time. These capabilities enable a company to respond to demand changes more efficiently, reduce forecasting errors, and automate price management for catalogs with hundreds of millions of items.


The network needs to make an open, transparent decision, based on the demand and supply of the movie, which will reasonably compensate the filmmaker and not gouge the viewer for what they are requesting. And receive feedback from peers on mistakes it can use to make corrections, without suffering the abuse of brigading.

Now, also, bear in mind dynamic pricing has been a disaster for Uber. Why? Perceptions of price-gouging, opaque algorithmic nonsense, and being a faceless monolith. Businesses are human. They are not automated well. The customers are human and the vendors are human. Many times, the vendor wants to go against something an algorithm might suggest.

Conceptually, we can achieve a fairly simple cryptocurrency input/output exchange here with not much trouble.

  1. 70% of the price for the movie goes to the movie wallet (i.e. the publisher)
  2. 30% of the price is divided between the network peers who provide the video chunks and bandwidth to serve it.

Now, how's that's enforced is a different matter, and subject to the level of potential abuse - a peer who fails to provide what is requested is hard to inflict a penalty on. The full 100% might be given to the movie wallet in advance, who allocates 30% to random "seeders" to provide the video peers. Or, perhaps, they only receive a partial fee (50%) until they provide the peers and license in exchange.

The keys here are a) viewers pay directly into the wallet/address for the movie, and not to any form of middleman or gatekeeper. The film publisher receives funds directly. And naturally, b) peers should receive a reward for providing streaming bandwidth.

The more you provide assistance to other viewers, the more currency you can earn to purchase movies. In this context, streaming can be seen as analogous to mining.

Another question here is the longevity of your purchase, and the complex issue of double-spending. As crypto transactions are final and immutable, are you:

  • Paying to watch once (like the cinema or rental)
  • Paying for 3 re-watches over a set time period (loyalty style)
  • Buying access permanently (like a DVD)
  • Being given the option by the publisher from all 3?

Price setting needs to be competitive:

  • Do you charge more for a new movie for exclusive access, or less to motivate people to watch it for less risk cost?
  • Do you charge more to enhance the perception it is worth more in value?
  • Do you provide special offer or free access?
  • Do recommenders or sharers earn a reward in the form of discounted forward prices?

The transaction should be private. No-one else needs to know what we're watching.

Playing The Movie

Once we have completed our transaction, - or perhaps during it - we need to receive an immediate list of peers to connect to, in order to begin the stream. We have paid the movie wallet for the right to watch it, and paid for peers to stream it to us over our bandwidth. This process needs to work lightspeed fast.

Critical: downloading of the first 1-33 mins of video and keyframe thumbnails must start as soon as the transaction is initialised, NOT afterwards. It enables playback to begin instantly once the transaction is finalised. If it fails, 2mins of a movie aren't a big deal.

Yes, so far, this sounds like Bittorrent/Webtorrent, but there's some important differences. The first is payment, but second, namely, the download is always designed to be incomplete.

Also, the need for a PIN code to restrict content the network says is R/18.

We will receive a sequence of one-use chunks of video, which are provided to us encrypted by the peers using our public key (or some other secret embedded within the transaction).We are not permitted to re-composite the entire video file, but we are now a network peer hosting several of those chunks for others - which we will encrypt for them with their key, and receive revenue for serving up.

Supposed we have a 110min movie, split into 110 slices of 1 min sections of video. As we know, it's not as simple as that, at all: subtitles, multi-bitrate etc. 10 peers might offer or be sequestered to provide 10 slices each. Receiving sections makes you a new peer, who can be a distributor, for reward.

Technically speaking, we will probably be establishing a RTCPeerConnection using RTCDataChannel from WebRTC.

Why WebRTC? Because it's easier to use an open source, standardised protocol with a wide variety of uses than create your own which you have to maintain.

Peer connections is the part of the WebRTC specifications that deals with connecting two applications on different computers to communicate using a peer-to-peer protocol. The communication between peers can be video, audio or arbitrary binary data (for clients supporting the RTCDataChannel API). In order to discover how two peers can connect, both clients need to provide an ICE (Internet Connectivity Establishment) Server configuration. This is either a STUN (Session Traversal Utilities for NAT) or a TURN (Traversal Using Relay NAT) server, and their role is to provide ICE candidates to each client which is then transferred to the remote peer. This transferring of ICE candidates is commonly called signaling.


A protocol solving this problem in a similar, roundabout way is PeerConnect: https://medium.com/@peerconnect18/introducing-peerconnect-js-272b3f8d11eb

The technicalities here are lengthy (see: https://github.com/kgryte/awesome-peer-to-peer), so we'll focus just on the movie side of it.

  1. ICE, STUN, and TURN are centralized servers. Bad news. Super nodes need to function as decentralised/distributed ICE signalling servers (see: https://github.com/dwrtc/dwrtc or http://www.thinkmind.org/articles/web_2017_1_30_40029.pdf)
  2. The network needs to store play, pause, and replay information. A viewer who has purchased a movie has the right to pause, stop, and come back tomorrow to restart it with a fresh network connection.
  3. The files served need to adapt to network connections. An 8K movie is not going to function well over a 200k home cable network which is clogged at 5PM.

There's a security concern here, of course. Peers with knowledge of each others' video chunks could conspire to re-composite the whole video file together. But what's the point, if you could just screen-record after paying a trivial purchase fee?

Reviewing/Rating The Movie

Reviews are crucial to films. They are a crowd-sourced mechanism of quality control. The trouble is they are generalised and subjective. What we are attempting to do is reach an objective score on something which is entirely subjective, based on the Appeal to Majority fallacy (https://en.wikipedia.org/wiki/Argumentum_ad_populum).

For example, IMDB's Bayesian average rating works like so:

weighted rating (WR)=(v/(v+m))R+(m/(v+m))C

R = average for the movie (mean) = (Rating)
v = number of votes for the movie = (votes)
m = minimum votes required to be listed in the Top 50 (currently 1000)
C = the mean vote across the whole report (currently 6.8)

Or as it's described on Math Exchange:

The formula is just a weighted average of the "naive-individual" rating for this movie (item) and a (sort of) "a priori-noncommittal" rating. The idea is that, if you have very few votes for your particular movie, you don't put much trust on it, and lean instead towards a conservative estimate, the "a priori" noncommittal rating: for example, the average rating across your entire universe. When the number of votes for your particular movie gets bigger, you trust that individual rating more.


There are certain die-hard rules in this abuse-ridden part of filmmaking:

  • Firstly, only those who definitely have seen the movie must be able to rate or review it.
  • Secondly, it must cost the reviewer to submit scoring, to prevent brigading and rigging.
  • Thirdly, those who invest time in providing an honest review/rating which is verified, need to be rewarded for it.

What we can do is split the various qualitative characteristics of the moving into individual ratings, with reasons for the rating itself:

  • Writing/Story (cliched, mediocre, intellectual, original etc) + overall (0 - 5)
  • Cinematography (dull, exciting, shaky, beautiful) + overall (0 - 5)
  • Acting performance (wooden, unremarkable, acceptable, moving, profound)
  • etc etc

Once reviews have been submitted immediately at the credits (not at the end of the video file), reviews need to be verified by the network as transactions with the reviewer earning a reputation score for objectivity weighting their contribution as higher than those without one.

Vexatious and political reviewers are enormously problematic.

This might seem overkill, but this tedious part of the distribution process is the means by which audiences make their choice of whether to watch or not. Better reviews mean more revenue and reputation.

In the real world, thee are the problems being solved:

  1. Journalist reviewers are simply bribed for good reviews.
  2. Academy and association members are simply bribed for nominations (awards are essentially bought).
  3. Activist journalists deliberately ignore or well-poison films they politically disagree with, and elevate those they like.
  4. Editors "adjust" overall scores (algorithmically or otherwise) for the same reasons.
  5. Vote brigaders and botnets viciously spam review sites to rig things in their favour.
  6. Competitive or resentful filmmaker competitors do the same, just to injure their partisan enemies.

As reviews are so critical to a movie's success, they must be verified and adjudicated as a block of transactions would be.

The Implications Are Severe & Exciting

This is no easy feat. Combining blockchains, ensuring bandwidth, dealing with fraud/abuse, and bringing all the pieces together is not trivial. But it's possible.

  • Blockchain theory gives us a way to do decision-making and provisioning without centralised power-brokers who can stifle the market for everyone else through gatekeeping.
  • Cheap hardware allows us to bypass Big Tech censors.
  • Network sharing/bouncing allows us to bypass upstream ISP censors (AT&T, for example, owns Warner Bros).
  • Open Source technology allows us to avoid the opportunity cost of having to develop our own base code.
  • Dynamically-provisioned peer-to-peer (P2P) distribution gives us a way to scale distribution asymmetrically to cost.
  • The open DNS system allows us to link files to real-world copyright holders.
  • Dynamically-suggested pricing allows us to build a network-powered electronic market;
  • Conscientious planning allows us to prepare to deal with abuse effectively.

If indie filmmakers have a ready-made global distribution market they can publish to without any cost, the game completely changes. The playing field is level again.

If studios and other political actors aren't able to stifle the reach of legal speech and expression, the game completely changes. The people are in charge again.

If cinema is nowhere, - because it's everywhere - Hollywood's game is lights,  cameras, and stars again.

The result is a vibrant market of art, freely available to anyone to enjoy. Opportunity for all to participate and rise without partiality or favour. Which can't be easily attacked or switched off.

It would be attacked, resisted, derailed, discredited, and poisoned at every turn. Because if you got it right....