Discussion autour de la RFC5 (devenue fygg)

Protocols DUBP
37

http://trm.creationmonetaire.info/appendice-2.html#les-4-libertes-economiques

Pour rappel, la première des 4 liberté défini dans la trm est tout de même :

  • La liberté de choix de son système monétaire

Sans quoi la position monopolistique d’une monnaie, fut-elle basé sur Duniter, ne pourrais plus être considéré comme libre.
Et cela me semble valable que le monopole soit un monopole légal, ou un monopole d’usage / de facto par une position de premier arrivant notable.

Mais je dérive (un peu) du sujet “protocole v11”

38

Je rappelerais simplement le sens de liberté tel que défini par TRM : non-nuisance. Un protocole qui permet à des personnes de nuire par vote au choix réalisé par les autres ne saurait implémenter une monnaie libre.

2 Likes
39

Exactement c’est l’un des aspects qui me dérange dans le vote. Il ne respecte pas le principe de non-nuisance. Si un choix est nuisible pour un individu, alors c’est que les implications de ce choix génèrent une ou plusieurs tensions chez l’individu, tensions qui peuvent être traités et accompagnés pour être transformés en objections constructives avec d’éventuelles propositions de reformulation/modification du choix de départ. C’est en quelque sorte ce que propose l’holacraty.

Au final c’est déjà ce que nous faisons de manière non formalisée sur ce forum concernant les choix techniques, on traite toutes les objections, ce qui transforme la proposition initiale jusqu’a devenir une proposition pour laquelle il n’y a plus d’objection valable (où jusqu’a abandon de la proposition si au moins une objection n’est pas résoluble).

Mais a plus grande échelle, il faudra bien que l’on finisse par formaliser nos process de décision internes au sein de la duniter team et plus largement au sein de l’ensemble des contributeurs.

La communauté g1 dans son ensemble certes, mais la duniter team et plus largement l’ensemble des contributeurs techniques constituent bien un groupe fortement investi et avec un raison d’être commune, et cela sera toujours ainsi.

l’Holocraty n’est pas adaptée aux petits groupes, nous sommes encore trop peu de contributeurs pour l’expérimentée, mais elle est en revanche particulièrement adaptée aux grands groupes. je me souviens du témoignage d’un patron de startup ou la gouvernance n’étais pas formalisée, il se sont posés la question de la gouvernance lorsqu’il ont dépassés la quinzaine de permanents, et sont alors passer en Holacraty.

Pour ce qui est de la façon d’impliquer davantage les utilisateurs qui ne sont pas contributeurs, la 1er des choses est déjà de communiquer sur nos grandes décisions et leur pourquoi dans les grandes lignes, se sera déjà un grand pas en avant :slight_smile:
Ensuite, faciliter la contribution, pour ça il faut des contributeurs disponibles et disposés a accueillir et accompagner les nouveaux souhaitant contribuer, ce qui prend du temps et de l’énergie :confused:

En revanche, concernant la question de faire participer aux choix techniques des utilisateurs qui ne contribuent pas et qui ne s’exprime pas sur l’espace de discussion dédié a ces choix, je n’y suis pas favorable. Je suis d’avis qu’une personne n’a de poids légitime sur une décision que si elle fait l’effort de s’informer et d’exprimer sont point de vue. En bref, qui ne dit mots consent.

3 Likes
40

Ce qui me semble important, c’est la transparence. Dans la mesure où le code est libre et vérifiable par tous, il y a déjà une transparence intrinsèque. Il est vrai que ce peut être « obfusqué » pour les non-informaticiens. Le seul risque ici est plutôt la prise de pouvoir par les informaticiens sur la vie de la monnaie, mais quand on dit « les informaticiens », ce n’est pas « le staff du forum duniter », c’est bien « l’ensemble des informaticiens du monde ». Et même si dans cette catégorie il y a probablement des individus qui ont soif de pouvoir, il ne s’agit que d’une minorité au regard de la communauté entière des informaticiens. Il y aura toujours de bonnes âmes parmi eux pour dénoncer ce qui est contraire à l’intérêt général.

