Features wishes for GVA (GraphQL Verification API)

API GVA
#1

List of wished features for the GVA (GraphQL Verificaton API) RFC:

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

    • Multiple balances in the same query

  • 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 could listen the exclusions rather than listening to the blocks flow
  • membershipChainableOn field

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

  • Actives branches, in order for the client to be able to send documents (contents related to the branch) to this branches
3 J'aime
Liste des DU consommés avec GVA
RFC API GVA déplacée?
Exclusions de la toile de confiance Ğ1-Test − Expirations des statuts de membre
Récupérer les données en piscine
#2

La RFC est ici : 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 :slight_smile:

1 J'aime
#3

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é.

2 J'aime
#4

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 :slight_smile:

#5

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.

1 J'aime
#6

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.

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.

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 ?

A préciser

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

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.

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.

#7

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.

1 J'aime
#8

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 :

1 J'aime
#9

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

1 J'aime
#10

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

3 J'aime
#11

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

3 J'aime
#12

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.

#13

@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 :slight_smile:

1 J'aime
#14

Oui, bien sûr.

1 J'aime
#15

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 :

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 ! » :wink:

2 J'aime