Il convient surtout de bien respirer profondément par le nez, 1 an d’existence ce n’est rien du tout. Absolument rien ne pause problème, et le taux d’adoption est encore bien trop rapide. L’année où l’on constatera un N(t) stable ou en régression sera une année où l’évolution des règles pourra commencer à être étudiée.
Patience et persévérance sont nécessaires concernant tout voyage qui veut mener suffisamment loin.
Très bien en ce cas. Je dirai simplement que quand le moment sera venu, le code sera prêt.
Je repensais à cette proposition cette après-midi.
Elle me plais tant d’un point de vu sécurité que diffusion plus aisée,
mais elle me conviens moins bien sur le plan “égalité entre être humain” d’un point de vu communication.
Le coté :
Me semble un vecteur de critique justifié.
J’aurais tendance d’une part à explorer la piste BrightID évoqué ici : BrightID - Identité unique décentralisée
D’autre part à penser/nommer les groupes que tu propose comme :
Et donc de présenter ça non comme un niveau privilégié mais comme une responsabilité à porter, avec le besoin de formation/compréhension associé pour pouvoir assumer sa responsabilité correctement.
Ceci dit, en reprenant l’analogie “droit de vote” = faire tourner un noeud membre, on restreint la citoyenneté au seul garant du fonctionnement technique.
L’intérêt que je vois à cette approche est de limiter la critique pyramidale par une rhétorique plus responsabilisante qu’élitiste.
L’inconvénient que j’y vois est paradoxalement de réduire l’attraction des rôle à responsabilité, et donc que de favoriser dans la pratique un aspect plus pyramidale dans le sens que les rôle à responsabilité risqueraient de rester détenu par une faible part des membres.
Ces réflexions ont-elle avancé depuis le temps ?
Me concernant j’y ai un peu réfléchi. Il y a bien deux problématiques distinctes :
Pour le 1er point, je suis toujours favorable à la création de liens faibles, qui ouvre à leurs bénéficiaires le droit de co-créer la monnaie (avec plus de 5 liens toutefois) et de certifier à leur tour en liens faibles.
Pour le 2ème point, je me demande s’il ne serait pas judicieux de reposer tout simplement sur la topologie de la toile de confiance. Une propriété, par exemple la qualité ou la centralité, permettrait de déterminer qui peut ou non calculer des blocs. L’avantage, c’est qu’avec une centralité élevée par exemple, on sait qu’il s’agit d’une personne investie socialement dans la monnaie et donc théoriquement facile à contacter et qui connaît bien le sujet.
Ceci permettrait d’éviter les « castes techniques », car le niveau de droits sur la Ğ1 devient alors simplement fonction de l’investissement apparent de la personne dans la monnaie.
Mais bon, ce n’est toujours qu’une réflexion à ce niveau.
Il y a en en effet deux objectifs distincts.
Je pense que le critère discriminant concernant les solutions a retenir c’est la complexité ajoutée autant coté code que coté utilisateur final.
Plus un programme est complexe plus il est source de bug et difficile a maintenir. De la même façon plus l’utilisation finale est complexe pet moins la monnaie libre est accessible (le systèeme actuel de certifications est déjà bien compliqué a comprendre pour beaucoup d’utilisateurs).
Donc tout ajout de complexité qui n’est pas absolument nécessaire devrait être proscrit.
Si, toute chose égale par ailleurs, on a une autre solution répondant au même besoin avec un ajout de complexité plus faible alors il conviens de la choisir 
Objectif 1 : a difficulté des nouveaux membres à rentrer (pour co-créer le DU et certifier à leur tour dans ce même but), problématique de création monétaire uniquement : J’avais indiqué dans ce présent fil que l’on peut faciliter l’entrée en modifiant les paramètres de la wot :
Objectif 2 : la sécurité de la blockchain par rapport au droit d’écriture : J’ai proposé sur un autre fil une solution qui ajote zéro complexité pour l’utilisateur final et une complexité faible pour le protocole : Proposition d’identités forgerons − solution user-friendly au problème de sécurité des instances cesium web
La création d’un 2ème type de certification dite “faible” me semble complexifier considérablement l’utilisation pour l’utilisateur final et rendre encore moins lisible la compréhension de la licence et de la toile de confiance 
Y a t’il d’autres idées induisant un ajout de complexité plus faible ? Que pensez-vous de ma proposition d’adaptation des paramètres de la wot ?
Oui c’est une bonne idée, et c’est moins complexe que ma proposition Après ça exclu du droit au calcul les personnes peu investies socialement, somme nous ok avec ça ? (c’est une question ouverte)
Je suis plutôt d’accord avec cela.
Sur le principe l’entrée devient plus facile.
Il faudra tirer toutes les conséquences de ces modifications de paramètres (en termes théoriques, comme l’avait fait Galuel), personnellement je ne l’ai pas fait. Mais bon, le détail des valeurs se discute. Sur le principe j’adhère, mais je ce que je veux va plus loin.
Ce qui me gêne le plus, et qui à mon sens rend l’entrée difficile, c’est la licence et ses implications (rien que la lire et la comprendre, enregistrer le certificat de révocation sinon-c’est-dangereux-pour-toute-la-toile, la formule du DU, la nécessaire transmission de la licence elle-même, ne certifier que conformément à cette licence et sa lourdeur d’implications).
C’est la raison pour laquelle je pousse les liens faibles, où la lecture de la licence, sa compréhension, son adhésion et sa transmission ne sont plus absolument nécessaires. En d’autres termes, pouvoir créer un compte « je veux participer à mon petit niveau », où une simple transmission orale de quelques principes suffit :
Ou d’autres principes similaires dont la transmission orale suffit.
Bien entendu il s’agit de membres légers, dont le pouvoir sur le système technique doit être limité. Mais vous voyez l’idée.
Ça dépend comment c’est fait. Au niveau humain, c’est peut-être juste le bouton de Cesium qui change (ou qui propose 2 boutons), et la transmission humaine qui devient au contraire très simple.
Au niveau technique, ça demande de qualifier la certification et donc d’ajouter un champ, d’adapter un peu la règle concernant sigQty si l’on voulait avoir une valeur plus haute, et rajouter un contrôle concernant la certification (ne pas pouvoir certifier fort si l’on a pas nous-même le niveau). C’est pas vraiment compliqué je trouve.
Par contre il est clair qu’on n’obtient pas la même toile si l’on introduit cette notion. Les membres ne seront plus aussi « experts » que ceux de la toile Ğ1 actuelle. Mais pour obtenir une toile significativement plus grande, je doute que l’on puisse se passer des liens faibles. Il suffit de chercher « humains liens faibles » dans un moteur de recherche pour trouver plein d’informations intéressantes à ce sujet.
Oui, j’avais lu. Bon, je suis pas trop fan mais pas totalement opposé non plus. Ma raison balance au niveau du volume et de la nature de ceux qui peuvent calculer des blocs.
D’un côté, en se certifiant les uns les autres en liens forts, on a une forte cohésion et c’est bien : les calculateurs se contactent donc facilement et peuvent réagir rapidement à un bug critique par exemple.
D’un autre côté, on génère une caste technique pyramidale, un centre. Et ça c’est peut-être moins bien vu tous les problèmes que posent l’existence d’un centre.
C’est pour ça que je proposais aussi l’histoire du droit via la centralité, qui a l’avantage d’être émergent (dépend de la dynamique de la toile), et selon le niveau fixé peut générer un volume conséquent de calculateurs potentiels.
Bon, vraiment, ce n’est qu’une proposition. Je ne suis sûr de rien. Ta solution avec caste technique est possiblement plus rassurante, je ne sais pas
Pas évident de répondre, ça dépend de ce que signifie “peu”. En tout cas je note que les calculants qui ne sont pas sollicitables et font perdurer une ancienne version buguée n’aident pas à renforcer la sécurité.
Je note aussi qu’une personne peu investie socialement dans la Ğ1 mais qui possède des compétences techniques peu aussi contribuer à la sécurité autrement, par exemple en codant (ce qui de fait l’amène à se rapprocher socialemet, par ailleurs).
Intuivement je dirais “oui, ok avec ça”.
C’est trop anticiper quoi que ce soit de complexifier un protocole sur lequel il y a 1,5 développeur actif. Il convient de garder les choses aussi simples que possible, jusqu’à ce qu’un seuil critique de développeurs actif soit atteint qui puisse décider s’il est opportun ou non de complexifier quoi que ce soit.
Il n’y a pas de problématique à entrer dans la WoT, il y une volonté d’aller vite quand le temps requis demande que la confiance soit établie, que les premiers ont mis 10 ans à se connaître et à démarrer, quand les derniers arrivés voudraient y être en quelques jours ou semaines n’a pas de légitimité à être pris en compte.
Si le protocole est complexifié (alors qu’il est déjà en état “simple” pas évident à saisir), alors cela ne fera qu’augmenter la barrière à l’entrée pour de nouveaux développeurs potentiel et la mort assurée de la monnaie à moyen terme.
Je n’ai pas l’intention de coder cela, je dis simplement que ne vois pas le système s’étendre à long terme sans cette notion.
D’ailleurs de manière générale je ne suis plus dans la démarche de développer davantage le protocole, mais de passer la main à d’autres. J’assure le fonctionnement tant que je peux, c’est tout.
C’est absolument pas bloquant avant des centaines de milliers de membres… C’est bien trop tôt pour y penser non seulement dans une vue pratique mais aussi dans une vue technique (pas encore d’équipe de développeurs actifs sur le protocole / Duniter, 1,5 développeur c’est rien, à moins de 10 c’est rien du tout).
La barrière à l’entrée au démarrage (et nous sommes à peine en démarrage), est avant tout mentale, pas technique.
S’il y a des efforts prioritaires c’est côté développement d’assurer une maintenance de fonctionnement (ce qui est parfaitement fait), une amélioration et simplification de la documentation en direction des nouveaux développeurs entrants potentiels (peut être réalisé par des développeurs entrants au fur et à mesure qu’ils s’approprient le protocole), le développement d’implémentations qui pourraient être plus attrayantes (pour des raisons de langage utilisé, de barrière à l’adoption du langage).
Côté client pour l’aspect une simplification et clarification de l’ergonomie client (avoir des clients 100% blockchain et pas des hybrides illisibles qui induisent en erreur sur la nature de la BDD blockchain), et des interfaces en terme de WoT qui soient plus lisibles et complètes pour une meilleure appropriation et prise en main (vue graphique sur la WoT, visualisation graphique des deadlines calendaires sur les expirations / renouvellements de certifications / membres…).
Bref, toujours d’abord et avant tout viser la simplicité maximale en terme de contenu et d’objectif.
Par exemple DU(t+1) = DU(t) + c²M/N est une formule très simple, qui tient en 18 caractères, tout ce qui tourne autour en terme d’explication ou de présentation graphique n’a qu’un but d’ergonomie client, et les soucis de compréhension ne sont que des barrières mentales qui n’ont pas de lien avec le sens de cette formulation.
Faire tomber des barrières mentales est quasiment impossible, très peu arrivent à remodeler leur esprit, cela demande un très grand entraînement pour se doter d’un esprit agile. Les changements ne se réalisent pas contre les barrières mentales, ils se réalisent quand les individus qui ont ces barrières mentales disparaissent, et les nouveaux paradigmes s’ils sont choisis ne se développent qu’au fur et à mesure que les nouveaux nés s’en emparent.
Aussi il ne faut pas espérer quoi que ce soit, mais savoir et comprendre ce qu’est le temps correspondant à des changements de nature profonde.
Seuls les changements superficiels sont rapides.
+1 pour Galuel : le plus limitant pour l’instant est la barrière mentale (culturelle), le travail des devs pour l’instant est de développer l’écosystème logiciel au profit de la compréhension et appropriation du sujet. Par exemple l’API GVA permettra aux personnes de jouer beaucoup plus facilement avec les données de la monnaie pour s’approprier son fonctionnement.
Je suis surpris que cette proposition n’ait pas plus de votes dans le sondage https://forum.duniter.org/t/votez-pour-les-propositions-de-securite-de-la-1/6892
En espérant ne pas faire la porcelaine dans le magasin d’éléphant… ou l’inverse… J’ai eu envie d’intervenir sur cette discussion.
Lors de mes recherches et explorations en quête d’un système d’information capable d’apporter à l’individu un espace numérique où règne la liberté de chacun dans le respect de tous…
Ce protocole ssb produit un “log” chiffré signé et timecodé qui se lit au travers d’applications qui se chargent d’y entremêler les logs de ses amis et de leur proches à un nombre de hop réglable (2 ou 3).
Le parfait réseau anoptique! Qui se propage par chaîne d’amis (nos données sont répliquées sur les machines de tous nos amis et leurs amis et inversement)
Un réseau social qui combine la liberté d’expression avec la liberté d’écouter. Un logiciel qui nous rend souverain (et responsable, on ne peut pas effacer) de la chaîne qui émanne de nous et s’entremêle à celles des autres. Une oeuvre d’art à n’en pas douter! Un réseau qui fait office de mail, de blog, de chat, de forum, de git, … client généraliste oasis. on peut y jouer aux echecs seul le partage de fichiers volumineux est à prescrire…
Et bien c’est en prenant le temps de comprendre le module Galilée que je me suis dit que scuttlebut et duniter avaient de sacré points en commun…
Bien que leur type de consensus soient différents, ces outils dessinent tous le même shéma (carte partielle du réseau cjdns, même protocole appliqué à une interface tun0 qui produit un mesh).
Et alors? et bien tout le monde se heurte à la même problématique… Quand, comment, où établir les racines des chaînes de confiance? Celle qui techniquement garantie une DHT fiable en fait.
Ici, Duniter fixé à 5 amis à la racine de sa WOT qui part du bloc#0. Un biais à la mise en place d’un système totalement décentralisé… Anoptique.
C’est là que m’est venue l’idée d’imaginer une “monnaie libre” crée dans ssb directement. En créant des types de “post” qui vont bien, on refait une ML quantitative ala G1. En fait pas qu’une seule, plein, une dans chaque Pub ssb (ceux qui concentrent assez d’amis pour établir une WOT humaine fiable)…
Parce que je suis de nombreux autres forums d’autres logiciels libres depuis des années… et que je constate souvent que beaucoup refont ce que d’autres font aussi… Comme la couche qui perce les firewall et régule les DDOS, le validateur de conformité de messages, les routines de chiffrage, déchiffrage, mise en index pour extraire des graph relationnels… Ca finalement dépend de l’application qu’on veut en faire et donc de comment écrire et lire l’entremèlage.
Pour finir, j’ai aussi ajouté IPFS à mes cordes. J’utilise actuellement 10% des possibilités de ce jouet… Mais c’est la pièce manquante à SSB, celle qui peut stocker et archiver les grosses pièces jointes. J’ai le projet d’y introduire un “container” (“dag” dans ipfs, “box” dans ssb), bref un truc qui conserve un fichier ses metadata et un compteur de copie et d’usage… raccordé à une clef de portefeuille G1. On y dessine un datacenter interplanetaire dont la monnaie est libre… Je rêve un peu, y’a encore des étapes… Reste-il encore un lecteur à cette distance du début de mon texte? (mettez un emoticon pour me le signaler)
J’espère que j’aurai de quoi faire une démo convaincante de tout ça avant cet été.
Je vous invite à me rejoindre dans ScuttleButt.
On se retrouve dans mon G1Pub
J’ai déjà commencé à faire des dons G1 à des amis sur ssb, à discuter des plans de “Fat Protocol”. La monnaie libre leur plait bien 
"pod.copylaradio.com:8008:@UeiA9iqZ0/XTjmYBht230KGr44bsr+Tl5BXSUDFv8vo=.ed25519~bChBvP4ILGfOmioTdZ2xOctiCTtSlkMVZQ6PGvpGhZg="
Suite des explications sur l’implémentation relativiste galiléenne de la ML. Dans SSB et IPFS.
Je reste persuadé que cette idée d’avoir plusieurs types de liens est très intéressantes, surtout à la lumière de ce qu’on vit partout dans le monde : le confinement.
Je n’ose pas trop parler de réorganiser des réunions physiques avant un moment. Les liens faibles permettraient de certifier quelqu’un après une visioconférence par exemple.
effectivement, pour revenir au sujet initial ça serait intéressant à mettre en place ces niveaux de liens.
Pas certain que trois niveaux soit le plus optimal, peut être que deux suffiraient.
je n’ai bien entendu pas grande vue d’à quel point ça serait long à implémenter.
Ensuite oui ça fait un niveau de complexité de plus à expliquer aux gens ou à écrire dans la licence.
Mais je ne suis pas certain que les gens adhérents aux valeurs de la licence la comprennent dans son entièreté, ou comprennent la formule du DU, mais avec plus de 3 ans de retour d’expérience, est-ce un obstacle à ce qu’ils fassent utilisation de la G1 ?
C’est comme sur d’autres projets: j’ai découvert que des gens pouvaient utiliser et adhérer aux valeurs du logiciel libre et des médias sociaux décentralisés sans comprendre du tout la différence avec un prétendu « réseau » social de GAFAM centralisé et privateur de libertés.
La majorité des gens étant des gens bien, ça ne pose pas de problème qu’ils comprennent toute la profondeur et les enjeux éthiques d’un truc pour y adhérer correctement.
Certes, c’est plus facile d’évangéliser les gens autour de soi quand on peut complètement répondre à toutes leurs interrogations, mais je suis certain que ça n’est pas un obstacle si on ne saisit pas tout.
le pire exemple: les accords de Bale qui ne sont expliqués à personne, quasi personne ne pige le fonctionnement de l’argent dette ou de la création monétaire, et les UNL très répandues 
Du coup, un ou plusieurs niveaux de liens, ça peut se résumer assez simplement comme disait @1000i100.
Bon et si quelqu’un a un graphique de l’'évolution du nombre de membres depuis le début je veux bien, (je ne parviens pas a avoir cette info sur un currency monitor ) histoire qu’on voit si ça stagne ou pas. ça pourrait être interessant à voir aussi.
en tous cas, le nombre de noeuds calculant des blocs reste assez faible, ça mériterait peut être une campagne de mise en place de noeuds auprès des membres historie de gagner en résilience. ça aussi c’est pas évident.
C’est parce que ces monnaies sont imposées et pas pour une autre raison qu’elles sont répandues.
Pour revenir au sujet, je reste personnellement plus favorable aux comptes forgerons/villageois, un concept ludique (démasquons les comptes loup-garous) et clair à expliquer. Le double niveau de certification me paraît nécessiter trop d’explications.
Si on se place d’un point de vue DDD (Documentation Driven Development), évidemment. 
@cgeek @Galuel @kimamila @1000i100 @vit @Moul @gerard94 et tout le monde, je souhaite ré-ouvrir les discussions sur cette proposition de @cgeek faite il y a 3ans et plus généralement sur le fait d’avoir plusieurs types de certifications.
À l’époque j’étais contre pour 3 raisons:
Concernant le 1er point, beaucoup d’eau à coulé sous les ponts depuis 3 ans, et la wot stagne de plus en plus, moi-même je ne cherche plus à convaincre mes amis de rejoindre la Ğ1, tellement le taux d’implication nécessaire pour y entrer est trop élevé. Je pensais en fait il y a 3 ans que la toile Ğ1 continuerai de s’étendre au rythmne de l’époque, et que 3 ans plus trad nous serions plus de 10000, et que ce faisant l’entrée serait devenue plus facile, 3 ans plus tard… il n’en est rien !
Concernant le 2ᵉ point, le fait de passer à substrate change tout, grâce à l’ultra-généricité de FRAME, au notamment grâce aux palettes instantiables, dont le parle dans ma 2ème vidéo, je peux facilement gérer plusieurs types de certifications avec la même palette, donc avec un seul et même code.
Concernant le 3ᵉ point, c’est le fait de faire beaucoup de maquettage d’UX avec Boris et @poka sur ğecko qui m’a appris que l’on peut guider l’utilisateur de manière a ce que ce soit simple pour lui, et qu’il comprenne uniquement ce qu’il a à comprendre pour ses usages.
Aussi, je me disais que 3 types de certif c’est trop, mais le 3ème type pourrais (devrais) être complètement masqué de l’UX pour les utilisateurs lambda, tant qu’ils ne demandent pas eux-mêmes à devenir membre forgeron (validateur), alors ils n’ont pas besoin de savoir qu’il existe un 3ᵉ type de certification.
Nous voila 4 ans et demi après le lancement, je pense que c’est le bon moment pour discuter de changements substantiels dans la toile de confiance, surtout que la migration sur substrate facilite grandement de tel changements techniquement.
Je ne propose pas de reprendre tel quel les modalités précises proposées par @cgeek, mais de s’en inspirer et réfléchir au fait d’avoir plusieurs types de certifications, et plus particulièrement une certification légère qui ne donne droit qu’au DU
Une certification légère pourrait être faite sans connaître la personne, par une simple vérification d’un document d’identité par exemple. Alors que la certification intermédiaire requiererait toujours de bien connaître conformément à la licence Ğ1.
Rassurez-vous, je ne vais pas intégrer de changements contre l’avis de la majorité, j’ai besoin de vos feedbacks pour m’assurer que je vais dans la bonne direction. J’aimerais d’ailleurs implémenter on-chain un comité technique composé des principaux contributeurs technique qui devrait valider tout changement de protocole à un certain quorum (par exemple 60%).
J’en parle dès maintenant pour qu’on ait le temps d’en discuter, d’en débattre, et de maturer nos décisions
Je vous invite tous à commencer d’ores et déjà à y réfléchir, et on en discutera aussi lors des visios mensuelles : Monthly online meeting of contributors to Duniter/Ğ1 technical ecosystem
Je n’ai pas l’impression que « la wot stagne », et le bitcoin qui est de même nature que la Ğ1 (blockchain, logiciel libre) s’est développé sans wot, ce qui n’est donc absolument pas nécessaire comme prérequis pour qu’une monnaie fonctionne.
Les questions peuvent se poser autrement :
Par ailleurs accumuler plusieurs points d’innovation en même temps me semble dangereux. Migrer sur substrate est déjà loin d’être fait, ce n’est pas une bonne idée d’y rajouter en même temps des défis supplémentaires, dont l’impact nécessite réflexion approfondie et vérifications. Attention à Perrette et le pot au lait !
La WOT menace de doubler rapidement avec l’implication des Espagnols, qui sont plus que motivés et en nombre grandissant. L’Espagne c’est grand, mais en plus ça communique avec toutes les Amériques (oui y compris l’Amérique Nord !), dans la même langue, je serais beaucoup plus circonspect sur la suite à cause de ça notamment.
S’il y a une innovation prioritaire à mon sens, qui pourrait suivre une migration c’est plutôt une réflexion à mener sur un processus acceptable de révocation d’un compte membre, pour assurer le cas des faux comptes. Ce point contribuerait à améliorer la confiance quant à la promesse de la monnaie libre.
Ce point étant développé, on peut alors imaginer adapter les règles d’inclusion dans la WoT de manière plus sereine, car on aura un système de sécurité en cas de dérapage.
Oui tu as raison https://foro.moneda-libre.org/
J’ai dis à kapis quand je l’ai vue, que j’étais persuadé qu’ils aillaient nous doubler en quelques années étant donnée leur motivation
Et beaucoup, beaucoup de personne d’Equateur notamment, mais aussi Brasil, m’ont plusieurs fois supplié de certifier leurs enfants et leur famille chez eux (alors que je ne parle pas un traitre mot d’espagnol…), car ils n’auront jamais l’occasion de venir en france pour lancer la wot là bas.
Elois à plusieurs propositions à vous faire au sujet de la wot, mais il prends le temps de bien y réfléchir avant de vous les détailler, et il a tout à fait raison de le faire, mais il a besoin de tous les avis éclairés ici
On est tous d’accords que la priorité est de faire la migration G1S en douceur, et de prendre le temps qu’il faut pour faire cette migration ISO.
Mais cela n’empêche pas de penser la suite, les réflexions de @cgeek étaient passionnantes.
Et Elois expliquera peut être que ne pas faire certaines modifications maintenant, c’est se complexifier la tache pour rien.
Il y aura de toute façon de très nombreux tests, automatisation de migration, ect … qui prendront le temps qu’il faut avant de lancer en prod.
Entièrement d’accords avec ça, et il faudra tôt ou tard que l’on discute tous ensemble du système de gouvernance Substrate que nous voulons appliquer à la G1, mais nous attendons que chacun prenne le temps de d’abords creuser le sujet substrate de leur côté, comme nous l’avons fait, avant de discuter de ce genre de question tous ensemble.