J’ai émis l’idée qu’il faudrait supprimer la Smith WoT, c’est-à-dire l’implémentation actuelle du code qui gère nos autorités en empruntant le code de la WoT.
Le problème du fonctionnement actuel, c’est qu’il nous contraint à avoir un comportement commun pour deux choses différentes (voir Pallets instanciables et vérifications d'adhésion). Or, la Smith WoT n’est pas satisfaisante aux yeux de @HugoTrentesaux ni moi-même, au moins.
J’ai commencé à me dire que je pourrais recoder un système minimaliste de WoT pour gérer les autorités dans authority-members, et puis je me suis demandé si l’on ne voudrait pas plus simple justement : pourquoi ne pas simplement déléguer la décision au comité technique ?
Concrètement, je crois :
(root) disposer d’un extrinsic pour promouvoir un membre de la WoT au statut de Smith
(root) disposer d’un extrinsic pour révoquer un membre du statut de Smith
(smith) disposer des calls habituels goOnline(), goOffline(), etc
La TdC forgeron vient de discussions ayant notamment eu lieu avec les membres lors des dernières RML, l’objectif étant de ne pas trop centraliser de pouvoir.
Le comité technique tel qu’il est aujourd’hui étant lui-même une solution temporaire en attendant de trouver un modèle plus scalable, démocratique et résistant aux putschs. Si je me souviens bien, le consensus aux RML était que le comité est temporairement tout-puissant, mais qu’à l’avenir il perdra son rôle politique pour se cantonner aux propositions de mise à jour et corrections de bugs, ce qui est un rôle éloigné de celui de décider des forgerons.
Si le comité technique décide des forgerons, comment le fait-il ? On pourrait faire des votes avec un seuil de 5, mais exigerait-on le respect de la licence forgeron à ceux qui ont voté pour l’entrée d’un membre ? Combien de votes contre pour refuser, et comment fait-on si une minorité fait blocage ?
Les discussions distinguent bien le comité technique et les nœuds forgerons, je crois qu’il n’y a pas trop de débat là-dessus.
Par contre, la définition des nœuds forgerons revient régulièrement. Au stade actuel, la solution à base de toile basée sur le même code que la WoT nous pose trop de problèmes. Nous pourrions soit la recoder dans authority-members (plus simplement, plus adaptée au besoin), soit – c’est mon intuition – nous pourrions pour l’instant nous en remettre au comité technique.
Je ne sais pas, on peut rester pour le début aux mêmes conditions que pour les Runtime Upgrade.
La justification à un tel système est simple : de toutes façons, à l’heure actuelle, le projet technique est porté par une poignée d’êtres humains présents sur ce forum. Sans eux, tout s’écroule à plus ou moins brève échéance. Selon moi, le comité technique initial de la Ğ1v2 sera composé de ces personnes qui devront savoir facilement et rapidement se contacter en cas de besoin. Car dans le pire des cas, ce seront encore elles qui proposeront le hard-fork en cas de nécessité.
Bref, je trouve que l’on s’embarrasse beaucoup avec cette toile forgeron aussi tôt dans le projet.
Comme mon objectif principal est découpler les forgerons de la WoT en termes de code source, et que je sens que la toile Smith semble être une solution plus acceptée, je vais partir dans cette direction.
En fait non, authority-members est très bien comme elle est. Je vais plutôt proposer une palette smith-members qui s’intercale entre la WoT (palette duniter-wot pour l’instant, j’espère identity plus tard) et authority-members.
Paramètres conservés
Je reprends les paramètres / handlers / providers suivants de la SmithWoT existante, et je commente le sens du paramètre dans la nouvelle palette smith-members :
Paramètre
Commentaire
Provider “IsMember”
Pour n’autoriser que les membres de la WoT à devenir Smith
Handler “MembershipRemoved”
Pour propager la perte du statut de membre de la WoT à la toile Smith
MinCertForMembership
Nombre de certifications pour être considéré Smith
MinCertForCreateIdtyRight
Nombre de certifications pour pouvoir inviter un nouveau Smith
CertPeriod
Délai à observer entre deux émissions de certifications pour un Smith
MaxByIssuer
Stock maximal de certifications actuellement émises pour un Smith
MinReceivedCertToBeAbleToIssueCert
Nombre minimum de certifications à recevoir en tant que Smith pour pouvoir en émettre soi-même
Paramètres supprimés
Paramètre
Commentaire
FirstIssuableOn
Pas d’intérêt de décaler le délai de la 1ère certification pour un Smith
MembershipPeriod
Rester Smith se fait en étant online, ou offline mais pendant un délai maximal donné (OfflineMaxDuration, voir ci-après)
ValidityPeriod
Pas d’expiration des certifications. Un Smith qui se fait éjecter (par le comité technique, par perte du statut de membre de la WoT ou par les offences) perd toutes ses certifications Smith
Nouveaux paramètres
Paramètre
Commentaire
OfflineMaxDuration
Durée maximale, en nombre de sessions, pendant laquelle un Smith peut rester offline. Au-delà, le Smith est éjecté et perd ses certifications smith.
Extrinsics
Paramètre
Commentaire
certify_smith
Permet de certifier un Smith, et de le créer s’il n’existe pas encore (pourrait être découpé en invite_smith et certify_smith, j’hésite sur ce point).
Je ne vois pas d’autre extrinsic nécessaire pour l’instant.
Je n’ai pas l’impression que ce soit compliqué à coder, je vais commencer pour voir.
Je pense qu’il faut prévoir que quand un Smith perd son statut de smith ses certifs Smith émises devrait disparaitre (dans le cas où il n’y a pas d’expiration des certifs Smith) peut-être avec un certain délai…
Je suis pertubé par le choix de nommage :
soit MinCertFor*
soit MinCertTo*
soit MinReceivedCertTo*
Mais un mix des deux me semble confusant.
Sinon sur le fond je suis d’accord avec @tuxmain tout ce qui va dans le sens de concentrer le pouvoir m’inquiète (sans forcément m’y opposer catégoriquement si ça permet à court terme d’avancer sans créer une concentration qui n’était pas de facto déjà là) et tout ce qui va dans le sens de diviser les pouvoir me branche (même si tant que c’est sur le principe, mais qu’en principe, on cumule les mandats, ça ne change pas grand chose à court terme).
Ces choix de nommage ne sont pas les miens, mais de toute façon je n’ai conservé que MinCertForMembership.
Pour ce qui est de la concentration des pouvoirs, je suis resté sur le principe d’une “Smith WoT” même si ça m’a coûté du temps de le faire afin qu’elle soit plus rapidement acceptée.
La principale différence, technique, c’est que cette palette n’est plus fondée sur une combinaison d’instances des palettes certification + membership + duniter-wot mais sur une unique palette non-instanciable et dédiée smith-members. Ce qui devrait largement faciliter sa délimitation et sa vérification (ticket #141). Donc améliorer la sécurité générale de la blockchain et la confiance dans le fait que la migration vers une Ğ1v2 va techniquement tenir.
Je me pose la question : à quoi sert l’invitation forgeron ? Ne pourrait-on pas se contenter de laisser les membres exprimer une candidature forgeron ? Ça simplifie légèrement le processus (un aller-retour en moins), mais surtout, ça change beaucoup la symbolique. On passerait de :
“la toile forgeron est un cercle fermé dans lequel il faut être invité”
à
“chaque membre de la Ğ1 peut exprimer le désir de calculer des blocs, il sera formé et certifié par les forgerons déjà à l’œuvre”
C’est juste que le processus avec invitation sollicite logiquement moins la blockchain, car il y a un anti-spam naturel si ce sont les Smiths qui invitent.
Dans le cas avec candidature, jusqu’à 100% de la WoT peut générer une entrée dans le storage Smiths, avec les implications en termes de calcul d’expiration associée. On pourrait mettre des limites, mais ça engendre d’autres problèmes.
Bref la solution avec invitation m’a semblé plus simple à gérer côté mainteneurs du Runtime.
On pourrait effectivement avoir des utilisateurs qui font la demande smith sans comprendre ce qu’elle signifie, mais pour ça il faudrait qu’il le cherchent vraiment parce que ce n’est pas une option qui sera disponible dans Cesium (a priori).
De manière générale, malgré les pratiques de sécurité des utilisateurs, la WoT est déjà une bonne base de confiance, j’estime que ce risque est faible et ne suis pas sûr qu’il vaille le coup d’une légère complexification.
La solution actuelle me paraît largement suffisante pour la migration, on verra tout ceci après !
Mais… c’est toi qui a relu la MR qui introduit ce mécanisme.
Ce n’est pas une attaque, seulement que je ne comprends pas votre méthode de travail, et personnellement c’est un élément qui me décourage de contribuer à Duniter-v2 en ce moment.
Moi perso je suis pleinement satisfait de leur méthode de travail. J’appellerais ça une méthode empirique.
Hugo a relu la MR de Cédric qui a sa proposition de changement de protocole, qui elle est débattu sur ce forum.
La relecture de la MR consiste à valider que le code est conforme à ce qu’il dit qu’il fait. Qu’il est cohérent et s’intègre bien à la stack. Qu’il ne pose pas de problème particulier.
Hugo a fait confiance à Cédric sur la partie smith pendant cette période, et la refonte de cette partie du protocole.
Refuser cette MR aboutie pour des raisons de choix de protocole aurait peut être amené une frustration de la part de Cédric, car c’est lui qui était en charge de refondre ce protocole.
Ca va aussi avec la phase actuelle de conception du projet.
Ca pourra également rester le cas dans le future sur les réseaux de dev.
Ca permet de faire en sorte que les choses avances vite et ne stagnent pas.
Hugo a compris la MR, validé que le code était conforme, et l’a donc validé.
Ça n’empêche pas de se poser des questions sur le protocole en lui même à posteriori.
En l’occurrence il se pose la question de la pertinence de cette partie du protocole, c’est qu’il n’avait peut être pas totalement cerné certains enjeux au moment de la proposition. Partie du protocole encore une fois prise en charge par Cécric à ce moment là.
Pour moi c’est une question de confiance, et d’évolution empirique du protocole.
J’y vois un aspect humain plus subtile que la froideur de la pertinence d’un protocole à un instant t.
Oui, en relisant la MR, j’ai considéré pour les mêmes raisons que l’invitation était logique, et la MR simplifiait grandement la procédure forgeron par rapport à ce qu’il y avait avant, donc c’était tout à fait logique d’accepter. On a par la suite corrigé quelques bugs et revu les événements en le confrontant à l’usage.
Après avoir fait quelques invitations forgeron en conditions réelles, je me rends compte que l’expérience utilisateur qui en résulte comporte encore un peu de friction :
Alice invite Eve
Eve accepte l’invitation
Alice certifie Eve
Bob certifie Eve
Ça fait deux actions de la part de Alice à faire à deux moments différents. Donc je me demandais si on pouvait pas faire sauter l’étape 1 en considérant que la toile de confiance n’est pas suffisamment source de spam.
D’autre part, la toile forgeron peut être perçue comme un “cercle de privilège” dans lequel il faut être invité. Le vocabulaire technique que l’on emploie a des conséquences sur la perception. Je ne parle pas uniquement des junistes actuels, mais aussi de ceux qui rejoindront par la suite. J’ai remarqué que dans Duniter v1, le fait de calculer des blocs et donc de participer à l’écriture était source de beaucoup d’implication. Moi même c’est une des premières choses que j’ai cherché à faire une fois membre. Ça a beau être un acte technique, les humains ne peuvent pas s’empêcher d’y mettre de la symbolique. Et remuniter est un exemple intéressant.
Je trouve que @poka a bien répondu. J’ajouterais que les tests sur des utilisateurs (apprentis forgerons) apportent des éléments nouveaux que je n’avais pas imaginé au moment de la relecture de la MR. Ça me paraît important de faire quelques itérations avec les testeurs pour éviter les surprises et lisser leur expérience.
J’en suis désolé. J’avais l’impression que tu étais moins présent parce que tu avais d’autres choses à faire, mais si nos méthodes sont un frein aux contributions, je veux bien des conseils pour améliorer ce point. Je suis aussi désolé que les RML18 aient eu lieu pendant des cours, c’est les aléas des emplois du temps. Si tu penses qu’il y aurait moyen de compenser ça, je suis à l’écoute des suggestions.
Si l’invitation doit être conservée, elle pourrait créer une certification automatiquement.
L’acceptation de l’invitation pourrait aussi être abandonnée si Eve doit confirmer, une fois être certifiée, pour devenir forgeron. La première certification vaudrait invitation.
Même avec une borne haute de 1ko par demande, si 10 000 membres spamment ça fait 10Mo, ça reste acceptable. (à multiplier tout de même par le nombre de blocs conservés par le nœud)
Comment je voyais les choses concernant l’organisation des contributions :
Le forum représente l’état du débat. Quand une chose importante (comme la refonte d’un mécanisme fondamental) fait consensus, quelqu’un s’y met éventuellement en s’étant annoncé (sur le forum ou en s’assignant l’issue). Ça permet d’avoir confiance dans le fait que le travail n’aura pas été inutile car finalement refusé, ou en doublon car quelqu’un d’autre a entre temps décidé de tout changer. Ça permet aussi d’avoir le temps de réfléchir aux régressions, car on a vite fait de faire réapparaître des problèmes qu’on avait soigneusement évités il y a longtemps, ou de réinventer la roue. Des fois j’ai aussi l’impression qu’on balaie des trucs sans prendre la peine de réfuter les justifications qui avaient jadis convaincu de la nécessité d’implémenter lesdits trucs (par exemple certaines idées d’Élois).
Ok pour des cycles plus courts avec plus d’essai-erreur, j’ai juste peur que ça laisse passer certaines choses qui ne font finalement pas consensus (c’est plus désagréable de remettre en cause le fait accompli, qu’une simple proposition).
Oui c’est surtout à cause des cours que j’ai moins de temps et que je préfère le passer sur des plus petits projets sur lesquels il y a moins de concurrence (au sens de “travail en parallèle”) et où je peux avoir une vision globale (ce qui demande beaucoup de temps pour la WoT), à mon rythme. C’est aussi qu’avec deux personnes à temps plein (ou presque) sur Duniter, ma contribution n’est vraiment pas nécessaire pour que le projet avance.
Pour les RML ce n’est pas vraiment un aléa d’emploi du temps, elles sont souvent organisées hors-vacances. Tant mieux si ça arrange une majorité, mais ce n’est évidemment pas compatible avec un emploi du temps scolaire. (cela dit, même pendant les petites vacances je n’aurais pas forcément le temps)
Je me dis qu’afin de limiter les spams, la demande pour devenir forgerons ne pourrais se faire qu’à partir de l’interface de gestion du nœud Duniter (car je suppose qu’une telle interface existera comme en V1).
Du coup cela impliquerait d’avoir déjà un nœud miroir fonctionnel avant de demander à devenir forgeron.
Et cela allègerait les clients pour utilisateur lambda.
Si un nœud non-forgeron peut faire la demande, alors il passe forcément par un extrinsic, et rien n’empêche un développeur de client d’implémenter la même chose. Ça rejoint la proposition de réduire le spam involontaire (par erreur ou méconnaissance) mais ne protège pas du spam malveillant. Ce qui me semble suffisant en supposant que le spam malveillant ne concerne qu’un minorité.