Je sais pas si ça peu vous aidez à prendre une décision mais
Moi perso je n’avais jamais flashé un qr-code avant d’utiliseer la June, j’ai toujours préféré taper moi même les adresses internet.
Et j’ai découvert la semaine dernière que l’appareil photo de mon smartphone était capable de détecter un qr-code, je ne le savait même pas, j’ai pourtant ce tel depuis bientôt 4 ans.
Tout ça pour dire que l’utilisation de qr-codes hors applications spécifiques ne me semble pas très répandu. Je me trompe peut-être, je n’ai qu’une vision partielle des choses.
1 Like
Non @poka tu as encore déformé. J’ai dit qu’il était possible de stocker une clé publique seule, c’est tout. J’ai pas parlé de script complexe 
Concernant les URI, ça prend considérablement plus de places pour le même contenu, et l’argument de l’interopérabilité ne tient pas : ces QR codes ne pourront être compris que par les app spécifiques qui comprenne ce protocole, qu’il soit en URI ou binarisé, c’est pareil.
Des données plus compactes permettent un qrcode avec plus de redondance et plus rapide à scanner, donc une meilleure expérience utilisateur.
Or, pour moi l’objectif c’est bien l’expérience utilisateur, pas utiliser à tout prix un truc existant si ça nous apporte rien…
1 Like
Non, en fait 
la différence du temps de scan est invisible pour l’utilisateur.
C’est un standard, qui délègue à l’OS du téléphone l’ouverture a partir d’une liste d’applications compatibles, comme on le ferait par exemple une extension de fichier. Typiquement : “Avec quelle application voulez vous ouvrir ce lien” / “Toujours | Cette fois seulement”
Mais ça reste a bien tester.
Même sans parler de cette détection automatique d’app compatible, un format explicite du type june://?amount= est plus simple a comprendre qu’un format binaire ou Hexa. Enfin ce n’est que mon avis.
@poka m’affirmait pourtant qu’à partir d’une certaine taille le QRcode est plus long à scanner. Ce qui est d’ailleurs logique si on y réfléchit. Donc non, selon la quantité de données que l’on veut intégrer dans le qrcode, la différence entre binaire ou URI n’est pas invisible pour l’utilisateur.
On en a parlé en visio avec @poka et @tuxmain. Et on se disait que, si c’est QUE pour ça, on peut faire un format : june://<encodage base 85>.
Ça permettrait de garder l’avantage du côté compact du binaire (encodé en base 85), tout en ayant l’avantage de l’auto-détection de l’app à utiliser pour ouvrir le «lien».
Mais dans la pratique j’en doute car d’après les tests sur g1lien ça ne semble pas fonctionner, en plus il y a des problèmes de formats différents selon PC ou mobile, bref, je suis pas convaincu.
Ce n’est pas destiné à être lu par un utilisateur. Et un dev saura lire la RFC et décoder ça comme il se doit, cet argument n’est pas valable
Oui mais c’est vrai qu’il y a de la marge quand même, la détection devient plus compliqué à partir du moment où il commence à y avoir beaucoup de data dans le QRcode.
Si dans le QRCode URI il n’y a que l’url d’un pod gchange et l’id de l’annonce, ça va. Si il y a que l’ID de l’annonce en string encore mieux.
Par contre si on veut plus de data style pubkey(s), amount(s), nom d’item, le tout en full text, alors je sais pas faut voir.
Comme je disais à Benoit sur signal, pour trancher cette question en fait j’aurais besoin qu’on ait un format d’URI fonctionnel et fiable qu’on puisse tester, sur tout appareil.
Tant que ce n’est pas le cas, binariser ce format me semble le mieux.
1 Like
Oui on veut, ça permettrait d’utiliser ce format de QRcode de manière agnostique de la plateforme, c’est ce que demandait @1000i100 notamment
Par exemple la page d’exemple de Benoit semble fonctionner sur desktop dans chrome, mais pas sur android:
Je pense que pour trancher il faut d’abord approfondir ces g1liens en fait.
Si on se rends compte que ça ne peut pas fonctionner sur mobile, alors autant binariser.
Mais en théorie ça doit être possible, d’autres le font donc bon.
Si en effet les g1liens sur mobiles fonctionnent, alors URI semblent plus pertinent, dans la mesure ou l’ensemble des data qu’on veut y stocker permettent un qrcode correctement redondé et de taille raisonnable.
Je suis passé par la case “bidouilleur qui écrit ses pages html à la main”, et le fait d’avoir un format documenté et compréhensible pour afficher la barre de financement est quelque chose que j’ai grandement apprécié. J’apprécierai de la même façon une syntaxe qui me permettra d’indiquer des destinataires, des montants, un commentaire, voire un script de déblocage, à la main.
Un.e dev oui. Mais la personne qui écrit sa page web perso dans son coin n’est pas forcément un.e dev, et iel appréciera grandement de pouvoir écrire son lien sans avoir à passer par ouatemille générateur de lien.
L’argument de @kimamila est tout à fait juste. La population ne se divise pas entre “devs” et “non-devs”, il y a tout un panel de personne qui ne comprend rien aux formats binaires, et aspire à utiliser des outils simples et à minimiser leur nombre (principe KISS). Une syntaxe G1lien au format binaire va à l’encontre de ce principe KISS, elle empêche l’écriture et l’audit du lien par un être humain.
En effet, c’est le 1er argument qui me semble recevable 
À ceci près qu’on ne parle pas des g1liens ici, mais des QRcodes.
Dans tous les cas, la personne qui écrit sa page web perso dans son coin devra de toute façon utiliser un logiciel pour générer son QRcode non ? Donc qu’est-ce que ça change pour elle ?
J’ai testé la taille qu’aurait le QRcode avec un protocole ASCII assez optimisé, c’est tout à fait acceptable avec les données actuelles.
En fait, le seul argument fort qui reste en faveur du binaire est qu’on pourra ajouter plus de données dedans à l’avenir.
Mais je peux tout à faire faire une lib JS simple et complète qui encode et décode les données binaires, je ne vois pas le problème.
J’oserais tout de même dire que transférer un nombre en base >2 encodé en ASCII ne me semble pas KISS, c’est juste plus haut niveau. Ce serait comme dire que WordPress est KISS par rapport à un site en HTML fait directement à la main.
Les questions qui peuvent résoudre ce débat selon moi :
- si l’intégration des
june://est possible sur téléphone - veut-on que les geeks puissent lire un QRcode sans avoir la bonne appli (parce que même en ASCII, Mme. Michu ne le lira pas)
- veut-on que les gens puissent l’enregistrer ou l’envoyer par SMS sans avoir la bonne appli
1 Like