@elois comme il y aura tout un tas de solutions envisageable a mettre en oeuvre, selon les implementations [ technique / coût ] pour le cadre « CB/TPE » je ne fais pas la distinction de qui peut faire quoi 
.
En tout cas, ca nous donne une base de référence sur laquelle communiquer 
ceci étant, derniere mouture… jusqu’a ce que je démonte entièrement le code 
je suis chiant mais je remplacerai “check datas integrity” par “check signature validity” 
honnêtement non, je ne vois pas tous instantanément ,des fois je ne remarque certaines erreurs qu’après 
Vendu !
En passant, tu peux modifier ce fichier svg sur ce site la:
http://editor.method.ac
et le sauvegarder a nouveau en svg pour le partager
yop,
au vu du retour de l’appel a tx/sources/pubkey :
la clé “conditions” de l’objet JSON , cette information me sert a quoi -si ce n’est de me rajouté de la data pour le plaisir - ?
ici, cette clé “conditions” n’est pas présente :
https://github.com/duniter/duniter/blob/master/doc/HTTP_API.md#txsourcespubkey
et “in real life” elle l’est.
https://g1.duniter.org/tx/sources/5cnvo5bmR8QbtyNVnkDXWq6n5My6oNLd1o6auJApGCsv
donc partant du principe qu’au fur et a mesure de nouvelles transactions, cette liste de sources ne fait que s’incrementer, ca va sévèrement piquer a un moment donné pour le traitement de cette liste et check si pubkey a suffisament de fond pour depenser sa monnaie ? je me trompe ? 
(je sais que duniter ne renvois pas les sources déjà consommées…, il me semble) (dans le cadre de traitement par des “petits” mcu, ainsi que la notion de bande passante pour la connectivité internet)
@max l’opération de génération du doc de transaction peut très bien être déléguée a un serveur tier pusqu’elle n’est pas sensible, ce n’est pas un problème 
Oui, c’est vrai qu’en interne, plus le temps passe, et plus il va y avoir de sources à vérifier, mais quand c’est fait en local par une requête sur une base de données, ça se sent pas. C’est exactement le même problème avec n’importe quel système qui tourne sur une blockchain. Ici, je ne pense pas que les nœuds se demandent ce genre d’informations par BMA, puisqu’ils les ont déjà!
Et puis, à terme on devrait pouvoir avoir des “savepoints” (en tout cas il me semble que c’est l’un des systèmes les plus simples pour régler les problèmes de montée en charge sur le long terme, et @cgeek l’a déjà mentionné), et donc de retomber avec un nombre raisonnable de sources à chaque fois.
C’est ce que j’en comprends en tout cas, tapez-moi dessus si je n’ai rien compris. 
Da 
, je vois bien, j’y réfléchis tout de même si je ne souhaite pas délégué cette opération de “composition du document” 
ou plutot preciser que ce sont des unités de traitement pas tres performante niveau rapidité, de vieux cpu / des mcu qui doivent faire le job
Oui @jytou j’entends bien ,
C’est dans le cadre ou mon materiel qui le réalise n’execute pas Duniter et fait bien une requete exterieur sur le reseau a un noeud.
A partir de la, si il peut exister une requete qui me retourne, amount et base, - seules informations nécessaire si je ne m’abuse pour check le solde [et peut etre une info telle la pubkey, au cas ou quelqu’un modifie les données entre duniter => moi et me fait faire tout le traitement dans le vent ] , j’y gagne sur le traffic réseau en bande passante et en traitement des données.
un octet, c’est déjà 8 bits de trop 
d’où
de la meme maniere concernant l’information du hash du block pour faire mon document de transaction, une requete sur le block courrant avec en retour juste le hash relatif au block, ce serait cool
c’est idiot. Il n’y a aucune sorte de raison pour que tu est besoin de générer ce document toi-même !
ta délicatesse me touche 
alors, j’ai rajouter du contenu a la phrase, c’est vrai que dit dans un premier temps, c’etait pas top, maintenant tu peux lire la suite de la phrase…
et ce a fin que tu puisse mieux comprendre mon point de vue - i hope 
voici un N’ieme document 
Je manque de délicatesse certe, mais je maintien, il faut justement d’autant plus délégué dans ce cas d’application
En passant, je n’etais pas ironique =)
c’est toujours un aspect très délicat de gérer les sensibilités de chacun.
Maintenant , c’est la ou il y a une “pseudo” divergence de point de vue, parce que l’on est toutefois d’accord.
Cependant j’insiste sur le fait d’envisager cette possibilité , pour le coût de tels appareils a l’achat, peu onéreux aujourd’hui et de pouvoir réutiliser du “vieux matos”.
Si cela peut permettre de deployer rapidement des solutions, pourquoi pas ?
Oui précisément, il les élague vu qu’elles ne servent plus. Donc une source consommée est tout simplement supprimée de la base de données.
toujours dans le cadre « A envois N unités a B »
Je pointe le doigt sur la partie jaune.
Concernant la possibilité pour celui qui voit son compte crédité lors d’une tx.
Soit le commercant :
j’ai donc 2 requetes qui me permette a présent de m’informer de l’état de tx
qui portent toutes les 2 sur tx/history[…]
est-ce que cela demande + de traitement pour duniter d’ aller chercher dans la bdd et fournir le resultat d’apres le hash de tx ?
d’un autre cote, si j’analyse:
je suis commercant, a priori je peux faire « history/KEY_A/pending » [et/ou] encore « history/KEY_B/pending » et voir si tout match, tout comme avec « /KEY_A/history » et « /KEY_B/history » une fois en blockchain
Dsl je ne comprend toujours pas, est ce parce que tu veut tester le système sans attendre qu’une lib fait génère le doc tx soit développée ? Dnas ce cas ok mais un module duniter a qui tu envoi /tx?form=A&tp=B&amout=X&comment=REF et qui te renvoi le(s) document(s) transactions correspondant ou la réponse “A n’a pas les fond” c’est facile a développer y aura pas besoin d’attendre 3 ans
Pour avoir beaucoup moins de données avec tx/history le commerçant peut faire une requete tx/history/[pubkey]/times/[from]/[to], en tenant compte du décalage entre l’horloge du TPE et l’heure blockchain il peut demander une fenetre courte de 1h autour du moment de la transaction, elle s’y trouvera forcément
ok 
sur le dernier schema, les requetes, ce sont celle en l’état de l’API.
en BLEU , en effet c’est un process qui déporter sur un node -via une lib de duniter- soulage le TPE, ca c’est cool , en + de quoi l’on minimise a 1 requete ( comparé au 2 en bleu actuellement)
maintenant tu me dis si cela te parle :
la 2 eme etape sur le node (receive TX devrait peut etre retourne aussi le hash de TX…?)
@elois j’ai vraiment besoin que tu me dise si tu comprends le dernier schema [tx_cb_tpe_node.svg] et celui-ci:
il est important de noté que DEUX CAS soit envisageable pour la réalisation pratique :
dans le cadre de développement des fonctions concernant l’api Duniter et en ayant une approche systemique,
dans le cas 1 ou le cas 2 => ce sont les memes ‘processus’ → il n’y a que l’usage qui change, exemple :
A) dans le cas 1, je fais appel a une requete web depuis le TPE => en direction de Duniter
B) dans le cas 2, j’integre dans mon programme cette communication en direct
dit autrement, pour dév l’API Duniter, voir / penser le cas n°1 pour réaliser les fonctions,
elles seront réutilisable pour le cas n°2
enfin mes docs sur l’API HTTP telle qu’elle est aujourd’hui ne fait que reveler la relative lourdeur de mise en oeuvre dans “un logiciel client” qui souhaite faire une application de transaction et aussi le flux de données qui peut etre reduit sur le reseau.
on est ok ?
Non mais c’est normal je ne comprend pas les schémas simples, plus c’est compliqué mieux je comprend 
Oui le 2ème je le comprend
Je pense cependant que la plupart des commerçants n’intégrerons pas leur propre nœud duniter, ils ont besoin d’une efficacité a toute épreuve sans se prendre la tête donc dans la pratique il saisirons dans le TPE une liste de 4 ou 5 nœuds duniter qu’il connaissent et dont ils savent que ces nœuds tournent généralement en permanence, et le TPE fera la requête au 1er, au 2ème si le 1er est down, au 3ème si les 2 premiers sont down, etc.
Et pour l’envoi final du document signé il vaut mieux envoyer le même document a plusieurs nœuds directement ça diminue fortement la chances qu’il y a ai un problème, et moins il y a de problèmes moins le commerçant perd du temps qu’il n’a pas a gérer les impayés…
Bref l’idée d’intégrer sont propre noeud duniter au TPE ne me semble pas adaptée. Par contre les commerçant plus conséquents qui disposent déjà d’un ou plusieurs serveurs pour raison pro eux installerons probablement spontanément leur propre nœuds duniter avec leurs TPE qui pointent dessus
Dans le cas de l’usage TPE je préconise un module coté serveur plutôt qu’une lib coté client puisque le but est de réduire le volume de données échangés ainsi que la quantité de calculs effectuée par le TPE.
Après il faudra attendre qu’un dev code un tel module, tu peut lancer en appel en proposant de financer en Ğ1 le développement d’un tel module
De mon côté , j’envisage que -oui- des “petits commercants” peuvent implementer un systeme comme le cas n°2 [TPE+DUNITER] en un module.
Je suis OK avec toi
on pense la même chose il me semble.
oui , patience patience, au vu de la stimulation de ce topic, ca va peut etre venir tres rapidement
c’est à l’étude