Je vous présente Ğ1Cotis.sh, un script qui permet de verser un pourcentage de cotisations sur des transactions qu’on reçoit. Il utilise un compte intermédiaire, sur lequel vont s’appliquer les % de cotisations. Le restant est versé sur un compte final.
J’ai codé ce script pour financer le développement de l’écosystème Duniter et la rémunération des noeuds, mais il pourrait servir à financer n’importe quel projet, groupe local, association… Qui a besoin d’un financement récurrent. Voire même verser des cotisations à sa commune, sa région, une mutuelle !
Il peut être utilisé pour un usage personnel, mais j’ai aussi prévu (et testé) une version à plusieurs comptes, que je vais proposer en région lyonnaise. Cette version permet d’héberger ce service pour un groupe local, des connaissances, etc… Je ne compte pas le proposer à des inconnu.e.s et devenir tiers de confiance. Si un tel projet vous semble souhaitable, je vous invite à installer votre instance de Ğ1Cotis et à en proposer son utilisation autour de vous !
Ce script dépend de Silkaj. Pour le moment, le paramétrage se fait à la main directement dans le fichier du script, mais j’ai prévu de créer un script de configuration. C’est encore un peu brouillon, mais utilisable, et déjà utilisé à l’adresse bg3AoYQKeyzaJaQoXJQATehLCk5wRFnYEvdRyjgg9LT.
Si vous avez quelques retours à me faire, j’en serais très heureux
(J’attends d’avoir écrit le script de configuration pour publier une première version)
Conceptuellement, je ne vois pas la logique d’un prélèvement proportionnel au volume d’échange. Verser une partie de la création monétaire, par exemple, a une logique car ça revient à consacrer une partie de la richesse produite (si j’ai bien compris, N DU est en moyenne la valeur de toutes les richesses produites en un jour par les membres).
Donc si je reverse 0,1 DU par jour à une collectivité, ça a un sens : je donne à la collectivité une proportion de ce que je produis. Par contre, qu’est-ce qui justifierait que les revenus de cette collectivité soient proportionnels à ce que je vends ou reçois ? (à part si ses besoins sont proportionnels à la quantité d’argent échangé, par exemple si les nœuds Duniter étaient des humains devant compter des billets à la main pour valider une signature.)
Ce script est une bonne idée, mais ça serait encore mieux de pouvoir choisir le mode de prélèvement : la transaction reçue, envoyée, le DU, le montant du compte, fixe… En fonction de ce qui est le plus logique selon le cas.
La soi-disant “richesse produite” (les valeurs monétisées) sont mesurables à partir du moment où elles ont été échangées. La monnaie créée n’est pas une richesse produite, c’est simplement l’outil de mesure de cette richesse. Pour verser une partie de la soi-disant “richesse produite”, il faut la mesurer sur les échanges réalisés.
J’ai choisi d’écrire ce script car j’ai choisi (de façon personnelle) de consacrer 5% de la monnaie gagnée (pas créée) au financement de la monnaie libre. Ce n’est certainement pas le seul modèle de cotisation, on peut aussi avoir le même montant chaque jour, ou une progression par paliers comme l’impôt sur le revenu, etc…
Il ne s’agit pas d’un prélèvement mais d’une cotisation volontaire. Je ne l’ai pas appuyé sur une réflexion théorique forte. Mais c’est un premier script, à partir duquel n’importe qui (et peut-être moi) pourra proposer un système plus développé.
edit - comme vous le voyez, je botte en touche sur votre question. Je fais ce que je peux à mon modeste niveau.
Il me semble sain de vouloir contribuer à financer le réseau à la mesure de ce que je l’utilise, et le montant de ce que je reçois est à mon sens une bonne mesure de mon utilisation du réseau.
Je partais juste du principe que pour avoir du sens, la masse monétaire doit correspondre à la quantité de marchandises existantes. Le DU est donc, à l’image du dividende d’un actionnaire qui est une part de la production de l’entreprise, une part de la production de la société. On fixe les prix relativement au DU, c’est ça qui le fait correspondre à la production.
Sinon bravo pour le script, pour moi le bash est une horreur barbare avec des caractères bizarres dans tous les sens et avec plein d’espaces.
Ce qui n’est absolument pas le cas dans une monnaie libre vu qu’elle reconnaît les Ğvaleurs et le Ğtravail, qui par définition ne sont pas des “marchandises existantes”.
merci. Le bash est aussi le langage le plus rapide d’accès quand on débute sous GnuNux. Mais j’en vois bien les limites
J’ai publié la version 0.1 de Ğ1Cotis. La peinture est encore fraîche. Fonctionne sous GNU/Linux avec Silkaj et Diceware installés. C’est à installer chez vous, ou à faire installer chez un.e ami.e, ce n’est pas un service “grand public”.
Pour l’installer, téléchargez une version compressée (zip, tar, etc…) et décompressez-la où bon vous semble, puis configurer config.sh.
Un script nouveau-compte.sh facilite la création de comptes de cotisation.
Appel à béta-test :
Il y manque (peut-être) un aspect important : je sais lancer Silkaj s’il a été installé par paquet ou par Pipenv. Par contre, je n’ai aucune idée de comment le lancer s’il a été installé par d’autres moyens.
Si vous avez une autre installation, pouvez-vous me dire comment vous lancez Silkaj (hors de sikaj ou pipenv run silkaj) ? Faut-il se placer dans le bon dossier pour exécuter la commande ? Pouvez-vous modifier le fichier config.sh pour que votre Silkaj se lance ? Merci d’avance.
Grande amélioration de la gestion de la périodicité. La v 0.1 ne permettait qu’une seule périodicité, à choisir entre quotidienne, hebdomadaire, mensuelle. La v 0.2 permet de gérer plusieurs périodicités, c’est bien plus pratique pour proposer ce service aux copines.
Gestion des virements récurrents. En attendant mieux (notamment un service web, à bonne entendeure ), il est possible de proposer facilement un service de virements récurrents à son groupe local, pour peu qu’on aie pas trop peur de la ligne de commande et qu’on aie déjà un petit serveur dispo (micro-PC ou autre).
des dossiers plus propres et mieux rangés.
TODO : je ferai quand ça me prendra :
la gestion d’alertes pour les virements récurrents, lorsque le compte “de réserve” est vide.
un petit script de nettoyage, pour supprimer un compte et/ou les fichiers en trop ou incomplets.
Oui, un fournisseur G1Cotis est tiers de confiance, et il n’y a aucun moyen de faire autrement àma connaissance et dans mes compétences.
Pour cela, sur mon instance, je crée les comptes, et les utilisateurices n’ont pas accès aux clefs privées. Iels doivent me faire confiance, et je ne connais aucun autre moyen de m’autoriser à faire des transactions en leur nom. Une fois que de la monnaie est envoyée sur leurs comptes de cotis, iels n’y ont pas accès avant qu’elle soit envoyée.
Donc, je n’ai pas accès aux identifiants/mdp des comptes personnels des utilisateurices, uniquement des comptes G1Cotis. Tout est nettement séparé, je ne demande pas aux utilisateurices des identifiants de compte.
edit- mais effectivement, il n’y a aucune défense en cas de prise de contrôle du serveur par un.e attaquant.e. C’est pour cela que je conseille l’utilisation de G1Cotis à petite échelle, pour limiter les risques.
Elle utilise une version “maison” de Silkaj qui gère l’envoi de plusieurs montants dans une même transactions. Cette amélioration évite la perte de transactions, c’est un grand ajout pour la robustesse de Ğ1cotis. Elle devrait etre mergée dans silkaj-v0.8.
Si vous allez regarder les transactions sortantes de ces deux comptes :
bg3AoYQKeyzaJaQoXJQATehLCk5wRFnYEvdRyjgg9LT
EUt3FqkmpUg8UdyrB2dGXtZoTo7GRXadEkHagL2q2AKb
Vous observerez qu’ils ne font pas la même répartition. L’un est pour financer plusieurs projets de développement de la Ğ1 selon mon bon plaisir, l’autre pour financer exclusivement les caisses des devs et des noeuds.
Il y a encore d’autres comptes G1Cotis dans la nature, qui font des répartition selon le bon plaisir de leurs propriétaires.
Bonjour,
Je m’étonne de l’initiative « mon bon plaisir » mais bon c’est la nature humaine? Cela reste perplexe et…
Les projets de développement devraient à mon sens être définis par la collectivité .
Quand j’achète un pain au chocolat, c’est également selon mon bon plaisir.
Quand je donne à la caisse des devs, idem.
Quand je crée Ğ1Cotis, toujours pareil.
Quand je préfère lire un bon roman ou dormir, c’est encore selon mon bon plaisir.
Et si je n’avais pas créé Ğ1Cotis selon mon bon plaisir, il n’y aurait pas de sujet de discussion à savoir si les taux doivent ou non être définis par la collectivité. Si vous souhaitez installer une instance Ğ1Cotis et, selon votre bon plaisir, soumettre les taux de cette instance à un vote, vous pouvez le faire en toute liberté. Si cette proposition est meilleure que la mienne, nul doute que la majorité s’y reportera.
D’autre part, le compte bg3AoYQKeyzaJaQoXJQATehLCk5wRFnYEvdRyjgg9LT, c’est chez moi et je ne suis engagé envers rien ni personne concernant ce compte, comme c’est stipulé sur la page Cesium+. Le fait que d’autres personne l’utilisent me convient très bien.
Cette version 0.3.1 n’apporte aucune amélioration fonctionnelle, mais seulement une doc légèrement plus complète et des explications plus précises dans le script de création de compte. Elle vise les nouvelles installations. Les anciennes n’ont pas besoin d’être mises à jour.
Elle fait suite aux retours des béta-testeurs @Attilax et @Paulart.
Il s’agit de la commande « REC » du serveur g1sms.fr (06-51-13-65-20)
Elle s’active par SMS (les scipts ./shell/sms_*), et depuis peu par email en TODO better, et TX en TODO tout court https://git.p2p.legal/axiom-team/G1sms/src/dev-fred/shell/cron_MINUTE.sh#L60
Il faut que j’ajoute un ordonnanceur de tache IFPS pour la version en Essaim…
Reste à vérifier le bon chiffrement, anonymiser les wallets par sha256, ajouter des API…
vu qu’elle reconnaît les Ğvaleurs et le Ğtravail, qui par définition ne sont pas des “marchandises existantes”.
), il est possible de proposer facilement un service de virements récurrents à son groupe local, pour peu qu’on aie pas trop peur de la ligne de commande et qu’on aie déjà un petit serveur dispo (micro-PC ou autre).