To be or not to be oriented?

Bonjour à toutes et à tous,

D’abord un grand bravo à tous ceux / celles qui oeuvrent pour définir et concrétiser une monnaie libre !
D’après ce que j’ai compris en écoutant Inso dans le Monnaie Libre n°76, le principal objectif de GTest porte sur la toile de confiance.

Je suis membre GTest depuis 8 jours et je voulais relater ma première expérience utilisateur. J’ai été accueilli par ce message :

Du coup, je me suis interrogé : "pourquoi devrais-je certifier des membres déjà présents dans la toile ? En plus, les sentries sont les personnes qui me paraissent en avoir le moins besoin. Intuitivement, j’avais plutôt l’idée de réserver mon quota de certifications pour des potentiels entrants.

J’ai donc creusé un peu notamment avec cette introduction à la toile de confiance et ces échanges.

J’en suis arrivé à cette question : mais pourquoi choisir d’orienter le graphe des relations entre membres ?

En procédant ainsi, on perd la notion de métrique/distance mathématique pour se rabattre sur une quasimétrique (perte de la propriété de symétrie). Ce choix ne me paraît pas neutre.

Les risques / inconvénients que j’y vois sont les suivants :

  • difficulté de compréhension pour les utilisateurs (en témoigne les nombreux échanges sur le forum) ;

  • risque d’avoir des puits (les membres qui ne certifient personne) dans la toile ;

  • obligation de mettre en place des stratégies / règles pour palier la perte de cette propriété de symétrie ; la nécessité de certifier en interne en est une il me semble ;

  • risque d’effets de bord qu’on maîtrise plus ou moins (les quasi-blocages aux paliers).

Est-ce que tout simplement au moment de la certification, il ne faudrait pas une acceptation du certifié, qui marquerait la reconnaissance mutuelle ?

Vous avez sûrement longuement débattu de cette question mais cela m’intéresse de

  1. savoir si ce point est figé ;
  2. comprendre pourquoi vous en êtes arrivés à ce choix.

Merci d’avance pour vos retours.

Benoît

Bonjour Beun,

Alors oui, ce point est figé, sauf à ce qu’on me démontre qu’une autre solution est nettement préférable.

Pourquoi donc ce choix ?

Tout d’abord parce qu’on peut déjà observer que la reconnaissance n’est pas forcément symétrique en dehors de Duniter : A peut très bien reconnaître B sans que ce dernier n’ait entendu parler de A. De plus, même si l’on prenait en compte “l’acceptation de B”, je ne verrai toujours pas cette acceptation comme une reconnaissance de A. C’est autre chose.

Mais il y a mieux : la reconnaissance asymétrique est un cas plus général de la reconnaissance que celle symétrique car, partant de la reconnaissance asymétrique comme fondement, je peux aussi produire des reconnaissances symétriques, l’inverse n’étant pas vrai. J’ai une information en moins si je ne prends que celle à double sens, c’est le sens, précisément, que je perds.

Et donc il se peut que des membres se reconnaissent de façon symétrique, mais c’est simplement une possibilité. D’ailleurs elle existe souvent, mais pas toujours pour des raisons qui regardent chacun.

Qu’en serait-il si nous avions choisi au contraire une définition se rapprochant de la métrique mathématique ? Le choix aurait-il été plus neutre ? En vertu de quoi ?

Il faut prendre en compte le contexte : une phase d’initialisation dans le cadre d’une monnaie fortement restreinte (distance max 3, et stock limité à 15 signatures). Le stock affecte terriblement le nombre de chemins possibles.

Dans une monnaie réelle, les paramètres reflètent une toile potentielle déjà existante (les relations “de la vraie vie” - si tant est qu’il existe une telle chose, bref !) : il n’y a donc pas trop de questions à se poser, on certifie ceux qu’on connait et les paramètres permettent grosso-modo cette reconnaissance sans blocage.

Par ailleurs, comprendre qu’on ne peut pas forcer autrui à nous reconnaître est une expérience structurante pour comprendre les fondements d’une monnaie libre : car reconnaître qu’autrui puisse évaluer différemment une reconnaissance prépare au fait qu’il en va de même pour les valeurs. Ce n’était pas voulu, mais l’effet est là.

