Bah moi j’ai exactement le même résultat
Je pense que tu n’as pas ajouté la lecture de la clé publique 
1 Like
YES en reprenant ta dernière version c’est nickel, j’ai jsute change:
# BytesIO adds a stream interface to bytes
# qr = BytesIO(b"here is the binary data in the QRcode")
qr = open("qrcode-AXfA-M5faml2THvBAmPs.bin","rb")
qr = BytesIO(qr.read())
Cool merci
1 Like
Je récupère bien les données gchange à partir du binaire qrcode en python:
./main.py
ZBd+XSdLmjNvoJgQ3wMTnSxqxVjSdCAMNeGQH8curcGpPMk7+2MjRTA6yotDiYq28uLBYG9LCbL28uJyhp7mEnpPl9HTWoakrZye1jKuNZdyuamU7sYSLjaUcL6+hHMnRcuDps/Eid5Tnx6kviDUa8rfpbbiIHVl71Jb+l/Ulr9H7b5YL7Z9/0Td0Y85XnWY459+(IMAGE_BASE_64)
1613850242
2 POLOS FRED PERRY
1 rouge impec 25 G1
1 blanc 1 tâche très claire et peu visible dans le dos 15 G1
Taille XS
LES 2 POUR 40 G1
Envoi MONDIAL RELAY souhaité (la Poste c'est cher, archaïque et pas pratique... )
*** VOIR MES AUTRES ANNONCES ! ***
Du coup, même pour annonce gchange, on suppose que le prix et la clé publique du vendeur son toujours encodé dans le qrcode, donc jamais besoin de les récupérer en ligne ?
Oui, la clé publique et le prix sont toujours dans le QRcode.
@matograine Est-ce que générer ce format de QRcode t’intéresse pour viĞnette ?
1 Like
A terme oui. Pas pour le moment, donc tu peux le mettre en basse priorité.
Tant qu’aucun client largement utilisé ne lit ces qrcodes (ou ne lit une syntaxe Ğ1-Lien sous forme de QRcode), je ne l’implémenterai pas.
Ca arrive 
1 Like
@tuxmain Je vois qu’il y a un champs Data. C’est prévu pour un commentaire ?
Je pense que prévoir l’utilisation de ce champs Data pour transmettre une ref. de transaction est utile. Exemple : dans un magasin, je passe en caisse, les articles sont scannés, on me demande une transaction pour le total. Avoir la référence de tx en commentaire permet au commerce de suivre les paiements.
Le champ data contient l’ID de l’annonce Ğchange. On peut aussi mettre ce qu’on veut à la place, pour l’instant ce n’est pas explicitement le commentaire.
Beau travail !
Cependant, pour le format, je ferai le même constat qu’ailleurs (g1lien) : pourquoi ne pas mettre une URI ?
Si c’est pour un paiement,chez URI june:// et avec le commentaire GCHANGE:[id_ad] ?
C’est surtout pour avoir le prix et d’autres données. Comme ça le QRcode est exploitable même sans connexion, ça permet d’avoir sa liste sur son téléphone pendant le gmarché avec les titres, clés publiques et prix, et de compléter avec les images quand la connexion revient.
1 Like
Oui, mais précisément, tu pourrai avoir une URI de paiement, donc avec la clef, le prix, un commentaire.
Ca évite de faire du spécifique à gchange.
Les clients qui sauront exploiter le commentaire de TX « GCHANGE: » pourront alors télécharger la miniature, le titre, etc ?
Ce n’est pas spécifique à gchange, le type de données est précisé. Pour l’instant j’ai mis vide, brut ou gchange, on pourrait ajouter g1bien, etc. La monnaie aussi est précisée (prix libre G1, unité G1, DU G1, etc.).
J’aime bien les protocoles binaires car ils sont plus compacts, mais à vous de voir si c’est un problème.
J’observe une augmentation entre 16% et 22% de la taille du côté du QRcode en passant du binaire à l’URI. (donc entre 35% et 48% de surface en plus)
Cela dit même avec 4cm de côté le QRcode URI avec le titre de l’annonce en plus reste lisible par mon téléphone.
@poka est-ce que tu préfères le format june://... ?
1 Like
@kimamila en fait à la base j’avais demandé à Tuxmain de générer des qrcodes avec juste l’id_ad d’annonce gchange en full text, puis ça a été finalement gchange:ID
Et c’est en discutant de ça avec elois, vit et Tuxmain pendant la dernière réunion qu’ils m’ont convaincu que c’était beaucoup mieux de le faire en binaire, pour des raisons de compaticité (ouioui…) des qrcodes avant tout.
Et la RFC que propose tuxmain est très général, elle permet de ne pas se limité à gchange, mais aussi d’'y encoder les clé publique junes, et même plusieurs clés ou scripts avec montants pour faire d’un coup un paiement unique multi-destinataire avec montants customs juste en flashant un qrcode.
Je pense que ça permet pleins de chose pour une taille de qrcode réduite, donc je pencherais plus pour la solution binarisé.
Le seul inconvénient que j’y voit c’est que c’est un peu plus chiant pour nous côté client à coder, mais bon Tuxmain nous à fait un exemple python qui déchiffre très bien ces qrcodes ça n’a pas l’aire insurmontable 
1 Like
Oula non, je n’ai pas fait ça ! 
(mais c’est une bonne idée…)
Effectivement l’avantage de rester compact est qu’on a plus de marge pour ajouter des données plus tard.
On peut ajouter le multi-destinataire au prix d’un octet de plus (stockant le nombre de destinataires). Pour des conditions de dépense plus complexes ça risque de demander un octet de plus par destinataire, mais est-ce utile pour l’instant ?
1 Like
Bah j’en ai parlé avec @elois au téléphone hier et il semblait penser que c’était possible avec ta RFC actuelle.
le fomart URI a pour avantage de pouvoir être traduit par tous les supports : QRCode, texte (SMS, etc.) et de pouvoir etre lu par les mobile, en lançant la bonne application.
Ainsi, un lecteur générique de QRCode peut faire l’affaire.
et surtout qu’il faut lancer l’outil de lecteur QRcode depuis la bonne App.
cela ne correspond pas à la pratique des gens. Pour eux un QRcode c’est une adresse web.
Il l’a slash sans savoir s’ils ont l’appli, en se disant : “ca doit marcher je penses”.
Si le lecteur de sait pas interprété, il affichira le texte qu’il a lu.
Tous cela me semble bien loin des usages des standards web.
Hum je ne comprends pas du tt cet argument, si les gens utilisent autre chose qu’un outil G1 pour scanner ces qrcode, même en texte, au mieux ils verront les champs brute qu’ils devront manipuler eux même ensuite via les bons outils.
Ca ne me semble pas vraiment l’usage de la grande majorité des gens.
Dans tous les cas ces qrcodes sont pensés pour être utilisé par les bon outils.
Le tout est qu’on se mettent tous d’accords sur ce standart, ça ne me semble pas la mer à boire (si on arrive pas à faire ça c’est qu’on est incapable de se mettre d’accords sur quoi que ce soit, c’est mauvais signe…)
Mais honnêtement moi ça m’est égale, full text me va aussi, je vous laisse trancher cette question, je préfère binarisé mais au fond ça m’est égale tant qu’on est tous d’accords.
non, comme je l’ai indiqué à la dernière visio, sur mobile :
- on peut soit avoir une adresse de type
http://qui ouvre une page web d’explication,
SAUF si une (ou plusieurs) App sait gérer ce domaine, alors elle propose de s’ouvrir. - soit gérer un protocole maison
june://qui proposera l’ouverture de l’App de ton choix. Tu peux ainsi avoir le choix entre Cesium, Gecko, etc.
Si aucune application ne sait gérer ce protocole, alors je ne sais pas trop ce que décide le mobile.