G1link syntax review / Choisissons la syntaxe G1Lien

Protocols
,
1

Bonjour, après quelques discussion avec @kimamila, plusieurs approches syntaxiques pour g1lien se profilent.

Êtes vous plus emballé par une des version, l’autre, ou avez vous d’autres propositions ?

Tout du long, sont utilisé pour désigner les syntaxe les éléments suivant :

  • [partie optionnelle]
  • <donnée spécifique à remplacer>

Proposition n°1 (de @1000i100)

Une syntaxe concise (pour les humains et QRcode), la plus lisible possible (pour les néophytes), et simple à comprendre (pour les néophytes).

Tous les liens commencent par g1: et peuvent être suivi par //.

Il peut ensuite y avoir un ou plusieurs bloc de sens séparés par des / . (paiement multi destinataire par exemple)

Un bloc de sens peut être :

  • une référence à un compte (clef publique encodée en base58 ou uid s’il n’entre pas en collision avec une commande, ou autre name service dans le futur)
  • une commande suivie de ses éventuels paramètres et sous-commandes séparés par : .

Voici à quoi pourrais ressembler les bloc de sens :

  • <wallet> désigne un compte spécifique par n’importe le quel des mode de désignation pris en charge. (ce qui donne un lien complet du type g1:<wallet>)
  • pubkey:<pubkey> désigne un compte spécifique par sa clef publique
  • uid:<uid> désigne un compte spécifique par son uid
  • ns:<ns> désigne un compte spécifique par un système de name service à inventer.
  • wallet:<uid or pubkey or ns> désigne un compte spécifique par n’importe le quel des mode de désignation pris en charge.
  • pay:<amount>:[to:]<wallet>[:ref:<comment>] propose le paiement de <amount> Ǧ1 à destination de <wallet> éventuellement accompagné d’une référence de transaction <comment>
  • tip:<amount>:[to:]<wallet> propose le paiement d’un pourboire de <amount> Ǧ1 à destination de <wallet>
  • balance:<wallet> affiche le nombre de Ǧ1 actuellement sur ce compte
  • toSign:<documentB58Encoded> propose un document prêt à signer. Il peut être transmis en QRCode à une application hors ligne qui effectue la signature avant de retransmettre le document signé.
  • signed:<documentB58Encoded> fourni un document signé, prêt à être envoyé en blockchain (dans la piscine) par une application relié à internet.
  • verifyNode:<nodeUrlB58Encoded> indique un noeud de référence qui sera utilisé par l’émeteur du g1lien pour vérifier que l’action à été effectué (permet d’accélérer la vérification si les documents sont envoyé aussi à ce noeud sans attendre la diffusion automatique entre piscine ou via la blockchain).

Exemple illustrant la simplicité pour un lien de paiement :
g1:pay:50:to:1000i100
voir pour la compacité :
g1:pay:50:1000i100

Proposition n°2 (de @kimamila), à base d’URI

S’inspirer au maximum de l’existant pour suivre les conventions qui permettrons aux développeur de s’y retrouver plus facilement. Les néophytes ne manipulerons pas les G1Lien eux même, il utiliseront des générateur de bouton de paiement ou assimilé, donc pas besoin de prioriser leur cas d’usage.

S’accorder uniquement sur la syntaxe des principaux cas d’usage, en veillant à leur simplicité d’implémentation, pour pouvoir mettre en place rapidement les G1Liens pour ces usages, quitte à étendre à d’autres cas de figures plus tard.

Références :

Proposition syntaxique :

Tous les liens commencent par g1: et peuvent être suivi par //.

