Sujet sur les liens faibles et posts en section Staff

Merci d’avoir partagé vos avis sur la question.
Attendons alors 5 à 10 ans pour vous laisser fignoler le prototype.
“Monsieur tout le monde” attendra, je vais calmer plus encore ma communication et j’en reparlerais à mme Michu dans 10 ans.

1 Like

Le risque c’est que des règles trop strictes ne permettent pas à la toile de grandir. Dans ce cas ces règles se renforceraient elles-mêmes à partir d’un certain point, créant un effet de seuil.

Ğaluel et toi pensez que ce n’est pas le cas actuellement, j’espère que vous avez raison. Je ne suis personnellement pas de cet avis.

3 Likes

Ce n’est pas une question d’avis, une simulation bête avec 50 connaissances par personne en moyenne et un délai de certification moyen permettent d’évaluer le temps nécessaire pour une toile de se développer et jusqu’où.

En l’absence d’une simulation ou d’une démonstration on peut dire “je ne sais pas” mais pointer un avis ne mène nulle part tu en conviendras.

Ce que je constate sur Perpignan c’est qu’il faut un temps nécessaire pour atteindre 5 certifiés bien formés, et je n’y vois aucun inconvénient bien au contraire.

Quant à Toulouse, ils ont démontré qu’une fois 5 certifiés atteints, les personnes souhaitant réaliser une monnaie libre ont fait et font le nécessaire pour continuer le processus.

Bien sûr cela ne s’impose pas.

Il me semble que l’avis distingue le robot de l’humain. Je sais que l’humain est pénible à mettre en équations, mais enlève la June reste l’humain, enlève l’humain…
D’ailleurs je ne me questionne plus sur ma particpation aux futures RML, le déroulement sur 3 jours prévu à Perpignan a levé toute hésitation.
Je ne suis pas ingénieur, seulement un “tout le monde”

Message reçu.

1 Like

Mais justement je prétends que ce n’est pas correct de faire ça, la toile où règnent 50 connaissances par personne en moyenne n’est pas la toile Ğ1 mais une toile projetée de l’ensemble de toutes les toiles humaines(t) dont les liens ne se sont pas établis de la même manière que pour la Ğ1.

Autrement dit cette toile projetée Tp contient notamment la toile Ğ1 Tğ, et cette toile Tğ telle que tu l’as pensée l’a été sur la base de l’existence de Tp et de la possibilité de pouvoir réutiliser ses chemins pour construire Tğ (c’est l’argument des 50 connaissances).

Or ce qui peut être constaté dès aujourd’hui c’est qu’un membre de Tğ ne peut révéler en son sein un nouveau point déjà présent dans Tp qu’à la seule condition que 5 points de Tğ possèdent 1 point en commun dans Tp, en sont conscients et que ce point de Tp souhaite intégrer la Ğ1.

Ce qui est déjà une sacrée condition ! Rien que dans Tp, quelle est la probabilité pour que, en prenant au hasard 5 points (on pourrait se limiter à un territoire restreint comme une région), ceux-ci possèdent 1 connaissance commune ? Puis 2, 3, 4, 5 ? Je serais très curieux de savoir, je pense que ça tombe très rapidement vers 0. Si j’ai juste il n’est pas étonnant qu’il faille faire des apéros pour étendre la Ğ1, car c’est déjà difficile dans Tp or Tğ << Tp (pour ne pas dire Tğ <<<<<<< Tp).

Il suffit d’ailleurs de prendre la toile des fondateurs : presque aucun de nous ne se connaissait à la base, la toile Ğ1 était une ğtoile qui est venue se projeter en plus sur Tp.

De sorte que se reposer sur la topologie de Tp pour construire Tğ me semble incorrect, que la contrainte des 5 liens forts est trop importante, et c’est pourquoi je pense que la toile va durablement stagner.

10 Likes

C’est rigolo, je venais justement de penser à ce genre d’argument.
Reste à savoir comment éviter les doubles comptes (sans parler d’attaques sibylles) si on relâche les règles.

