retriev icon indicating copy to clipboard operation
retriev copied to clipboard
verified publisher icon cryptonetlab

Referee Network status API

Open 0xjona opened this issue 3 years ago • 12 comments

0xjona avatar May 17 '22 11:05 0xjona

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 avatar Aug 25 '22 10:08 turinglabsorg

We need one more signal:

  • ERROR: signal that shows the error if happens

turinglabsorg avatar Aug 30 '22 07:08 turinglabsorg

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

0xjona avatar Sep 05 '22 14:09 0xjona

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

turinglabsorg avatar Sep 05 '22 15:09 turinglabsorg

some reference

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

0xjona avatar Sep 05 '22 15:09 0xjona

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

irenegia avatar Nov 15 '22 10:11 irenegia

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

turinglabsorg avatar Nov 15 '22 10:11 turinglabsorg

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

irenegia avatar Nov 15 '22 10:11 irenegia

@irenegia here we are: @gdelsi

turinglabsorg avatar Nov 15 '22 10:11 turinglabsorg

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

0xjona avatar Nov 15 '22 10:11 0xjona

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

irenegia avatar Nov 16 '22 16:11 irenegia

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

turinglabsorg avatar Nov 18 '22 10:11 turinglabsorg