Plus égalitaire et rapide avec une toile fédérative plutôt que mycélienne?

Anté-scriptum : j’ouvre ici une réflexion théorique.

Je ne souhaite pas voir le sujet balayé par des arguments du type :

  • pas prioritaire
  • pas le temps / les ressources.

Ces arguments sont tout à fait recevable, mais s’ils sont les vôtres, gagnez du temps en les appliquant : passez votre chemin pour laisser celleux qui souhaite en discuter le faire et utilisez votre temps et vos ressources à ce qui vous semble prioritaire.

Une évolution de cette ampleur me semblant hors de portée des ressources humaines que nous avons actuellement pour faire évoluer la G1, raison pour laquelle je n’avais pas écrit sur le sujet plus tôt. Je propose ici d’ouvrir une réflexion théorique sur ces modes de croissance, leurs intérêts et inconvénients, d’un point de vue propagation, sécurité/fiabilité, compréhensibilité/vulgarisation/communication.


Vitesse de convergence vers une symétrie spatiale selon les modalités de croissance de la toile ?

Cela fait quelques temps (années) que je me dis que les caractéristiques de la toile de confiance telle qu’elle fonctionne dans la G1 comporte des écueils que tous les systèmes de réputation ne partagent pas.

Je vais regrouper les toiles de confiance ou systèmes de réputation en 2 familles :

  • toile/système/réseau à croissance mycélienne : seul des comptes au contact du réseau existant peuvent le rejoindre. Conséquences :
    • être proche des initiateurs / de celleux qui sont déjà dedans est un avantage, une asymétrie spatiale, durant toute la phase de croissance / tant que la toile n’est pas omniprésente.
    • la vitesse de croissance est limitée à la frange voisine de la toile existante, donc la phase de croissance est très lente, et pérennise donc l’asymétrie spatiale des années durant, à moins d’automatiser l’ajout de proche en proche, ce qui rendrait la notion de confiance caduque (à moins qu’une idée ne soit trouvée à ce sujet).
    • avantage en revanche, l’adoption de proche en proche à partir du foyer original permet une forte acculturation, et donc un maintien d’une certaine homogénéité culturelle qui favorise cohésion et sentiment d’appartenance communautaire.
  • toile/système/réseau à croissance fédérative : des îlots peuvent se créer et croître indépendamment, avec une réputation locale, non reconnu par les autres îlots tant qu’ils ne sont pas interconnectés. Lorsque les îlots se connectent/fédèrent entre eux, la réputation/confiance peut se mettre à circuler/alimenter façon vase communiquant les îlots initialement séparés. La notion de réputation/confiance globale peut être liée au plus grand réseau, ou au réseau(x) héritant de sources initiales considérées comme fiables. Conséquences :
    • un groupe local peut tisser son propre réseau et agir en parallèle/simultanément pour se fédérer avec réseaux des autres.
    • des groupes locaux peuvent se former simultanément aux 4 coins de la planètes, sans limite de nombre.
    • dès que les groupes deviennent suffisamment grands pour toucher les autres, ils se fédèrent naturellement.
    • le rythme de croissance est limité par la connaissance et l’adhésion à la proposition associée au système, et non à la proximité avec celleux qui en font déjà partie.
    • l’asymétrie spatiale s’en voit très fortement réduite.
    • l’acculturation aussi.
    • les mécaniques anti sybil doivent prendre en compte l’arrivée de bouts de réseaux entiers.

Exemples de toile mycélienne : G1, DNS
Exemples de toile fédérative : BrightID, GPG

4 J'aimes

@elois Je te laisse me dire si c’est plus compréhensible une fois écrit qu’au téléphone :wink:

La fédérative n’est ni plus égalitaire ni plus rapide selon moi mais juste impropre au développement d’une monnaie libre.

La réflexion va buter essentiellement sur ce point. Le point crucial reste ainsi déterminé : « étant donné que la monnaie va reposer sur la confiance liée au fait que 1 individu -> 1 seul compte membre créateur de DU (monnaie), comment s’assurer qu’il n’y a pas de comptes doubles ? ».

Ce problème ne se pose pas dans GPG par exemple, puisqu’il n’y a pas de problème dans ce réseau à créer autant de comptes que l’on veut, qui ont tous les mêmes droits.