Une condition fortement contraignante est justement nécessaire afin de s’assurer que la Ğ1 puisse prendre le temps de mûrir avec des gens qui ne sont pas “monsieur tout le monde” et qui restent proche de personnes maîtrisant la technique ou/et de la compréhension de la TRM. Tout comme les conditions fortement contraignantes d’accès au web pendant sa 1ère décennie d’existante lui ont permis de mûrir convenablement.

La aussi c’est souhaitable, si tel n’était pas le cas on pourrais rapidement se retrouver avec une majorité de personnes qui ne sont pas assez proche de la compréhension technique ou théorique, ce qui serait fatal vu l’état encore très expérimental des outils et le très faible nombre de contributeurs.

J’espère bien qu’elle va stagner, tout est allé beaucoup trop vite alors qu’on est bien loin de pouvoir accueillir “monsieur tout le monde”. On n’a qu’un seul contributeur principal au client le plus utilisé (Cesium), on n’a toujours pas d’app pour iOs, les bugs sont encore nombreux et mette un temps fou à être traités, on a déjà le plus grand mal à gérer la mise en production actuelle autant coté serveur que coté client, alors oui clairement il faut que la toile arrête de croître aussi vite.

Comme je viens de l’expliquer dans mon paragraphe précédent, les attaques Sibylle sont loin d’être notre premier souci. Même sans aucun attaque on a déjà grand mal à maintenir la mise en production actuelle alors qu’on n’a moins de 1500 membres, il serait donc fou d’alléger les règles maintenant !

3 Likes

Certes Eloïs, mais c’est une argumentation hors-sujet. Ces règles ont été pensées indépendamment du fait qu’il manquerait ou qu’il y aurait trop de développeurs.

1 Like

Perso je considère que ce n’est pas hors-sujet puisqu’il y a une relation entre le volume de contributions et la taille de la communauté. Ce lien joue comme un cercle vicieux au début puis au passage d’un certain seuil jouera comme un cercle vertueux.
Pour l’instant nous sommes dans un cercle vicieux : plus la communauté grandie plus les contributeurs ont du mal a assurer derrière, ce qui freine l’agrandissement de la communauté. Un jours nous passerons un seuil de se sera l’inverse : plus la communauté grandira, plus les contributeurs seront nombreux et plus cela permettra d’accélérer l’agrandissement de la communauté.

Pour l’instant ce n’est pas le cas car nous n’avons aucun financement donc les contributeurs n’ont aucun intérêt pécuniaire a contribuer, on se limite donc au contributeurs contribuant par conviction. On passera du cercle vicieux au cercle vertueux le jours ou il deviendra pécuniairement intéressant de contribuer au projet. C’est con mais c’est comme ça, la plupart des gens ne sont pas pas des bon samaritains, surtout dans une société ou l’on galère déjà fortement a joindre les deux bouts a cause d’une monnaie rare.
Tout les autres projets de logiciels libres rencontre ce même problème, et seul ceux qui ont des financements en monnaie non-libre (dons inclus) arrivent a passer a l’échelle (sauf les petits programmes peu complexes et peu critiques).

Concernant comment “ces règles ont été pensés”, je ne suis pas dans la tête des autres mais de mon coté je ne les ai pas perçus comme indépendantes de l’aspect contributeurs :slight_smile:

2 Likes

Je fais référence à ce sujet : Étude de la WoT et celui-ci n’en fait pas mention.

Mais par ailleurs je n’ai jamais eu vent d’un quelconque lien des règles de la WoT avec le nombre de développeurs. Si c’était le cas sans que j’en ai été informé, alors même que j’étais développeur du cœur, cela constituerai une manipulation que je n’accepterais pas. Toutefois je doute très fortement d’une telle chose, heureusement.

