Add validator name to delegations/debonding_delegations endpoints

[pro-wh]

Currently we only return the entity ID to represent a validator for some endpoints, mainly the delegations/debonding delegations: https://testnet.nexus.oasis.io/v1/consensus/accounts/oasis1qrfzje4yzruzayezpdc79fhsaul4lshwyqyy2gvu/delegations?limit=5&offset=0

Request from frontend: Add the validator name when available to the api responses

---

Comment from @buberdds:

Hey @Andrew Low, now when I think about it I think we need something more.

https://explorer.dev.oasis.io/mainnet/consensus/address/oasis1qqnk4au603zs94k0d0n7c0hkx8t4p6r87s60axru?page=2

Staking card (delegations API) validator column oasis1…9eu2ev

Transactions (transactions API) to column oasis1…9eu2ev

but in case of transactions API it doesn't make sense to add ValidatorMedia and check if any addr is in validators list.

This all could work with extending Named Account account-names/mainnet_consensus.json , but validator addresses can change so it cannot be hardcoded.

@Peter I remember you had some idea, but I don't remember details.

side note: when designing solution let's keep in mind that long term it is not only about validators, but also ERC-20 and ERC-721 tokens names/addresses. Can these be hardcoded in account-names ?

---

Comment from Peter:

My idea would be to keep the APIs as they are, and on frontend, query the ValidatorMedia for all validators once and then store/cache the responses locally in client store for some time (e.g. 5 minutes or until the page is refreshed). Then, on the frontend, whenever you are dealing with addresses, additionally check the local store to see if the address has a name and use it.

I have no idea how simple/hard this is to achieve in our frontend architecture, but to me, it seems a very logical solution and is general enough that I can also work for other types of named addresses (account names, token names...).

---

Comment from @buberdds:

ahh so just fetch all validators whenever we need it usinghttps://nexus.oasis.io/v1/consensus/validators and transform response to key/value map

other than that

• works until we hit 1000 validators

• different frontend logic compared to other account names

• validators endpoint is slow (but caching response for a few minutes is fine here)

This sounds good. Thanks will do it this way.

---

Comment from @buberdds:

What about tokens ERC-20 and ERC-721 tokens names/addresses? This cannot be fetched like validators because of is_total_count_clipped: true.

---

Comment from Peter:

different frontend logic compared to other account names

Yeah different logic for fetching from API, but on the frontend I believe it can be unified so that on that end it would be the same.

validators endpoint is slow (but caching response for a few minutes is fine here)

We can/should also look into improving the endpoint performance on the backend. But yeah even then we should still cache this on frontend as well.

Feel free to create a task for this it is problematic.

What about tokens ERC-20 and ERC-721 tokens names/addresses? This cannot be fetched like validators because of is_total_count_clipped: true.

I'm not familiar with that part of the API, how is it currently fetched? We can make the needed changes on the API to make it simpler/more convenient.

[ptrus]

We decided against this: #769 (comment)