Concept: UGC Paid Livestreaming Platform using Livepeer

[deboot]

Summary

This post contains a high-level concept for building out a “User Generated Content” (UGC) paid livestreaming Platform using Livepeer.

The concept consists of the following set of (perhaps somewhat esoteric) points and proposals, which aim to outline an incremental approach towards the creation of a sustainable paid livestreaming platform.

All feedback is welcome in the comments below.

Concept

1. Broadly speaking, the variable costs of a UGC livestreaming Platform are:
   a) costs of Transcoding - processing content to make it more accessible and distributable.
   b) costs of Distribution - sending content data over a network to the Consumer.
   Both sets of costs should be considered when building any UGC livestreaming platform.
   

   

2. Transcoding costs scale “per livestream”. The livestream can be transcoded once, and distributed many times (see point 3), in real-time.

3. Distribution costs scale “per Consumer”. Each Consumer needs a copy of the content data in order to watch live.

4. Proposal: A pay-to-play Platform may wish to have Transcoding costs covered by the Publisher, and Distribution costs covered by the Consumer.

5. Costs of Distribution can be covered by charging a “Platform cost” to the (paying) Consumer, in addition to the royalty paid to the Publisher.
   a) This “Platform cost” may vary based on the quality of the livestream rendition being consumed i.e. charge more for the 2160p (higher cost to serve) than for 144p (lower cost to serve).
   b) varying this cost would like require the charging mechanism to be sufficiently responsive to cater to adaptive bitrate playback, and is not discussed further here.
   

   

6. Costs of Transcoding can be covered by charging the Publisher a “Platform cost”, to be able to publish a stream to the Platform.
   a) This can act as a rudimentary anti-spam measure.
   b) See point 7 for thoughts on how to mitigate this.
   

   

7. In order to not appear prohibitive however, the Platform may wish to allow a Publisher to livestream content “for free” i.e. without Transcoding, and perhaps with source resolution capped (to allow it to be somewhat distributable and accessible), e.g. at 144p or 240p (+ audio).
   

   

8. The Platform may then wish to offer the Publisher a way to “upgrade” their streams by adding Transcoding, in order to make their content more accessible (= more paying Consumers) and distributable, and also to raise / remove any resolution cap.
   a) A Publisher may choose to “upgrade” only once they can cover the costs (perhaps using revenue from publishing “for free”), and when they are ready to start targeting larger audiences, with higher quality networking and playback facilities.
   b) A Platform may wish to only offer a Publisher to upgrade if they have accumulated a positive balance, and are thus are able to afford Transcoding fees.

9. A Platform may wish also to start by building the “for free” option for the Publisher, in order to cultivate content on their Platform, while proving the pay-to-play mechanics with the Consumer, and limiting their overhead costs. A phased approach to building out such a platform is briefly described below.

Phased Build Out

Phase 0 - “free platform”

• Free-to-publish
  • Resolution capped at 144p video + audio
  • No Transcoding = no costs to Platform
  • Content is highly accessible
• Free-to-consume
  • Distribution costs borne by Platform (investment required)

Note: implement back end for this using single Livepeer Broadcaster in off-chain mode.
Note: Low resolution content = low / limited costs.
Note: Phase 0 allows evaluation of Livepeer software.

Phase 1 - “paid platform”

• Free-to-publish
  • Resolution capped at 144p video + audio
  • No Transcoding = no costs to Platform
  • Content is highly accessible
• Pay-to-consume
  • “Royalty fees” paid direct to Publisher
  • “Platform costs” charged to Consumers for Distribution
  • Merely pass on cost of serving 144p video + audio

Note: also implement back end for this using single Livepeer Broadcaster in off-chain mode.
Note: use webhooks to integrate the Pay-to-consume UI with the Livepeer Broadcaster.
Note: focus community-building at this phase towards music livestreaming, where audio is more important than video.

Phase 2 - “paid platform with slightly higher quality content”

• Free-to-publish
  • Resolution capped at 144p video + audio
  • No Transcoding = no costs to Platform
• Pay-to-publish
  • Publisher can pay to “upgrade”, to increase video quality and add Transcoding to make content more accessible and distributable
  • Resolution capped at 240p video + audio
  • “Platform costs” charged to Publishers for Transcoding (240p >> 144p)
