# Features wishes for GVA (GraphQL Verification API)
**URL:** https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600
**Category:** GVA
**Tags:** gva
**Created:** [23 November 2019 19:44 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600 "2019-11-23T19:44:09Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [23 November 2019 19:44 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/1 "2019-11-23T19:44:10Z")
List of wished features for the GVA (GraphQL Verificaton API) [RFC](https://git.duniter.org/nodes/common/doc/blob/graphql_api_rfc/rfc/0003%20RFC%20GraphQL%20API%20for%20Duniter%20Clients.md):
### Meta
- API versioning
- All request returning lists must have a limit (offset, limit) to avoid ddos.
- All request returning list of 0-n elements must be paginated
### Currency
- …
### Money
- Account balance
- Account operation history with offset and limit (paginate) and within a time range.
- Current, (previous? next?) UD value
- Block number/mediantime and UD value of reevaluation (Blocks with UD amount \> previous UD block), like blockhain/with/ud, but blockchain/with/reevaluation
- Handle sources for a transaction : by telling only the issuers, the amount and the recipients, create the transaction object (handling the sources multiple conditions and the refound).
- Transaction times: `treatedTime`: when it enters the blockchain, `receivedTime`: when the transaction have been received in the mempool
- List of UD created (consumed and not consumed) by specifying a pubkey, a field could indicate if the UD was consumed
- Sources list should contains the timestamp of the tx referenced by the source, to evaluate CSV() and CLTV() unlock conditions.
### WoT
- `Idty`: `uid` from a pubkey
- `Identities`: `uids` from a list of pubkeys
- Way/path to retrieve and to filter into the identities, the membership, and the certification documents (revocation? seems useless)
- List memberships documents from an identity
- Exclusions event over WebSocket: [DeathReaper](https://git.duniter.org/clients/python/silkaj/issues/256) could listen the exclusions rather than listening to the blocks flow
- [`membershipChainableOn` field](https://forum.duniter.org/t/entree-pierro-dans-la-toile-de-confiance/7485/5)
### Documents
- Access mempool/sandbox documents: transactions, certifications, identities, membership, and revocation
### Network
List of GVA endpoint of nodes with the latest version and on the consensus blockchain (real p2p clients) see : [[GVA] Add request to get network peers with enough info to make a real p2p client (#1424) · Issues · nodes / typescript / duniter · GitLab](https://git.duniter.org/nodes/typescript/duniter/-/issues/1424)
- Actives branches, in order for the client to be able to send documents (contents related to the branch) to this branches
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [23 November 2019 20:25 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/2 "2019-11-23T20:25:59Z")
La RFC est ici : [rfc/0003 RFC GraphQL API for Duniter Clients.md · graphql\_api\_rfc · nodes / common / doc · GitLab](https://git.duniter.org/nodes/common/doc/blob/graphql_api_rfc/rfc/0003%20RFC%20GraphQL%20API%20for%20Duniter%20Clients.md)
Il faudra la mettre a jours en fonction des besoins qui auront été exposés ici.
En effet cela nous aiderait beaucoup que les développeurs des clients et autres logiciels tiers nous expriment leur besoin, on (nottament @ji_emme, @jsprenger et moi) vas essayer de faire au mieux mais on ne peut pas connaître les besoins aussi bien que vous 🙂
---
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [23 November 2019 20:27 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/3 "2019-11-23T20:27:27Z")
Je préfère lister ça dans un wiki.
Flemme de faire des `git commit` pour ça.
Ça viendra une fois que ce wiki se sera étoffé.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [23 November 2019 20:28 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/4 "2019-11-23T20:28:39Z")
T’inquiète je n’ai pas dit que tu devais le faire, je comptais de toute façon proposer des maj de la RFC régulièrement, je pourrais inclure ce qui est validé ici dans la foulée 🙂
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [26 March 2020 11:46 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/5 "2020-03-26T11:46:32Z")
J’ai ajouté une demande dont j’ai besoin pour le support des conditions de lock/unlock complexes dans Sakia.
Pour résoudre les paramètres CSV(time) et CLTV(timestamp), j’ai besoin du timestamp de la source.
Hors cette info n’est pas dans la liste des sources fournie par BMA.
Je suis obligé de récupérer le timestamp de la transaction référencée par l’identifier de la source, mais encore faut-il que j’ai téléchargé la transaction correspondante dans ma base de donnée…
Bref, pour GVA, j’aimerais si possible avoir le timestamp directement dans l’objet source renvoyé.
Cela a sûrement des conséquences sur le débat des transactions qui survivent aux forks.
Mais cela me semble indispensable pour arriver à gérer facilement les échanges avec CSV, CLTV et par conséquent les échanges en Atomic swap, que Sakia va bientôt essayer de supporter.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [28 July 2020 11:16 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/6 "2020-07-28T11:16:46Z")
> [@Moul](#):
>
> Transaction times: `treatedTime` : when it enters the blockchain
Je préfère `writtenTime`. C’est plus consistant avec le champ writtenOn déjà utilisé partout dans le code. C’est bien la date d’écriture en blockchain qui nous intéresse ici, et non pas la date de “traitement”, qui ne veut rien dire car il y a des traitements dès réception.
> [@Moul](#):
>
> List of UD created (consumed and not consumed) by specifying a pubkey, a field could indicate if the UD was consumed
Je préfère donner deux listes de numéros de blocs, une pour les DU consommé, et une pour les DU non-consommés. Car c’est ainsi que la data est présente en BDD.
> [@Moul](#):
>
> Sources list should contains the timestamp of the tx referenced by the source
On peut généraliser un champ `createdOn` pour toute source. Dans le cas d’un DU c’est le medianTime du bloc qui l’a créé, et dans le cas d’une UTXO c’est la date d’écriture en blockchain de la transaction d’origine. Cela vous conviendrait-t-il ?
> [@Moul](#):
>
> Way/path to retrieve and to filter into the identities, the membership, and the certification documents
A préciser
> [@Moul](#):
>
> Exclusions event over WebSocket: [DeathReaper](https://git.duniter.org/clients/python/silkaj/issues/256) could listen the exclusions rather than listening to the blocks flow
Ce sera géré par les souscriptions. Les souscriptions correspondant à des événements, le plus simple est de mettre en place une souscription par type d’événement dans un bloc : joiners, excluded, etc
> [@Moul](#):
>
> List of GVA endpoint of nodes with the latest version and on the consensus blockchain (real p2p clients)
Je ne comprends pas ce qui est nommé “the latest version” ici.
Il n’y a pas non plus de définition du consensus, ce concept n’existe pas coté Duniter.
Ce sont les clients qui définissent eux-mêmes les critères sur lesquels ils se basent pour définir quel est le consensus de leur point de vue.
Donc si vous voulez que l’API GVA vous donne un “consensus” il faut me préciser selon quels critères vous le définissez.
> [@Moul](#):
>
> Actives branches, in order for the client to be able to send documents (contents related to the branch) to this branches
Idem je ne sais pas ce qu’est une “active branch”, en l’absence de définition précise et non-ambiguë je ne peux rien faire.
---
### Author:  [@matograine](https://forum.duniter.org/u/matograine)
#### Post date: [24 October 2020 13:16 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/7 "2020-10-24T13:16:14Z")
Si on veut faciliter la création de clients anonymes, avec dérivation de clef publique, une requête utile de GVA serait de pouvoir demander les UTXO pour plusieurs clefs publiques en une seule requête.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [7 December 2020 10:40 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/8 "2020-12-07T10:40:59Z")
J’ai mis des cases à cocher pour suivre l’évolution de GVA dans le billet d’origine.
J’ai fait une issue pour la requête des nodes permettant d’avoir un client p2p :
> **[\[GVA\] Add request to get network peers with enough info to make a real p2p...](https://git.duniter.org/nodes/typescript/duniter/-/issues/1424)**
>
> I have made a python helper to help client keep a list of consensus blockchain nodes. The BMA API needs two requests to get all info...
---
### Author:  [@revolunet](https://forum.duniter.org/u/revolunet)
#### Post date: [5 January 2021 12:01 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/9 "2021-01-05T12:01:57Z")
Bonjour,
Est-il possible d’avoir une liste « globale » des dernieres transactions via GVA ? Je n’ai trouvé qu’en spécifiant une clé publique mais ca limite à la clé en question
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [5 January 2021 14:28 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/10 "2021-01-05T14:28:24Z")
> [@revolunet](#):
>
> Est-il possible d’avoir une liste « globale » des dernieres transactions via GVA ?
Non ce n’est pas possible et la DB n’est pas conçue pour, il faudrait dont modifier la DB, faisable mais compliquer comme contribution, donc ça ne pourra pas être dans les 1ères choses que feront les futurs contributeurs de GVA
---
### Author:  [@kimamila](https://forum.duniter.org/u/kimamila)
#### Post date: [6 January 2021 16:38 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/11 "2021-01-06T16:38:28Z")
> [@revolunet](#):
>
> Est-il possible d’avoir une liste « globale » des dernieres transactions via GVA ? Je n’ai trouvé qu’en spécifiant une clé publique mais ca limite à la clé en question
Via les derniers blocs, ou une subscription sur newBlock, ca me parait pas trop compliqués.
Peut-etre ajouté une fonciton pour récupérer les blocs avec un filtre `withTx: Boolean`
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [6 January 2021 17:41 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/12 "2021-01-06T17:41:07Z")
> [@kimamila](#):
>
> Via les derniers blocs, ou une subscription sur newBlock, ca me parait pas trop compliqués
> Peut-être ajouté une fonction pour récupérer les blocs avec un filtre `withTx: Boolean`
Ce n’est qu’un changement d’API mais la difficulté côté back reste la même, car les tx par bloc ne sont pas encore en base (on a que les meta-données des blocs).
Il faut créer une nouvelle collection, par exemple de type (BlockNumber, [TxHash]). Rien d’insurmontable pour quelqu’un de bien expérimenté en Rust et à l’aise avec la codebase de GVA, mais pour un nouveau contributeur c’est pas le plus simple car ça touche au schéma de la DB.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [20 January 2021 08:52 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/13 "2021-01-20T08:52:38Z")
@gerard94 je soutiens ma thèse le 2 février, après ça on pourrait se faire une séance ensemble pour regarder les feature wishes de wotwizard pour GVA ?
Ça permettrait de rendre wotwizard indépendant d’une version de duniter. Ensuite on pourrait voir comment rendre l’API Graphql de Wotwizard accessible à l’extérieur et enfin on pourrait développer facilement un client wotwizard et utiliser des données de wotwizard dans les clients 🙂
---
### Author:  [@gerard94](https://forum.duniter.org/u/gerard94)
#### Post date: [20 January 2021 20:39 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/14 "2021-01-20T20:39:19Z")
Oui, bien sûr.
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [14 February 2021 18:07 UTC](https://forum.duniter.org/t/features-wishes-for-gva-graphql-verification-api/6600/15 "2021-02-14T18:07:40Z")
Pour Tikka, et pour tous les clients GVA en général, je souhaite utiliser la requête des Heads/Peer comme indiqué dans cette demande, pour être vraiment p2p dès le départ :
> **[\[GVA\] Add request to get network peers with enough info to make a real p2p...](https://git.duniter.org/nodes/typescript/duniter/-/issues/1424)**
>
> I have made a python helper to help client keep a list of consensus blockchain nodes. See : https://forum.duniter.org/t/fonction-daide-pour-avoir-un-vrai-client-python-p2p/7821
Je lance un appel à Hackathon en ligne à @tuxmain, @poka et ceux qui ont suivi la formation GVA/Rust. Pourrions nous proposer un commit avec cette fonctionnalité ? Êtes-vous dispo en Février/Mars ?
Merci de me contacter en privé.
« _Sky is the limit !_ » 😉