Pour l’instant nous sommes dans un cercle vicieux : plus la communauté grandie plus les besoins en contributeurs sera pressante, ce qui émulera par l’agrandissement de la communauté l’intérêt de nouveaux contributeurs. Un jours nous passerons un seuil et se sera l’inverse : plus les contributeurs seront nombreux, plus la communauté grandira, et plus cela permettra d’accélérer l’agrandissement de la communauté.

Ca tient tout autant la route… , là ou dans la première version on compte sur la mécanique mathématique. dans la deuxième on compte sur le facteur humain.

S’il y a des Ğvaleurs, il y a sûrement des Ğsolutions tout aussi peu prévisibles.

D’ailleurs c’est parce-que la communauté bitcoin s’est agrandie, que le code n’a plus suivi. Et c’est alors que les devs se sont collés au problème à posteriori, non à priori.

1 Like

Il faut se rendre à l’évidence, l’argument développé par @elois est corroboré par les faits. Dans les faits, il y a maintenant 0 contributeur au coeur avec la prise de distance (justifiée et qui ne pose pas question) du développeur historique unique.

Nous avons donc de bonnes raisons de penser qu’il est possible que la Ğ1 ne passe pas l’année 2019 ou l’année 2020 pour des raisons essentiellement techniques (bugs non résolus par manque de compétences, ou manque de temps, effondrement de l’idée de lancement d’une première monnaie libre).

Donc il ne remet pas en question aucune évolution possible que ce soit. Il dirige seulement la réflexion sur l’objectif d’amener des contributeurs au niveau nécessaire pour penser des évolutions et être en mesure de les mettre en oeuvre et les maintenir via les possibilités exposées précédemment.

Après les utilisateurs peuvent réfléchir et discuter de tout ce qu’ils veulent. Ils peuvent même tenter de faire des évolutions de code ! Après tout un troupeau de lemmings fait aussi ce qu’il pense nécessaire de faire.

3 Likes

Et pourtant les lemmings sont toujours là.
Pas sur que l’humain survive à sa supérieure intelligence en revanche…

Il ne faut pas avoir des raisonnements binaires, bien sur que les devs sont un besoin majeur pour la monnaie, tout autant que les utilisateurs.
Il n’y a pas à prioriser l’un ou l’autre, les deux avancent de concert et quand l’un avance trop l’autre le rattrape parce-qu’il n’y a pas d’autre possibilité sinon la disparition. Il n’y a pas de poule ou d’œuf au commencement, il y a les deux. Tout comme l’espace ou le temps ne peuvent être dissociés pour permettre l’expansion de l’univers. (si expansion il y a)

Edit: désolé j’arrête là car je me rend compte qu’au final je suis en train de débattre, ce qui n’est ni l’endroit, ni légitime de ma part je dois l’admettre.

Question peut-être un peu bête, mais du coup, doit-on virer du réseau ceux qui ont certifiés leurs très jeunes enfants ? Parce qu’ils n’ont à l’évidence pas pu respecter la licence…

1 Like

Le respect de la licence incombe principalement au certificateur.
Dans le cas d’un très jeune enfant le devoir d’information est simplement différé.
Il est donc (de mon point de vue) possible de certifier des enfants au QI inférieur à un lemming.

Comme le dit bien Jean, le certificateur valide le certifié soit parce que celui-ci apporte les preuves de confiance nécessaires et des moyens de le joindre, soit parce que ses tuteurs légaux le font. Donc pour les personnes sous “tutelle”, ce sont les tuteurs qui apportent les preuves de confiance 1 identité => 1 compte et les moyens de les joindre.

1 Like

D’accord, je comprends, merci pour ces explications.

