Referee Network status API

[turinglabsorg]

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]

We need one more signal:

• ERROR: signal that shows the error if happens

[0xjona]

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

[turinglabsorg]

@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]

some reference

• https://nft.storage/stats/
• https://status.filecoin.io/

[irenegia]

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

[turinglabsorg]

@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]

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

[turinglabsorg]

@irenegia here we are: @gdelsi

[0xjona]

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

[irenegia]

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]

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