Livepeer Cloud SPE Proposal - Draft

[papa_bear]

Hello Livepeer community,

We’d like to present our proposal for the Livepeer Cloud SPE. The proposal details our plan to increase demand, adoption, and fees on the Livepeer network.

Thank you for reviewing the proposal. We look forward to your feedback and questions.

@MikeZupper - xodeapp.xyz
@speedybird - speedybird.eth
@papa_bear - solarfarm.papa-bear.eth

---

Table of Contents

• Table of Contents
• Livepeer Cloud SPE
  • Our Misson
  • Approach/ Strategy
    • Livepeer Integrations with Widely Adopted Media Servers
    • Introduce the “Public” Livepeer Cloud Broadcaster
    • Clear and Easy documentation for a go-livepeer Broadcaster
    • Analytics
  • Expected Impact
  • Milestones
  • Roadmap
  • Transparency
  • Governance
  • Funding

Livepeer Cloud SPE

Our Misson

Livepeer Cloud’s core mission is to increase accessibility and adoption of the Livepeer network. We aim to achieve this by integrating the Livepeer Network seamlessly into users’ existing workflows and eliminate the need for them to “move” to Livepeer. Our strategy involves executing three key objectives:

1. Implement Livepeer Cloud - a “free to use” Livepeer Broadcaster:
   Allow users to experience the Livepeer Network in a “web2-like” manner, using a publicly accessible Broadcaster without the need for crypto wallets.
2. A Robust Integration of Livepeer with an open-source media server - Owncast:
   Ensure a strong integration of Livepeer with Owncast, an open-source media server.
3. Demystify the Livepeer Broadcaster:
   Provide clear documentation for deploying, configuring, and funding a Livepeer Broadcaster, making the process accessible to users with varying technical expertise.

These objectives provide a blueprint for enabling the Livepeer Network within any streaming media platform, thereby lowering barriers to entry for other communities.

Figure 1. - Illustrates the current state of the Livepeer Network with Catalyst/Studio Broadcaster and envisions a future with multiple coexisting broadcast sources.

Approach/ Strategy

Livepeer Integrations with Widely Adopted Media Servers

To increase accessibility of Livepeer, we will enhance open source media engines to send streams through the Livepeer network, starting with Owncast. We’ll contribute to the Owncast Project, enabling it to seamlessly leverage the Livepeer Cloud Public Broadcaster (or a self-hosted version of a Livepeer’s Broadcaster Node). Pending feedback and additional proposals, we will target other media servers like Oven Media Engine and Ant Media Server.

Introduce the “Public” Livepeer Cloud Broadcaster