Possible que BrightID arrive à un résultat, mais ce système est encore en beta.

Ceci dit si on lit les tenants de BrightID, on lit très précisément :

"Groups in BrightID are useful for one thing: to prove that you’re a unique person. Groups represent a small number of people that know each other well. "

Ce qui semble me rappeler doucement un principe de TdC bien connu…

Bref je dirais donc que la priorité étant 1 invididu - 1 compte, la question n’est pas « quel système de toile, la question résultante étant alors de comment éviter les faux comptes », mais « comment éviter les faux comptes, la réponse à cette question déterminant le type de Toile résultant ».

Trouver donc la réponse à la question « comment éviter les faux comptes » (et donc la fausse monnaie libre) est nécessaire et suffisante pour savoir quoi faire, et ce sans aucun a-priori sur les caractéristiques de la Toile résultante.

5 J'aimes

Je suis d’accord avec ton analyse @1000i100. De toute façon il est impossible de garantir à priori qu’il n’y a pas de compte ‹ tricheur ›…
Je trouve que BrightID ressemble au système d’évaluation introduit dans gchange !?
Le contrôle pourrait alors se faire à posteriori… Lors des échanges… Et ainsi motiver à échanger pour atteindre et conserver un niveau qui permet d’activer le statut forgeron du DU.

Yep, j’en parlais ici : Fusion/Division de monnaie libre/toile de confiance

Si on trouve des règles de fusion/Division de ML on est bon :slight_smile:

Et pour répondre à cette question j’avais également lancé ce sujet : La monnaie libre comme engagement entre 2 personnes

Où j’ai une approche pair-à-pair de ce qu’est finalement une monnaie libre : des engagements de redistribution de part relative de monnaie entre des personnes.

Si on trouve les règles qui permettent d’étendre des engagements à plusieurs personnes de façon asymétrique (Alice et Bob s’engage mutuellement, Bob et Carole s’engage mutuellement, qu’en est-il de la relation Alice-Carole ?) on est bon :slight_smile: Mais pas dit que ça soit possible :sweat_smile:

Dans ce cas de figure, une monnaie directement en relatif M/N pourrait aussi être pratique : Formules en référentiel DU et M/N

Car on n’a pas besoin de calculer M :smiley: Le calcul du DU et l’évolution du solde doit prendre en compte la variation de N.

Mais lors qu’une fusion de deux ML, il y sûrement une règle à appliquer sur tout les soldes pour les convertir dans la nouvelle ML fusion des deux précédentes.


Sur le fait d’être présent dans plusieurs ML, on en avait déjà parlé sur l’autre forum : https://forum.monnaie-libre.fr/t/plusieurs-ml-plusieurs-toiles-un-seul-ou-plusieurs-du/1921

Est-ce vraiment un avantage ? Voir mon commentaire ici : https://forum.monnaie-libre.fr/t/plusieurs-ml-plusieurs-toiles-un-seul-ou-plusieurs-du/1921/31?u=yyy

Est-ce qu’on serait pas dans le cas de Alice/Bob/Carole juste au dessus ?


Concernant les engagements, si on y réfléchi, peut-être que ça ne suffit pas. C’est l’exemple du village ML et des touristes qui viennent dépenser une fois par an, voir ici : https://forum.monnaie-libre.fr/t/un-village-monnaie-libriste/10768/38?u=yyy

Pour le résumer, signer un engagement de redistribuer son surplus monétaire avec d’autres, c’est prendre le risque de vendre des biens/services contre ce surplus monétaire, mais ne pouvant pas le dépenser, de le perdre sans contrepartie (alors que le but de la vente était de pouvoir acheter biens/services en retour).

On dirait que tel quel, ça ne suffit pas. la ML semble bien être le meilleur des intermédiaires des échanges, et que l’intermédiaire des échanges ne peut pas être « réserve de valeur », mais il nous manque peut être un autre outil, externe au premier, pour régler ce problème (de ne pas être garanti de pouvoir dépenser ce surplus).

J’en parlais ici : https://forum.monnaie-libre.fr/t/trois-fonctions-de-la-monnaie-trois-outils-differents/7925

1 J'aime

