Sans configuration de l’OS : Selon ce guide, les navigateurs Chromium permettent d’ouvrir les protocoles spéciaux avec un programme extérieur. Edge a besoin d’une extension, Firefox d’une extension ou d’une config.
Avec configuration de l’OS (installation d’un paquet ou exécution d’un script) : Sous Linux et sous Windows c’est possible.
Donc le préfixe web+ ne semble pas nécessaire.
J’ai essayé sur Chromium, il propose bien d’ouvrir un lien g1:test avec xdg-utils, donc apparemment on a bien droit aux chiffres, au moins sur ce navigateur sur Linux.
À propos du schéma générique : plutôt que de faire un truc complètement nouveau, on pourrait utiliser la RFC8905 (non validée par l’IETF mais au moins elle existe) : payto://g1/adresse?amount=42&comment=bla
L’inconvénient d’un schéma générique est que si plusieurs programmes de paiement sont installés, il y aura conflit (et on risque d’ouvrir le lien bitcoin avec Cesium, ou le lien Ğ1 avec le wallet Ğ3).
D’après les messages précédents, je vais proposer dans une RFC (exemples) :
On est sûr de ça ? payto://g1... s’ouvrira avec un wallet qui écoute payto même si ce wallet ne gère pas la Ğ1? Et inversement pour BTC si on n’accepte que le match G1 ? Seul le keyword avant // est vérifié par le protocole ?
C’est dommage, car dans le future, on pourrait ne pas exclure du “lobbying” de notre part pour intégrer le réseau Ğ1 dans des wallets connus génériques.
Si le navigateur ou l’OS gère bêtement les protocoles avec une association “protocole->programme”, comme c’est le cas maintenant, alors le seul moyen serait d’avoir un dispatcher qui sait décoder le protocole.
Puisque la RFC n’est pas validée, je doute que les navigateurs implémentent ce protocole. (et même si elle l’était, les navigateurs n’ont pas l’air motivés à faciliter le développement de protocoles alternatifs)
Nous avons déjà traité ce sujet, non ? Dans Césium, les liens june:// et web+june:// sont pris en charge. Cf échange qui ouvre Césium sur les liens de paiement. Cela fonctionne tantôt sous iOS et Android (june://) ou sous navigateurs desktop (web+june) mais il n’y a pas de système parfaitement supporté partout (enfin en 2020 il n’y en avait pas).
Ou alors il faut un protocole très répandu (type ipfs://) pour que les desktop l’ajoute à leur whitelist.
Les protocoles d’URI ne doivent normalement pas comporter de chiffres. Donc g1:// ne fonctionne pas.
Pourquoi ne pas garder june:// ?
J’ai implémenté déjà plusieurs types d’actions par URI dans Césium et gchange.
Les QRCodes de Ginkgo utilise ces URI.
autre chose : le montant est saisissable en g1 (?amount=) ou DU (?udAmount=)
J’ai relancé ici parce que je n’ai pas trouvé de documentation définitive sur le sujet. Je n’ai rien contre standardiser ce que fait Cesium, si tu as une description précise de ton protocole.
Le but de la RFC est de penser aux cas qui pourraient changer d’un client à l’autre, pour éviter les problèmes d’incompatibilité et d’implémentations partielles. Et aussi que plein de propositions différentes traînent sur le forum donc je ne sais pas lesquelles sont implémentées.
Y a-t-il une RFC de l’IETF qui dit ça ? En tout cas ça fonctionne sur Chromium. Mais ok pour garder june.
Quant au nombre de slash on peut n’en mettre aucun (par exemple les liens magnet:), mais peut-être que certains navigateurs sont moins embêtants avec leur saleté de barre d’url de recherche (quoique sous Chromium, même avec :// ça lance une recherche). Je suppose que l’idée est de mimer http:// ?
