Renouvellement des certifications

protocole
g1-test
g1

#1

Un sujet est revenu durant ces RML11 : la possibilité de renouveler une certification.

Concrètement, comme vous le savez déjà une certification dure 2 ans. Donc au bout de 2 années, la certification expire et le membre qui l’a reçu peut demander à son émetteur de la renouveler. Mais ce rejeu ne peut pas être fait avant les 2 ans dans le protocole actuel. Il faut attendre l’expiration.

Le problème : la discontinuité

Cela pose problème par exemple pour ceux certifiés exactement par 5 personnes. Quand l’une des certifications va expirer, le membre sera immédiatement exclu. Il y aura donc « un trou » dans la production de DU pour ce membre, de même il ne pourra plus calculer de blocs ni certifier.

Le phénomène s’amplifie par le fait que les 5 certifieurs initiaux vont devoir à nouveau se synchroniser pour faire revenir ce membre, mais plus encore les 59 premiers membres de la Ğ1 vont littéralement créer un trou de certifications au 08/03/20, qui peut lui-même s’étendre par effet domino aux membres certifiés par eux (qui vont subir le même problème des 5 certifications, mais en plus leurs certifieurs seront eux-mêmes tombés et ne pourront plus les certifier).

Un contournement : trouver de nouveaux certificateurs

Il est toutefois possible de contourner cette discontinuité en récupérant pour soi-même des certifications venant d’autres personnes, ce qui peut permettre le roulement.

Ainsi si je possède 5 certifications et que l’une d’entre elles expire avant les autres (ce qui est très probable sauf à ce que les 5 membres aient cliqué simultanément sur “certifier”), alors obtenir une 6ème certification permet de rester membre le temps de renouveler la certification tombée.

Cela demande toutefois une certaine rigueur et réactivité de la part des certifieurs, ce qui, étant donné que nous sommes humains, n’est pas vraiment envisageable à grande échelle.

Une solution : autoriser le renouvellement anticipé

L’idée est la même chose que pour l’adhésion : permettre de renouveler la certification avant qu’elle n’expire.

Aujourd’hui on peut renouveler son adhésion dès 2 mois après le dernier renouvellement. Ainsi un nouveau membre arrivé le 01/01/19 dont l’adhésion court jusqu’au 01/01/20, peut renouveler son adhésion avant la date de fin :

  • le 01/03/19, soit 2 mois après, décalant sa fin d’adhésion au 01/03/20
  • le 01/06/19, soit 6 mois après, décalant sa fin d’adhésion au 01/06/20

Il serait possible d’utiliser exactement le même mécanisme pour les certifications. Ainsi en renouvelant ma certification auprès de X 8 mois après l’avoir certifié, je décale de 8 mois la date d’expiration de celle-ci.

Mais afin d’éviter le spam, on pourrait n’autoriser le renouvellement que 2 mois après l’émission de la certification (ou un autre chiffre, mais l’adhésion ayant déjà ce délai ça simplifie la mémorisation).

Des avis ? Sachant qu’il n’est pas très urgent d’implémenter cette fonctionnalité, mais mieux vaut ne pas tarder pour éviter un effondrement.


Conservation nombre de membres ≥ 1 200
#2

Je suis tout à fait pour cette fonctionnalité. Il faudrait aussi que ce renouvellement de certification implique aussi le cooldown de 5j, mais sans incrémenter le compteur de certification (ou faire -1 +1, ce qui reviens au même).


#3

Je suis pour !

Pour rappel, la discussion avait commencée ici :


#4

Oui ce serait une certification, donc le délai de 5 jours s’appliquerait aussi à la certification qui suivrait le renouvellement. Et en effet on ne touche pas au stock.


#5

Le délai de 2 mois avant renouvellement, pour une certif durant 2 ans, me parait très court.
Choisir 22 mois (2 ans - 2 mois) me paraitrait viable,
mais pour des questions de simplicité cognitive, je propose 1 an.


#6

Je ne sais pas si c’est clair : celui qui renouvelle au bout de 2 mois ne fait que décaler la fin de la certification précédente de 2 mois.


#7

Yeap, la certification remplace la précédente, et est valide pour 2 ans à partir de la date de renouvellement.


#8

