Schedule tab for Smapp

[tal-m]

Rationale

As a smapp user, I feel the current version of Smapp leaves quite a bit of information unreported. I wanted to suggest the info I would like to receive, as well as propose a possible UI.

Information

The most important information I'm missing is a detailed itemized list of what is expected and when. In particular:

• PoST data init
• PoET registration
• PoET proof received
• PoST proof
• Next ATX is published
• Next Epoch Starts
• Active set is determined
• Block proposal/Ballot generation
• Hare participation
• Hare output / Block is generated
• Block is finalized
• Tortoise Beacon

Suggested UI

I think this is important enough to dedicate a new "tab" in Smapp; let's call it the schedule tab. The display can show a four-week (two epoch) timeline, annotated in both layers and wall-clock times.

Both past and future events should be marked along the timeline, with some pointer indicating the current point on the timeline.

For events with a probabilistic duration (such as PoST proof), we should indicate the expected duration (and update in real time as more information arrives), but also make it clear that this is probabilistic (e.g., using error bars or a heat map to indicate confidence).

Probably the easiest way to do this is to use a calendar widget, since it should already have most of the required display functionality. For probabilistic durations, we could use a "regular" calendar event for the expected duration, and a "tentative" event for the 99% percentile.

Note: I have uploaded a jupyter notebook explaining how to compute the expected remaining times for the PoST proof, as well as percentile calculations. The notebook has a theoretical explanation along with simple python code (both are quite likely to have bugs -- this is a first draft -- but I think the overall structure is sound)

Possible variations/extensions

For users who don't care about exactly what's happening, we could have a "simple" schedule mode. For example, in this mode we could focus on the user-facing implications rather than the protocol events. So, for example, instead of "k2pow computation" the event could be "High CPU use", and instead of PoST read/process it would be "High CPU and I/O", while "Hare participation" could be instead "Must be online in this interval", etc.

Ideally, we would have both kinds of information available in a format that's easy for non-technical users to understand but still gives more technical users the detailed information they want.