For discussion: steer developers towards self-hosted solutions

[chrishobcroft]

For me, there is an important shift in mindset which needs to happen. A shift towards encouraging developers to build live video applications which interact directly with the public network. i.e. instead of building against a proprietary api exposing arbitrary and limited functionality.

Cultivate the long tail of Broadcasters

The following approach can be positively described as approaches to building on Livepeer. It doesn't involve any crypto until the app scales, and also doesn't require a used dox the self with username/email/credit card etc.

It is motivated by the idea of cultivating a more diverse active set of Broadcasters than currently exists, and reduce Orchestrators' over-reliance on a single source of live content and fees.

i) run a B/Mist in offchain mode (no username/password, no crypto expertise needed, no cost) it's as easy as running ./livepeer -broadcaster or whatever the MistServer equivalent is, and how many competent devs couldn't do that? This gives them full access to a livestreaming node which they can even build from source and tinker with under the hood.

ii) if/when needed (i.e. if/when the B's upstream bandwidth gets saturated by too many outgoing streams), configure their own CDN to distribute content more cost-effectively. This isn't beyond the capabilities of most developers, and is effectively what .com does.

iii) run a self-hosted O/T in offchain mode (still no crypto needed, doesn't even need an -ethUrl). This can even start with CPU transcoding to begin, and add a GPU if/when more than a few incoming streams start coming in.

iv) if/when required (i.e. if/when the O/T's transcoding capacity get saturated by too many incoming streams), connect to Rinkeby testnet, then if necessary to Mainnet (requires deposit/reserve). This became much more feasible since the switch to Arbitrum in terms of reserve deposit for PM tickets, and paves a way towards diversifying the active Broadcaster set, which can only be a good thing for the public network in the long run. It will also help to inform any work done on evolving the fee mechanism, to make sure we don't make it prohibitive for small independent Bs to feed the Os with source video content and fees.

This approach may be slightly more complex than just getting a free account with .com API, but it sets a developer on a path where they are entirely self-reliant and self-sovereign. Overall, it feels like a far more coherent and authentic approach for a project which aims to be the world's open video infrastructure, compared with "sign up for an account with this US-based corporation".

This is instead of proposing that developers build to an arbitrary API with limited functionality, where they need to rely on a centralised team to share their priorities, which isn't a scalable approach to serve all developers building video apps for the metaverse, and introduces points of failure (.com itself).

I appreciate this is some kind of strategy question, but I would be interested in hearing views of others.

[hthillman]

I think your analysis is generally correct, here are a few thoughts to kick things off:

• I'd argue that this is all predicated on
  • a more cohesive integration between Mist and the Broadcaster node (currently in the works)
  • reductions in the reserve requirements (also in the works)
• fwiw, there are also some updates that can be made to the hosted gateway service to make it more palatable - e.g., exposing the ability to connect directly with an ethereum address and pay directly in crypto rather than signing up with username/pw and supplying a CC. this doesn't address the concern about direct interaction, but it is better