To foster adoption, we will also deploy, manage, and fund a publicly available broadcaster called Livepeer Cloud. The public broadcaster will have a limited deposit and reserve funded by this proposal. This will allow traditional users to take Livepeer for a “test drive” without having to take on the complexities of learning how to manage wallets, keys, or Broadcaster funding. This can also then act as a stepping stone to more intimate usage over time whereupon the users can setup their own Broadcaster. We will be capturing and sharing key analytics from Livepeer Cloud Broadcaster (see #analytics below for more detail).

Clear and Easy documentation for a go-livepeer Broadcaster

To further amplify the effects of this proposal and provide a glide path for new users who want to leverage Livepeer beyond the Livepeer Cloud Broadcaster, we will document the operational path to setup and fund a self-hosted Broadcaster.

Analytics

Analytics play a critical role in the process of “test driving” the Livepeer Network. Consequently, we will capture key metrics to provide a comprehensive understanding of the platform’s performance. The metrics to be monitored include usage/minutes transcoded, the number of streams, tickets paid out, and the current status of broadcaster funding. This data will be made publicly available on the same domain as the Livepeer Cloud Broadcaster, ensuring transparency and accessibility for all stakeholders.

Expected Impact

Successful delivery of these capabilities will enable others to quickly bootstrap additional Broadcasters on the network with widely used toolchains. The addition of new Broadcasters from communities outside of the web3 ecosystem will enable diversity and growth in the Livepeer network. Initial adoption, measured through increased streams, will be encouraged within communities like Owncast and its Owncast Directory.

While usage is crucial to growth, the diversity of Broadcasters is a major factor as well. Reducing the barriers to enable this diversity, will strengthen the network by increasing the variety of available content, the community of users, and the sources of revenue for the protocol. As the network usage and strength increases, this will act as a fly-wheel to drive further adoption and remove perceived as well as real barriers to adoption.

Milestones

The milestones for this SPE are functional identical to the approach outlined above:

1. Funding and provisioning of the Livepeer Cloud Broadcaster.
2. Core development of an integration of Owncast with the Livepeer Cloud broadcaster.
3. Simplified Documentation to setup and integration with the Livepeer Cloud Broadcaster.
4. A web-based site producing metrics from the Livepeer Cloud Broadcaster hosted by this SPE

Roadmap

As potential follow ups to this effort, the team envisions the following roadmap with additional integrations and AI video compute playground.

Items above represent targets this SPE considers as exciting areas to pursue after the completion of the milestones in this proposal.

Transparency

To foster transparency, the core SPE team will be delivering all source code and documentation as a Github repository. The contents will be publicly available and licensed with a permissive scheme like the Apache license.

Additionally, the core team will all be compensated through this proposal. The teams members are:

Mike Zupper - Architect and Technical Lead
papabear - Community Lead, Testing, and Documentation
Speedy Bird - Technical Implementation and Documentation

The three members have all previously made open and consistent contributions to this community. They are experts in enterprise software systems from web applications and video processing to advanced analytics and AI applications. We are frequently present in the community events and forums.

Governance

The SPE team will distribute the funds among themselves after payment. The community’s input before and during the SPE will be collected via:

1. A Livepeer forum post seeking feedback on the proposal prior to submission.
2. Attendance at the following events to discuss the proposal, collect feedback, and reshape (if necessary) the proposal prior to funding: Weekly Water Cooler Chat & Treasury Chat
3. After approval, the team will continue to attend the following events to present progress: Weekly Water Cooler Chat & Treasury Chat

If the team finds based on community feedback that additional milestones are desirable, the SPE will produce a revised roadmap and/or another proposal to fund such initiatives. In fact, the SPE team believes this proposal naturally lends itself to building out additional capabilities and in-roads to communities outside Livepeer. This will in turn drive the core mission of increase adoption and network strength.

Funding

Total funding - $44,500 USD

$8,500 USD - Public Broadcaster Setup, Installation, Ongoing Operations
$2,400 a year for Broadcaster deposit and reserve; remaining funds for compute and operational costs. If compute or stream costs exceed these numbers, the Broadcaster’s capacity will be constrained to ensure no overages.

$36,000 USD - Owncast Integration, Metrics Dashboard - Development, Documentation, Testing

• Public Broadcaster
  • Deploy Public Broadcaster and document setup for use in Livepeer docs (Windows, Linux, Docker)
  • Assess compute and costs including usage characteristics (ticket payouts)
  • Develop and deploy monitoring stack with key metrics for broadcaster health and payouts
• Develop and Open Source Owncast Integration with Public Broadcaster

note: funding to be converted to LPT at time of proposal submission

[Strykar]

Very interesting and would fill a much needed gap in broadcaster adoption.

Two questions:

1. Does this need to be an SPE, why not just a grant or a series of grants to see this to fruition?
2. Why Owncast and not Mist?

[stronk]

@Strykar

Why Owncast and not Mist?

Not to speak for them, but MistServer already has Livepeer support and Catalyst makes it easy to deploy a MistServer-based stack. People who are running MistServer directly can plug in their Studio API key or point to their own B’s and get started with transcoding. The Mist team will also come out with our own docker and cloud images (so that people can easily deploy to IE AWS). Heck, we’re working on an entire custom Linux OS finetuned for media workflows with a customer (we’ve got a box in the office with SDI I/O and a Intel Arc GPU for transcoding with the OS installed to test with).
This grant would be an excellent supplement to cover more bases, though! There are tons of media servers out there which deserve access to cheap transcoding

[papa_bear]

Thanks for all the interest in the proposal!

We’ve grouped together all the questions from the forum and discord and posted them with replies below to keep the discussion organized.

Q&A

1. @Authority_Null asks “What separates this from livepeer studio for the end user?”

Livepeer Studio is one of many great media engines that individuals use to broadcast streams. While there has been great progress with Studio, it requires users to learn a new tool and migrate their existing workflow. By integrating additional media servers, users don’t need to learn a new tool or change their approach. As a result, we are bringing Livepeer to them and opening up new distribution channels into Livepeer. This latter point also drives client diversity in Livepeer that will strengthen the network.

2. @thomshutt | Livepeer asks

"This is awesome, my main comment would be that each of:

• Livepeer Integrations with Widely Adopted Media Servers
• Clear and Easy documentation for a go-livepeer Broadcaster
• Introduce the “Public” Livepeer Cloud Broadcaster

could each be their own project, which might make the scoping a bit more manageable"

While each milestone has been designed to be discretely understood, they work together as a whole. We want to reduce barriers to adoption and increase the available distribution channels bringing content to Livepeer. If we integrate Livepeer into these media servers without the Public Cloud Broadcaser, the integrations will require additional effort and complexity to setup a Broadcaster, wallets, and so on. > The reverse scenario is the current status quo where no direct integration exists with these media engines. The end result is a partial solution that only transcodes files and leaves the media engine user to manage the rest of the process (download segments and serve them). By combining all the scope together, we are enabling the Livepeer community along with the SPE team to commit to an end-to-end solution with a streamlined UX that works out of the box. This streamlined experience eliminates all the aforementioned complexities to quickly bring these tools and their commnunities to Livepeer.

3. @Strykar asks

"Very interesting and would fill a much needed gap in broadcaster adoption.

Two questions:

Does this need to be an SPE, why not just a grant or a series of grants to see this to fruition?"

See Response to Question #2

“Why Owncast and not Mist?”

In regards to Owncast vs Mist, we are not looking to exlucde any media server in the long term. Mist currently is the engine within Studio and so an integration exists today. Additioanly, Owncast is a lightweight and easy to use offering. Combined with Studio, these capabilities enable Livepeer to boast various options depending on the user. More directly, Livepeer will be able to offer a robust, scaleable soltion with Studio and a more personal solution with Owncast. With regards to other media engines, this SPE team is interested in future integrations under additional proposals.

“could each be their own project, which might make the scoping a bit more manageable”

See Response to Question #2

In addition to our response, @stronk says “Not to speak for them, but MistServer already has Livepeer support and Catalyst makes it easy to deploy a MistServer-based stack. People who are running MistServer directly can plug in their Studio API key or point to their own B’s and get started with transcoding. The Mist team will also come out with our own docker and cloud images (so that people can easily deploy to IE AWS). Heck, we’re working on an entire custom Linux OS finetuned for media workflows with a customer (we’ve got a box in the office with SDI I/O and a Intel Arc GPU for transcoding with the OS installed to test with). This grant would be an excellent supplement to cover more bases, though! There are tons of media servers out there which deserve access to cheap transcoding”

4. @hthillman | livepeer asks

“How do you plan to generate demand? Is the idea that if the capability exists people will use it, or do you plan to evangelize this somehow?”

As mentioned above, we believe in bringing Livepeer to the users and enabling them to use their native tools. This gives communities outside Livepeer an opportunity to use Livepeer without the need for any migration or capital investment. As part of our work, we wil be engaging the Owncast community to raise awareness, encourage usage, and adopt our integration as an available default in their distributions. These activities will offer valuable insights into additional features to increase adoption and eliminate barriers.

There were several new discussions in discord in the last hour which I will summarize and add here shortly.

[papa_bear]

As promised below are the comments and replies from yesterday’s discussion.

5. dob | stated
   I’ll +1 this. I love the proposal - think it’s great for the decentralization of Livepeer and it’s another shot on goal of generating demand. But…as Mamood and Hunter mentioned, I think just integrating the technology has typically fallen a bit short of generating demand in the past.

There’s a lot of history, but the short version is that the go-livepeer B as an open source solution for transcoding wasn’t productized enough to generate adoption on its own. Livepeer had been roughly integrated with Wowza as a plugin in the early days, and it was difficult to find the Wowza users that wanted to take advantage of LP’s transcoding, and Livepeer Studio has been integrated with Mist Server for years…with some usage for sure, but it’s not a home run on the adoption side.

I still would love to see it tried in a pureplay open source ecosystem, but I don’t think there should be wishful thinking around “if we build it they will come.”

We agree. A lot of open source succeeded b/c the tool was either too compelling or super easy to adopt. I can’t say Livepeer hits all those marks. It seems that if we had integrations across the board, clear cost metrics, clear docs on how to onboard, and removal/reduction of wallet barriers…it would be far more likely to garner new users. This proposal does take a step in that journey.

6. Brad | ad-astra-video
   Is this going to be a PR to the main repo for these projects or a fork? I don’t know much about these projects (eg has plugins or has to be integrated with a PR). My experience with media servers for personal use is mostly plex and some kodi/emby/jellyfin.

7. Brad | ad-astra-video
   Ya, and the maintainers are open to the PR? Still interested in the integration because think can serve a purpose for a lighter build out to streaming content and diversity in broadcasters.

Yes we have reached out to the repo owner of Owncast and we are witting for a reply. Regardless we will be submitting a PR to the repo for the integration. The open source fork will be available for anyone to use as well.

8. AndrewGolota
   Cant orchs set 0 price for this specific B instead of redistributing money? And then spend money for actual development and marketing? That would make B thing part of proposal irrelevant. If this concept works then you can charge from users then.

Sure Os are free to set a price of 0 for the public B, however we do not wish to make this a requirement.

[obodur]

I was determined to not say yes to any fund transfer until Livepeer AI came alive. And I don’t think what you guys intend to do will immediately reflect on demand significantly.
But…
But I decided I’ll vote yes because this needs to be done sooner or later. I’ve always said Livepeer is an infrastructure project that doesn’t need a whole different type of industry (web3) to take off. And If we still wanna get a fraction of web2 on board, your proposal is a neceesary step to that. (We may see the real effect maybe much later, but still.)

[papa_bear]

Responses to questions/comments posed by @rickstaa in the Livepeer discord Discord

9. 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.

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

[Paul_Nice]

I voted against cause it looks way too biased

Why Owncast?
Approximated expense are kind way to high
We should stay focused on our strong sides maybe

[MikeZupper]

Thanks @Paul_Nice for taking time to provide feedback. Could you please clarify what you mean the proposal “looks way too biased”?

We choose Owncast because we see a user base of self-hosted streamers that could benefit from the use of Livepeer’s transcoding services. These users are independent of large streaming platforms. With education/documentation, we feel these users can strengthen the diversity of Livepeer broadcaster nodes by self hosting their own Livepeer nodes.

Lastly, Owncast is the first integration we chose. We intend on bringing Livepeer to other media platforms such as Ant Media and Oven Media Engine.

Again, we appreciate your voice and vote! As we plan the next round of integrations, we’d love to hear your input.

[papa_bear]

The Livepeer Cloud SPE has a draft of the Broadcaster documentation ready for your review. This will be our first milestone deliverable from our proposal . Here is the link: https://docs.livepeer.cloud/ The docs are password protected (to prevent Google from indexing it). The username is user and the password is password To view the docs, click on the dropdown at the top and select Broadcaster

Any feedback you can provide would be great. Just as an FYI, we will be hosting a “Office Hours” event February 27, 2024 at 12 PM EST walking through the entire guide and setting up a brand new Broadcaster node. Come Join US!!!

[dob]

Hey, I just wanted to get a refresher on the status of this documentation milestone, as I’m not sure where it was left. I remember there was some discussion around the renaming of Broadcaster to Gateways, but I’m not sure if something is waiting for review? merging? conceptual change approval?

Thanks!