Ça rejoint ma remarque précédente : comprendre qu’on ne peut pas forcer autrui à nous reconnaître. Car dans ce cas, est-ce que B a réellement souhaité reconnaître A ou l’a-t-il simplement fait pour obtenir une certification de plus ?

Par ailleurs il existe déjà des puits, dans Duniter et en-dehors : des personnes qui souhaitent être reconnues mais ne font pas de même ensuite. Nous l’avons largement vu dans TestNet mais aussi dans GTest : c’est aussi pour cela que tu as reçu ce message de Candidesk, qui a senti que la diligence pour être reconnu n’était pas toujours là pour reconnaître à son tour (encore une fois, pour des raisons qui regardent chacun, il n’y a pas de jugement à faire ici).

Et donc, doit-on les forcer à le faire ? Je ne pense pas, la cause de la reconnaissance n’étant plus la même, l’effet ne sera pas le même non-plus. On aura pas forcément une reconnaissance, mais un bout de “papier numérique” sans signification.

C’est pour cela que nous avons 2 notions permettant de gérer ces puits :

  • les sentinelles
  • le pourcentage de reconnaissance par les sentinelles dans le cadre de la distance

Tu me diras « ç’aurait été plus simple s’il y avait eu symétrie dans toute la toile ». Peut-être que oui, tout comme le monde physique serait certainement plus simple sans brisure spontanée de symétrie. Mais peut-être qu’alors nous n’existerions pas :slight_smile:

En espérant avoir répondu à tes interrogations.

2 Likes

Oui. Bien vu, tout à fait.

Ce risque est inexistant puisque la distance se fonde sur les sentries.

C’est possible oui tout à fait, mais il faut démontrer la supériorité de l’approche.

Peu importe le “pourquoi” de quoi que ce soit. Le protocole est ainsi. Il ya-t-il d’excellentes raisons pour le faire autrement ? Si non alors il n’y a pas de raison de le changer, si oui, alors il faut considérer ce point en effet.

Bonsoir,

Merci à tous les deux d’avoir pris le temps de me répondre.

J’en serais bien incapable, je l’avoue.

Selon moi, il y a souvent un compromis entre deux approches :

  1. soit nous adoptons un cadre mathématique avec des hypothèses fortes. Ce faisant, nous avons toutes les propriétés qui nous plaisent bien. Les avantages sont : moins de complexité, moins de risques de bugs, de comportements inattendus, etc. Seulement, ces hypothèses peuvent s’avérer trop restrictives pour modéliser correctement la réalité et on ne résout alors… plus rien ! :blush:
  2. soit on relâche les hypothèses (la perte de symétrie en l’occurrence) et il faut trouver des solutions aux problèmes qui peuvent survenir, ce que vous avez fait avec ces notions de sentinelles ou de pourcentage de (quasi-)distances notamment.

J’ai déjà rencontré des soucis similaires sur d’autres projets (pas transposables cependant). Quand j’ai commencé à me pencher sur la toile de confiance et le choix du graphe orienté, tous les voyants se sont allumés ! :blush:

Je comprends.

C’est indéniable.

J’utilisais le mot “neutre” dans le sens “anodin”.
Ce choix d’adopter un graphe orienté est un choix responsable : on choisit de se passer de la symétrie pour mieux modéliser les relations de certification. Ok.

J’espère que tu as raison.
La montée à l’échelle m’inquiète un peu (à tort, j’espère). Est-ce que des tests de ce type ont été menés ?

Honnêtement, je ne sais pas.

C’est peut-être simplement un point de vigilance.

A part ĞTest, pas à ma connaissance.

Il y a bien eu TestNet également, la montée en membres était très facile : distance de 5, et 1 seule certification requise pour entrer, 1 certification / heure max. Il n’y a jamais eu de blocage sérieux à ma connaissance.

Mais la montée à l’échelle m’inquiète aussi, pas pour les aspects toile de confiance :slight_smile:

Peut-on envisager une monnaie de test dédiée (avec des paramètres de temps très courts entre les certifications) et un simulateur informatique de comportements humains ? (avec différents comportements de certification, de transactions, etc.) Cela aurait un sens ?

Ça pourrait être intéressant oui !