C’est très simple : ouvre “Mes opérations” dans Cesium et demandes toi comment sont reconstituées toutes les informations affichées :
- le montant du mouvement (et non pas le montant de la transaction, car une transactions peut concerné plusieurs comptes destination")
- le ou les émetteurs / destinataires. il faut penser à exclure les outputs qui concerne les montant non consommé (la monnaie rendue).
- l’heure utilisateur de l’opération
Tout ceci est impossible a avoir directement, tel que tu as modéliser le type Transaction. Il faut bidouiller chaque TX recu, et récupérer tout plein d’info (inputs, outputs) qui ne vont servir que pour calculer ces champs.
Voila, c’est cela que je disais. 
Oui, tout à fait. En revanche je ne trouve pas le nom du paramètre “account” très intuitif… a voir.
Peut-être plutôt :
movementsByPubkey(
paging: Paging!
pubkey: String
state: DocumentState!
): Transactions
movementsByCondition(
paging: Paging!
condition: String
state: DocumentState!
): Transactions
En principe, le développeur du client sait dans cas de figure il se trouve. Il peut aussi requeter les deux en une seule fois, via une requete multiple.
Coté noeud, ca permettra d’avoir des caches plus optimisé, par pubkey ou par condition, car les usages ne sont pas les même, et l’indexation sera différente.
Par exemple, il est légitime que movementsByPubkey retourne aussi les TX dont les conditions utilisent la pubkey (comme un like en BDD) et non pas seulement =SIG(pubkey).
Nous ne sommes pas d’accord la dessus. C’est à toi de prouver que la définition du “temps redressé” ne fait pas déjà consensus, et qu’il y aurait d’autres définitions possibles, plus pratiques, etc. Je n’en connais aucune de plus pratique, après étudier la question à fond. Le temps blockchain est une information technique qui fait consensus, l’heure redressée aussi, dans la mesure où elle est déterminée à partir d’une simple constante liée à la monnaie.
userTime = medianTime + <constante>. Je ne vois pas l’interet de forcer tous les clients à refaire le même calcul. Sauf si , encore une fois, tu as mieux mais alors montre nous ton calcul.
Je rajoute enfin qu’on peut rendre ce champs explicite, par son nommage. par exemple effectiveTime, straightenedTime ou userTime.
Ce temps redressé est parfaitement défini et compris par la plupart des acteurs. Galuel et cgeek compris, avec qui je nous l’avons défini. La formule est quand même assez triviale.
Je ne vais pas attendre patiemment que tu la comprennes.
Non, il ne ‘faut’ pas, justement. En revanche je peux comprendre que tu “ai envie”. Mais c’est tout à fait différent. A ce stade, je me passe volontier de ta permission.
Je vois bien que nous ne sommes pas sur la même longueur d’onde, et je ne vais attendre que tu comprennes tout pour avancer. Si mes choix ne sont pas bons, tu auras donc l’occasion de les critiquer a posteriori, et non pas l’inverse.
Je vais spécifier et coder, et avancer avec du concret, et non pas discuter pendant des heures avec toi.
De toute manière, il n’y a pas encore de noeud DURS en exploitation, si ? Et vous n’avez pas commencé à codé GVA, si ?