• Pay-to-consume
  • “Royalty fees” paid direct to Publisher
  • “Platform costs” charged to Consumers for Distribution
  • Merely pass on cost of serving either a) 144p video + audio, or b) “upgraded” 240p video + audio

Note: implement this using two instances of Livepeer Broadcaster a) one in off-chain mode (no transcoding) for free-to-publish, and b) one in onchain mode (transcoding via Livepeer public network) for pay-to-publish.

Phase 3 - “paid platform with even higher quality content”

• Free-to-publish
  • Resolution capped at 144p video + audio
  • No Transcoding = no costs to Platform
• Pay-to-publish
  • Publisher can pay to “upgrade”, to increase video quality and add Transcoding to make content more accessible and distributable
  • Resolution capped at 360p video + audio
  • “Platform costs” charged to Publishers for Transcoding (360p >> 240p >> 144p)
• Pay-to-consume
  • “Royalty fees” paid direct to Publisher
  • “Platform costs” charged to Consumers for Distribution
  • Merely pass on cost of serving either a) 144p video + audio, or b) “upgraded” 240p video + audio, or c) “even more upgraded” 360p video + audio.

Phase n - “endgame”

• Free-to-publish
  • Resolution capped at 144p video + audio
  • No Transcoding = no costs to Platform
• Pay-to-publish
  • Publisher can pay to “upgrade”, to increase video quality and add Transcoding to make content more accessible and distributable
  • Resolution capped at 2160p (4K) video + audio
  • “Platform costs” charged to Publishers for Transcoding (2160p >> 1440p >> 1080p >> 720p >> 576p >> 360p >> 240p >> 144p)
• Pay-to-consume
  • “Royalty fees” paid direct to Publisher
  • “Platform costs” charged to Consumers for Distribution
  • Merely (!) pass on cost of serving either a) 144p, b) 240p, c) 360p, d) 576p, e) 720p, f) 1080p, g) 1440p, h) 2160p.

Note: at this stage, in order to more easily account for the “Platform costs” charged to Consumers for Distribution, it may be prudent to investigate platforms providing data bandwidth marketplace functionality, such as Orchid (also on Ethereum).

[payton]

Thanks for putting this together - it’s an interesting read!

Can you define who your target publishers/consumers are? That will influence my feedback quite a bit (and I assume others as well). Additionally, is it assumed that Phase 0 would be started in current day?

Both of those influence plausibility of the platform’s economics.

Technically speaking, I do like the idea of including transcoding as a separate service upgrade. I do think there will need to be many abstractions for the consumer if they are assumed to be the general public.

[deboot]

Can you define who your target publishers/consumers are?

Given the ease with which live content can be captured via a camera and microphone, and published from either a computer or a smartphone via a browser or app, I’m going to boldly limit target Publishers/Consumers to “anyone with a computer or a smartphone”.

Additionally, is it assumed that Phase 0 would be started in current day?

Yes, phase 0 has been technically possible using Livepeer’s Broadcaster software since 2018.

Things have since come on “leaps and bounds” in recent years, in terms of the realistic ability to take things to further phases, since the advent of Streamflow, with scalable transcoding.

The Confluence upgrade, with a potential migration to a L2, can pave the way to cost-effective paid livestreaming to become real, perhaps using services such a Superfluid for streaming money. At least I’m optimistic in this direction, and I see the barriers to such things lowering.

This isn’t to say that there won’t need to be work on designing and implementing a coherent UX, but the components required on the back end to enable such concepts are emerging and maturing.

I do think there will need to be many abstractions for the consumer if they are assumed to be the general public.

Can you explain what kind of abstractions you mean?

I mean, how hard is it really for a user to a) load up a web app (on a computer, or on a smartphone), b) connect a wallet, c) tell it to access their camera / mic, d) tap “start streaming”? or c) select which stream they want to start paying to watch?

Sure, it’s not all something everyone knows how to do today, but I do feel that with things like Sign-In With Ethereum, and the growth of web-based video conferencing software (“Allow {app_name} to use your microphone”, “Allow {app_name} to use your camera”) - but seeing what things like Beem are doing is inspiring in this direction (for me at least).

