Analyze the gap between the current functionality and the product design

[josepablofm78]

Analyze the functionality shown in the product design and figure out what it would take to add these functionalities in the app, in terms of new integrations, architecture components, etc

[josepablofm78]

Client View

this view allows clients to find a miner and pick one of them to make a deal.

It should be implemented from the scratch, both API methods and frontend, but it's not a priority at this moment

[josepablofm78]

Clients Onboading

Done.

Improvement. Add a backend to store the data for the Notaries table. It could be as simple as an url where the json file is deployed

[josepablofm78]

Notary View

Currently working on pagination, ordering and filtering. It will be implemented in the next days.

Public Request tab

Done

Verified Clients tab

To print the info shown in this tab, we call the proper method of the API to get the state of the verifreg actor. This state only returns the f0 Id and the remaining datacap of verified clients. For each client, we look for the f1 address to show more comprehensive information

In the figma design, this table also shows the Client Name, the audit trail (as link to github issue), and the name of the Notary who granted the datacap

It would be possible to add this information looking for the addresses in github's onboarding repo, but it would have the following cons:

• It would be quite slow. For each verify client returned by the node, we would have to look for an issue whicj body contains the address of the client
• It would increase dramatically the number of requests to github API. We are currently requesting a lot of information from github API, so it could exceed the allowed ratio of requests
• scalability. we are performing pagination at the client side, as Lotus RPC API does not allow to get paginated information, so we have to get the list of verified clients at once. So if we look for github information for each client we would have serious performance issues, and the RAM consumption will be increased seriously

To address this problems, we can think in adding a backend store where we can persist this info we could look and get in a performative fashion

Client Overview

The design includes a screen to show some detailed information about a client:

What we can do, and this is related with the previous point, is to do the rows of the verified client table clickable and to look in github for the specific address of a client, and get the basic info from the correspondent issue to fill this screen

We can also show the data related with the approval, based on the comments and the labels in the issue. But take into account how this info could change with future implementation of issues #71 #65

[josepablofm78]

RKH View

Currently working on pagination, ordering and filtering. It will be implemented in the next days.

Notary Requests

Done

Accepted Notaries

Exactly the same situation commented in the Notary View with Verified Clients tab. We are printing the info coming from the actor, but the design shows additional info we can only get from github, at this moment

All the comments about Verified Clients tab apply here as well. The "granted by" column does not make sense as RKH are only the executioners of the governance team decisions

Notary Overview

The design includes a screen to show some detailed information about a Notary:

The same comments apply here. Additionally, this particular overview also shows a list of all of the datacap request granted by the notary. As the state of the actor does not store the notary who verified a particular client, we could get this info querying the onboarding repo, looking for assignee and granted label