Du coup le tuteur gère plusieurs compte membres.
Cela donne un grand pouvoir à un tuteur gérant 4 ou 5 compte ou plus, car il peut à lui seul certifié d’autres comptes, jusqu’à 100 compte, et à partir de ces comptes il peut en certifier d’autre.
La toile de confiance devient beaucoup moins fiable.
Il me semble que la certification devrait dissocier le fait que la personne existe de manière unique, et donc doit recevoir un DU, et le fait que la personne soit en capacité de certifier d’autre personne.
Donc plutôtqu’un statut de tuteur j’imagine un niveau intermédiaire de certification “membre sous tutelle” ce membre recevrai son DU, mais ne pourrais certifier d’autre membre.
Je pense que techniquement c’est possible, et pas trop complexe à développer.
Qu’en pense les développeurs pro?

Ils y a différents niveaux de “pouvoirs” dans la Ḡ1 qui sont malheureusement difficiles à égaliser, mais comme dans beaucoup de domaines (hiérarchie par l’expertise par exemple).

  • Les développeurs ont l’expertise du code, ils définissent donc le protocole (les lois) de la June. Soit par eux mêmes pour ce qui est incompréhensibles aux utilisateurs, soit en réponse à une demande des utilisateurs sur des domaines compréhensibles par tous.
  • Les personnes membres qui font tourner des serveurs, ont le pouvoir de refuser une version du logiciel qui ne leur conviendrait pas. Ce sont eux qui appliquent les lois du code en l’exécutant sur leurs serveurs. Et en créant des blocs dans la blockchain.
  • Les utilisateurs membres qui crée la monnaie ont le pouvoir de ne plus utiliser la monnaie si le protocole ne leur convient pas. Ou de protester sur les forums ou les réseaux sociaux.

Ce sont déjà les trois niveaux importants de pouvoir.

Pour des raisons de sécurité, il est prévu de dissocier les membres capables de créer des blocs dans la blockchain des autres. On aura donc :

  • créateurs de monnaie et certificateurs.
  • créateurs de monnaie et de blocs et certificateurs.

Le problème du bébé qui certifie a déjà eu lieu et il revient aux certificateurs des parents d’agir pour leur rappeler la licence et de ne pas utiliser le compte de l’enfant pour certifier. Ce problème peut se résoudre par la toile de confiance. Sans ajouter une troisième catégorie qui diviserait la communauté et rendrait complexe sa compréhension.

Je propose cette idée pour résoudre un des problème contradictoire de l’extension de l’utilisation de la monnaie.
Je pense que l’utilisation de cette sera de plus en plus intéressante et aisée s’il y a de plus en plus d’utilisateur de cette monnaie. C’est sans doute pour cela que j’en ai entendu parler sur le site OVS Nantes : Les utilisateurs en font de la pub.
(J’avais déjà vu quelques article sur le sujet l’an dernier, mais à l’époque cela me semblait limité à l’Occitanie)

Les utilisateurs non certifié auront toujours (à mon avis) l’impression d’être lésé par rapport aux membres certifiés qui eux peuvent crée de la monnaie et donc “s’enrichir” sans rien faire.
D’où la course aux certifications que je constate sur les forums. Et sans doute aussi lors lors des Rencontres Monnaie Libre.

J’ai toujours entendu dire que plus une collectivité s’agrandit plus la probabilité de comportement malhonnête augmente. Et que toute personne disposant d’un pouvoir aura tendance à abuser de ce pouvoir. (Ici le pouvoir de certifier)

Donc plus on veut faciliter les échanges plus on augmente les risques de fraude.

Ma proposition a pour but de facilité l’augmentation du nombre d’utilisateurs (sans qu’ils se sentent lésés) tout en limitant les risques de fraudes.

J’ai cru comprendre qu’il y avait pénurie de développeurs compétents sur le sujet, donc je comprends qu’il faille se contenter de ce qui se fait techniquement, et renforcer la confiance en l’humain (et donc ralentir les certifications)
Personnellement je ne certifierais pas quelqu’un que je n’aurais croisé que deux ou trois fois. Donc je n’espère pas être certifié avant longtemps, mais je me sentirais un peu lésé tant que je ne serai pas cocréateur de monnaie.

Je me pose la question ; dois-je faire de la pub la June? Où au contraire lui garder un caractère confidentiel?