Referee Network status API

cryptonetlab / retriev

Home of Retriev protocol (by CryptoNet + YOMI)

https://retriev.org

18 stars 5 forks source link

Referee Network status API #15

Open 0xjona opened 2 years ago

turinglabsorg commented 2 years ago

Starting a discussion about what data must be collected from the referee network. At the moment i've inserted those statuses:

PING: signal that says node is available, i'm sending it each 60s
START_<APPEAL_ID>: signal that says an appeal started
SLASH_<APPEAL_ID>: signal that says a provider was slashed for an appeal
RETRIEVE_<APPEAL_ID>: signal that says referee retrieved the file

Main goal of the network status is, in my opinion:

Internal tracking of nodes with a simple dashboard
Collect informations about referee's activity
Track processes and debug if something is not working properly
Show financial aspects maybe?

turinglabsorg commented 2 years ago

We need one more signal:

ERROR: signal that shows the error if happens

0xjona commented 2 years ago

@turinglabsorg what is the shipping date for this? what to you need?

turinglabsorg commented 2 years ago

@0xjona @irenegia we need to discuss with @claudiofabbro on how to show data. All things i proposed in comments above are implemented and collected, now we need to understand how to use data. Simple things can be:

See if a referee is online or not (1 minute timeframe)
How many appeals, retrievals referee network processed

Something else?

0xjona commented 2 years ago

some reference

irenegia commented 2 years ago

@turinglabsorg Is this still in progress or should I move to paused/done?

turinglabsorg commented 2 years ago

@irenegia the API part is done, we collect data as i described here but there's no graphic implementation. I think we should continue working on that with Elisea.

irenegia commented 2 years ago

what's elisea handle on github? so I can add her here!

turinglabsorg commented 2 years ago

@irenegia here we are: @gdelsi

0xjona commented 2 years ago

Yes it was not planned before, we focused on something else. And yes lets design it, both for retriev and onchain

irenegia commented 2 years ago

okay, should we close this issue as "api work done" and open two new issues for the design work (one for retriev and one for onchain)?

@turinglabsorg @0xjona

turinglabsorg commented 2 years ago

Split the SLASH_<APPEAL_ID> in two different signals to have more granularity:

SLASH_AS_LEADER_<APPEAL_ID>: When a referee slashes the provider as leader

SLASH_WITH_CONSENSUS_<APPEAL_ID>: When a referee collects the slashes and post them onchain