weir (noun): a dam in a stream or river to raise the water level or divert its flow (Merriam-Webster)
Livepeer has been successful in executing on its original vision of a decentralized network for transcoding live video streams, with millions of minutes processed over an open, scalable and cost-effective network. This network has grown into a robust ecosystem participants and partners, many of whom are also pushing hard into real-time AI, tapping into the community's expertise in developing and operating cutting-edge, complex and latency-sensitive infrastructure.
Despite this progress, Liveeper's adoption remains low compared to other solutions in the video streaming and AI space. One factor is the difficulty of running a gateway, which is the primary entry point into the Livepeer network.
Running a gateway today requires familiarity with the Ethereum network and Livepeer's micropayments scheme. For developers unfamiliar with web3 - which is most of them - this is daunting, distracting, or even off-putting.
Gateway operators also typically need to maintain separate media servers and familiarize themselves with the details of video ingest and delivery. This infrastructure-heavy setup requires additional specialized domain knowledge, and runs counter to today's preferences for hosted, serverless or edge computing.
Not only does this increase onboarding friction for new developers, it also steers the community towards a limited number of centralized, hosted gateway providers who have the specific expertise to run gateway infrastructure. While these providers can make it easier for developers to use Livepeer under the hood, app integrations typically use APIs that are proprietary to the provider. This runs counter to the spirit of decentralization, sacrifies latency and flexibility, and limits opportunities for community-driven innovation.
These factors limit the number of gateways on the network, and constrains the community of contributors who are focused on improving the gateway and related technologies and services. This proposal suggests two approaches to addressing this problem: payments clearinghouses and local gateways.
A clearinghouse would be a payment proxy mechanism that works on top of the existing Livepeer probabilistic micropayments (PM) system. Clearinghouses can sign PM tickets on behalf of gateways, maintaining existing orchestrator payment flows while settling balances with gateways in their preferred currency. This approach would offer a wide range of benefits: expanded payment options for users and apps, accountability for SPEs and growth initiatives, and security improvements.
Offer “thick client” SDKs for web, mobile and backend environments that communicate directly with orchestrators. Media handling and transport can happen locally behind an easy-to-use interface. Payments are abstracted via clearinghouses. This disaggregates the gateway from being a standalone, infrastructure-heavy component into one that can run embeded within web and mobile apps, lambdas, or IoT devices. Gateway SDKs become a community resource, maintained by experts and open to a larger community of contributors. This increases opportunities to use the network in various ways - such as with a mix of services for payments, discovery or orchesrating - and ensures those services remain aligned with the larger ecosystem.
Livepeer's unrivaled advantage is in its enthusiastic and vibrant community that is incentivized to see the network succeed. The proposals for a payments clearinghouse and local gateways will increase the range of participation on the network, and allows for specialized contributions in targeted areas such as payments, media or platform-specific APIs. The effect of this would be to bolster the overall capabilities of the network in more directions, from more contributors.