Livepeer Network Phases

Building a network that supports a fully decentralized live video broadcasting infrastructure requires building solutions across many different categories of challenges including peer-to-peer networking, live protocols, economic incentives, verification of work, blockchain scalability, media encoding, user applications, and more. Many of the underlying technologies that Livepeer is being built on top of are still nascent themselves. We look forward to contributing to the entire ecosystem to enable not just decentralized live broadcast, but also the full suite of tools necessary to build decentralized applications. This outline of the phases of the Livepeer Network, starting with the current Snowmelt phase and ending with the Oceanic phase, lays out the path forward from the centralized live streaming infrastructure that we have today to a full ecosystem of decentralized video services that we envision for the future.

Snowmelt

The Snowmelt phase is the very beginning of a functional Livepeer network — emphasis on functional, and not on performance or robustness. It is intended as a developer preview and integration period, allowing transcoding nodes to get set up, tested, and demonstrate the value that they can add to the network through scalable transcoding. Incentives for transcoding are battle tested for the first time. The interface to use the network will be command line tools and developer APIs. Users can use the Snowmelt phase to lay the groundwork for their video-enabled decentralized apps, or output production video through gateway nodes and traditional CDNs, or decentralized storage platforms for later playback.

Tributary

The Tributary phase adds support for production level transcoding profiles, proper gas accounting, governance, and slashing in the case of poorly behaved nodes. It is intended as a fast-follow to the developer preview Snowmelt phase, and fixes any issues or bugs that arise during the preview period.

Streamflow

The Streamflow phase is about performance. Introducing peer-to-peer delivery of the video segments through the PPSPP protocol, light nodes, mobile nodes, and browsers can now participate in content delivery without the need for a centralized CDN or gateway node. WebRTC transport brings support to the browser. More codecs are introduced for wider format support. Incentives are introduced for seeding streams to the network.

Confluence

The Confluence phase is a user facing release. Clients are introduced for major platforms that allow publishing and consuming video through high level programatic interfaces such as JS libraries, native mobile libraries, and broadcasting platform plugins. Video encryption and privacy features are introduced to support uses cases that require this. Dapps are introduced for basic broadcasting, consuming streams, and platform interactions. Livepeer moves beyond developers and to traditional broadcasters and consumers.

Delta

The Delta phase is focused on removing any last shred of centralized trust from the verification of transcoding operation. During this phase Livepeer will migrate from a verified computation API based approach to verification to Truebit, which instead uses incentives to ensure that the correct result of a computation is made available on chain.

Ocean

The Oceanic phase occurs when the Livepeer protocol is stable, decentralized, and highly performant. At this point the focus can shift to extensibility, introducing the many features to a media server that are necessary to support all live video streaming use cases, and supporting integrations into many existing platforms. Where new protocols are needed to decentralize further aspects of the streaming landscape, such as analytics, accessibility, thumbnail generation, moderation/curation, ad insertion, etc, Livepeer Token can serve as a sector coin for jumpstarting the solutions around these challenges.

— — —

Iterating through these many phases will take years, but it is a goal of the Livepeer project to do so in a way that allows users to benefit from the utility of the network on day 1. The network will gain more and more functionality and trustless autonomy over time, but in order for it to do so we’ll also have to make sure to embed the correct governance and upgrade paths. Communicating this plan and getting feedback on it early on is an important part of setting expectations amongst the ecosystem around how we can all move forward together towards the goal of decentralized live video broadcast.