[payton]

@deboot

in terms of the realistic ability to take things to further phases

100% agreed that the current technical state of decentralized infrastructure is mature enough to start making this a reality. At least for Livepeer specifically, I do think the orchestrator / transcoder community does need to solidify more before becoming ‘production ready’. I’m still fresh in the orchestrator community but, from initial impressions, would argue we are still very much in an organizational/building period. I wasn’t going to mention this at all and am only bringing it up because it is semi-related to your message (more than happy to discuss this in detail too… perhaps for a different thread). Again, I agree we are ready to start building out platforms that utilize these technologies.

@deboot

perhaps using services such a Superfluid for streaming money

Very intrigued in this and will be taking a look after this post!

@deboot

components required on the back end to enable such concepts are emerging and maturing

Absolutely agreed.

@deboot

Can you explain what kind of abstractions you mean?

Addressing this throughout the remainder of the post:

@deboot

how hard is it really for a user to a) load up a web app (on a computer, or on a smartphone), b) connect a wallet

Is it hard? Absolutely not. Is it intuitive? [opinion] Absolutely not.

The “Connect a wallet” UX is going to take a very long time to catch on (if ever… leaning towards never). Consider the fact that only 16% of Americans have used crypto. This includes investing. I’m going to make an educated guess that a large portion of that 16% only really traded crypto on platforms like Coinbase and have never managed their own wallet. Changes in user behavior take a lot of time. Coinbase has succeeded because they abstracted every detail of crypto away and framed it in a familiar way. People like you and I have no problem managing our own wallets. Not so much for the majority of the rest of the world.

Hell… adoption of contactless payments has taken well over two decades and I still know people who have never used it (nor know how to). I agree that projects like Sign-In With Ethereum (thank you for the link) are steps in the right direction. Abstracting UX to something familiar is going to be critical for adoption of any decentralized platform.

@deboot

I’m going to boldly limit target Publishers/Consumers to “anyone with a computer or a smartphone”.

This brings me to my overarching critique of your proposal: Abstraction and eventual concretization of the decentralized community should be built in to your roll out.

I admittedly didn’t intend to bring up the “Connect a wallet” UX but expanded on that earlier since it is also something I was curious about hearing opinions on. With that said, I’m going to change paths a bit while still remaining on the topic of abstraction and subsequent concretization.

Your Phase 0 defines a free platform to attract users. Phase 1 immediately moves to a platform where consumers are paying broadcasters for content.

I think this build out, if started now with the general public as a target, fails to recognize the current media consumption ecosystem. We live in a world where the majority of popular content is either free or paid via a flat-rate recurring subscription. “Free” content is at the expense of the consumer’s time via ads or at the expense of the consumer’s data. Subscription-based content, on the other hand, is at the expense of the consumer’s capital and is non-variable so they expect what they will be paying (arguably also at the expense of their data, but let’s not get in to that).

Motivation: Content consumers today are not familiar with paying for UGC. In the instances that they are, it’s a non-variable subscription model with “trial” periods.

I want to argue that the only way a decentralized UGC platform will be successful is if we transfer some of these concepts over to your initial phases (say phase -2 and phase -1). As time goes on, abstractions can become concrete and your pay-as-you-go model can slowly reveal itself.

On that note, I think advertising will remain an important role in the launch of decentralized UGC platforms (as awful as it sounds). I’m interested in the idea of a phased roll out that is free via platform investment and ads. Broadcasters will want to make money and I’m not sure a pay-as-you-go model will support that currently. As a result, the initial platform should include a monetization service for broadcasters. This monetization would subsidize the cost of streaming and the cost of the platform itself. Once the broadcaster reaches an audience of a certain size, they can start profiting. The broadcaster can, of course, front the cost of transcoding and distribution if they wish.

You’ll notice, this is exactly what YouTube does… content producers can’t start profiting off of ads until after a certain threshold is reached so there is actual value being brought in.

This would be one of the first phases of your build out and would slowly blend to the new decentralized model (concretization).

That was a lot. I made a lot of definitive statements throughout. Please challenge everything! Love the conversation and appreciate your time!

[deboot]

Thanks @payton for the extensive feedback. In response:

At least for Livepeer specifically, I do think the orchestrator / transcoder community does need to solidify more before becoming ‘production ready’. I’m still fresh in the orchestrator community but, from initial impressions, would argue we are still very much in an organizational/building period.

I don’t know if I agree. Having run transcoding infrastructure in Livepeer’s network since mainnet launch in Q2 2018, and seeing the volume of production traffic being processed by the network, I think it is ready to handle the volumes that might be expected of a Platform as described above. If such a platform were to saturate Livepeer network, it would likely result in an increase in supply (e.g. more GPUs per Orchestrator).

Further, I think it is worth noting that a Platform can also choose to initially run its own dedicated Orchestrator/Transcoder infrastructure in-house, before needing to even touch the public network. For example, 2 consumer-level GPUs would be capable of handling up to 60 concurrent livestreams of capacity. This capacity can also be made available on the public network as the Platform scales up usage… making it some sort of win-win!

Your Phase 0 defines a free platform to attract users.

To clarify, this phase is designed to evaluate Livepeer software. It is not intended to be user-facing, other than perhaps to perform limited user testing on the “Free-to-publish” mechanism.

If I were pushed to include real end-users, I would start with limited “friendly Publishers” at Phase 1, with the sole intention of demonstrating to them that they can (technically) start streaming, and start earning. I firmly believe that if they can see non-zero amount of money flowing into their control, however little, they can have an “aha” moment, and they will want more.

The “Connect a wallet” UX is going to take a very long time to catch on (if ever… leaning towards never). Consider the fact that only 16% of Americans have used crypto. This includes investing. I’m going to make an educated guess that a large portion of that 16% only really traded crypto on platforms like Coinbase and have never managed their own wallet. Changes in user behavior take a lot of time.

I hear you. But I don’t agree with the “never”. I think with the proliferation of fragmented databases of usernames/passwords, and the growing mistrust of “login with Facebook”-type mechanisms, then a “Sign-in With Ethereum” is actually a very neat option, especially in the context of ENS growing in appeal. It reminds me of my favourite recent NFT image:

I certainly don’t expect that overnight 100% of the world is going to wake up to the benefits (for them) of SIWE, but from witnessing the number of twitter handles with .eth ENS names in their titles, it strikes me that there is a small but growing set of potential users who might be willing to “waste” a dollar via Superfluid on Arbitrum, to test a new paid Livestreaming (and any number of Publishers all over the world who would be happy to absorb those “wasted” dollars.)

Consider also, the limitations of alternative approaches for a Publisher to receive funds - e.g. bank accounts, Google Adwords, fill in forms, jump through Google’s hoops, comply with their rules, trust their calculations, believe their tracking… it’s all a big opaque and complex mechanism which only those Publishers with plenty of energy for bureaucracy are going to make it through. Compare that with “download app, get ETH address, start receiving”… there are numerous benefits to the proposed approach which centralised mechanisms can’t even begin to compete with.

All of which reminds me of a recent tweet from @epolynya (my favourite new follow on Twitter), reminding us how much better the world could be:

https://twitter.com/epolynya/status/1467002102123692034

I think this build out, if started now with the general public as a target, fails to recognize the current media consumption ecosystem. We live in a world where the majority of popular content is either free or paid via a flat-rate recurring subscription. “Free” content is at the expense of the consumer’s time via ads or at the expense of the consumer’s data. Subscription-based content, on the other hand, is at the expense of the consumer’s capital and is non-variable so they expect what they will be paying (arguably also at the expense of their data, but let’s not get in to that).

I think this perspective is valid, however it only tells one side of the story - that of the Consumer. It fails to consider the Publisher, and whether there is sufficient funds reaching the individuals who ultimately provide the content which fuels all such machines.

I believe that by providing Publishers with alternative ways to share and monetise their performances in real time, as well as test the market by dynamically setting their own prices, Consumers will have to choose between a) low-quality free-with-ads / all-you-can-eat subscription, or b) paid content direct-to-publishers of innovative live content. And I think enough people will choose b) to make it worthwhile.

To add some colour to this, I will refer you to the following anecdotal links:

• Recent tweet from satirical journal The Onion.
• Recent twitter poll from @0xstark, which is only asking people to guess, and no hard data (yet), but also thought-provoking.

