Responses to questions/comments posed by @rickstaa in the Livepeer discord Discord
- Rick | transcode.eth
Could you clarify the specific information gap in setting up a broadcaster? While I’ve noted some documentation on https://docs.livepeer.org/, it primarily focuses on livepeer.studio, and there’s extensive information about streaming on Stream Settings | MistServer documentation. It seems there might be a need for more detailed documentation on integrating open-source media engines like OwnCast with Livepeer. Are you considering expanding the documentation on docs.livepeer.org to include this, possibly through a new broadcaster section? Or, are you thinking of creating a separate website dedicated to this information?
The current gap in the documentation for setting up a broadcaster using go-live peer is evident 
. To make the process more accessible to average users, the documentation could be less technical and more user-friendly. A valuable enhancement would be adding a ‘Broadcasters’ section on livepeer.org and a comprehensive guide on Create a livestream - Livepeer Docs. This guide should simplify the broadcasting process for general users. Implementing these improvements might be feasible under LivePeer grants. It’s also important to clarify the focus of your documentation. If the goal is to assist users with LivePeer.studio, this aspect is a trivial part of launching the broadcaster. Could you clarify whether the aim is to refine the existing documentation or to create external documentation to support the launch of the livepeer.cloud broadcaster? 
A practical approach would be to enhance the existing documentation by adding a dedicated section for broadcasters. This section should comprehensively cover all the open-source engines that are compatible, presented in an easy-to-understand manner. Collaborating with ‘livepeer.inc’ seems like the most effective strategy to determine the best way to enhance this documentation. This partnership could ensure that the information is both accurate and user-friendly.
Absolutely, let’s summarize for clarity. The documentation in question is designed to facilitate a swift and efficient setup for users to begin broadcasting and streaming. This aligns perfectly with another of your goals, namely, ‘A Robust Integration of Livepeer with Owncast 3, an Open-Source Media Server.’ The connection between these two objectives is quite evident 
.
The aim is to develop comprehensive documentation for setting up a self-hosted, go-livepeer broadcaster and add it to the official Livepeer docs.The documentation will cover essential elements such as the minimum infrastructure requirements, the process of funding the broadcaster, and configuration options.
- Rick | transcode.eth
Q2: I highly support the main goal to achieve ‘A Robust Integration of Livepeer with an Open-Source Media Server - Owncast 3’. This project enjoys not only substantial adoption but also features thorough documentation, highlighting it as an outstanding endeavour. Its alignment with initiatives like the “Open Network” grant further underscores its suitability. Additionally, how this objective dovetails with other goals in your Special Purpose Entity (SPE) proposal is commendable, and I fully endorse its inclusion in the SPE 
.
However, we must not overlook specific crucial considerations to ensure this objective contributes effectively to the broader ecosystem given that you are requesting a treasury grant.
I think this objective should be pursued closely with other network broadcasters, notably LivePeer Inc. It’s vital to develop a universal implementation and communication protocol that all network broadcasters can adopt. The aim is to create a user-friendly protocol that any new network broadcaster can quickly implement. This protocol needs to be transparent and flexible, enabling users to easily switch between broadcasters by updating the broadcaster’s endpoint. This protocol must be distinct from your new Public broadcaster. I’m curious about your team’s perspective on this approach. You might find it helpful to examine the communication pipeline used by GitHub - livepeer/livepeer-js: JavaScript library for the Livepeer API. for their API, as it could offer valuable insights for this project.
I haven’t thoroughly explored the livepeer-js library yet. However, I want to emphasis the importance of developing a general communication protocol that benefits the entire ecosystem, not just your new public broadcaster. In my opinion, establishing such a protocol would significantly enhance the strength of your Special Purpose Entity’s (SPE) proposal.
Your proposal emphasizes a web2 approach, but I’m curious about the potential advantages of integrating a web3 endpoint for Owncast. This could benefit users who prefer using Owncast without relying on an intermediary broadcaster . This idea aligns well with my previous suggestion about the versatility of your bridging solution, which could be applicable to any broadcaster, and underscores the importance of comprehensive documentation.
Okay let’s move to the last objective you are describing in the proposal Implement Livepeer Cloud - a “free to use” Livepeer Broadcaster.
I’ve seen that this question has been discussed before, and you’ve elaborated on it. However, for the community’s benefit, could you provide a simple comparison table that highlights how your broadcaster differs from Livepeer.inc?
The idea of harmonizing a set of APIs for all Broadcasters is a good idea. For now, a public facing API for livepeer.cloud is not scoped as part of this SPE, investigating this further is an opportunity. The current livepeer-js client is modeled off of Livepeer Studio so some effort will have to be made to update livepeer-js to support other media solutions. The Livepeer Cloud SPE mission is discreet. As stated, we intend to bring the native Livepeer Protocol to the customers in their current software stack. We believe the Livepeer Protocol is NOT Livepeer Studio. The lack of broadcaster diversity is a critical driver for the Livepeer Cloud SPE. It is based on complete Open Source and a transparent operational model for others to replicate.
- Rick | transcode.eth
Q3: In your forum post, you propose allowing users to access the Livepeer Network in a “web2-like” manner through a publicly accessible broadcaster, bypassing the need for crypto wallets. However, doesn’t Livepeer.inc’s Hacker plan already offers a similar service by providing 1000 free transcoding minutes and an easy-to-use web interface. My personal experience with their platform was efficient and straightforward: it took just 3 minutes to set up an account and start live-streaming without involving any web3 tools.
While their interface could be more intuitive, perhaps resembling Twitch for easier streaming and browsing, improvements in this area might be in their pipeline. Given this context, I am keen to understand the specific benefits your Public Broadcaster brings compared to Livepeer.inc’s service. Considering your request for treasury funds rather than a grant, it’s essential to identify your broadcaster’s unique contributions, especially in light of the substantial investments needed for AI development in the ecosystem. I recognize the value of having multiple players in the protocol to foster decentralization, innovation, and resilience in the long run. Still, I think having a clearer picture of how exactly your broadcaster differs from livepeer.inc is crucial.
Livepeer Studio does allow users to set up easily and avoid web3 technology hurdles. That said, it still requires use of a centralized player (Livepeer Inc). Livepeer.cloud is intended to be a community funded effort that offers an alternative path and strengthens the decentralized ethos of Livepeer the protocol.
- Rick | transcode.eth
I understand the $2,400 annual allocation for the Broadcaster deposit and reserve from the treasury funds, especially since it’s a modest amount aimed at network promotion. However, I’m curious about the rationale for this budget request, as discussed in yesterday’s water cooler grant. This functionality also seems feasible under a microgrant, mainly by adding budget and monthly budget options to the pricePerBroadcaster CLI argument. I’ve already planned to implement this feature. Since I am more than prepared to donate a portion of broadcasting minutes to your broadcaster and Livepeer Inc., I’m asking to aid in network adoption. Although @SpeedyBird.xyz offered a comprehensive answer yesterday and @Papa-Bear | Solar Farm already gave a short answer on the forum post, I think a brief recap of your stance on this here would benefit all the voters for a clear understanding.
The treasury today is funded via inflationary rewards that previously went to Orchestrators. By leveraging these funds, we are avoiding passing on additional costs to Orchestrators. The idea of setting a price per Broadcaster has broader applicability and could allow Orchestrators to donate additional capacity. As usage increases for livepeer.cloud, we may want to adopt these approaches. In the early stages here however, our goal is to facilitate network diversity via providing a public endpoint that can be tested which uses a documented and open source solution stack. Livepeer.cloud is a stepping stone for the real customers to move onto a self-hosted on-chain solution. The SPE’s goal is to bring Livepeer to customers’ existing workflows, trying out livepeer without any complexity, and then finally integrating with existing/new media servers.
- Rick | transcode.eth
Your recent forum post about the intention to release analytics data publicly from your broadcaster is commendable:heart_on_fire: . Given the current scarcity of such data, your initiative could serve as a valuable model for others in the broadcasting community. In line with this, we could consider establishing a public data aggregator. This platform would allow orchestrators and broadcasters to contribute their data, enhancing transparency and collective learning voluntarily. While this idea might extend beyond the scope of your current SPE, it would be insightful to know your perspective on continuing this data-sharing approach after achieving the SPE milestones. Your response, particularly in light of your commercial aspirations, could highlight your potential role as a pivotal community member championing the cause of transparent and impartial data aggregation . @SpeedyBird.xyz gave a brief answer to this question in the water cooler chat but I think it would be nice to revisit it here.
As you mentioned, @xodeapp and @speedybird investigated this approach and discussed how to achieve it in a decentralized manner. The idea was to add this to the core of go-livepeer for Broadcasters and Orchestrators alike. Ideally, such data would then be published by all active Livepeer nodes and presented on the Livepeer Explorer. This was part of research done for the [https://stream.network/](Streamr Network) integration grant (which is still in the early phase of planning). Pending the completion of the initial Livepeer Cloud SPE scope, we will bring this up as a potential next project. If you are interested in teaming up, we can certainly discuss. We believe this is a project the broader Livepeer community might be able to contribute to as well.
- Rick | transcode.eth
(Final Question): Extending from my previous question, and anticipating future developments, I am keen to understand your group’s commercial goals following the completion of the SPE milestones. Your contributions in the forum post and the water cooler chat suggest a solid commitment to the community’s overall benefit. Regarding Livepeer Cloud, is its primary role envisioned as a community-focused initiative to enhance demand onboarding, or do you see it potentially evolving into a significant commercial entity within the ecosystem? Having a preliminary perspective on this matter would be invaluable in enabling the community to make an informed decision when voting on your proposal.
We have no plans to monetize at this time. If significant interest in our solution / integrations yields an opportunity to monetize the solution, we are willing to explore the idea. This will be on a customer by customer basis. We do hope customers reach out so we can learn their problems and find ways to solve them using livepeer. In the end, a decentralized approach where a go-livepeer broadcaster node runs "serverless’ ’ and connects to Orchestrators on the network to relay work, setup streams, get metrics, and so on would be fantastic. This would eliminate the need for a commercial entity or greatly reduce it. As such, it would enable a more decentralized video compute network. As far as where this livepeer.cloud could go, this is one of several.