Mycélienne ou fédérative, les 2 approches sont de la modération à priori.
C’est juste une idée, je dit certainement une bêtise car je n’y connais pas grand chose en tdc, mais ce ne serait pas possible de faire de la modération à postériori ?
Avec des bots qui scaneraient la toile pour vérifier les certifications. Le DU serait créé quelques jours après la date de certification pour laisser le temps aux bots de faire leur travail…

Qui modérerait ? Une entité centrale et infaillible ? Bof. Les membres de la TdC ? On revient au même système de certification.

Pour modérer a posteriori, il faut pouvoir annuler. Ça voudrait dire qu’on pourrait empêcher quelqu’un d’être membre. Cela me paraît dangereux, il faudrait arriver à faire ça sans permettre le chantage, le « vandalisme de toile »… (c’est pour ça que les certifications sont irrévocables actuellement)

1 J'aime

Oui, je pensais à ça. Mais c’est vrai, comme tu dis, cela revient au même système de certification. Car qui aurait autorité pour annuler une certification ? Des bots… certifiés ?

Merci @1000i100 c’est plus clair :slight_smile: (c’est moi qui ai demandé a 1000i100 de nous parler de cette idée sur ce forum suite a un échange téléphonique ou il a abordé cette idée).

Par contre j’ai des doutes sur la faisabilité technique tout en répondant au besoin « 1 humain = 1 compte », il me faudrait un exemple ou une proposition technique de comment faire cela en répondant au besoin, mais d’intuition j’ai l’impression que ce n’est pas possible.

Je ne crois pas que BrightID soit fédératif comme tu le décris, chaque application peut en effet choisir son groupe seed, mais il y a bien un seul groupe seed par application.

BrightID n’est pas UN système d’identification. C’est un réseau que chaque application peut utiliser avec sa propre formule pour définir un compte est bien un humain unique ou non, ce qui passe par définir :

  • Une formule de calcul du score
  • Un seuil = montant du score à partir duquel on considère que le compte correspond suffisamment probablement a un humain unique.

Ce qui n’a rien de fédératif.


Concernant l’approche de @yyy, je pense personnellement que la fusion de toiles et une mauvaise idée, la toile de confiance est déjà la partie la plus complexe du code de Duniter, la plupart des bugs en production (presque tous en fait) ont concernés cette partie.
Une fusion de toile, quelle que soit la manière dont se serait spécifié, me semble être d’une complexité infiniment plus grande, ce qui est contraire au principe KISS.

Il me semble essentiel que l’on reste centré sur la manière la plus simple possible de répondre au besoin « 1humain = 1 compte ».
Alors peut-être qu’il existe une manière KISS de faire du fédératif (j’en doute, mais je laisse la porte ouverte, on ne sait jamais) mais alors il faut trouver autre chose qu’une fusion de toiles.

Je laisse chercher ceux que ça intéresse, en parallèle je pense qu’il est possible de modifier/adapter notre toile mycélienne pour amoindrir certains de ces écueils, et perso je préfère me concentrer sur cette 2ème voie :slight_smile:

2 J'aimes

Sauf que ces comptes sont relié entre eux par un système de groupe, et on peut créer des groupes entre nous, quel que soit le nous, et appartenir à plusieurs groupes.

Pour moi, c’est ici qu’est l’aspect fédératif.

Ensuite, selon comment on calcul le score, le seuil de confiance pour considérer un compte comme répondant au 1compte = 1 humain, on se retrouve avec une toile de confiance qui reste fédérative, ou qui l’est moins, ou peut-être pas du tout, mais j’ai du mal à imaginer quel mode de calcul pourrais rendre ce socle à base de groupes fédératif non fédératif, même avec une seule seed.

En fait j’ai envie de faire un parallèle entre centralisé, décentralisé, et acentré/distribué.
Les réseau physique informatique sont à ma connaissance a des degré différent de centralisation/décentralisation.

Pour moi, du 100% mycélien, c’est un peu comme si il fallait que je commence par brancher ma box et qu’elle se connecte à internet, avant de pouvoir brancher un switch derrière la box, puis mon/mes pc au switch.

Du fédératif : j’ai mon réseau local qui marche, sans accéder à internet, et quand je branche ma box / la fibre dans ma box, alors mon réseau est relié aux autres réseaux.

Si à chaque coupure de courant, je devais faire gaffe à ce que ma box ai retrouver internet avant d’allimenter mon switch, puis attendre que mon switch ai booté pour allumer mon pc… ben ça serait pas pratique.

