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.

Currency

  • …

Money

  • 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
  • Account balance
  • 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).
  • Account operation history with offset and limit (paginate) and within a time range.
  • 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

  • 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)
  • Actives branches, in order for the client to be able to send documents (contents related to the branch) to this branches
3 J'aimes
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é.

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