This issue proposes a high level architecture for simply combining Ethereum-blockchain-based server-side software from Livepeer and Orchid Technology to create a Livestreaming Nano-royalties Server, to be run as part of web3.
The specific objective is to connect Livepeer, Orchid and Ethereum, to create a server-based mechanism to allow livestream video content, being served by a Livepeer Broadcaster, to be paid-for by the Consumer of the livestream, by the byte, in real-time, using Orchid Protocol, settled via Ethereum.
This mechanism would allow owners of livestream media rights to publish their content live, and to be paid nano-royalties by consumers of the live content. Nano-royalties would be paid in real-time, per-byte of livestream media data consumed.
The broader objective is to create a real-world use-case which if adopted, would result in an increased flow of capital through Orchid Protocol, Livepeer Protocol and Ethereum. As a starting point, this would be used as a use-case to demonstrate the power of the infrastructure being created within this ecosystem.
Further evolution from this simple combination is discussed in the appendices below.
Component Functionality
Here we give a high level overview of the functionality of the software being used.
The proposal is to create an easily deployable architecture, by combining these two independent software systems and simplifying, in order to achieve the desired objective:
The architecture is the same as for Orchid described above, but with the one difference that Orchid only forwards requests to the co-located Livepeer Broadcaster, instead of to the www.
Using these building blocks, this approach can provide a way to exchange value per the objective of this issue.
Further, it would be able to do this by using existing software configured in specific ways, thus would have minimal support overhead.
This issue can be closed when there exists a set of detailed step-by-step Build and Configuration Instructions for a server-based system as defined in the High Level Architecture, in order to achieve the objective stated in the introduction.
Livepeer software is open-source and well-documented. Orchid software is open-source, and code is available with comments, and some preliminary documentation.
The instructions should consider using docker as a way to easily launch such services in containers. Alternatively, it can also be run as a set of systemd services on Linux, with an appropriate set of individual configuration parameters and files.
Appendices
1. It might be wrong
It is acknowledged by the author that it may be impossible to achieve the objective using the architecture proposed, and in this case, a revised and improved High Level Architecture may be submitted in order to close this issue.
2. Livepeer Open-Source Video Infrastructure Software
The Livepeer Broadcaster is only one part of the capability of the Livepeer open-source video infrastructure software, and Livepeer Protocol, on Ethereum.
Primarily, there also exists a real-time video Transcoding functionality. Transcoding is the act of "re-sizing" the video content, in order to make it more accessible. For example, re-sizing a 4K (3840x2160) video stream to 144p (256x144 pixels) makes it easier to a) stream across the internet for watching (especially on poor connections), b) consume on more devices, perhaps with less power, or with smaller screen size.
Transcoding can either be run locally, per the instructions in simple-streaming-server, or can be offloaded to Livepeer's Public Transcoding network, and paid using Livepeer's Probabilistic Micropayments Protocol, on Ethereum.
3. Incorporating Transcoding
Incorporating transcoding allows the content to become highly accessible, and allows it to reach as many humans as possible.
Further, it would allow consumers receiving a 144p encoding to pay substantially less than consumers receiving a 4K encoding - which would seem like a fair model on first inspection.
A further evolution of the architecture described in the scope of this issue would be to connect the Livepeer Broadcaster to Livepeer's Public Transcoding network. After all, if the Broadcaster has an initial revenue stream in OXT, it can make sense for them to swap to ETH and pay for Transcoding fees to make their content HIGHLY ACCESSIBLE.
Further, it makes for an elegant way to meter and charge for video content, instead of needing to charge different amounts for different renditions "by the second", it automatically takes into account the cost by more closely charging "per-pixel" (proxied by "per-byte").
4. Key Sharing
An obvious refinement to then make is to have the Server in the architecture use the same Ethereum key for Livepeer and Orchid.
This would make things operationally much easier for anyone operating the server, and would also allow a shared pool for gas-like fees, and also swapping between OXT, ETH, and potentially even LPT in order to fund operations.
5. Protocol-level Integration
Further considering could be given to the benefits of creating a protocol-level integration to automate the handling of functions such as:
Maintaining an appropriate balance of OXT, ETH, LPT with swaps via an AMM, and operator-configured parameters for weighting the basket attached to the Server.
Abstracting the OXT / ETH / LPT from both the Consumer and the Server operator, allowing inputs and outputs to all be made in a stablecoin, such as DAI.
6. Something for the Publishers (the artists!)
This issue talks extensively about a mechanism for a Consumer to pay an Operator of Broadcasting Payment Infrastructure, for the content being served by that broadcasting payment infrastructure.
However, it does not touch on where this livestream content would come from, and what the incentive would be for Publishers to share their creativity and artwork for the delight of the Consumers!
So, a further rudimentary optimisation would be to provide a way for the Consumer to pay BOTH the Operator of Broadcasting Payment Infrastructure AND whoever is publishing livestream content into the infrastructure (the Publisher). This way, there is the opportunity to create a mechanism to incentivise the Operator of Broadcasting Infrastructure and the Publisher to collaborate, much in similar ways that Musicians and Promoters / Distributors have worked in the past... only digitally-only, and faster and in real-time.
But that's a topic for further debate.
7. Public Network
So, there already exists a public network of Transcoders, and a public network of Privacy Nodes... but if this can work, it can be integrated into an independent public network of Broadcasters, with potential for inflation funding to subsidise the bootstrapping of nodes onto the network, before they begin to receive fees for content.
If such a network of Broadcasters existed, it would provide multiple endpoints for client apps to connect to in order to consume and publish live video content. Further, it would drive new capital flows through Livepeer, Orchid and Ethereum.
Introduction
This issue proposes a high level architecture for simply combining Ethereum-blockchain-based server-side software from Livepeer and Orchid Technology to create a Livestreaming Nano-royalties Server, to be run as part of web3.
The specific objective is to connect Livepeer, Orchid and Ethereum, to create a server-based mechanism to allow livestream video content, being served by a Livepeer Broadcaster, to be paid-for by the Consumer of the livestream, by the byte, in real-time, using Orchid Protocol, settled via Ethereum.
This mechanism would allow owners of livestream media rights to publish their content live, and to be paid nano-royalties by consumers of the live content. Nano-royalties would be paid in real-time, per-byte of livestream media data consumed.
The broader objective is to create a real-world use-case which if adopted, would result in an increased flow of capital through Orchid Protocol, Livepeer Protocol and Ethereum. As a starting point, this would be used as a use-case to demonstrate the power of the infrastructure being created within this ecosystem.
Further evolution from this simple combination is discussed in the appendices below.
Component Functionality
Here we give a high level overview of the functionality of the software being used.
Livepeer Broadcaster (and videoDAC Livestream Consumer App)
At a very rudimentary level, Livepeer's Broadcaster software works like this (when used with videoDAC Livestream Consumer App):
Source for this software is available at:
livepeerpre-compiled binaries.simple-streaming-server- simple instructions on how to use Livepeer Broadcaster, and other features of Livepeer open-source video infrastructure.Orchid "Exit Node" Overview
At a very rudimentary level, Orchid's VPN software works like this:
Source for this software is available at:
High Level Architecture
The proposal is to create an easily deployable architecture, by combining these two independent software systems and simplifying, in order to achieve the desired objective:
The architecture is the same as for Orchid described above, but with the one difference that Orchid only forwards requests to the co-located Livepeer Broadcaster, instead of to the www.
Using these building blocks, this approach can provide a way to exchange value per the objective of this issue.
Further, it would be able to do this by using existing software configured in specific ways, thus would have minimal support overhead.
Build and Configuration Instructions
This issue can be closed when there exists a set of detailed step-by-step Build and Configuration Instructions for a server-based system as defined in the High Level Architecture, in order to achieve the objective stated in the introduction.
Livepeer software is open-source and well-documented. Orchid software is open-source, and code is available with comments, and some preliminary documentation.
The instructions should consider using
dockeras a way to easily launch such services in containers. Alternatively, it can also be run as a set ofsystemdservices on Linux, with an appropriate set of individual configuration parameters and files.Appendices
1. It might be wrong
It is acknowledged by the author that it may be impossible to achieve the objective using the architecture proposed, and in this case, a revised and improved High Level Architecture may be submitted in order to close this issue.
2. Livepeer Open-Source Video Infrastructure Software
The Livepeer Broadcaster is only one part of the capability of the Livepeer open-source video infrastructure software, and Livepeer Protocol, on Ethereum.
Primarily, there also exists a real-time video Transcoding functionality. Transcoding is the act of "re-sizing" the video content, in order to make it more accessible. For example, re-sizing a 4K (
3840x2160) video stream to 144p (256x144 pixels) makes it easier to a) stream across the internet for watching (especially on poor connections), b) consume on more devices, perhaps with less power, or with smaller screen size.Transcoding can either be run locally, per the instructions in
simple-streaming-server, or can be offloaded to Livepeer's Public Transcoding network, and paid using Livepeer's Probabilistic Micropayments Protocol, on Ethereum.3. Incorporating Transcoding
Incorporating transcoding allows the content to become highly accessible, and allows it to reach as many humans as possible.
Further, it would allow consumers receiving a 144p encoding to pay substantially less than consumers receiving a 4K encoding - which would seem like a fair model on first inspection.
A further evolution of the architecture described in the scope of this issue would be to connect the Livepeer Broadcaster to Livepeer's Public Transcoding network. After all, if the Broadcaster has an initial revenue stream in OXT, it can make sense for them to swap to ETH and pay for Transcoding fees to make their content HIGHLY ACCESSIBLE.
Further, it makes for an elegant way to meter and charge for video content, instead of needing to charge different amounts for different renditions "by the second", it automatically takes into account the cost by more closely charging "per-pixel" (proxied by "per-byte").
4. Key Sharing
An obvious refinement to then make is to have the Server in the architecture use the same Ethereum key for Livepeer and Orchid.
This would make things operationally much easier for anyone operating the server, and would also allow a shared pool for gas-like fees, and also swapping between OXT, ETH, and potentially even LPT in order to fund operations.
5. Protocol-level Integration
Further considering could be given to the benefits of creating a protocol-level integration to automate the handling of functions such as:
6. Something for the Publishers (the artists!)
This issue talks extensively about a mechanism for a Consumer to pay an Operator of Broadcasting Payment Infrastructure, for the content being served by that broadcasting payment infrastructure.
However, it does not touch on where this livestream content would come from, and what the incentive would be for Publishers to share their creativity and artwork for the delight of the Consumers!
So, a further rudimentary optimisation would be to provide a way for the Consumer to pay BOTH the Operator of Broadcasting Payment Infrastructure AND whoever is publishing livestream content into the infrastructure (the Publisher). This way, there is the opportunity to create a mechanism to incentivise the Operator of Broadcasting Infrastructure and the Publisher to collaborate, much in similar ways that Musicians and Promoters / Distributors have worked in the past... only digitally-only, and faster and in real-time.
But that's a topic for further debate.
7. Public Network
So, there already exists a public network of Transcoders, and a public network of Privacy Nodes... but if this can work, it can be integrated into an independent public network of Broadcasters, with potential for inflation funding to subsidise the bootstrapping of nodes onto the network, before they begin to receive fees for content.
If such a network of Broadcasters existed, it would provide multiple endpoints for client apps to connect to in order to consume and publish live video content. Further, it would drive new capital flows through Livepeer, Orchid and Ethereum.