Display Smeshing Activations

[avive]

Motivation

Display user's activations to the user to make the somewhat complex and opaque smeshing flow from the time the user sets up post data, until he starts getting rewards for smeshing much more transparent and understandable.

Design Direction

• Add 'Activations' button to the main Smesher screen. Clicking on it should push a new Activations Log screen.

Activation Log Screen

• A sub-screen of Smesher screen - similar ui pattern to how the transactions log is sub-screen of the main wallet screen.
• Back button to go back main Smesher screen.
• Screen should display a list of activations for the current Smesher Id, sorted by newest activations first.

Activation list view summary

• Epoch #.
• Activation ID short string e.g. 0x1234...1234.
• Post size (GB).
• Icon button to view in explorer.
• Activation State + time-stamp of state time.

Clicking on activation should expand its view (similar to the UX pattern in the TX log).

• Visual Design:

Expended Activation View - Displayed Data

• Full activation id + button to view in explorer.

• Smesher id + button to view in explorer.

• Activation rewards account + button to view in explorer.

• Epoch # - the epoch that the ATX submission got on the mesh.

• Space: Activation size in Post (storage units)

• Previous activation ID + button to view in explorer.

• Activation State + timestamp of state time.

• Target epoch: 'This activation makes you eligible to produce blocks and collect rewards from time X to time Y".

• Visual design:

Activation State

In the happy flow, activations move from state 1 to 4.

1. Submitted to PoET by node.
2. Got PoET result to node.
3. Submitted to mesh by node.
4. On the mesh.

State 1 to 3 are only known to the node which submitted the activation.

[avive]

Feedback on this new feature is welcomed @brusherru @noamnelke @lrettig @moshababo . It is an important one because it increases transparency and makes the user more empowered as he sees what's happening with each activation (ATX)

[avive]

I got some feedback - working on next design iteration considering it.

[avive]

@noamnelke feedback:

• we don’t have timestamps of when an ATX was created, submitted to PoET and published
• I think this can be made more intuitive - I find the current design confusing it also doesn’t mention the ATX’s positioning ATX.
• I think ATXs should be presented as associated with an epoch on the list level. All epochs should have an entry - with or without an ATX.
• If one epoch was skipped there should be an indication for that. If multiple epochs in a row were skipped then we can combine them into one row.
• The row for the next epoch should say what the status is
• I also think that we can do a special “first time smesher checklist” that tells you everything that needs to happen to get your first reward (set up post, sync with the network, publish ATX, wait for first eligibility, publish a ballot).

[oriya]

Had a preliminary discussion with @noamnelke to create additional visuals exploring a SMAPPer's Journey and the specific value "activations" will add to user (smesher/smapper) such as

• Did my initialization finish
• When will I be eligible to smesh
• Once eligible, when will I earn, and how much (estimated)

[oriya]

Thank you @noamnelke for providing us with an amazing presentation for everything (just about) that is possible as far as activations messaging and user-journey goes. All in this attached document. We will be using this document to build out iterations. Smeshing status.pdf

[oriya]

What @avive and I came up with so far is the addition of a section called "REWARDS" that will display a smesher's rewards based on PAST, PRESENT & FUTURE EPOCHS, basic information (TIMEWHAT-FORHOW-MUCH) with the potential/links to further drill down.

The problem: where is my coin? The solution: when is your coin! My Rewards section provides rewards snapshot and info for:

• PAST (EPOCHS): what you have alreaded earned - exact.
• CURRENT (EPOCH): what you’re about to earn / earning.
• FUTURE (EPOCH): what you will earn - rough estimate

Epoch TIME STAMPS with Countdown: Ended/Started/Starting...

• Epoch STATUS msgs for -

1. NOW - Active / Inactive.
2. FUTURE - POS Initializing / Syncing Network / Waiting for Poet / Waiting Next Epoch /

*Color Indicator for Initializing/Active/Error.

Special Section for Error MSGs: i.e. poet not responding, missed activation window.

Reward Information -

• Time: 02/Apr/2023 17:00
• Reward Activity: Publish ballot
• Reward Amount: 0.0501 SMH

All / More links to it’s own ALL REWARDS SECTION:

[noamnelke]

I don't like this separation of epochs - I think it's mostly confusing.

I think that I, as a user, would just want to know what rewards I've already earned (regardless of epoch) and what rewards I'm expecting.

Instead of providing this answer in a simple way (list of past rewards and list of future rewards), we're showing this complex hierarchy that hides away the interesting details.

I don't mind having some "epoch view" or "group by epoch" IN ADDITION to a simple list, but I believe this is not what most users will care about.

If you think I'm out of touch then I propose the following: create a similarly well designed mockup of my suggestion (two lists) and have a conversation with users. Show some users my version and others the version you propose and ask questions to see which version makes things clearer to them. (We can also consider showing the same users both versions, but we have to be careful with this, because users will "learn" from the first version they see and it may affect what they understand from the second)

[brusherru]

I agree with @noamnelke. This separation of past, present and future seems a bit complicated. I like what I see in the presentation by @noamnelke. I think that the single timeline will be a best way to show what is happening here. Then we can add user-specific data to this timeline and he will know where is he and what he can expect.

I've created some kind of design draft in google sheets :D Please, check it out: Smeshing Rewards.pdf

