Oui c’est exactement l’idée que j’avais quand j’en parlais à l’époque avec @NicoLiuresa, qui voulait développer la même chose que toi mais je n’ai plus de nouvelles de sa part.
Aussi pour éviter les perte de monnaie liés aux erreurs de saisie du numéro, on avait imaginer le mécanisme suivant :
le destinataire de la monnaie reçoit un code
l’émetteur doit envoyer ce code au serveur sms pour finaliser la transaction.
Pour l’envoi vers des portefeuilles duniter classiques ce n’est évidemment pas possible de se prémunir des erreurs de saisie, faudra attendre qu’on intègre un mécanisme de checksum (protocokle v11).
Alors no, en réalité seules certains types précis de calculs se feront plus vite de manière quantique, d’autres types de calculs sont au contraire plus lent en quantique qu’en binaire, c’est pour cela qu’il est possible de concevoir des algos quantico-résistants
Oui de toute façon le sms c’est unsafe de base, je pense que ça pourrait etre a l’instar de “paiement sans contact des CB” limité a de faibles montants.
Il y a qq trucs à discuter et régler avant de mettre en prod sur Ḡ1.
Les opérations réalisables par SMS ou Site Web
Les fonctions du site web (Inscription Newsletter, Administration du compte SMS, Envoi de transactions, Cloture de compte, Virement d’un compte à l’autre en cas de changement de téléphone? …)
Le coût et les financements des SMS (UNL et/ou G1)
La communication envers les membres actuels et les nouveaux.
Je pensais ouvrir ces discussions avec vous. Et @yann et @mathieuBize que je peux rencontrer sur Toulouse.
@Frederic_Renault tu a oublier dans la liste la fiabilité technique, il vaut mieux avoir un programme solides et bien tester dans toutes les configurations prévues avant de vendre ton service a des utilisateurs lambda
Ce serait déjà bien que tu partage ton code sur un dépot de notre gitlab comme je t’ai proposer (ou sur github si tu préfère) ainsi on pourrait t’aider, au moins en review
Mais avant cela réfléchi bien a la licence que tu souhaite apposer sur ton code, si c’est du copyleft tu pourra quand même dégager des revenu pour la fourniture du service (serveur sms), et de toute façon techniquement c’est facile a faire donc tu aura de la concurrence tôt ou tard !
Tu as raison, la fiabilité du code est importante!
En fait, je rêve du moment où on pourra se nourrir, se loger, se vêtir, se soigner, voyager en utilisant une monnaie libre. Ma motivation derrière la fourniture de ce service SMS et de faciliter l’usage quotidien de la Monnaie Libre par le plus grand nombre! Et ainsi atteindre ce stade de résilience économique…
Mais, comme tu le fait justement remarquer ce type de service est assez simple à développer (ça m’a prit 2 jours) et peut potentiellement dégager des revenus. D’où mon souhait de discuter avec la communauté de la meilleure façon de l’utiliser pour qu’il serve au mieux les objectifs…
Bien que je compte le faire, je pense qu’il est prématuré de publier le code en public tant que le cadre de son usage n’a pas été défini et accepté par la communauté (mais je peux te l’envoyer si tu veux y jeter un oeil
En plus il faudrait vraiment enlever le coût (UNL) trop important de Twilio (16cts/SMS!!)…
Il me semble que raspbian/sms et un certain opérateur au forfait à 2€ et SMS illimités pourrait être la solution. Dans un premier temps, il n’y aura probablement pas énormément de volume, et en tout cas un volume bien moindre que n’importe quel ado. Je ne pense pas que ça poserait problème. Et le jour où le volume devient conséquent, il n’est jamais trop tard pour basculer sur une solution plus « pro ».
J’ai retrouvé un dongle 3G dans un coin, il me manque la SIM…
En plus de diminuer les coûts, ça augmenterai la sécurité du service en ne laissant que le téléphone accéder au script du scénario de manipulation G1… Actuellement, c’est ouvert sur le web pour que Twilio y accède.
Je viens de tester l’envoi de SMS par raspberry, ça marche très bien, et la mise en place est plutôt simple !
J’ai suivi ce tuto.
En gros :
repérage du tty où est la clé,
installation de gammu,
configuration de gammu (une ligne à modifier pour le bon tty),
identification du dongle par gammu,
envoi du SMS !
Il faut y ajouter une bricole, la configuration du code PIN en utilisant la commande avant d’envoyer un SMS :
gammu entersecuritycode PIN le_code_PIN
Et voilà. Éventuellement, je pourrais te mettre le truc à dispo pour envoyer des SMS, je sais pas trop comment, même si du coup je prévois de l’utiliser pour mes besoins perso.
Le fait de passer un compte < 1 GT à zéro fait disparaître le montant ou le transfère ailleurs?
Cette propriété s’applique-t-elle aussi à un compte membre?
L’argent est perdu. Les comptes membres sont aussi affectés, puisqu’au niveau des transactions il n’y aucun différence entre un compte portefeuille et un compte membre.
J’ai du mal à comprendre pourquoi cela a lieu? Les centimes de Ḡ1 n’ont pas de valeur… Leur disparition n’influence-t-elle pas la consistance de la monnaie dans le temps et l’espace?
Une autre question concernant les comptes “abandonnés” (décès ou perte des clefs d’accès): existe-t-il on procédure qui prend en charge les Ḡ1 oubliés?
Parceque si on autorisait des sorties de transactions aussi petits, des attaquants pourrais les utiliser pour spammer et poluer le réseau. De plus, de si petites valeurs sont négligables par rapport à la masse monétaire totale. Ce “problème” n’existera plus dans la prochaine version du protocole, puisque les “compte” seront gérés différements et de la destruction de monnaie arrivera dans des cas beaucoup plus rares.
Pas directement, ils sont laissés comme ça. Cela dit, la somme minimale autorisée sur un compte est relative à la valeur du DU. Quand le DU va augmenter au fil des années, ce minimum va augmenter aussi, et les comptes abandonnés finiront par passer sous cette limite et seront détruits, vu que leur valeur est négligeable par rapport à la masse monétaire.
Oui, je sais, surtout chez cet opérateur. Mais j’aimerais savoir d’où provient l’info « 500 SMS par jour ». Après, je pense que pour l’instant on est très loin des 500 paiements SMS par jour, et comme je le disais plus haut, le jour où ça décolle, il sera toujours temps de faire autrement (on peut même avoir plein de membres qui fournissent le service d’envoi de SMS avec le forfait 2€ pour faire du load-balancing… dans la mesure où le setup est simple à faire, ça serait faisable).
Je ne pense pas que ça poserait problème. Et le jour où le volume devient conséquent, il n’est jamais trop tard pour basculer sur une solution plus « pro ».
Mais j’aimerais savoir d’où provient l’info « 500 SMS par jour ». Après, je pense que pour l’instant on est très loin des 500 paiements SMS par jour, et comme je le disais plus haut, le jour où ça décolle, il sera toujours temps de faire autrement (on peut même avoir plein de membres qui fournissent le service d’envoi de SMS avec le forfait 2€ pour faire du load-balancing… dans la mesure où le setup est simple à faire, ça serait faisable).