A common consensus among experienced Orchestrators is that running the Orchestrator and Transcoder on the same machine results in the least to zero stability issues. This has the downside of requiring to setup an Orchestrator (and thus the wallet) at every transcoder location.
Splitting the O and T also adds latency since communication isn’t over a local socket. Orchestrators with split O+T setups will provide the data and metrics LP may need around this.
Orchestrators wish to have network insights into the protocol, to measure things like traffic demand by geographical regions. Since this data is best know to Orchestrators, a proposal to create an opt-in, community run and driven “Livepeer Network and Orchestrator” map and website was suggested. An RFC for this should be posted to the forum soon. @ftkuhnsman has created some interesting tools at GitHub - musicmank545/livepeer
What is the Redeemer role, and what part does it play, if any, in today’s version of the protocol?
I missed the first half of the water cooler - what’s the goal here in terms of content? Is it (a) a more useful version of Introduction - Livepeer Docs, or (b) something else entirely?
If it’s (a), I’d push for contributions to the docs. If it’s (b), the wiki might be a good place with the caveat that a lot of the info there is very outdated.
Two guiding principles: (1) we should avoid duplicating information (2) we should attack the root of the issue. If “community wiki” is filling in for lackluster documentation, then we should fix the documentation (and potentially KO the wiki so it doesn’t confuse people) rather than increasing the maintenance surface area.
Sounds like we’re having some trouble reproducing this? Definitely on the radar but concise steps to reproduce will go a long way towards moving this forward. cc @yondon@rafal
Orchestrators wish to have network insights into the protocol… An RFC for this should be posted to the forum soon.
Excited to see this RFC!
What is the Redeemer role, and what part does it play, if any, in today’s version of the protocol?
Let me think about this and get back to you later today… I would argue that some of this should be in the docs to begin with, but I also see the value of a standalone wiki.