Référencement des lieux sur OpenStreetMap acceptant la G1

Edit : Sondage pour le code utilisé :

  • JUN
  • XJU
  • XG1
  • XGU
  • XJN
  • duniter
  • gune
  • g1
  • g1-mode-de-paiement

0 votant

Bonjour à tous, je propose une idée pour référencer les lieux acceptant la G1 sur OpenStreetMap : Il existe une clé (OSM fonctionne par un système clé/valeur) pour indiquer qu’un lieu accepte X devise. https://wiki.openstreetmap.org/wiki/FR:Key:currency

Est ce que la June possède un code à 3 caractères ou l’on utilise seulement G1 ? Dans l’idée et cohérence de l’ISO 4217 cela pourrait être « XJU » ou « JUN » ?

Avec un référencement sur OSM, il serait possible ensuite de sortir une carte des commerces/assos/autre acceptant la June :slight_smile:

15 J'aimes

Super idée !

J’ai bien peur qu’il faille exclusivement des codes de monnaies issues de l’ISO 4217, et la Ğ1 n’en fait pas partie…
Sinon « XJU » ou « JUN » n’iront pas du tout car « June » n’est pas le nom de la monnaie, mais une approximation phonétique (d’ailleurs incorrecte) de « Ğ1 ».
Un meilleur code à 3 lettre serait par exemple « XĞ1 », mais je ne pense pas que le caractère accentué soit possible, il reste « XG1 ». S’il ne faut pas de chiffre (je ne suis pas sûr) « GUN » ne va pas car « UNE » est tronqué et donc il s’agit de « UN » au masculin ce qui est contradictoire avec LA Ğ1 et de plus sémantiquement « GUN », arme en anglais et antagoniste avec les idées véhiculées dans la communauté ML.
Par contre, il me semble qu’il puisse y avoir 4 lettres, certaines crypto-monnaie en effet ont 4 lettres (USDT,DOGE,NANO,DASH, …) on peut donc imaginer le code « GUNE » (ou « ĞUNE » si accent)…

1 J'aime

On peut rajouter la propriété payment:duniter=yes et/ou payment:g1sms=yes https://wiki.openstreetmap.org/wiki/FR:Key:payment

Ou pourquoi pas payement:gune=yes ou payement:g1=yes?
Il y a dans les exemples payment:bitcoin=*

Faudrait quand même se mettre d’accord! Non?

Oui c’est sûr ! S’il y a plusieurs références ça ne sert plus à regrouper ^^

Parce que pas! :stuck_out_tongue: Non parce que je ne sais pas pas ce que c’est qu’un paiement en « gune », ça ne correspond à rien… Ce n’est pas un protocole, ni le nom d’une monnaie.

Pourquoi pas… Là au moins il s’agit du nom de code d’une monnaie (libre en plus!).

S’agit il du protocol bitcoin, ou de la monnaie bitcoin, ou du logiciel bitcoin, ou de la blockchain bitcoin?


Il me semble que payment:xxx= doit désigner le moyen de paiement et non la monnaie vu qu’il y a déjà currency:xxx= pour ça…
D’où mes propositions pour faire une transaction on peut utiliser duniter logiciel (libre) générateur de crypto-monnaies, ou bien g1sms, mais on peut étendre ceci à cesium, sakia, silkaj tant qu’on y est!

A bien y réfléchir, ce sont des logiciels clients, et ce n’est pas au commerce de défénir avec quoi le client va payer… non finalement je ne vois pas poourquoi mettre autre chose que payment:duniter=yes et à la limite un jour payment:dunitrut=yes

Voir même seulement le protocol payment:dup=yes !


M’est avis qu’il faudrait attendre l’arrêt/définition du nom choisi pour le protocol navigateur et prendre le même…

1 J'aime

Sur le point soulevé par @dig, si on veut le nom d’un moyen de paiement alors c’est bine le nom d’un logiciel client qu’il faut indiquer, car c’est l’une des rasions d’être d’un logiciel client que d’être un moyen de paiement.
Duniter n’est pas un moyen de paiement, et le protocole DUBP encore moins. Un moyen de paiment c’est un outil qui te permet de payer (dans une un plusieurs monnaies). Cesium, silkaj et g1sms sont bien des moyen de paiement.

Mais en effet cela oriente les usages de l’utilisateur, la seule solution pleinement satisfaisante serait de faire une demande officielle d’intégration de la monnaie Ğ1 dans la norme iso 4217, ou si cela est d’usage, de fixer nous même un code officiel dans l’esprit de cette norme ISO et de nous en servir.

