pour faire des liens vers tout un tas de choses associé à la Ǧ1.
Par exemple, si je veux proposer un paiement en Ǧ1, plutôt que de faire un lien vers mon instance de cesium-api ou d’une instance historique, faire un lien avec ce custom-protocol pour que le navigateur de l’internaute redirige vers son instance préférée et de confiance (ou vers son client lourd)
C’est en tout cas comme ça que je compte procéder pour G1Billet en utilisant une page qui propose de gérer le protocole web+g1 en recevant les liens web+g1 et en les convertissant pour pointer vers des services compatible. De cette façon, si je fait confiance au portail g1.1000i100.fr, je peux dire de passer par là (et donc par les instance locales géré par le même type) pour gérer les liens web+g1 ou si je préfère passer par le portail g1.aquilenet.fr et qu’il on aussi mis de quoi accepter le protocole web+g1, je peux choisir de passer par eux.
Ensuite quand je scan un G1Billet pour vérifier ça validité ou pour l’encaisser (ou que je vais sur un site qui invite aux dons en utilisant le protocole web+g1 plutôt qu’une instance spécifique de cesium, ou n’importe quel cas que je n’ai pas anticipé qui utiliserais le protocole web+g1) alors j’arrive sur l’instance que j’ai indiqué comme de confiance et non une autre. (et si je n’arrive pas dessus en scannant un G1Billet, je peux déjà m’inquiéter de sa validité)
Il faudra que chaque domaine ou appli (qui le souhaite) implémente cette écoute de custom-protocol car ca se passe par domaine… Et l’utilisateur devra avoir déjà visité ledit domaine pour profiter de la redirection, avant ca, si aucun domain n’est enregistré pour ce protocol qu’est ce qu’il se passe? 404?
web+g1 c’est moche! Je sais bien que c’est ce que dit la spec, mais je ne crois pas que la partie “web+” soit complètement obligatoire techniquement (les navigateur forcent?). En tout cas dans electron, la chaine avant les “://” est libre.
Ce serait bien de pouvoir avoir un ou des protocol(s) plus sympa(s) et parlant(s) du style:
g1://
duniter+g1://
cesium+g1://
cesium://
sakia://
g1+tx://
g1+cert://
g1+wot://
Ca devrait plus être du style duniter://, dans l’optique que ça soit utilisable pour toute monnaie libre réalisée avec Duniter avec n’importe quel client.
Ce que j’ai lu, c’est qu’il fallais préfixer de web+ pour que ça marche, mais je n’ai pas encore testé.
En effet, je préfèrerais :
g1://
Ǧ1://
duniter://
mais aucun des association à un logiciel spécifique en revanche : au logiciel d’accepter la syntaxe du protocole pour envoyer l’utilisateur à l’endroit adéquoit chez eux quand ils analyse le lien.
Entre duniter:// et g1:// je suis partagé.
si effectivement la compatibilité est de 100% entre les différentes monnaies libre issue de la TRM et basé sur Duniter, alors on pourrais envisager duniter:// mais :
un noeud duniter est mono-monnaie
seul sakia (et peutêtre silkaj) gère plusieurs monnaies à la demande
une instance cesium est mono-monnaie
comme la ǧ1 nous l’a montré, des paramètres on été ajouté en dur dans le code après lancement. Si une autre monnaie de prod voit le jour, il y a des chances qu’elle ai aussi ses spécificité et donc qu’elle est besoin de clients adapté…
Bref, pour toutes ces raisons et parceque j’étais essentiellement dans l’idée d’un usage web donc d’un protocole qui redirige vers une url différente au choix de l’utilisateur, et que sa confiance me semble pouvoir ne pas être vers la même instance selon la monnaie (d’autant que toutes les instances ne gère pas nécessairement toutes les monnaies)…
Bref, tout ça pour dire que si duniter:// pourrais être plus général, il me semble surtout plus propice à des souci de compatibilité, ou à, au final ralonger la syntaxe pour un gain pas évident avec du duniter://g1/
bref, je suis favorable à :
g1://
Ǧ1://
ǧ1://
web+g1://
Je réfléchie à l’intérêt ou non de n’avoir qu’un seul protocole, et pour qui.
duniter://
Pratique pour les développeur d’app, il n’y a qu’un protocole à enregistrer pour toutes les monnaie basé sur duniter. Pour les utilisateur en revanche, ça risque d’être un protocole buggué dès qu’ils utilise une duniter-monnaie qui n’est pas la monnaie majoritaire (cf message précédent).
g1:// pratique pour les utilisateur, pour chaque monnaie qu’il utilise, ils indique l’app ou l’instance web par défaut qu’ils veulent et ça roule. Pour le développeur en revanche, il est peut-être nécessaire d’ajouter quelques ligne dans l’app pour chaque monnaie.
chacun fait son protocole parce-qu’on ne se met pas d’accord entre nous :
a court terme, plus pratique pour les dev, mais à long terme, soit chaque app devra géré chaque protocole pour que ça juste marche pour les utilisateur, soit un des protocoles s’imposera par la pratique et les autres disparaitrons… soit tous disparaitrons parce-que ça sera inutilisable pour les utilisateurs.
Tout a fait, chaque monnaie a sa propre communauté, ses propres développeurs en finira forcément par dévier vers ces propres règles, et l’on ne peut pas assurer une inter opérabilité parfaite a priori, après le nom Duniter est implicitement lié a la Ğ1 et lorsque d’autres monnaies libres verront le jours elle forkeront duniter sous un autre nom donc il n’y a aucun problème a utiliser duniter://
sauf que si c’est utiliser duniter:// pour que ça ne serve qu’a la g1, autant utiliser g1:// c’est plus court et je pense, en plus, plus clair pour les utilisateur.
Il me semblait que le code de Duniter n’avait pas besoin d’être forké pour gérer d’autres Ḡ*?!
“duniter wizard” propose de définir les différents paramètres d’une nouvelle monnaie libre?
Je n’ai pas bien compris encore quels étaient les effets des valeurs d’initialisation…
Je veux bien qu’on m’éclaire sur la question.
Pour faciliter l’utilisation du protocole g1 (je soutiens à 100% l’initiative), peut-on envisager le développement d’un module Firefox par exemple ? Genre installable en quelques clics et capable aussitôt d’interpréter le protocole en question.
de base, il ne devrais pas en avoir besoin (le navigateur devrais s’en sortir si on lui parle correctement)
Mais un module me semble utile pour reconnaitre les liens cesium n’utilisant pas le protocole et les convertir vers le protocole pour utiliser le logiciel qu’on veux et non l’instance associé au lien.
les comptes porte-feuilles peuvent-ils avoir un uid ? ou est-ce un privilège réservé aux membres ?
Si c’est réservé aux membre, il me semble utile d’avoir un système de “NameService” pour identifier un compte par quelquechose de plus court et mémorisable que la clef publique.
Si ce n’est pas réservé au membre, sachant qu’actuellement ils ne périment pas, comment se prémunire du cyber-squatting d’UID ?
Je poste ça ici car si :
web+g1://pay:montant/to:pubkey ou g1://pay:montant/to:pubkey peuvent être pas mal,
web+g1://pay:montant/to:uid ou g1://pay:Montant/to:uid me semble encore plus lisible comme uri.
C’est réservé aux membres, tant qu’on regarde en blockchain. Car en piscine tu peux bien squatter un UID non-utilisé en blockchain pendant 2 mois. Et tu peux même faire perdurer la chose en te recréant une identité en piscine au bout de 2 mois, encore une fois tant qu’aucune identité en blockchain ne réserve définitivement le pseudo.
sachant que sans paramètre ça dirige sur envoyer bitcoin.
qqchose dans ce gout là :
duniter://FNVeWqnZCjGFspj1sjBmwFfoT8tDv99ifGLbNY2UpzPw?amount=1
et
duniter://FNVeWqnZCjGFspj1sjBmwFfoT8tDv99ifGLbNY2UpzPw?user=user à certifier
ou
duniter://FNVeWqnZCjGFspj1sjBmwFfoT8tDv99ifGLbNY2UpzPw?cert=user à certifier
sachant qu’en push on a que c’est deux TX de possible.
Après j’avais en première instance pensé à duniter comme nom du protocole, on peut imaginer un param pour forcer la currency, histoire d’être sûr :
