A visual story of the network path a video segment starts at the broadcaster up to the time it arrives at the end-user’s device would be very useful to quickly grasp the network flow of data on the protocol. It may make a good addition to Livepeer - A 10-minute Primer
A visual story that explains the tokenomics, the Primer appears to be inadequate for non-developers. A video which Delegators, Broadcasters and Orchestrators can take away roles and responsibilities from, while understanding new LPT minting and it’s separation from the ETH fees paid would ease understanding the protocol to non-developers and folks unfamiliar with a blockchain and exploring it.
Creation of an “Orchestrator Selection Algorithm” document in the official Livepeer Docs, that is kept current by Livepeer. Document the current Livepeer.com API’s selection parameters and provide a few more examples that private broadcasters may configure with things like Orchestrator bias over Delegated Stake or Price per Pixel.
Provide transparency of Livepeer’s selection for Orchestrators and food for thought for new Broadcasters deciding on Orchestrator selection parameters.
Being able to reload the livepeer config without having to kill the entire process would be game-changing for operational efficiency. This is sorely needed.
First of all thank you for this summary @Strykar - this is an enormous help and it’s already informing prioritization efforts!
A few initial thoughts:
Reload livepeer configuration without restarting the process.
Clearly this is a huge priority and would improve the orchestrator experience. First reaction from the core dev team is that reloading the config upon any change in the file will be technically tricky. Here’s an alternative solution that would be simpler (and something we can hopefully complete in December):
Add support for using a config file so that it is easier to start livepeer with systemd / non-bash setups
Provide a guide for restarting livepeer if you need to change your configuration without losing any streams that are currently coming in by spinning up a node with the new configuration, moving streams over to that new node and then shutting down the existing node. Something similar to this /storage-providers/operate/maintenance/ (but hopefully simpler) along with some technical changes to make it easier to do
Would this mitigate the issue in the short-term?
A visual story that explains the tokenomics,
I’d be interested to hear about the goals here and/or problems with the primer… My initial reaction is that the Primer gives basic, high-level info and then people can drill down into the docs as necessary
A visual story of the network path
Agree that this would be helpful - I’m wondering if a diagram in the docs would suffice, especially if the docs are moved to a more prominent location. IMO it should probably be added Introduction - Livepeer Docs, possibly under a section header like “Understanding Livepeer”.
Creation of an “ Orchestrator Selection Algorithm ” document in the official Livepeer Docs, that is kept current by Livepeer.
Makes sense, I do agree that this is important. Given bandwidth constraints it probably won’t happen until Q1 2022 but is on the radar
I like the second option as a temporary solution for now. At least that gives Orchestrators some flexibilty.
Another really great feature would be allowing Orchestrators to enter a “maintenance mode”, where no new streams will be accepted which will allow an Orchestrator to finish up current streams and close their node. Probably another tough one to get going but still worth a thought.
Better logging. Add flags to dump “all logs” or “Error Logs” to capture vital information.
When orchestrators suddenly lose all of their sessions or half etc. its good to be able to see why. Especially if this happens in the middle of the night and picks back up later it would be useful to be able to see the output.
additionally, maybe dump logs per day and retain x amount of days back to avoid overflow of data storage.
1 would work well on Linux, and if it works on Windows too, it’s definitely a solution in the short term.
2 sounds amazing, and a lot of effort
The goal here is to present the entire lifecycle of video broadcasting to getting paid and minting LPT in an easier to understand video than reading the primer and docs after it. They can both co-exist without taking value away from each other. Honestly, a clear, complex as it may get, diagram here may work too.
A diagram of the network flow would suffice!
Q1 2022 for the selection algorithm would be awesome.
Since the code is already in use, can it just be made public so we can look at it and see how it currently works? If Livepeer needs until next quarter to write an official doc to add to the Livepeer documentation that’s fine, but it’s area of a lot of confusion that should be easy to remedy if we can just look at the code.
It is public! If anyone is interested, we would welcome a PR to add an explainer. At the bottom of this post, i’ve linked a place in the docs where it could go
Functions determining selection
This function determines if you are in the pool
Thank you.