Tu dis qu’actuellement il faut que « le staff » prenne une décision pour qu’elle soit implémentée. Je répondrais que si un sous-ensemble de membres n’est pas d’accord avec telle ou telle décision, rien ne leur interdit de faire leur propre fork. Et si tu argues qu’il leur faut des informaticiens pour ça, il leur en faudrait aussi en cas de vote : si aucun informaticien n’a envie d’implémenter une fonctionnalité parce que tous les informaticiens la jugent mauvaise, on revient à la même situation. Le vote en blockchain pourrait uniquement être un moyen de faire pression sur les informaticiens autour de fonctionnalités qu’ils ne veulent pas implémenter. Ils peuvent avoir de bonnes raisons pour le faire par le fait qu’ils sont experts dans le domaine, mais aussi de mauvaises, comme refuser d’implémenter une fonctionnalité qui pourrait leur retirer du pouvoir.

À ce sujet, je partage l’avis d’Éloïs : l’un des principaux problèmes du vote populaire, c’est qu’il est souvent affectif et émotionnel plutôt que raisonné et décidé en toute connaissance de cause. D’autre part, les décisions à prendre sont souvent liées à des choix techniques qui sont difficiles à expliquer à tous. On le voit bien, même ici, un choix qui paraît « simple » comme le choix de l’intervalle de réactualisation du DU n’est pas trivial et nécessite des connaissances que même un très bon informaticien peut avoir « zappées ».
Ce qui manque peut-être est un « cahier des charges explicatif » qui résume les choix faits, leurs principaux contre-arguments et leur réfutation ainsi que d’éventuelles références pour ceux qui veulent en savoir plus, afin que tous aient un accès encore plus transparents aux choix pris et leurs raisons. Il y a déjà un wiki en place, comme dirait Ğaluel, yapluka.

5 Likes
41

Je n’ai rien à redire ça.

Merci pour toutes vos réponses très constructives, j’oublie l’idée du vote pour le moment, dans l’idée qu’a long terme on pourrait avoir quelque chose comme l’Holocraty.

42

Je vous invite à réfléchir à ces points :

  • Les principes les plus stables, qui durent le plus longtemps, sont aussi les plus profondément cohérents et simples (point qui est semblable au rasoir d’Ockham).
  • Le code de la monnaie n’est pas le code de la WoT.
  • Le code de la WoT n’est pas le code de Duniter.
  • Le code de Duniter n’est pas le protocole (DUP).

Puis :

  • Le logiciel étant sous licence libre il est donc de fait transparent de par sa nature même.
  • Le seul obstacle qui peut empêcher d’autres êtres humains de réaliser une modification économique non-nuisible est dès lors uniquement l’ignorance. L’ignorance vis à vis du code de la monnaie, du code de la WoT, du code Duniter, du code du protocole.
  • Libre ne signifie pas sans auteur, et il est faux et trompeur d’appeler du même nom que l’auteur un objet libre que l’on modifie sans l’accord de l’auteur.

Et donc il s’ensuit que :

  • Vouloir changer le code de la monnaie suppose de développer une autre monnaie sous un autre nom.
  • Vouloir changer le code de la WoT suppose de développer une autre WoT sous un autre nom.
  • Vouloir changer le code de Duniter suppose de développer un autre logiciel sous un autre nom.
  • Vouloir changer le code du protocole suppose de développer un autre protocole sous un autre nom.

Et c’est pourquoi pour chaque objet, il existe un nom et qu’il y a dès lors :

  • Une licence relative à la monnaie associée à son nom.
  • Une licence relative à la WoT associée à son nom.
  • Une licence relative à Duniter associée à son nom.
  • Une licence relative au protocole associé à son nom.

Les auteurs étant dépositaires du nom, seul le code étant libre, tout changement relatif au même nom est donc in-fine relatif à la légitimité transmise par son auteur.

De sorte qu’il n’y a ainsi pas d’erreur en terme de désignation et d’évolution, et respect du principe de non-nuisance quant à la volonté du créateur.

