Add further fields to include approximate time

[sborrazas]

The fields and endpoints are the following:

• approximate_last_updated_time in channels/{stateChannelId}
• approximate_last_updated_time in channels endpoint
• approximate_activated_time in names (with expand=true) endpoint
• approximate_auction_end_time in names/auctions endpoint
• approximate_expiration_time and approximate_auction_end_time in names/{name} endpoint
• approximate_created_time in accounts/{nameHash}/activities (for cases if micro_time is not available) endpoint
• approximate_created_time in contracts/logs?contract_id={contractId} endpoint
• approximate_activated_time in oracles endpoint
• approximate_registered_time in oracles/{oracleId} endpoint

refs #831

[janmichek]

In the state channel responses, I see the attribute name lastUpdatedTime so this is the exact time, not an approximate?

[sborrazas]

In the state channel responses, I see the attribute name lastUpdatedTime so this is the exact time, not an approximate?

@janmichek that is correct

[janmichek]

Question on the oracles responses:

So the registerTime is the time value of activeFrom?
What is the value of register for? Is it a keyblock value? How it can be registered in future?

[sborrazas]

@janmichek the value for register is the transaction index of the register, same with extends. We had to keep txis for backwards compatibility, but please use tx_hash=true for these endpoints, which will be the behavior of v3. e.g. https://mainnet.aeternity.io/mdw/v2/oracles/ok_2NRBaMsgSDjZRFw4dU82KCqLa5W7aQdbJAzaFprTpjEGLAzroV?tx_hash=true

[janmichek]

Are you sure this naming is precise? I would expect approximate_action_end_time. The word expire is used for the end of the name lease.

https://mainnet.aeternity.io/mdw/v2/names/auctions?by=expiration&direction=forward&limit=10

[sborrazas]

@janmichek that's true, approximate_auction_end should be present there to indicate when the auction will terminate, as oppose to expire_time which indicates when the name will expire. I'll add it to names

[janmichek]

approximate_activated_time in names (with expand=true) endpoint

It seems to be missing (or some other similarly named value) in response

https://mainnet.aeternity.io/mdw/v2/names?state=active&by=activation&direction=backward&limit=4&expand=true&by=activation

[janmichek]

approximate_expiration_time and approximate_auction_end_time in names/{name} endpoint

seems to be missing

https://mainnet.aeternity.io/mdw/v2/names/dragonflycaptain.chain

[janmichek]

ping

[sborrazas]

@janmichek I forgot to reference this issue on the PR, but this is already implemented on #1573 and will be available on the next deploy

[janmichek]

Cool, thanks!

[janmichek]

There still seems to be 2 walues missing from initial requirements

approximate_expiration_time in names/{name} endpoint
https://mainnet.aeternity.io/mdw/v2/names/paradigm.chain

approximate_activated_time in names (with expand=true) endpoint
https://mainnet.aeternity.io/mdw/v2/names?state=active&by=activation&direction=backward&limit=4&expand=true&by=activation

Can you add it please?

[janmichek]

Hello, there does not seem to be approximate_activated_time to https://mainnet.aeternity.io/mdw/v2/names?state=active&by=activation&direction=backward&limit=4&expand=true&by=activation endpoint.

Also, I got one new minor request to add approximate_activated_time to names/{name}

Can you process it please?

[sborrazas]

@janmichek these changes are part of v3, and present on a route like https://mainnet.aeternity.io/mdw/v3/names?state=active&by=activation&direction=backward&limit=4&expand=true&by=activation .

I will now add the /names/:name route to v3 as well.

[janmichek]

Excellent, thanks for clarification and further addition

[sborrazas]

/names/:name added to v3

[janmichek]

/names/:name added to v3

Thank you. I was checking that. Compared to V2 there is no name fee in V3 we have been using, so I cannot switch to V3 for that reason. How do you think you could fix it?

[sborrazas]

@janmichek can you indicate where the name fee appears in v2?

[janmichek]

@janmichek can you indicate where the name fee appears in v2?

UPDATE:

1. I cannot switch to V3 of /names/:name because there are pointers missing
2. I cannot switch to V3 of https://mainnet.aeternity.io/mdw/v3/names?state=active&by=activation&direction=backward&limit=4&expand=true&by=activation because there is a name_fee missing

[sborrazas]

@janmichek sorry, but I didn't see where the name fee is. can you indicate where the name fee appears in v2?

[janmichek]

@janmichek sorry, but I didn't see where the name fee is. can you indicate where the name fee appears in v2?

https://mainnet.aeternity.io/mdw/v2/names?state=active&by=activation&direction=backward&limit=4&expand=true&by=activation

[sborrazas]

@janmichek it's part of the first claim, not the top name object. In v3, we no longer return nested lists of things, this is not proper API design. Would you rather include name_fee attribute on the name?

[janmichek]

I see. It does not have to be a nested value with the whole history of claims. This is the UI I want to preserve

[sborrazas]

@janmichek cool, I'll update the name so that it includes this information, that way you won't have to rely on nested lists of claims, or any list of anything, including pointers

[janmichek]

Hello, I can see now that nameFee has been exposed, but I still miss the pointers
Is it something that will be delivered?

Side question: You mention that a nested list is an antipattern for API, but for the name in auction, I cab see a nested object. Why it's like that? (I don't have specific preference, just curious )

[sborrazas]

Hello, I can see now that nameFee has been exposed, but I still miss the pointers Is it something that will be delivered?

Side question: You mention that a nested list is an antipattern for API, but for the name in auction, I cab see a nested object. Why it's like that? (I don't have specific preference, just curious )

Nested lists are part of the old legacy API which was not properly designed. V3 shouldn't contain any of these lists, auctions currently doesn't: https://mainnet.aeternity.io/mdw/v3/names/auctions

[janmichek]

Hello, I can see now that nameFee has been exposed, but I still miss the pointers
Is it something that will be delivered?

@sborrazas

[janmichek]

@yaboiishere @sborrazas

[sborrazas]

Pointers are already returned via the /v3/names/:id/pointers endpoint https://mainnet.aeternity.io/mdw/v3/names/unchain.chain/pointers. But for some reason it's not paginated, we will work on that next

[janmichek]

Pointers are already returned via the /v3/names/:id/pointers endpoint https://mainnet.aeternity.io/mdw/v3/names/unchain.chain/pointers. But for some reason it's not paginated, we will work on that next

Should I daisy chain the call of /v3/names/:id/pointers for every row in v3/names listing? The previous v2 solution was just fine.

[sborrazas]

We wouldn't want to return an unlimited list of things at any of the endpoints we have, but I just asked the node team and it looks like there's a limit of 32 pointers max. In this case we can add them to the names list like the node does @yaboiishere is working on that

[sborrazas]

Pointers is now part of the names object on v3. Closing