Decentralized Video Streaming with Lit and Livepeer

TL;DR: We built a serverless streaming app with Lit Protocol and Livepeer that makes it easier to build apps for viewing paid content. Access to paid content is no longer dependent on the app: anyone can build their own front-end without leaking the content to unauthorized users. This is impactful for any video publisher who’s fed up with walled gardens like Netflix or video players who take the majority of ad revenue like YouTube.

You can try the demo here and check out our source code here. 

If you’re interested in decentralized streaming, whether as a creator or a developer, Studio 256 would love to talk to you. You can also reach me at dave@studio-256.com.

Going direct to consumer is still hard

The ongoing streaming wars and the release of video-as-a-service infrastructure by companies like Mux, Livepeer and JW Player has enabled more creators to release content directly to their fans. These products simplified the streaming tech stack so creators don’t have to build their own servers for storing and delivering content. 

But despite the innovations, building streaming apps is still not a trivial task. Here’s the basic architecture of an app that lets people watch content they purchased access to:

The choice of CDN and the mechanism for signing/validating messages is governed by the aforementioned video infrastructure providers. Many use signed JWTs. 

Certainly an improvement over building the entire stack yourself, but it still requires building a full stack application. Furthermore, web applications are not static; there is ongoing maintenance even if no new features are added. What happens if the creator stops maintaining this app? Their fans lose access to the content. So creators end up being CTOs responsible for managing and maintaining a technology stack. For most, licensing content to Netflix is the lesser of two evils.

How to make going direct to consumer easier

Our approach removes the burden of maintaining an application. By using Lit Protocol and Livepeer, we have built a serverless back-end that allows anyone (including the creator) to host a front-end for viewing content. If the creator stops maintaining their app, no problem; the content and its access permissions are still available on-chain. Users will always be able to access the content directly through their own front-end, or through other front-ends that are created by the community. And most importantly, security isn’t compromised: The video is never available for download.

Here’s how it works:

The centralized server in the video-as-a-service example has been  replaced by a Lit Action, javascript code that is stored on IPFS and executable by Lit nodes. The Lit Action checks the user has permission to view the video and signs a message. This architecture eliminates the burden for the creator to maintain any backend infrastructure. Building front-end apps is easier than building full stack apps. 

How is this secure?

In both architectures, signing and verifying messages requires a private key. In the original architecture, the server built and maintained by the creator is custodying the private key so that users can’t distribute it to unauthorized users. If the Lit Action is stored on IPFS, a public network, how does the private key remain secure?

Lit released a new feature called Decrypt Within A Lit Action. It allows you to encrypt information and set the condition that only a specific Lit Action (identified by its IPFS CID) can decrypt it. To understand how we leverage this feature, we’ll walk through step-by-step how the app is set up and how users access the content:

The video is uploaded to Livepeer’s CDN with a JWT playback restriction, meaning the video can’t be played unless the user has a valid signed JWT. After generating a private key for signing JWTs, a Lit Action is uploaded to IPFS. The action does the following:

1. Checks if the user calling the action is the holder of a specific NFT. The NFT contract address is hard-coded into the action. 
2. Decrypts the private key and signs a JWT.
3. Returns the JWT to the user.

When the user wants to watch the video, they sign a message and pass the message and encrypted private key to the Lit Action. If the user meets the criteria for watching the video, the Lit Action returns a signed JWT. 

Because the private key for signing JWTs can only be decrypted within the Lit Action, the private key is never exposed to the user. Furthermore, because the Lit Action is stored on public, decentralized storage, anyone can integrate the Lit Action with a front-end to enable permissioned users to watch the video. 

You can try the demo here and check out our source code here.