Introduction
The current approach to encourage developers to build on Livepeer primarily consists of suggesting they sign up for an API key from livepeer.com.
This approach provides an ultra-simple starting point for a developer at any level to build simple live video applications using Livepeer, in a way which assists them in migrating to production environment on mainnet.
Problem Statement
The problems I see with this approach however are:
- mandating developers use livepeer.com’s chosen authentication mechanism limits their freedom (see here for alternative)
- increases a developer’s reliance on .com, and their proprietary API (rug risk)
- increases the centralisation risk due to the public network’s reliance on .com’s Broadcaster
- provides no migration path towards a video app developer migrating to running their own infrastructure.
This post presents an alternative approach towards encouraging developers to build using Livepeer’s open source stack in their environment.
Approach
This approach involves a developer beginning by running their own Livepeer Broadcaster / Mist.
A diagram summarising the approach is show below:
Phase 0
The objective is to make this phase as simple as possible, in order to help a developer get started.
This can be as simple as:
-
Download and install Livepeer (can use pre-compiled binaries, or build from source)
-
Run with
./livepeer -broadcaster.
This provides a developer with local rtmp and hls interfaces, for publishing and consuming content.
It is important to consider that any application functionality developed against this simple environment would also function in an equivalent way against environments defined in other phases.
There is no requirement to understand any blockchain technology at this phase, nor is there any cost associated.
Phase 1
Once a developer has had a chance to build basic initial functionality from the Broadcaster, this next phase adds local transcoding functionality into the environment.
This allows a developer to begin to build application functionality which utilises transcoded streams (e.g. adaptive bitrate playback of transcoded content).
They can run with the following commands:
-
Run with
./livepeer -broadcaster -orchAddr 127.0.0.1:8936. -
Run with
./livepeer -orchestrator -transcoder -serviceAddr 127.0.0.1:8936 -cliAddr 127.0.0.1:7936 -v 99.
There is no requirement to understand any blockchain technology at this phase, nor is there any cost associated.
Phase 2
At this phase, a developer is able to start to engage with blockchain network, via Livepeer’s Public Test Network. This provides a them with a gentle and low-cost introduction to connecting their Broadcaster to a blockchain for the first time.
They can run with the following command:
-
Run with
./livepeer -broadcaster -network rinkeby -ethUrl https://rinkeby.arbitrum.io/rpc. -
./livepeer_clito configure their Broadcaster with deposit and reserve.
There is no requirement to incur any costs, and users are able to learn how to run on a blockchain.
Phase 3
At this phase, once the developer has learned how to operate with Broadcaster on a public testnet, they can simply migrate to using the more reliable (but real-money) Livepeer mainnet public network.
They can run with the following command:
-
Run with
./livepeer -broadcaster -network mainnet -ethUrl https://arb1.arbitrum.io/rpc. -
./livepeer_clito configure their Broadcaster with deposit and reserve.
Pros and Cons
The positive of this, is that they then have full autonomy and freedom to build what they like, and even to develop the front end in tandem with evolving the logic on the back end (the Livepeer Broadcaster / Mist). Furthermore, they can start out on a well-understood and coherent path which can migrate their environments towards a mainnet launch.
The negative of this approach, is that a developer is then required to run their own instance of Livepeer in dev, test and production. This has implications in terms of the size of the Broadcaster’s reserve deposit.