3 Likes
43

Est-ce que la v11 du protocole prévoie la possibilité de changer de mot de passe (donc de clé publique) ?

Je me demandais également si ce ne serait pas une bonne idée d’avoir la possibilité de révoquer un certificat que l’on a attribué à quelqu’un. Dans le cas, par exemple, où l’on se rend compte que la personne envers qui on avait confiance ne respecte plus la licence Ğ1…

44

Cette possibilité existe déjà, la certification n’étant valable que 2 ans, peut ne pas être renouvelée.

45

Pour le moment non, mais tu peux révoquer ton compte et en faire un nouveau, puis te refaire certifier. Je ne pense pas que ça se fera, puisque ton IdentityUID dépend de la clé publique.

2 Likes
46

@nanocryk Au tu réfléchi a la réversibilité de chaque état ?

Duniter doit être en capacité a partir d’un état(t), et du dernier bloc, d’effectuer un revert sur ce bloc, c’est a dire d’appliquer le protocole blockchain a l’envers pour se retrouver a l’état (t-1). Cela est nécessaire pour permettre les rooling back (dépilement pour changer de branche suite a une décision de l’algo de résolution de fork).

Et je me demande si les arbres de merkle ne cassent pas cette reversibilité ?

47

On stocke toujours l’état se trouvant au début de la fenêtre de fork. On peut rollback les relations (transactions) entre des objets de l’état, mais pas tout leur contenu. Cependant si les documents sont stockés dans l’arbre plus longtemps que la fenetre de fork, pas de problème pour rollback. J’essaierai de developper un paragraphe sur ça dans la RFC, ça peut être une propriété très interessante :slight_smile:

Ils n’ont rien a voir la dedans, ils servent juste de preuve de l’état pour les clients.

48

Ok c’est bien ce qu’il me semblait le protocole v11 n’est pas réversible, il faut donc stocker deux états E(t) et E(t-windowForkSize) ce qui prend plus de mémoire c’est dommage :confused:

Mais si ce n’est pas du aux arbres de merkel qu’est qui fait qu’il n’est pas possible de revert un état, les scripts de tx avancés ?

49

Ca ne répond pas à ta question ?

50

Mais on occupe alors beaucoup trop de mémoire pour rien, c’est trop couteux, il vaut mieux stocker 2 états complets a windowForkSize d’intervalle :wink:

Ben non, ma question c’est de savoir qu’est ce qui rend fondamentalement le protocole v11 non réversible, je crois comprendre que c’est le nouveau système de script de tx.

51

Je parle ici de documents comme celui d’identité, comme expliqué ci-dessous.

Avant, il faudrait déjà vérifier “ce qui le rend fondamentalement non réversible”, et je ne vois pas ce que le système de script viens faire la dedans.

Dans un état les seuls nouvelles informations viennent de la partie transformation, qui est stockée pendant la periode de résolution de fork. La destruction d’informations est un type de transformation qui fait perdre de l’information, mais qui si elle concerne une information qui n’a pas changé depuis le debut de la fenêtre de fork alors ce n’est clairement pas un problème.

Par exemple dans le cas d’une identité révoquée. On peut dire qu’au bout de 6 mois cette identitée revoquée est obliée, ce qui peut par exemple permettre de réutiliser le pseudonyme. Vu la fenêtre de fork est de 100 blocs, soit un peu plus de 8h, on sait que cette suppression (irréversible vu qu’il y a perte d’information) concerne une information qui n’est plus utile depuis longtemps et qui ne changera pas d’un fork à l’autre. On peut donc suivre cette information sans connaitre ses détails. Vu que l’on connait la date de suppression, et on peut aussi compter à rebour le nombre de blocs qui lui reste a vivre, depiler le fork et repiler la nouvelle version, en réincrémentant le compteur.

Comme dit dans un message précédent, je vais essayer d’y consacrer une partie. Mais on ne peux pas encore en juger, vu que ni l’état ni la transformation n’a été définie clairement, ce qui est la prochaine partie de la RFC.