Pour autant, si je considère que j’ai internet parceque j’ai pu relier mon PC à celui de mon coloc, box débranché, ben, je suis loin du compte.

En gros, pour revenir à la TdC le DU par membre :

Si on se certifie entre coloc, on ne va pas avoir de DU si on est pas relié au reste de la toile.

En revanche, on peu se certifier entre nous, ce qui me semble un gros plus fédératif par rapport à attendre que l’un ai son DU/status de membre pour pouvoir certifier son voisin.

Si on c’est certifié entre nous, puis que l’un (ou plusieurs selon l’algo) se reli à une zone alimenté par des seed, alors notre score monte, et, toujours selon l’ago, on atteint potentiellement le seuil poru avoir le status de membre/le DU. Du coup, on a pu créer les liens en amont, de manière fédérative, puis allimenter le réseau local après coup.

3 J'aimes

Bah ça revient à gérer un logiciel tiers qui gère la piscine ou une piscine, ça peut rester parfaitement indépendant de Duniter.

Tu crées un logiciel P2P qui gère des certifications, et donc l’objectif est d’entrer à terme dans la TdC Ğ1. Lorsque des groupes se sont bien certifiés entre eux, et que quelques uns commencent à entrer dans la TdC Ğ1, alors faire entrer les autres membres devient plus rapide et plus simple.

2 J'aimes

Du coup, un logiciel tier qui est capable de rejouer des certifications dans le bon timing automatiquement le jour ou là zone de toile est alimenté. D’un point de vu expérience utilisateur ça me semble jouable, d’un point de vue sécurité, je vois mal comment faire ça efficacement pour l’usager sans avoir une copie de sa clef privé pour pouvoir rejouer les certif le moment venu dans le protocol duniter, du coup, ça me semble foireux.

Le max faisable avec une sécurité correcte, ça serait de collecter des pré-certifs, et d’envoyer des notifications par email pour inviter à certifier les pré-certifié le jour ou les certifs peuvent passer.

2 J'aimes

Cette idée est très intéressante, et je pense que le projet Circles s’en approche. Si l’on autorise une toile de confiance non connexe dans un logiciel, autrement dit plusieurs toiles de confiance, les différentes parties ne peuvent pas échanger de monnaie (dans tous les cas produite par DU) car il n’y a pas de relation de confiance. Et dans le cas d’un lien, quel est le gage de confiance suffisant pour accepter la monnaie ? … les règles de la toile de confiance ! On peut donc considérer comme non connectées deux régions du graphe connexes mais qui ne remplissent pas les règles de la toile, ça devient compliqué à gérer ! Mais c’est possible, à conditions de répondre aux questions suivantes :

  • à propos des conditions de validation d’une transaction
    • accepte-t-on la monnaie venant du toile non connexe ?
    • si non, accepte-t-on la monnaie produite par un DU antérieur à la date de fédération ?
  • quand considère-t-on deux toiles comme fédérées ? doit-on attendre que toute une toile soit fédérée ou peut-on accepter une partie seulement ?
  • comment gère-t-on la scission d’une toile ? les individus exclus d’une toile par règle de distance par exemple fondent-ils une nouvelle toile ?

Pour s’imaginer les problèmes que l’on rencontrerait, on peut imaginer que plusieurs monnaies utilisant le logiciel duniter avec leur propre toiles de confiance (mais les mêmes paramètres) souhaitent fusionner. Il faudrait émettre les certifications en nombre suffisant pour que les toiles respectent leur règle de distance puis prévoir un mécanisme de migration pour les DU créés initialement sur une toile le soient sur l’autre… Bref, il y a du boulot !!

2 J'aimes

C’est ici que s’étend le gouffre entre purs théoriciens abstraits (typiquement mathématiciens) et informaticiens. La réalisation informatique suppose un investissement, une rigueur, une procédure, un protocole, dont la charge ne peut être ignorée.

La distance est aussi grande que celle qui sépare Erathostène de Sputnik, dans toutes les dimensions : spatiale, temporelle, humaine, historique, énergétique etc…

Au point qu’on est en droit de se poser la question de quelle métrique utiliser pour mesurer de telles distances.

5 J'aimes