@avive @oriya @noamnelke @maparr

[oriya]

At this point, with all this great feedback- I tend to agree with you both.

In addition, what we propose @avive and myself, is to separate "messaging & information" about

rewards / activations / epochs

from our desired focused "my rewards" screen,

like you both suggested - keep it clear

Recent & Upcoming

So the evolving idea is to keep the Rewards screen focused - something of a combination of your suggestions @noamnelke @brusherru keeping it simple with the ability for quick epoch reference

And then focus on a new Status Screen which can include messages, progress, error and so forth for

Active epoch 35 for X days Progress msg (Smeshing / waiting for next reward

Next epoch 36 starting in .. Waiting for Poet

Last Epoch 34 ended X days Ballots submitted

At first we can try to rework the current Smeshing Status screen to have current POS status data & messages

and add new POST status data and messages

So we are taking all of this and come come up with another variation for Rewards plus start to do a potential rework for the Smeshing Screen for additional relevant information.

As you can see, your feedback is critical and appreciated

[brusherru]

List of data that we need to render in any way.

Checkbox next to the data piece indicates do we have an API or not.

1. [x] Smesher ID — already use SmesherService.SmesherID
2. [x] Space (PoS size)
   • we store it right into node-config.json under the smeshing-opts key. So we can take these values from here
   • but probably the proper way is to use unimplemented GRPC API: SmesherService.EstimatedRewards
3. [ ] Created (date)
   • We can easily store the date in fs when we done creating a PoS data. Do we need it?
   • Otherwise, we can find the first Activation via GRPC API MeshService.AccountMeshDataQuery & Stream and get the layer number from here and then calculate the approximate time. API points probably implemented (we use it to retrieve transactions, but not activations, so I'm not sure about them).
   • Btw, am I understood right that we always store layer numbers and calculate dates from them?
4. [ ] Status
   • Not initialized — smeshing-opts is empty
   • Initializing store — smeshing-opts not empty & SmesherService.PostSetupStatus === STATE_IN_PROGRESS
   • Paused initialization — smeshing-opts not empty & SmesherService.PostSetupStatus === STATE_NOT_STARTED
   • Initialization complete. Waiting for next epoch — smeshing-opts not empty & SmesherService.IsSmeshing & SmesherService.PostSetupStatus === STATE_COMPLETE
   • + epoch number — take the latest current layer at the moment of this event, store it, and calculate the epoch from it (fragile way since we can not request this value from any API) ??
   • + calculate estimation time — calculate estimated time to the next epoch from the current latest layer
   • Activation State (I'd like to call it "Generating PoST proof") or error — no API
   • Earning rewards — no API
5. [x] All rest activation details we can show up easily using Activation type, mentioned above

If I forget something — let me know.

List of not implemented API:

• [ ] SmesherService.EstimatedRewards — returns "12 UNIMPLEMENTED: this endpoint is not implemented"
• [ ] Unexisting API endpoint for "Activation State" and possible error. Probably should also include a layer/epoch number. Aka: `SmesherService.IsGeneratingProofStream returns { layer, status: enum { NOT_STARTED, STARTED, FINISHED, ERRORED }, error: Error | null }
• [ ] Need to test AccountMeshDataQuery and AccountMeshDataStream in MeshService with 2 flag to filter for Activations.

[avive]

We should figure out who, if anyone from core dev can add these features to the api. @selfdual-brain @noamnelke @lrettig @moshababo . If it is not likely that this task can be done anytime soon then Smapp should just mock data from the API so we can move forward on this feature until the API work is done. I think that we should not attempt to parse the logs for data - it is fragile and will make the current api even more stale...

[avive]

This is exactly how we should evolve the API - based on client needs...

[noamnelke]

Only thing I would add to what @avive said is that I think that the SmesherService is not detailed enough (in addition to not being implemented), so we may need to think about how to enrich it, possibly based on my wireframes.

[oriya]

an update: this has split into the following 3 branches:

1. Updating API with needs specific to this new feature (rewards & activations) https://github.com/spacemeshos/smapp/issues/911
2. Using the data we gather from the node itself - update the existing smeshing screen with additional information such as epoch eligibility last reward earned. https://github.com/spacemeshos/smapp/issues/912
3. work on UX for a new potential REWARDS screen that will include future data from the updated API.

Will continue to work on # 3 after we see an updated smeshing screen - so we can experience the data - it's worth the wait since we are assuming to see something in a week.

[lrettig]

@oriya would you mind opening an issue in the API repository (linked here/to the other split issues) tracking what needs to be added or changed there?

One more thought: from a product perspective, it would be really nice to study prior art, i.e., what other projects are doing - what can we learn from them and what can we improve? How does this look to a Chia miner, or an Ethereum 2 validator?

[brusherru]

I think that in the current situation when we already have a pretty informative Smesher screen it is not so important to show activation logs in Smapp. Especially if Explorer will show all this information.

So I propose to change the priority to low, and wait for some feedback from the community. Then we can decide do we need to do it or not. @oriya please take care of it or close the issue if you think it's not actual anymore from the product perspective

[oriya]

Yes, most of the relevant information is either in the current smesher screen update or the upcoming with (with updated statuses and estimations) - so I am re-labeling this as future plans - specifically for a new "rewards" screen.