On that note, I think advertising will remain an important role in the launch of decentralized UGC platforms (as awful as it sounds). I’m interested in the idea of a phased roll out that is free via platform investment and ads.

This is where we differ most. I have zero interest in incorporating advertising in launching a livestreaming platform where the aim is to create the means by which Consumers can (and must) pay Publishers directly in order to enjoy their content.

I think it sends the wrong message to both sides of the market, namely that there ever needs to exist such intermediaries.

I don’t believe they are necessary, even to fund any bootstrapping, if the key variable costs (Transcoding, Distribution) are covered per the proposal above. Including them in the strategy will at best send the wrong message to the supply-side and demand-side, and at worst help perpetuate their business models, thus actually making it harder (IMHO) to achieve the desired endgame.

[payton]

This is great. Thanks, @deboot .

For the sake of organization, I’ll break this up into three parts: Livepeer production readiness, UGC platform feedback, my modifications to your proposal.

Livepeer production readiness:

@deboot

If such a platform were to saturate Livepeer network, it would likely result in an increase in supply (e.g. more GPUs per Orchestrator).

Absolutely agree that in time, the network would adjust. However, my argument is that the network is not capable of adjusting in time to support heavy, production workflows. These have tight SLAs that have strict infrastructure requirements.

As of writing this, there are currently 118,000 live channels on Twitch. Let’s assume the Livepeer network can sustain this transcoding effort. If Twitch sends out a marketing email promoting a new broadcasting feature/benefit/etc, the spike of new broadcasters could easily take down a lot of our workforce.

Orchestrators need to be equipped to handle these spikes / scale accordingly. Just to name a couple of things I see problematic with current infra:

1. In an O / T setup (O separate from T), you may be able to scale your T level as work increases. However, there also needs to be measures in place to scale your O level. It could easily be the case that bandwidth on your O is saturated and your product starts throttling (us-east-1 outage a couple of weeks ago was loosely related).

2. In an O/T setup (O and T on same machine), you may have multiple nodes distributed. Many Os use weighted DNS for nodes in the same region. Weighted DNS of course assigns traffic blindly and not based on any sort of metric / capacity. It could be the case that a saturated O still gets connections from the DNS entry and then that broadcaster stops sending it work because they think it’s full (when in reality the other O in that DNS entry is free). A naive fix would be a connection-based load balancer.

My main point here is that Orchestrator infrastructure needs to mature. Especially with routing / general scalability. Less than half of registered orchestrators are active, so there’s even more reliance on the few that are doing work. The problem that orchestrators are solving (should be solving/worrying about) is routing, distribution, and validation of work.

UGC Platform Feedback:

@deboot

It reminds me of my favourite recent NFT image:

Adding this to my collection hahaha

@deboot

I firmly believe that if they can see non-zero amount of money flowing into their control, however little, they can have an “aha” moment, and they will want more.

Love it. This is such a strong statement.

@deboot

I think this perspective is valid, however it only tells one side of the story - that of the Consumer. It fails to consider the Publisher, and whether there is sufficient funds reaching the individuals who ultimately provide the content which fuels all such machines.

Very good point. My response does indeed weigh in heavier on the consumer’s perspective. The referenced advertising is a product for the broadcasters, though (concept explained at the end).

@deboot

Recent twitter poll from @0xstark, which is only asking people to guess, and no hard data (yet), but also thought-provoking.

I’d like to call out that, despite the fact that there are trends and we are slowly moving in the right direction, this poll is heavily biased towards the web3 community (given it’s stark’s tweet). The same goes for the .ens twitter handle trend. This does not apply to the general public. The NFT publicity is positively impacting our efforts, though.

@deboot

I have zero interest in incorporating advertising in launching a livestreaming platform where the aim is to create the means by which Consumers can (and must) pay Publishers directly in order to enjoy their content.

I understand the sentiment and underlying ambitions of removing the intermediary payment hops. Advertising is not going anywhere, though. Even if publishers are being paid by the consumer directly, they themselves will eventually start advertising with their own brand deals. Having any sort of audience is and always will be valuable. Companies selling products will always persist.

In terms of feedback for your proposal, I want to narrow the scope back in to where my concern lies: user acquisition.

