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 !
1 Like
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 
2 Likes
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 ?
1 Like
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[…]
- si vous avez des infos concernant history/pubkey/pending
- d’apres mon schema, est ce que ce serait plus judicieux de faire en sorte par exemple, une requête tx/[hash tx]/pending ?
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
1 Like
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 :
- [cb] [tpe] [duniter] sont 3 entités distinctes ; 3 “machines” différentes
- l 'encadrement vert et on utilise plus que 2 “machines” => [ [TPE] + [DUNITER] ] sont parties integrantes d’une même machine
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
1 Like
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.
- La possibilité pour eux de participer a la sécurisation de la monnaie est un argument de poids.
- Le coût de ce matériel est “peu onéreux” → argument ++
- Si en plus on peut projeter un systeme tel que “remuniter” dans ce cadre, c’est un argument +++.
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
1 Like
Clairement non , aujourd’hui ce que rapporte remuniter est dérisoire par rapport a l’énergie qu’il faut mettre à disposition du réseau, et ce sera encore plus vrai pour des petits appareils tel des TPE, de plus cela fera consommer considérablement plus de bandes passantes dans un cas d’application ou l’on souhaite justement la limitée, j’insiste mais vouloir intégrer un nœud duniter, sur le TPE me semble vraiment une mauvaise idée, même pour un nœud mirroir…
3 Likes
Je reviens pour y voir + clair.
Selon la solution envisagée => voir les points 1 et 2 sur le schema,
voici la problematique relevant de la communication et du traitement de l’information entre TPE <=> Duniter
-
TPE envois lors de la 2e requete que la signature a Duniter
=> contraintes: la 1ere et la 2eme requete s’effectuent sur le même noeud.
=> les + : on diminue le traffic réseau . On peut envisager des websockets. -
TPE envois l’ensemble [ donnée transaction + signature ]
=> les + : la 1er et la 2eme requete sont indépendantes.
=> les - : on augmente le traffic réseau
Dans les 2 cas, une fois la transaction enregistrée en blockchain, on peut prendre n’importe quelle adresse de noeud…
Edit : pour une réponse a ce dernier message, utiliser le topic suivant:
https://forum.duniter.org/t/systeme-transaction-discussion/
Quelqu’un saurait m’expliquer l’intérêt du champ offset ?
Je n’ai pas trouvé sa définition dans la documentation du protocole ni de l’API BMA.
Et, cette définition me semble fausse, car c’est le rôle du champ identifier de référencer la source de monnaie.
-
identifiercorrespond :- soit à une clé publique (pour le DU)
- soit au hash d’une transaction
-
posvaut :- soit le numéro du bloc contenant le DU pour la clé publique
- soit la position de la source au sein de la transaction visée par le hash
identifier
De sorte que identifier + pos permette d’identifier une source de monnaie de manière unique sans aucune ambiguïté.
1 Like
Donc, si j’ai bien compris, offset indique la position de la source crée dans la transaction qui créer cette source ?
Par exemple les outputs de cette transaction :
"outputs": [
"8032:0:SIG(6Zajb1e1uwadPNXa2gEwFLMuWp7koMBDkcTAD5TK6uqd)",
"7294:0:SIG(DQh2YyvsGbfehrDmYta3XZXwqNpQXx7yeRMK7Ak59JMg)"
],
devrait avoir comme offset 0 pour la première et 1 pour la seconde ?
1 Like
Oui. Et pour le hash, avec seulement cet extrait, on ne peut pas savoir.
1 Like