(Feature) Render validators' registered (unconfirmed) physical address from PoPA

[unjapones]

The PR that implements #74 only retrieves & renders a confirmed address from PoPA. This issue covers retrieving & rendering a registered (unconfirmed) address.

This also aims to prioritize the address information. The following list may represent the order of how reliable the information is:

1. Confirmed physical address from PoPA.
2. Registered (unconfirmed) address from PoPA.
3. Already existing address from ValidatorMetadata.sol (fallback scenario, meant to be deprecated/dropped/hidden?)

How this is prioritization is represented on the UI needs to be defined.

[unjapones]

Assigned the people that may be involved in the definitions of this ticket, following the suggestions of this comment. Sorry in advance for the spam.

[varasev]

I think we should display address information for each validator in the following manner:

• First of all, display all confirmed addresses from PoPA contract for each validator. If there is at least one confirmed address, don't display unconfirmed addresses from PoPA and address from ValidatorMetadata.

• If there are no confirmed addresses from PoPA, display unconfirmed addresses from PoPA but with Unconfirmed label. If there is at least one unconfirmed address, don't display an address from ValidatorMetadata.

• If there are no confirmed or unconfirmed addresses from PoPA, display the address from ValidatorMetadata contract (fallback scenario) with the same Unconfirmed label.

I suggest to represent the list of addresses in the following manner:

Example for confirmed addresses from PoPA:

Example for unconfirmed addresses from PoPA:

Example for unconfirmed address from ValidatorMetadata:

If there is only one address (either confirmed or not), don't display #1, as on the last screen.

Also, we should remove the displaying of State and Zip Code rows and display state and zip code inside Confirmed Address or Unconfirmed Address row, separating those from the address with a comma, as it's shown on the screens above.

Does anyone have some other thoughts or suggestions?

[igorbarinov]

Vadim, I like your idea. Could we have information about token/ token registry on hover? e.g. like we have in the bridge https://cl.ly/9b5d30ad0a8d

[varasev]

@igorbarinov Could you specify exact information that we should display about token/ registry?

I see that EthereumClaimsRegistry contract stores confirmation block number.

ProofOfPhysicalAddress contract stores physical addresses and creation block number/ confirmation sha3 code for each physical address.

[vbaranov]

I like the proposal☝️. My 50 POA wei to it:

1. Unconfirmed/confirmed takes a lot of space - it could be changed to badges as it proposed in original issue https://github.com/poanetwork/poa-dapps-validators/issues/74#issue-351271440 (though it will take some work from a designer)
2. There is no reason to copy Address at every line
3. I'm not sure, do we need a counter for those addresses?

Proposed compact view of card with multiple addresses could looks like this:

Proposed view for a card with a single address:

[pashagonchar]

Zeplin:https://zpl.io/2jw7P46

[unjapones]

@pashagonchar I believe each Address item is comprised of Street + State + Zip Code, and they don't have a State and Zip Code in common (like the mockups that @varasev posted on his 1st comment), should we update the Zeplin?

[pashagonchar]

@unjapones Zeplin: https://zpl.io/2jw7P46

[varasev]

Let's display the addresses as it's shown in the comment above but remove State and Zip Code rows.

@igorbarinov @vbaranov Do you think we should display confirmed addresses along with unconfirmed ones as it's shown in that comment? Or the logic described here should be implemented?

[vbaranov]

@varasev I would suggest displaying as much info from POPA DApp as we have. So I vote to display both: confirmed and unconfirmed addresses.

[igorbarinov]

I agree that we should display as much information as possible from POPA Dapp. For some apps, like bridge, it was important to hide some information because it was not important for end users. Users of validators dapp will use it to get as much information about validators as possible.

[varasev]

@unjapones Well, let's display both confirmed and unconfirmed addresses from PoPA then, as it's shown here (without State and Zip Code rows). The address from ValidatorMetadata should only be displayed if there are no addresses for validator in PoPA contract (as a fallback scenario).

[unjapones]

@varasev @igorbarinov @vbaranov since we agreed to show the address from ValidatorMetadata as unregistered and as a fallback scenario, then the form to set the Metadata of a validator will still show the corresponding fields.

Do we want to add a link to the PoPA DApp on the set Metadata form and/or hide its address fields? this is the 3rd item that @pablofullana originally described in #74

P/s: we should probably discuss this in #79

[varasev]

Answered here: https://github.com/poanetwork/poa-dapps-validators/issues/79#issuecomment-418414058