Sinon, pour ces histoires de piscines un peu pénibles, j’ai pris les décisions suivantes :
augmentation de la taille des piscines : identités (100 -> 5000), certifications (300 -> 1000), memberships (200 -> 5000). Effet immédiat pour g1.duniter.fr.
augmentation similaire pour tous les nœuds dans la prochaine version
retour à des piscines plus petites dans quelques années
Et si d’aventure quelqu’un s’amusait à créer plein de sybils dans le but de remplir les piscines, ben … on ce sera retour à la case départ. Si cela n’arrive pas toutefois, cela pourrait débloquer de nombreuses inscriptions.
Le problème est surtout lié aux identités sans certifications qui n’ont pas de frein. Le seul fait d’avoir au moins 1 certification implique la responsabilité d’au moins 1 membre de la WoT (+ la limitation des certifications / membre, ce qui encadre le tout de manière absolue).
Si donc il était nécessaire d’avoir au moins 1 certification valide avant de pouvoir entrer en piscine, il n’y aurait pas d’embouteillages, et si on a 2 certifications valides on passerait devant celles qui n’en ont qu’une (triées par date, les plus anciennes sortant en premier), pareil pour 3 certifications, jusqu’à 5 évidemment…
Ce qui signifie que les certifications d’identités devraient être prioritaires devant les identités elles-mêmes, et être triées par nombre de certifications sur une même identité puis date (à nombre égal les plus récentes d’abord).
Les identités solitaires ne feraient ainsi aucun embouteillage, et les candidats pourraient tout à fait créer leurs clés sans pour autant être en piscine, ce qui ne peut gêner en rien théoriquement la création de documents de certifications par les membres de la WoT.
Et qui résoud entièrement la problématique des piscines.
Comme aujourd’hui, il faut transmettre son ID/pubkey à un certifieur membre de la WoT. Ce qu’on peut faire sous la forme d’un document Duniter. Mais pas besoin de passer par la piscine pour ça. Il faut au moins 1 certification valide avec pour que la piscine la retienne.
Oui mais dans ce cas cela ne gêne pas d’avoir ces piscines. Elles sont une facilité supplémentaire, parfois engorgée et donc les clients pourrraient proposer une alternative dans ce cas (comme l’export du document).
Elle sont surtout une cible de spams pour les remplir en permanence…
D’ailleurs je me demande aussi si ça ne serait pas efficace de demander 1 et 1 seule certification pour entrer en piscine, et que les certifications supplémentaires soient aussi distantes dans le temps. Ainsi tout nouvel entrant serait analysable pendant un temps incompressible. Tandis que sinon on peut entrer rapidement avec les 5 certifications valides d’un coup, ni vu ni connu… (enfin connu en blockchain, mais donc trop tard…)
C’est bien pour ça qu’elles ont une taille limitée. J’augmente temporairement leur taille pour faire faciliter l’initialisation de la toile Ğ1, mais je remettrai la limite initiale ensuite, qui est par ailleurs très restrictive (100 identités en attente).
Ensuite tu peux rajouter plein de critères, notamment ceux temporels qui sont très efficaces. Mais bon il ne faudrait pas rendre l’entrée trop difficile non plus, pour le moment en tout cas ça me paraît contre-productif.
le problème c’est qu’avec certification ou pas, un membre qui voudrait saturer les piscines, peut volontairement créer plein de comptes qu’il certifie ensuite en piscine. car la restriction de 1 certification tous les 5 jours n’existe pas en piscine.
il serait alors peut-être intéressent de limiter le nombre de certification possible en piscine a 12 par membres (60j / 5j)
et ajouter une suppression automatique des d’identités en piscine ayant reçu aucune certification après 72h.
Pas forcément automatique. Disons que si(nouvelle identité reçue ET piscine pleine) alors suppression(identité orpheline la plus ancienne + ajout de la nouvelle identité).
Bon finalement je suis parti sur une toute autre solution : la piscine de certifications sera désormais relative à chaque membre (#927), seuls les membres pourront émettre des certifications (#930), et toujours accepter l’identité embarquée dans une certification acceptée (#931).
Avec ce combo, et étant donné la possibilité d’avoir 12 certifications concurrentes au max dans Ğ1 (comme l’a rappelé Tortue), on a donc 1 piscine de 12 certifications max par membre. Tant que celui-ci ne l’a pas remplie, il peut émettre de nouvelles certifications et créer l’identité qui va avec simultanément.
S’il remplit sa piscine de 12 certifications, il ne pourra plus en émettre de nouvelles avant que l’une d’elle ne soit intégrée en blockchain ou périme.
Ainsi s’il spam une piscine, ce ne sera que la sienne.
Cela n’exclue pas la solution évoquée plus tôt par Tortue et Galuel, mais limite sa nécessité à court terme.