Ensuite est désigné une ressources blockchain qui peut être :

  • g1://block/<number>[/]
  • g1://pubkey/<pubkey>[/]
  • g1://pubkey/<pubkey>/ballance[/]
  • g1:[//]<pubkey>[/]

Pour un g1lien orienté action, utiliser ?action=<action>[&<key>=<value>][...]:

  • g1://pubkey/<targetPubkey>[/]?action=pay&amount=<amount>&ref=<comment>
  • g1:<targetPubkey>?<amount>[&<refComment>] pour l’action la plus cumune, la version condensé est aussi géré.

Pour cibler des ressources de manière plus avancé :

  • g1://block?q=hash:<hash>
  • g1:[//]?q=uid:<uid>[?action=certify]

Limites actuelles de cette approche :

  • le paiement multi-destinataire est proposé avec une syntaxe qui groupe les receveur et groupe les montant mais nécessite une gimnastique mental pou identifier à quel destinataire est associé quel paiement :
    g1://<pubkey1>,<pubkey2>?amount=50,100
  • les liens de paiement commence par la clef publique ce qui rend le montant moins lisible au survol du lien (lien qui peut être affiché tronqué en affichant que l début)

Avantage bonus : la syntaxe <pubkey>:<checksum> n’entre pas en collision avec la syntaxe proposé par @kimamila alors qu’elle nécessiterais un changement de caractère séparateur pour celle de @1000i100.

A vos clavier !

3 Likes
2

En tant que développeur je trouve la syntaxe de @1000i100 plus simple à comprendre et à implémenter que la syntaxe de @kimamila.

Je réfute l’argument selon lequel s’inspirer de ce qui ce fait dans les autres crypto permettrais aux dev de s’y retrouver plus facilement. La majorité de nos contributeurs ne connaissent pas les conventions des autres crypto.

D’autres part car il faut avoir un regard critique sur les conventions des autres crypto, certaines sont très pertinentes mais d’autres beaucoup moins. Ce principe de reprise systématique de l’existant est dangereux, c’est à cause de lui que l’on se traîne des vielles casseroles qui n’ont pas de sens (par ex. se retrouver à doubler sha256 pour faire comme BTC; ça ne sert strictement à rien mais ça alourdit les traitements côté client…).

Ou comment s’assurer de garder un mur technique infranchissable entre dev et utilisateurs…

Si les G1Lien ne peuvent pas être écris à la main on perd une partie de leur intérêt. Ce serait quand même bien de pouvoir rédiger facilement un lien de paiement dans un message texte posté sur un réseau social par exemple.

Viens l’argument de la vérifiabilité, et là c’est une question de sécurité donc c’est important. Avant de cliquer sur un g1lien, l’utilisateur doit pouvoir vérifier lui-même sont contenu.

Conclusion : la syntaxe de @1000i100 est plus simple, plus sécurisée et plus inclusive. La syntaxe de @kimamila nous fait perdre tous ces avantages… pour rien !

3 Likes
3

C’est bizarre d’avoir un bloc g1 parmi des blocs pubkey, etc.

4

Je rejoins @elois sur ça,je trouve qu’un g1lien devrait pouvoir être écris a la main.
Je vote donc également pour la syntaxe de @1000i100 !
D’un point de vue purement technique,au lieu d’implémenter a chaque fois la syntaxe dans tous les clients,ne serait il pas plus simple de créer une extension pour les navigateurs (une seule en fait comme webextension est compatible avec quasi-tous les navigateurs).
Cette extension pourrait par exemple ouvrir un menu pour choisir avec quel client terminer la transaction quand un lien g1 est cliqué.
On peut en plus facilement enregistrer un custom protocol dans firefox :


5

J’ajoute des précisions/corrections concernant la proposition n°2 :

  • il ne s’agit pas tant de copier ce que font les autres crypto, que de comprendre qu’une URI adresse d’abord une ressource sur le web.
    Or comment adresse t on une ressource, par exemple en http:// ou autre ? Par un chemin (path) qui utilise des slash (et non pas des « : »). C’est d’abord cette convention des slash qui m’a fait réagir.

  • un ressource peut-être vu comme un chemin, donc, comme dans un explorateur de fichier. Ensuite, si des actions y sont possible, elles sont passées dans les queryParams ("?arg1=val1&arg2=val2") qui permet une souplesse dans l’ordre des champs, tout en étant extensible.

  • le paiement multi destinataire est tout à fait possible :
    g1://<pubkey1>,<pubkey2>?amount=50,100

  • ce genre d’URI est tout aussi simple à comprendre pour les utilisateurs lambda, car proche de l’adressage d’une ressource en http.
    Il est faux de penser que ma syntaxe n°1 sera plus simple à écrire, car ceux qui l’utilisent devront tout de même lire la specification. Mon intuition est que les utilisateurs lambda ne le feront pas. Je penses que votre réflexion est trop abstraite pour que vous vous en rendiez compte. Dans un cas réel un utilisateur évitera autant que possible la lecture d’une spec, pour éviter une erreur de saisie, et utilisera s’il existe un générateur de lien.

L’adressage d’une ressource est quelque chose de connu et qui a largement fait ses preuves, c’est pourquoi je ne suis pas favorable à revenir la dessus, pour un besoin strictement identique.

La gestion d’action sur une ressource est également largement utilise dans le monde web (soit via un / ou les query param) et je ne vois pas non plus de besoin nouveau qui justifierait d’en changer.

Mon intuition est aussi que ce que vous préférez dans la syntaxe n°1 vous concerne d’avantage, que les utilisateurs lambda. N’est-ce pas les geeks qui aiment saisir eux même les liens (par exemple en markdown),
Et qui aiment vérifier les liens (en bas du navigateur) au survol d’un bouton ou d’un lien ?

Par ailleurs les liens que je propose seront tout à fait aussi lisibles.

6

Effectivement, c’est corrigé pour mieux exprimer ce que je voulais dire.

1 Like
7

Effectivement @kimamila,on adresse un url avec des /,d’ailleurs,je pense que la syntaxe @1000i100 pourrait tout a fait être modifiée avec des /

8

Un message a été fusionné à un sujet existant : Création d’une unité supplémentaire

9

C’est tout l’objet de ma proposition.

Voici le parallèle avec un système de ressources (fichiers par exemple) :

  • g1:/ : désigne la blockchain G1, comme espace de nommage (sans désigner comment y accéder)
    des sous-repertoires, par exemple :
    • /wallet
      • /pubkey1
      • /pubkey2
      • (…)
    • /block
      • /1
      • /2
        …

Comme la désignation d’une wallet par pubkey est le cas d’usage le plus courant, on peut également se passer de /wallet, un peu comme si on faisait un lien symbolique, ce qui donne donc :

  • g1:/
    • /pubkey1
    • /pubkey2
      • (…)
    • /wallet
      • (…)
    • /block
      • (…)

Les actions sur une ressource peuvent être nombreuse, mais la plus courant dans notre cas sera le transfer de monnaie. D’où l’idée de rendre l’action de transfer celle par défaut, dès lors que « ?amount= » est présent.

Dans tous les cas, la lisibilité de l’URI se focalise sur la ressource ciblée (pour un paiement : la pubkey apparaît en premier), et non pas l’action qui de toute manière sera visible par :

  • le libellé du bouton
  • et par l’écran qui s’ouvrirent (l’écran de paiement dans le cas de Cesium). Il faut en effet également rappeler que l’authentification et la validation de l’action se fait dans un second temps, dans l’écran qui s’ouvrira après le click sur le lien.
    Pas besoin donc que l’utilisateur analyse entièrement le lien en bas du navigateur (qui est souvent tronqué ! Et qui le sera tout autant pour la proposition de @1000i100)

Je rappelle enfin que les cas d’utilisation de « tip » ou multidestinataire ne sont pas les plus fréquents, loin de là, et que se focaliser sur la lisibilité de leur lien pour bâtir des « bloc de sens » séparé par des slash me semble une mauvaise idée.

En d’autre terme la proposition n°1 facilite surtout la lecture des liens correspondant à des CU peu fréquents.

3 Likes
10

Pour ma part, en tant que développeur de client, je préfère le schéma de type URI. Parce que j’ai des bibliothèques éprouvées pour les analyser ou les construire facilement. Je n’ai pas envie d’écrire un analyseur ou un constructeur dédié…

Côté utilisateur, seules les personnes un peu geek qui connaissent le web et se soucient de la sécurité vont lire les liens. Autant qu’ils y voient un schéma conforme à la norme d’une URI, qu’ils comprennent parfaitement.

Donc mon avis est de recommander le format URI.

4 Likes
11

C’est aussi cela qui m’a motivé à faire la proposition n°2. Pas envie de réécrire un parseur, alors que Cesium utilise celui du navigateur (via la balise <a>), qui parse les URI nativement.

1 Like
12

Autre questionnement concernant ces g1 liens :

  • peut on énvisager d’avoir une URL du type « http://g1.duniter.org/… » pour gérer le comportement par défaut des G1 lien ?

En effet, dans le monde des OS de smartphone, les URL http:// sont généralement utilisés pour rediriger vers une Application cliente. Avec un fallback par défaut qui ouvre le lien dans un navigateur.
Ceci permettrait à un utilisateur lambda d’avoir une page lisibleà chaque clic sur un lien (Par exemple, avec une page d’explication : « Pourquoi je vois ce lien »).

13

Premiers tests d’implémentation

Depuis 3 jours, j’ai commencé à tester des G1 liens dans les différents cas d’utilisation (CU) concernant Cesium.

Limitations constatées

Voici quelques déconvenues :

  • les syntaxes du type g1: (ou g1://) ne sont jamais possible dans les navigateurs, car les chiffres ne sont pas autorisé dans les URI cliquables.
    Idem pour les syntaxes du type web+g1: (ou web+g1://), à cause du chiffre.
  • les syntaxes du type june: (ou june://) :
    • ne sont pas autorisé sur les navigateurs sous PC, car en dehors des protocoles autorisés.
    • En revanche, ils sont fonctionnels depuis les navigateurs sur mobile, et peuvent ouvrir une App qui déclare les gérer.
  • les syntaxes du type web+june: (ou web+june:// ou encore ou web+june://) :
    • fonctionnent bien sur les navigateurs sur PC, quand elles sont prise en charge par une extension web, ou un site web ; MAIS l’utilisateur doit faire une action (peu intuitive sous Firefox, dans la barre de recherche généralement) pour associer l’extension ou le site web ;
    • ne sont jamais autorisé dans les navigateurs sur mobile, dans la mesure ou Cesium ne peut pas déclarer les gérer

Conséquences

Ceci implique :

  • de revoir le nom du protocole (g1) pour enlever le chiffre.
  • dans les site qui proposeront des G1 Lien (ex: site de ventes, blog, etc) de gérer 2 cas de figure :
    • Si navigateur mobile : lien du type <protocole>:
    • Si navigateur PC : lien du type web+<protocole>:

Bienvenue dans le monde réel ! :slight_smile:

Proposition de nom du protocole

Je réalise qu’un nom de protocole trop spécifique à la G1 (g1: ou june:) implique :

  • de devoir recoder des choses pour chaque monnaie libre (g1-test, et les les futurs monnaies)
  • que les G Lien pourrait tout autant s’appliquer à d’autre crypto monnaie, en dehors de l’adressage d’un uid

Je propose donc :

  • de trouver un nom de protocole plus générique, qui peut s’appliquer à toute crypto monnaie. Par exemple :

    • crypto-currency://

    ou à défaut aux autres monnaies libres Duniter-like :

    • dup:// (Le protocole de Duniter)

  • de mettre le nom de la monnaie explicitement, par exemple :

  • crypto-currency://g1 ou dup://g1 ou dup://g1-test
    Ce qui correspond au host dans le formalisme URI

En effet, les ressources ou actions spécifiques à chaque crypto peuvent être gérer ensuite, par le path ou les queryParams de l’URI. Par exemple, pour l’usage des UID

Cette démarche faciliterait l’adoption par les navigateur de ce futur protocole (aujourd’hui seul bitcoin:// est autorisé ! Quidd des autres crypto)

Qu’en dites vous ?

4 Likes
14

Comparaison avec le protocol bitcoin:

Ce que je note au sujet de la spec BIP 21 décrivant les URI bitcoin: :

  • Pour un paiement, utilisation des params :
    • label= qui donne un libellé associé au compte
    • message= qui donne un commentaire, mais qui ne sera pas stocké dans la BC, pour éviter des stocker des information personnelles. Ceci est stocker typiquement par le logiciel client.
      Ca me semble nécessaire pour protéger la vie privé, et éviter la confusion avec comment du protocole Duniter.
2 Likes
15

Comparaison avec le protocol bitcoin:

Ce que je note au sujet de la spec BIP 21 décrivant les URI bitcoin: :

  • Pour un paiement, utilisation des params :
    • label= qui donne un libellé associé au compte
    • message= qui donne un commentaire, mais qui ne sera pas stocké dans la BC, pour éviter des stocker des information personnelles. Ceci est stocker typiquement par le logiciel client.
      Ca me semble nécessaire pour protéger la vie privé, et éviter la confusion avec comment du protocole Duniter.
1 Like
16

Tu m’étonnes,j’avais fait un test d’implémentation dans une web extension et ça avait bien marché (par contre,j’avais tenté ext+g1 et pas web+g1)

C’est le coté relou de FF :wink:

Qu’est ce que tu appelles une action peu intuitive ?

Je trouve l’idée plutôt bonne,ça évitera une démarche rigolote fastidieuse d’adoption à d’autres monnaies.

Selon moi,le meilleur moyen est de créer une webextension qui laisse le choix entre les différents clients quand un g1Lien est cliqué (j’ai ouvert un post sur reddit a ce sujet (https://www.reddit.com/r/WebExtensions/comments/i94a94/interact_with_bash_on_webextension/)

17

Tu vas pouvoir tester sur la v1.6.8 de Cesium : tu installe l’extension, tu l’ouvres, et tu cherches comment acccepter la prise en compte des liens “web+june” :slight_smile:
Suivant les navigateurs, c’est plus ou moins simple…

18

En suivant la procédure

Nécessite d’autoriser au préalable l’extension à gérer ce type d’extension (un bouton apparait dans la barre d’adresse de l’extension : cliquez dessus pour accepter).

J’ai essayé,mais aucun bouton n’apparaît dans la barre d’adresse

19

Bizarre, je viens d’essayer ext+g1, et :

  • sous Firefox, et j’ai l’erreur suivante :
    image

  • Sous Chrome/Chromium, cela indique clairement d’utiliser “web+” et non “ext+” :

    image
    image776×253 60.9 KB

Comment avais tu fait pour tester ? Pourras tu reessayer de ton côté ?

Peux tu essayer dans la console JS, de m’envoyer les lignes “[app] Registering protocol ‘web+june’…” et les suivantes ?

20

Ok,j’ai trouvé,en fait,ce n’est pas autorisé d’enregistrer un protocole en navigation privée.
J’avais juste mis une ligne dans le manifest de l’addons.

1 Like