D’ailleurs certains commerçant n’acceptent pas tout les moyens de paiement d’une monnaie mais seulement certains, un commerçant peut très bien accepter la G1 mais refuser les paiement par g1sms et vice-versa.

Autre solution satisfaisante, citer tout les moyen de paiement en Ğ1 acceptés par le commerçant, et lorsqu’un nouveau moyen de paiement en Ğ1 apparaît, il faut demander an commerçant s’il accepte ce nouveau moyen de paiement et mettre a jours la data si c’est le cas.

2 J'aimes

Ça serait pas équivalent à lister « electrum, coinbase, bitcoind, blocktrail, etc. » pour le bitcoin ? Le commerçant se fiche de connaître mon client, si j’utilise ĞMixer ou Ğ1SMS ou non. Il veut savoir comment vérifier et récupérer la transaction.

Pour les euros, on liste les différents protocoles acceptés : espèces, chèques, virement, paypal…

Qu’on utilise silkaj, cesium ou g1sms, c’est le même protocole : un virement via Duniter. D’autres protocoles seraient un Ğ1billet, ou un billet fiduciaire (dont l’émetteur serait à préciser) par exemple.

Donc j’ajoute à la liste des propositions : (changer g1 par la norme iso4217-like adoptée)

  • g1-duniter pour la Ğ1 par virement direct (du point de vue du commerçant)
  • g1-billet pour la Ğ1 par billet jetable
  • g1-fid-toto pour la Ğ1 par espèces fiduciaires émises par le groupe local Toto
  • g1 pour la Ğ1, tous moyens confondus

D’après wikipédia, l’usage dans cette norme est qu’on utilise que des caractères alphabétiques sans accent, et qu’une monnaie non lié à un pays commence par un X comme XDC pour le dollar des caraïbes, XAF pour le franc CFA, ou XBT pour le bitcoin.
Mais en fait le bitcoin n’est pas dans la liste officielle :crazy_face:

Donc pour la Ğ1 çà pourrait être effectivement XGU, ou XJU, voire XGN ou XJN suivant qu’on préfère s’approcher de la lettre ou de la phonétique.
On fait quoi ? Un vote ou on laisse le créateur décider? :kissing:

1 J'aime

On pourrait aussi s’approcher de la graphie avec XGI, mais ça risque d’être source de confusions.

Encore que « I » est la graphie romaine du chiffre arabe « 1 » donc c’est pas mal (ma première pensée allait au l33t sp34k :rofl:).

1 J'aime

Tu parle bien de protocole, donc c’est de DUBP qu’il s’agit, et non pas de Duniter qu’une n’est qu’une des implémentations possibles. C’est comme ci au lieu de parler du moyen de paiement « virement bancaire », tu parlais du moyen de paiement « virement crédit agricole », qu’elle que soit la banque commercialle utilisée ça reste un virement. De la même façon, quel que soit le serveur blockchain auquel le client envoi sa transaction Ğ1, sa reste une transaction du protocole DUBP.

@Galuel a tu un avis sur la question, quel code choisissons nous pour la Ğ1 au sein de la norme iso 4217 ?

Ok, pour moi Duniter était le protocole. Qu’en est-il si on remplace duniter par dupb dans mon message ?

Non c’est le nom d’un logiciel, ce n’est pas le protocole.

Alors il deviens juste :slight_smile:

XGU me semble bien, « U » étant le premier caractère de « Une » c’est trivialement bon.

1 J'aime

Bonjour à tous, je découvre ce fil de discussion.
L’un·e d’entre vous as-t-ielle déjà réalisé l’implémentation dans OSM ?

@Candide Pas encore :wink:

Je vous invite à voter dans le premier topic pour le code que vous souhaitez qu’on utilise :wink:

je ne sais identifier de quoi vous parlez. pourriez-vous fournir un lien ?

Si l’objectif est de proposer une code répondant à l’ISO 4217 (ce qui est en soi une très bonne idée), je ne vois pas pourquoi des choix sont proposés qui ne répondent pas à cette norme (g1, XG1, duniter, etc.)

Je rappelle que les chiffres ne sont pas acceptés, seules les lettres le sont. XG1 ne répond pas à cette norme.

D’autre part, le X est utilisé pour les monnaies indépendantes d’un état-Nation, donc il est adapté pour Ğ1.

Pour la suite, je me range à l’avis du théoricien :

3 J'aimes