PorteJune: une application pour échanger en monnaie libre

Co-création d'applications J'ai une idée
1

La June (aussi écrite Ğ1) est une monnaie libre et équitable, décorélée des monnaies actuelles. Bien que basée sur la blockchain, et donc décentralisée, elle ne repose pas sur la spéculation et n’a pas le coût écologique des autres cryptomonnaies. Partie de Toulouse en 2017, elle compte des milliers de membres actifs dans la France entière, mais aussi en Espagne et dans d’autres pays du monde.

Depuis 2-3 ans, une nouvelle API nommé GVA, de type GraphQL, permet de facilement créer des portemonnaies en June, et de recevoir ou envoyer des transactions vers d’autres comptes. L’application Ğ1nkgo et le bot Telegram Ğ1 Superbot utilisent cet API.

Les portefeuilles ainsi créés sont des « hot wallets », dans le sens où ils sont moins sécurisés que les portefeuilles créés avec l’application officielle (Cesium), mais qu’ils permettent de plus facilement faire des transactions, un peu à la manière des paiements sans contact des cartes de crédit.

PorteJune est le nom de code d’une application type portefeuille qui enregistrerait toutes les données de l’utilisateur (notamment la clé de son portefeuille) sur son espace de donnée personnelle (Pod). L’avantage par rapport aux autres applications existantes est qu’on pourrait passer par le protocole ActivityPub pour notifier les utilisateurs d’un paiement, ou faire une demande de paiement.

Une fois cette application développée, on pourrait imaginer que les autres applications compatibles ActivityPods puissent proposer des transactions en June, en passant uniquement par ActivityPub. Par exemple, une personne qui propose une rencontre sur Bienvenue chez moi pourraient demander un prix en June au moment de l’inscription. Le paiement pourrait être automatiquement validé. Si la personne se désinscrit, elle serait automatiquement remboursée.

L’idée de monétiser les échanges pourrait repousser celles et ceux qui souhaitent sortir des logiques capitalistes. Cependant quiconque a déjà utilisé la monnaie libre sait que son usage est tout à fait différent: comme cette monnaie est abondante, et qu’elle ne reproduit pas les inégalités qu’on retrouve dans la société, l’utiliser est comme un jeu. La monnaie retrouve son véritable sens: valoriser les contributions des acteurs d’une société.

(Bien sûr, les créateurs de rencontres sur Bienvenue chez moi resteraient libre de ne pas demander des June, ou d’accepter des personnes qui n’ont pas encore de June. A priori, on favoriserait plutôt le principe de la « participation libre et consciente »)

Détails techniques

J’ai parlé de cette idée sur le forum des développeurs de la monnaie libre et j’ai eu ces précisions techniques:

1 « J'aime »
2

Donc ça serait une application et un service accessible aux autres applications ?

Ce que tu dis là m’intéresse bien.
Je n’ai pas expérimenté longtemps la June mais je n’ai pas eu ce ressenti. Comme c’était assez tôt dans son existence, ça explique peut-être cette différence de perception.
Je suis assez réticent à l’idée de mettre de la monnaie là où il n’y en a pas aujourd’hui, même avec une monnaie plus vertueuse (June, JEU ou autre). Mais j’ai bien envie d’en discuter.

1 « J'aime »
3

L’application elle-même permettrait simplement de créer un porte-feuille et d’envoyer de l’argent à d’autres personnes.

Mais on peut imaginer que les autres applications puissent aussi envoyer de l’argent, par exemple en utilisant une activité ActivityPub. L’application PorteJune pourrait facilement écouter la boîte d’envoi de l’utilisateur, détecter ces activités et effectuer les transactions demandées. Mais dans ce cas il faudrait que l’utilisateur donne certaines permissions aux applications, pour éviter des abus.

Ou alors, pour plus de contrôle, on pourrait simplement rediriger l’utilisateur sur l’appli PorteJune. Mais cela empêcherait de faire des applications automatisées, comme illustré dans mon exemple.

Note: Techniquement, les applications pourraient également demander un accès direct à la clé privée du portefeuille, stockée sur le Pod, mais ce ne serait pas sûr donc pas recommandé.

4

<Digression généralisante>

Les deux cas d’usage me semble intéressants, de manière générique, c’est-à-dire pour d’autres services que ce porte-monnaie de June. On pourrait avoir des applications qui soient, entre-autres, des providers. Elles déclareraient pouvoir fournir un service (ici une interaction avec le porte-monnaie June de l’utilisateur). Pour utiliser certaines fonctionnalités d’une application A, qui serait dépendante d’un service B, il faudrait que l’utilisateur connecte une autre application C fournisseuse de ce service B.

Dans le cas de PorteJune, une autre application pourrait avoir des fonctionnalités liées à la June qui ne serait utilisable qu’après avoir fait le lien entre celle-ci et PorteJune ou une application similaire respectant une même API.

Pour le mode de délégation, comme dit plus haut, je pense que les deux que tu proposes ont un intérêt et correspondent à différentes situations ou niveaux de confiance.

On pourrait définir une façon « standard » pour une application de déclarer un « besoin fonctionnel » qui pourrait être rempli par une autre application. Il faudrait une spécification versionnée pour chaque service, contenant une description des interactions possibles via ActivityPub et des données stockées. Une application pourrait déclarer respecter les spécifications d’un certain service (en précisant la version).
Il y a déjà quelque chose de ce genre en réflexion ? Je pense que c’est un peu tôt pour rentrer vraiment là-dedans, donc c’est surtout par curiosité.

</Digression généralisante>
(est-ce qu’on déplace ça dans la catégorie Coin technique/ActivityPods ?)