Il serait cependant une bonne idée de voir ensemble ce qui a déjà été proposé dans la RFC pour s’assurer qu’on part sur des bases solides validées, sinon ça voudrait dire écrire cette nouvelle partie avec le risque de devoir la refaire.

52

Exactement c’est pour cela que j’en parle maintenant, s’il est possible de revert un block v11 se serait fort préférable pour des raisons de performance et de stockage :slight_smile:
Je reregarderai la RFC en détail d’ici quelques jours, la je suis sur autre chose :wink:

1 Like
53

Qu’on se comprenne bien : ce qui est important, ce que pour une fenêtre de fork de 100 blocs, il soit possible à partir de n’importe quel état(t) … état(t-100) de revenir à l’état précédent, sans perte de données.

Et je ne vois pas pourquoi tu dis qu’on ne peut pas rollbacker “tout leur contenu” ?

Et puis de non-régression : le protocole v10 permet le revert de bloc dans la fenêtre de fork sans aucune perte d’information, au sens où tout bloc dépilé voit son contenu mis en piscine et donc être réutilisable, je ne vois pas pourquoi le v11 ne pourrait pas le faire.

Je pense qu’il y a plusieurs quiproquos qui traînent dans notre discussion.

54

Si on ne stocke que le dernier état, hors je proposais de stocker l’état(t) et état(t-100). De plus les données qui ne peuvent pas être rollback sont des données qui ont été supprimées après un temps d’expiration qui, s’il est supérieur à la fenêtre de fork, ne pose aucun problème.

Pendant au moins 100 blocs, tous les documents entrés en blockchain sont référencés dans l’arbre et les noeuds doivent pouvoir les fournir avec leur preuve. Quand une source est complètement consomée, elle a son solde à 0 et si au bout de 100 block elle est toujours à 0, elle est supprimé. Cette suppression peut alors contenir les informations nécéssaires à rollback. Admetons qu’elle soit supprimée, et qu’il y a un fork. Quand on dépile les blocks, on va se retrouver avec l’association account -> (amount=0,index=18). On ne connait plus le script, mais ce n’est pas grave : personne ne peux le dépenser, et le met en output sur une nouvelle transaction pendant l’empilage du fork, alors le script sera a nouveau connu.

Bref, je n’ai jamais dit que qu’on ne pouvait pas rollback. Vous avez tendence à prendre certains de mes phrases en dehors de leur contexte, dans le sens ou je propose plusieurs solutions au problème soulevé et vous ne citez (lisez ?) que la première. Si vous voyez un détail qui ne vous semble pas réversible, donnez le moi. Mais supposer que c’est le cas sans donner ce qui coince, ça ne va pas beaucoup aider.

A nouveau, je précise que j’ai cette reversibilité en tête et que je détaillerais son processus dans la RFC quand je ferais la partie “Block”, mais j’attends d’abord un review de ce qui est déjà fait pour éviter d’avoir à la refaire plusieurs fois.

55

Mais il n’y a aucun problème avec ça, la notion de rollback n’a de sens que dans la fenêtre de fork. Une donné qui n’existe plus ni n’a aucune utilité que ce soit et qui se trouve hors fenêtre peut légitimement être supprimée.

Qu’est-ce donc que cette phrase ?

Tu es dans ta bulle de réflexion. Tes concepts et nouveautés sont peut être clairs dans ta tête, mais ne le sont pas pour ceux qui les découvrent (par définition). Aussi dans notre tentative de comprendre, on bute dès qu’un élément nous semble incorrect vu qu’on n’a pas tous les éléments.

Tu vois ! Donc ne le prend pas mal. Si tu t’agaces parce que tu crois qu’on rejette tes productions, dis-toi bien que c’est faux car sinon on ne s’embêterait pas à tout lire et à te répondre.

Bref, on attend la suite.

2 Likes
56

Quand les données sont supprimées, il y a perte d’information qui ne peut pas être rollback. Il faudra que je regarde exactement qu’est ce qui est supprimé et si ça pose problème en cas de fork.