Payer ses légumes en Ğ1 sur Cagette.net


#1

Bonjour à tous,

Je suis le développeur de Cagette.net, une plateforme web qui permet aux producteurs de vendre leur produits en direct, sans intermédiaire ni commission.
Beaucoup d’AMAP, de groupements d’achats associatifs ou de collectifs producteurs utilisent notre plateforme pour organiser des commandes de produits locaux et souvent bio.
Notre code est libre en grande partie.

ça faisait longtemps que je pensais implémenter le paiement en Ğ1 sur Cagette, et suite à l’apéro monnaie libre à Bordeaux hier soir, je me suis motivé et ai passé un peu de temps pour voir si c’était faisable…
Il y a 30 000 familles sur Cagette donc ça serait super intéressant de pouvoir leur proposer d’utiliser la Ğ1 pour acheter leur alimentation en direct auprès des producteurs ( si ils sont d’accord, mais ça c’est une autre histoire ). Je suis convaincu que les monnaies alternatives se développeront vraiment quand il sera possible d’acheter des choses “essentielles” ( l’alimentation, le logement, l’énergie, la santé… ), j’ai donc là l’occasion d’ajouter mon grain de sel pour développer le côté alimentation.

BREF , j’ai un prototype qui fonctionne sur notre instance de test ! :

http://pp.cagette.net/group/724

( il faut s’inscrire pour valider la commande si vous voulez aller jusqu’au bout )

Question techniques :

(J’utilise l’API de virement de Cesium https://g1.duniter.fr/api/#/app/home)

Je reçois sur la return_url plusieurs paramètres : par exemple
{amount : 120, tx : undefined, pubkey : 8vSBtv7tuKCASYkA4UjRvrMLKAdMx2Vhg9tXVzttXQuU, comment : Paiement Cagette.net, hash : A18355A991BEEAF…4E18A754E1D050F}

tx est undefined, c’est quoi ? l’id de transaction ? c’est undefined car ça n’a pas été encore traité par la blockchain ?

à quoi correspond le Hash ?

Comment vérifier que la transaction a bien eu lieu ( avec le bon montant, le bon destinataire ) pour que Cagette.net puisse valider le paiement définitivement ?
On gère déjà les paiements qui se valident plus tard ( par exemple un virement, ou un paiement en espèce sur place ) donc on pourrait imaginer un cron qui checke les paiements en G1 non validés en interrogeant Cesium ou un node directement …

Remarque : amount est en “centimes de G1” , c’est une pratique courante dans ce genre d’API mais c’est précisé nulle part :wink:

Merci de votre aide :broccoli::leafy_green::cucumber::potato::carrot::corn:
-François


#2

Pour le moment la seule façon de faire est de requeter l’api BMA pour y retrouver ta transaction, la documentation est ici : https://git.duniter.org/nodes/typescript/duniter/blob/dev/doc/HTTP_API.md

Effectivement ça peut être fait avec une tache cron. L’idéal étant d’avoir un tableau de 3 ou 4 noeuds en lesquels tu a confiance, pour pouvoir en avoir au moins 1 qui te répond si les autres sont down :slight_smile:

EDIT: Le hash je crois que c’est le hash de la transaction, et que tu doit le garder en mémoire pour pouvoir le founrir a BMA afin de retrouver la dite transaction. Sinon une autre façon de faire est d’ajouter une référence dans le commentaire de la transaction et de chercher dans les réponses de BMA la dite référence :wink:

EDIT2: c’est @kimamila qui a dev l’api cesium, il pourra te dire pourquoi le champ tx est a undefined :slight_smile:


#3

@Bubar, après avoir fini le dev, je pense que ce serait une bonne idée de poster sur https://forum.monnaie-libre.fr :slight_smile:


#4

Oui bien sûr, mais je m’occuperai de la com quand tout sera prêt :slight_smile:


#5

Extra ça !!
On est preneur pour tester ta solution ici, car on a justement besoin d’outil pour notre gcoop !

Je vais regarder ce qui cloche dans l’API (le undefined notamment) et voir comment on peut gérer facilement la validation.
Ça devrait pas être compliqué, car maintenant les noeuds Césium+ (ElasticSearch) indexe les transactions de manière unitaire.
Par exemple :
https://g1.data.duniter.fr/g1/movement/_search?pretty&q=merci

Il faudrait juste que j’y ajoute le hash de la transaction pour des recherches plus rapide.
Dans référence, tu peux savoir si le block est validé depuis longtemps, par le numéro.


#6

Merci @kimamila
Si je cherche par clé publique ça marche : https://g1.data.duniter.fr/g1/movement/_search?pretty&q=8vSBtv7tuKCASYkA4UjRvrMLKAdMx2Vhg9tXVzttXQuU

Mais effectivement par hash, ça ne fonctionne pas : https://g1.data.duniter.fr/g1/movement/_search?pretty&q=A18355A991BEEAF247552FBDDE470FFE38C0B7586F2EAD3DC4E18A754E1D050F
(d’ailleurs les hash que je vois dans le résultat de la premiere requete ne correspondent pas à ceux que j’ai eu dans la return_url )

Dernière question : est ce que c’est le hash ou le tx qui représente l’ID unique de la transaction ?

Sinon pour ta coop, je t’ai PM :wink:


#7

Le hash dans reference est celui du bloc. Un bloc est identifié de manière unique par son [number, hash] (que l’on appelle aussi le blockstamp).
Au sein d’un bloc, il peut y avoir plusieurs TX, mais le TX.hash est unique.
n’hésites pas à explorer les données de la blockchain, pour comprendre, en cliquant sur un bloc dans la vue réseau de Cesium, par exemple. Tu pourra avoir accès au fichier brut facilement (en JSON)


#8

En cas de Fork, est-il possible de trouver la transaction effectuée et qu’ensuite elle disparaisse lors de la résolution de fork et donc après l’expédition de la marchandise ?


#9

Ce qui est possible et qui arrive hélas assez souvent est qu’en cas de fork, si la transaction (via son blockstamp) se base sur un bloc qui n’existe pas sur la chaine majoritaire, alors la transaction n’est pas re-jouable sur cette chaine majoritaire (car elle mentionne un blockstamp (blockNumber + blockId) qui n’existe pas dans la version actuelle de la vérité.

La solution pour s’en prémunir est d’antidater les transactions, ou attendre x blocs pour se prémunir de fork éventuel.

La fenêtre de fork par défaut sur le réseau est de 100 blocs, laisser la TX en attente autant peut être contraignant pour les clients. (8h avant validation du paiement ^^).

Il faut donc trouver un juste milieu entre risque et délais. J’ai choisi 6 blocs personnellement, mais en cas de gros fork, ça veut dire soucis en perspective niveau support. :wink:


#10

Ce thread


semble évoquer une solution qui minime les forks et qui serait peut-être plus favorable au e-commerce.


#11

Je pense que le souci est ailleurs pour ma part, le faite que les TX ne soit pas rejouable me dérange. ^^

On a bien évoqué le sujet dans différents topics.


#12

@Bubar > Si jamais tu fais un truc qui s’intègre à de la vente d’infoproduits sur Wordpress, genre une gateway pour WooCommerce, ça m’intéresse :slight_smile:


#13

Bonjour , je viens de voir vôtre article et je voulais savoir si ont peu payer ses légumes en G1 aujourd’hui ?


#14

@ben79 : Ici c’est plutôt le forum technique. Le forum des utilisateurs c’est https://forum.monnaie-libre.fr. Sinon oui dans certaines régions, des gens vendent des légumes en Junes.