Your goal for a successful decentralized UGC platform should be user acquisition. You need to acquire broadcasters and you need to acquire viewers. According to the target, the majority of both of these groups of people live in web2. The viewers are used to getting high quality content for ‘free’. The broadcasters are used to using a medium that seamlessly delivers their content to their viewers (perhaps at the expense of less direct pay via ads).

How does your proposal acquire web2 users?

Consider web2 and web3 to be two neighboring islands. Web2 folks are still fairly content with their lives. The folks on web2 look over to web3 and see some interesting things. The question is… how do they get there? They could build a boat or swim, but that’s a lot of effort given they’re not dying for web3 yet. Instead, we need some folks in web3 to build them a bridge. How does your proposal build them the bridge? I think your proposal will lose to other platforms who build a better bridge.

I understand your approach for distributing the load of operational costs. However, that assumes a change in user behavior. Viewers expect high quality content for free. Why would they start paying for it? Most broadcasters also can’t front the cost of HD transcoding AND distribution. As a result, the platform needs to do something about it (whether that’s ads or just more of an investment).

I do think there is room for an advertising component on a streaming platform. It makes advertising widely available. A streamer with 20 average concurrent viewers isn’t going to get a brand deal. However, a platform with 200 concurrent streamers each with 20 average concurrent viewers absolutely will. The platform offsets the lift in this advertising scenario.

In summary, your proposal seems technically sound for eventual adoption. However, to adopt web2 users in a timely manner while beating competing platforms, I think you need to build a better bridge.

My Proposal:

Roughly, this is how I see getting to Phase N of your plan:

Phase 1) A web2-equivalent platform but with decentralized infrastructure. This platform’s claim to fame is the fact that it is decentralized (plays well with the NFT publicity and general crypto hype). This platform has the same economics. Advertising. All payments go consumer → platform → broadcaster. Users login with a centralized username/password. Same web2 problems but powered by web3.

Phase 2) We start construction on the bridge to web3. Users are offered the opportunity to migrate their username/password to a wallet. Great opportunity for sign in with ethereum (I’m obsessed with that project right now, so thank you). Similar to how Mojang was acquired by Microsoft and started migrating Mojang accounts to Microsoft accounts (additional benefits from migrating).

Phase 3) The first introduction to viewer → broadcaster payments. Do the Twitch channel subscription model but with their new wallet “account” as a payment source. Give them features to make the switch (such as removing ads or incorporating ideas of distributing operational costs as per your proposal).

Phase 4) (Interchangeable with Phase 3) The broadcaster also unlocks features if they connect their wallet such as 60fps streaming… something to improve the viewer experience directly. Perhaps this is where ideas of your Phase 3 comes in.

Phase 5…N-1) Similar transitional phases from web2 → web3 until user behavior changes

Phase N) Your model exactly as is.

[Titan-Node]

Consumers should pay in BAT tokens. Which they earn for free while using Brave. Perfect integration fit I see there.

[deboot]

Viewers expect high quality content for free

I acknowledge this, but for me, this is the root of what we’re getting at here. A global systemic problem in terms of funding creativity.

When I talk about my concepts publicly and privately, nobody ever believes that people will want to pay for anything ever.

People expect it to be free, and that whoever made this thing that they are currently being entertained by, deserves absolutely nothing from them.

They expect that some unseen system takes care of feeding, clothing and housing the artists that make the entertainment. Perhaps a corporation, or a national carrier, or a radio station, or a government, or an advertising agency, record label, copyright lawyer, royalties agency.

But not the people, heck no! The people shall feast on visions and sounds that will delight their ears, and laugh together at the joys being shared. But when it comes to feed the artist’s children, they say “I’m sorry I dont have any pocket change”.

So I acknowledge that this is the way the world is. But I think it’s the problem. With Napster and Digital and Bittorrent, digital has broken the creativity funding model. And now we gotta fix it.

I do think there is room for an advertising component on a streaming platform

Did you ever consider that if we just stopped advertising “at” people all the time, then they’d do whatever they wanna do naturally, and we’d all be far more balanced as a society?

My Proposal

Hey @f1l1b0x, @payton has come with some passion and a plan for how to make UGC Paid Livestreaming Platform. Does any of this play well in your planning?