Rafał Leszko

I had a quick look at this issue and here are a few thoughts: 1. From the UX perspective, I think we should allow having multiple ETH URLs in the...

I plan to do this ticket in a few parts: - [x] Mist API client + scaffolding of its usage https://github.com/livepeer/catalyst-api/pull/8 - [x] Handling triggers from Mist - [x] Calling...

I think we can close this issue, because the work is already implemented in #8. One thing that we need to add is the stream cleanup, but I've created a...

Related to #2076. In a more general sense, we want to be able to tell if Livepeer Node is up and ready, so that we can use it in k8...

## TL;DR To address the explosion of the number of concurrent HTTP requests during the discovery process I suggest to implement 2 improvements: - caching orchestrator info data - batching...

@yondonfu and @red-0ne Please take a look and review it.

> Are Os updating some of their info without announcing it onchain? What are these infos? If we manage to make O announce changes onchain and since changes are not...

I think we can't store all the OrchInfo data on-chain, because: 1. each on-chain modification has a cost, which results in less frequent changes (for the context, `price per pixel`...

> True, in this case O will be sending a tx each time he wants to notify Bs about it's new params. Yeah, that's why I think it's not going...

Thanks for the feedback @yondonfu > From a terminology POV should we use the following? > > * O discovery -> process for fetching and caching OrchestratorInfo messages from known...