Display certification received and issued

One can take inspiration from the Cesium v1 view:

Data source for this will be the duniter-squid indexer. Two dev instances are already available:

• https://subsquid.gdev.coinduf.eu/graphql
• https://gdev-squid.axiom-team.fr/graphql

The query for that will look like:

query CertsViewQuery($identity_index: Int!) {
  identities(where: {index_eq: $identity_index}) {
    index
    name
    certIssued(orderBy: createdOn_DESC) {
      receiver {
        name
      }
      createdOn
      active
    }
    certReceived(orderBy: createdOn_DESC) {
      issuer {
        name
      }
      createdOn
      active
    }
  }
}

It can also take inspiration from wotwizard

added Doing label

assigned to @txels

I'm looking into displaying expiry dates on certifications... what are the units for the "expireOn" values, or in other words how should the "expireOn" values be converted to calendar dates? Not sure if these timestamps (in duniter I think these are referred as type TimestampV1?) are expressed in seconds [or blocks (in duniterv2 these are one every 6s but that is not how v1 works)] since genesis etc... cc @HugoTrentesaux @blavenie

Ah I found in the indexer code: expireOn: expiration_block as number, so this is the block where it will expire. So am I right assuming that the expiry date is something like this pseudocode (assuming all the due time unit arithmetic):

blockDuration = 6  # seconds... this value will eventually be provided by the network
secondsFromGenesisToExpiry = expireOn * blockDuration
expiryDate = genesisStart + secondsFromGenesisToExpiry

(I am making an assumption that genesis is block 0 and all blocks are numbered sequentially)

Although it is quite unclear to me how the data will have been migrated from duniterv1 and how those expireOn block numbers will have been computed.

In Duniter v1, every duration was based on timestamps. In Duniter v2, it is only the case for Universal Dividend and UD reevaluation, the other duration are based on block number which is more convenient to implement and precise enough for the use case.

So in migration script, the expiration timestamp is converted to a block number based on the assumption that they will be spaced by 6 seconds.

You are right that in order to display a value in human readable format, the block number has to be converted back to a timestamp using the same assumption. In Duniter code, it is defined by MILLISECS_PER_BLOCK

You can get it from the runtime metadata in the constants (babe.expectedBlockTime()) like in the screenshot above in polkadotjs app.

Are these block numbers predicted block numbers in Duniterv2, assuming that the Genesis block is 0 and it goes sequentially from there? Then I also need to know what the Genesis block date is, to use that as the reference start date. Am I right to think that these values I have to retrieve from the Duniterv2 API via Polkadotjs?

As an example, for one certificate I have a value of expireon = 10460070

I convert that to e.g. days:

10460070 * 6 / 3600 / 24 -> 726.3937500000001

...I imagine this means 726 days after genesis which seems reasonable for a very recent certificate. So now I have to add the genesis date to that and I'm done?

Currently in Cesium2 that doesn't seem to be available yet, as I'm seeing block 0 attributed to the Unix epoch:

This may just be a problem in the indexed data...

The block 0 is an exception, it does not contain a timestamp. The first timestamp is available in the block 1, you can see block details in the explorer: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fgdev.coinduf.eu%2Fws#/explorer/query/1.

But @poka did a hack to add the block zero timestamp in the indexer: nodes/duniter-squid!4 (comment 40896). It will be deployed on the next network.

As it will never change after the Ğ1 is migrated, it's not a problem to use a hardcoded value. But we can still apply the block zero timestamp estimation trick to get results automatically for gdev networks.

Thanks for the infos, I think I've now correctly implemented this in !10 (diffs) - the expiry dates match the ones I see in Cesium v1

mentioned in merge request !10 (merged)

I realise there are two places where we can show certifications... from any person when browsing their web of trust, and from my account page. I've implemented the first option in !10 (merged), not sure if this ticket was intended for both cases?

mentioned in merge request !13 (closed)

Added a new MR for the wallet page: !13 (closed)

closed