# Prototype de GVA
**URL:** https://forum.duniter.org/t/prototype-de-gva/7688
**Category:** Duniter-v1
**Tags:** gva
**Created:** [18 October 2020 14:40 UTC](https://forum.duniter.org/t/prototype-de-gva/7688 "2020-10-18T14:40:53Z")
**Posts on this page:** 20
**Page:** 7
### Author:  [@matograine](https://forum.duniter.org/u/matograine)
#### Post date: [23 March 2021 13:26 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/122 "2021-03-23T13:26:18Z")
3 messages ont été scindés en un nouveau sujet : [Supprimer les UserID?](https://forum.duniter.org/t/supprimer-les-userid/8229)
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 April 2021 20:32 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/123 "2021-04-21T20:32:13Z")
@tuxmain a implémenté la requête permettant d’obtenir les fiches de peer et les HEADs, j’aurais préféré qu’un autre contributeur y arrive, mais @HugoTrentesaux et @vit n’ont malheureusement pas poursuivi l’exercice après l’atelier 🙃
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [21 April 2021 21:37 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/124 "2021-04-21T21:37:51Z")
> [@kimamila](#):
>
> est-ce possible via GVA de faire des recherches insensible à la casse ? (sur les UID)
C’est possible dans l’API de graphql de wotwizard
---
### Author:  [@poka](https://forum.duniter.org/u/poka)
#### Post date: [21 April 2021 22:03 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/125 "2021-04-21T22:03:12Z")
Bravo @tuxmain , gestion des fork au démarrage de Gecko imminente.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [21 April 2021 23:05 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/126 "2021-04-21T23:05:01Z")
Pendant le hackathon, @1000i100 à passé une journée en peer programming avec moi pour implémenter la requête GVA « endpoints », cette requête vous retourne tout les endpoints connus pour l’API demandée :
---
### Author:  [@1000i100](https://forum.duniter.org/u/1000i100)
#### Post date: [22 April 2021 11:50 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/127 "2021-04-22T11:50:41Z")
Et du coup, je vois que tu as fait le changement pour mettre endpoints dans network.
aurais-tu le commit de ce changement que je vois comment tu as fait ?
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [22 April 2021 11:58 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/129 "2021-04-22T11:58:03Z")
> **[\[ref\] gva: move query endpoints in network (a6f749ac) · Commits · nodes /...](https://git.duniter.org/nodes/typescript/duniter/-/commit/a6f749acd4f69d6f2d1d76e1fce6c7db8b87955f)**
>
> Crypto-currency software to operate Ğ1 libre currency
---
### Author:  [@1000i100](https://forum.duniter.org/u/1000i100)
#### Post date: [22 April 2021 14:20 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/130 "2021-04-22T14:20:31Z")
Merci !
> **[\[ref\] gva: move query endpoints in network (a6f749ac) · Commits · nodes /...](https://git.duniter.org/nodes/typescript/duniter/-/commit/a6f749acd4f69d6f2d1d76e1fce6c7db8b87955f#dbb939f3398833e90a9f41676cec43e1769a6759_23_33)**
>
> Crypto-currency software to operate Ğ1 libre currency
` network_db.peers_old().iter(.., |it| {`
Je vois à plusieurs endroits `peers_old`. Pourquoi old ?
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [22 April 2021 14:33 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/131 "2021-04-22T14:33:35Z")
> [@1000i100](#):
>
> Pourquoi old ?
Pour différencier de la future collection `peers` qui stockera le nouveau format de fiches de peer, notamment sans les peer partagés et sans les champs obsolètes.
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [23 April 2021 08:06 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/132 "2021-04-23T08:06:21Z")
> [@elois](#):
>
> Pendant le hackathon, @1000i100 à passé une journée en peer programming avec moi pour implémenter la requête GVA « endpoints », cette requête vous retourne tout les endpoints connus pour l’API demandée :
Ca s’annonce bien tout ca ! 🙂
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [12 May 2021 20:50 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/133 "2021-05-12T20:50:05Z")
Ajout du champ `receivedTime ` pour les transactions en mempool: il s’agit de la date et heure de première réception du document transaction par le nœud Duniter.
À la demande de @kimamila, cette information à également été ajoutée dans BMA, dans le champ `time`, ce champ valait `null` pour les transactions en attente, il contiendra désormais la date de réception du document 🙂
À noter que le champ `time` contenait déjà la date d’écriture en blockchain pour les transactions écrites en blockchain.
Il semblerait que le code de Cesium n’est même pas besoin d’être modifié, car la date et heure de la transaction est le résultat de l’expression `time || blockstampTime`
Quant à GVA, il y a déjà depuis plusieurs mois le champ `writtenTime` pour les transactions en blockchain 😉
Aujourd’hui j’ai réalisé quelques tests de ce nouveau champ `receivedTime` et il semble fonctionner. J’ai également testé la bonne valorisation du champ `time` dans BMA pour les transactions en attentes, là aussi ça semble bien fonctionner 😃
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [13 May 2021 05:16 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/134 "2021-05-13T05:16:04Z")
Énorme !
Ça veut dire qu’on va pouvoir s’appuyer sur des blocs plus ancien pour émettre les TX, et limiter au maximum les risques de pertes de TX a cause de fork. 🙂
La prochaine version de Cesium va être sympa (commentaires chiffrés, scan réseau en tâche de fond, TX lié au bloc HEAD - 100) !
Faut juste que je trouve du temps pour la finir 🙂 mais notre bébé va mieux (après des soucis les premiers mois). Je vais pouvoir sortir la tête de l’eau.
---
### Author:  [@Candidesk8](https://forum.duniter.org/u/Candidesk8)
#### Post date: [13 May 2021 08:25 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/135 "2021-05-13T08:25:32Z")
> [@elois](#):
>
> champ `writterTime`
Je suppose que c’est une typo : written time
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [15 May 2021 14:24 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/136 "2021-05-15T14:24:49Z")
Une requête importante pour plein d’outils est les certifications (liste des certifications d’une identité et toutes les certifications).
@elois penses-tu que je peux m’en occuper ? Il me semble que tous les ingrédients sont là. 👨🍳
Je pense ajouter des champs `issued` et `received` à `GvaIdtyDbV1`. (ou `issued_certs` ou `certs_issued`, j’hésite toujours entre l’avantage du préfixage et le respect de la grammaire anglaise)
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [15 May 2021 17:09 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/137 "2021-05-15T17:09:20Z")
> [@tuxmain](#):
>
> @elois penses-tu que je peux m’en occuper ?
Oui tu as les compétences pour. Par contre il faut qu’on prenne bien le temps de réfléchir à quel schéma de DB, et pour cela il faut partir du besoin. Je te propose de commencer par écrire les requêtes graphql que le client doit pouvoir faire, en précisant bien quelles données il doit pouvoir obtenir.
C’est seulement à partir d’une description non-ambigue du besoin qu’on pourra réfléchir à un schéma de DB optimisé pour ce besoin 🙂
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [15 May 2021 17:36 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/138 "2021-05-15T17:36:57Z")
Des outils comme la wotmap et la worldwotmap ont besoin de la liste de toutes les certifications actives :
```auto
query {
certifications() {
issuer # pubkey
receiver # pubkey
}
}
```
Des clients comme Cesium ont besoin des certifications d’une identité, avec leur numéro de bloc d’écriture, et date d’écriture ou date d’expiration :
```auto
query {
certificationsOfIdty(pubkey: String) {
issued {
recipient # pubkey
block_number # ou blockstamp ?
written_time # ou expire_time, ou les deux
}
received {
issuer # pubkey
block_number # ou blockstamp ?
written_time # ou expire_time, ou les deux
}
}
}
```
Les différents moyens que je vois :
- ajouter des champs `issued` et `received` dans `GvaIdtyDbV1`, contenant la liste des certifications. Il faudrait juste les ajouter dans la requête `idty` et créer une requête paginée `idties`.
- pareil, mais en stockant non pas les certifications, mais leur hash. Les certifications seraient stockées dans une autre db, par hash.
Comme il faut pouvoir retrouver les certifications d’une identité, je ne vois pas comment faire autrement sans refaire un index par clé publique, et dans ce cas-là on peut utiliser `gva_identities`.
Avoir les certifications avec les identités rend aussi les choses plus simples pour wotmap et worldwotmap.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [15 May 2021 17:55 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/139 "2021-05-15T17:55:09Z")
> [@tuxmain](#):
>
> Des outils comme la wotmap et la worldwotmap ont besoin de la liste de toutes les certifications actives :
> [@tuxmain](#):
>
> Des clients comme Cesium ont besoin des certifications d’une identité, avec leur numéro de bloc d’écriture, et date d’écriture ou date d’expiration :
Ok donc on doit pouvoir :
- Parcourir toutes les certifications
- Parcourir toutes les certifications émises par une clé publique donnée
- Parcourir toutes les certifications reçues par une clé publique donnée
- Pour chaque certification, avoir comme information: émétteur, receveur, numéro de bloc de création, numéro de bloc d’écriture (toutes dates pouvant être récupérées où calculer à partir de ces données).
De plus, il faut penser aux besoins d’indexation et de revert. On doit donc pouvoir mettre à jour une certification (renouvellement) sans en créer une nouvelle. On doit également pouvoir supprimer une certification lorsqu’elle expire (car cet event n’est pas déclaré dans les blocs).
En vue de ces besoins, voici comment je modifierai la DB :
1. Ajouter une collection `certifications` dont la clé est `issuer || target` et la valeur une struct du genre:
```rust
GvaCertDbV1 {
created_on: BlockNumber
written_block: BlockNumber
}
```
1. Ajouter une collection `certs_by_expire` avec comme clé `U64BE` et comme valeur `Vec<(Pubkey, Pubkey)>`
2. Ajouter un champ `certifiers: Vec` à la struct `GvaIdtyDbV1`.
Et c’est tout, je te laisse réfléchir à pourquoi c’est suffisant pour répondre correctement à tous les cas 😉
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [15 May 2021 18:41 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/140 "2021-05-15T18:41:21Z")
Pour gagner de la place on peut remplacer la clé par un id en u64, [sled permet de générer un id garanti unique](https://docs.rs/sled/0.34.6/sled/struct.Db.html#method.generate_id), il faut juste que je ré-expose cette fonction 🙂
Au lieu d’avoir 6 clés publiques par certification on aurait alors 4 id et 2 clés publiques. Soit `4 x 8 + 2 x 33 = 96` octets par certification au lieu de `5 x 33 = 165` octets par certification.
Ce qui donne :
1. Ajouter une collection `certifications` dont la clé est `U64BE` et la valeur une struct du genre:
```auto
GvaCertDbV1 {
issuer: Pubkey,
receiver: Pubkey,
created_on: BlockNumber,
written_block: BlockNumber,
}
```
1. Ajouter une collection `certs_by_expire` avec comme clé `U64BE` et comme valeur `Vec`
2. Ajouter les 2 champs `certifiers: Vec` et `certified: Vec` à la struct `GvaIdtyDbV1`.
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [16 May 2021 16:53 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/141 "2021-05-16T16:53:56Z")
Ok, juste une question : pourquoi `certs_by_expire` ? pour WotWizard ?
Edit: ou c’est parce que l’expiration de la certification n’est pas dans le bloc ?
donc pour ajouter une certification, il faut d’abord vérifier en parcourant les certifications listées dans le champ `certified` de l’issuer qu’il n’en existe pas une ayant les mêmes issuer et receiver ; si oui, la modifier, si non, la créer.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [16 May 2021 20:51 UTC](https://forum.duniter.org/t/prototype-de-gva/7688/142 "2021-05-16T20:51:12Z")
> [@tuxmain](#):
>
> ou c’est parce que l’expiration de la certification n’est pas dans le bloc ?
Oui c’est ça, je l’ai dit plus haut :
> [@elois](#):
>
> On doit également pouvoir supprimer une certification lorsqu’elle expire (car cet event n’est pas déclaré dans les blocs).
> [@tuxmain](#):
>
> donc pour ajouter une certification, il faut d’abord vérifier en parcourant les certifications listées dans le champ `certified` de l’issuer qu’il n’en existe pas une ayant les mêmes issuer et receiver ; si oui, la modifier, si non, la créer.
Exactement, bien vu 🙂
Donc le champ `certified` ne sera pas un `Vec` mais un `HashSet` 🙂
[Previous page](https://forum.duniter.org/t/prototype-de-gva/7688.md?page=6)
[Next page](https://forum.duniter.org/t/prototype-de-gva/7688.md?page=8)