C’est très clair, oui. Je me dis que ça risque de pousser certains à demander un constant renouvellement. Ce n’est pas au niveau technique, mais au niveau humain je me dis que “s’inquiéter de ses certifs” doit être limité à 1 fois/an.
“Si les devs ont mis si bas, ça doit être pour une bonne raison, on n’est jamais trop prudent”.


#9

Bon après gagner 2 mois ce n’est vraiment pas beaucoup, et on peut arguer que pour éviter le spam on mette plus de temps.

Maintenant pour l’adhésion c’est 2 mois pour 1 an, soit 17% de la durée de vie. Vu que la certif dure 2 ans en proportion ça ferait 4 mois.

Honnêtement je n’ai pas de préférence, c’est un compromis entre liberté de l’utilisateur de pouvoir renouveler suffisamment tôt et la liberté des autres d’avoir une blockchain qui n’est pas spammée par les certifications.

Au niveau chiffres, une blockchain à 1.000.000 d’utilisateurs ayant 50 certifications en moyenne signifie 10⁶ x 50 / 288 / 365,25 / 2 = 237 certifications par bloc en moyenne, juste pour maintenir entièrement la toile et sous réserve que les certifications sont émises précisément tous les 2 ans.

Plus les utilisateurs peuvent renouveler tôt, plus ce chiffre de 237 peut monter. Peut-être que 1 an est un bon compromis en termes de symétrie.


#10

Un an me semble pas mal. On a le temps de renouveler sans pouvoir spammer.

D’ailleurs, une raison pour avoir choisi 2 mois pour 1 an en ce qui concerne l’adhésion ?


#11

Je ne sais plus, mais c’est marqué dans un sujet du forum (de mémoire).


#12

Okay je vais faire un peu d’archéologie :slight_smile:

Du coup tu as toujours besoin de ma certification ? Quelqu’un d’autre en à besoin ?


#13

Je re-up le sujet qui me paraît maintenant plus urgent, même si on a jusqu’à mars 2019.

Le renouvellement des certifications avant expiration devrait être mis en place avant cette date dans l’idéal.

J’ai créé une issue pour cela :


#14

C’est une modification assez sensible du protocole, je peut le faire dans Durs si c’est souhaité mais je ne maîtrise pas suffisamment le code de Duniter pour pouvoir le faire dans Duniter, et je n’ai pas envie de toute façon.
De mon coté, je n’implémenterai aucun changement de protocole dans Duniter car je ne peut pas m’investir sur deux implémentations a la fois pour des parties aussi critiques :sweat_smile:

A noté qu’en mars 2019 Duniter sera toujours la seule implémentation en prod, donc quoi que je fasse sur Durs ça n’aura pas d’impact sur ce sujet :slight_smile:


#15

Oui je pense que c’est souhaitable sinon pour “survivre” à la fin des 5 certifications quasi simultanément, il en faut 5 de plus en décalé, soit le double.

Je pense qu’aucun utilisateur n’est conscient de cela.

Tu devrais l’implémenter dès le départ dans Durs amha.


#16

Je suis de ton avis @vtexier, ça me préoccupe aussi.

@elois : étant donné que je ne veux plus trop m’investir dans les changements du protocole mais que celle-ci semble nécessaire, je propose que :

  • soit 1) j’implémente ce changement avec déclenchement temporel (facile)
  • soit 2) j’implémente à la fois ce changement et celui sur le feature flag (investissement plus important)

Dans les deux cas je souhaite d’abord remettre un peu Duniter sur pied en version 1.7.

Personnellement je préfère la solution 1), mais ton avis peut m’orienter vers l’autre solution sinon. Ou encore autre chose.


#17

la solution 1) me conviens car pour la solution 2 je préfère qu’on prenne le temps de faire ça bien, avec des flags et tout, et ça me semble plus critique car ça change le format des blocks !
De plus, un déclenchement temporel me semble ne pas poser de problème ici dans le sens ou ce changement n’aura aucun impact avant le 1er mars 2019 sur la Ğ1 et qu’on peut donc prendre le temps de le tester sur g1-test avant pour être sur :slight_smile:


#18

Alors l’idée est bien que le déclenchement se fasse avant Mars 2019 (le plus tôt possible, en fait).

Mais sinon, OK, je pars sur 1).