Summary
This post contains an idea for enabling Livepeer Broadcaster (or Mist Server) to present an interface to allow a front end to authenticate a user who has “Signed In With Ethereum” (SIWE).
The approach can enable publishing and consuming of livestream content via Livepeer software, end-to-end encrypted via a user’s self-sovereign private/public keypair (used to transact on Ethereum).
Motivation
Allowing a user (Publisher or Consumer) to “sign in with Ethereum” can provide numerous benefits to builders and users alike.
Primarily, it enables the builder to compose video applications involving other interoperable web3 building blocks, to allow a user to coherently port their profile across multiple different services.
Such components include:
- Payment rails (e.g. transfer, Superfluid, other)
- Naming / Discovery (e.g. via Ethereum Name Service)
- NFT marketplaces for publishing / consuming content
- Distributed governance mechanisms (multisigs, DAOs)
- Onchain gating (e.g. Token, Permissioning)
Such an integration can pave the way for experimentation in concepts such as Community-Driven Moderation, Pay-to-Play / Livestream-to-Earn, Content Discovery, Democratised Scheduling, and Reputation-based Access.
Components
It involves the following components of the web3 video stack:
- user (i.e. with their keypair)
- app UI (e.g. a web app / mobile app - front end interface)
- back end interface (e.g. Livepeer Broadcaster / Mist Server)
- Blockchain / EVM (smart contract platform)
Process Diagram
Below is a diagram describing a high level approach to authenticating a user to be able to interact with a Livepeer Broadcaster / Mist, using their Ethereum account to .
User Permission Contract
The above example refers to a “User Permission Contract”. This can be thought of essentially as an onchain permissioning database, and may, for example, consist of 2 tables canPublish and canConsume. The Livepeer B / Mist could query whether an authenticated user has appropriate privileges to publish or consume.
A rudimentary implementation of such a contract can be found here.
It is envisaged that by default, a B would reference a non-permissive instance of such a contract, effectively denying any user the ability to publish or consume. A Broadcaster can then choose to deploy another instance of the permissioning database, and configure the B to reference this new instance.