En fait la taille des piscine n’est pas vraiment le facteur déterminant. J’ai mis une taille technique déjà haute, en rapport avec le renouvellement des individus.
Explications : en admettant que l’on vise 10.000.000 d’individus, le nombre de naissances en France étant d’environ 800.000 par an, on a potentiellement environ 10/60 de ces naissances dans Ğ1 à terme, soit ~133.333 par an, divisé par 365 jours, cela me donne 365 naissances par jour (c’est fort ça ! on tombe sur 365² naissances max par an dans Ğ1, joli hasard du nombre).
Or avec 288 blocs par jours, cela fait 2 identités en permanence en piscine si la certification se fait immédiatement. Bref avec 100 places, il y a largement assez de ce point de vue.
Après bien sûr, toutes les identités n’arrivent pas simultanément, il y a donc besoin de plus de places. Mais on n’en est pas à 10.000.000 de membres aujourd’hui ! Donc 100 places en piscine est très largement suffisant au regard des naissances potentielles dans Ğ1 (= l’arrivée d’un nouveau membre, que ça corresponde ou non à une naissance réelle, peu importe).
C’est juste que cette taille n’est pas suffisante au regard du goulot d’étranglement à l’initialisation. Mais est-ce important ?
Peut-être est-ce un problème de référence de temps, car cette certification d’inso, bien qu’ayant été écrite samedi 18 mars, a été réalisée le 12 mars. Mais le délai court sur la date d’inscription en blockchain, pas sur la date d’émission de la certification.
C’est une supposition de ma part, dis-moi ce qu’il en est selon toi.
Excellent ! D’ailleurs ça fait rebondir sur un bug similaire dans Cesium qui affiche du coup une fausse date aussi ! Ce qui explique pourquoi malgré une vérification approfondie du sujet hier, je n’arrivais pas à trouver le problème, Cesium ne donne pas les bonnes infos…
Pas forcément : pour le moment ça bloque la création de nouveaux comptes pour tous ceux qui passent par Cesium sur duniter.fr, car ils tapent tous sur la même sandbox. S’ils instanciaient leur propre nœud, alors leur Cesium embarqué ou même un Sakia qui pointerait sur leur nœud permettrait à coup sûr d’accepter leur identité (c’est une règle des sandboxes Duniter : toujours accepter ses propres documents).
Ensuite, l’identité peut se propager aux piscines d’autres nœuds s’ils ont de la place, ou tout simplement car quelqu’un certifierait leur identité, la faisant passer de facto en priorité, comme tu l’avais fait remarqué il y a un moment.
Je me demande si pour finir, il ne faudrait pas que les clients puissent permettre de certifier des identités à partir de documents d’identités bruts. Du type :
“Exporter mon identité”
“Certifier une identité -> importer un document d’identité”
Ce document serait partageable par mail / chat / forum / autre.
Comment le noeud identifie ses propres documents? Si contacter en localhost?
(ce n’est probablement pas cela, car on a du mal à faire écouter BMA en localhost et sur une autre IP simultanément)
Tout document a un émetteur, voire plusieurs dans le cas de transactions co-signées. Donc on peut vérifier que la clé publique du nœud = clé de l’émetteur.
Ici on est dans le cas où la personne n’est pas encore membre.
Si je comprends bien, il faut configurer le nœud miroir pour que la clef de celui-ci corresponde au compte que le futur membre aura choisi ?
De plus, la première certification doit être envoyé à ce nœud miroir, car si tt les piscines sont pleines ils n’auront pas l’information du document d’identité du futur membre.
Oui mais pour générer cette certification il faut bien requêté un nœud qui contient le document d’identité (ou export du document comme le propose inso)
Bref via un partage de fichier quelconque.
Pour dégager un peu les noeuds, les clients pourraient soumettre les documents uniquement quand le “dossier est complet”, comme proposé par @cgeek il y a déjà quelques mois…
Salut,
je pense qu’il nous faudrait plus d’informations pour pouvoir t’aider efficacement.
Sur un raspberry, la procédure que je suis (et qui a fonctionné pour moi) est la suivante:
téléchargement de la version arm,
ipkg -i <fichier.deb>
duniter webstart
ouvrir le navigateur et aller à localhost:9220
synchroniser avec le bon nœud (pour Ğtest, attention, la version compatible installée doit alors être inférieure à 1, de la forme 0.91.4, par contre pour Ğ1 ça doit être 1.x.x)
paramétrer le réseau dans les paramètres (pour ma part, uniquement ipv4, les ports et le nom de domaine), là il y a différentes possibilités suivant si upnp est activé sur la box, si un nom de domaine pointe sur ton adresse, si tu es en ip fixe ou pas… et du coup potentiellement aller aussi sur la config de la box pour rediriger le port réseau vers le raspberry,
changer la clé dans crypto (surtout pour les membres pour pouvoir calculer des blocs).
Je crois que c’est l’essentiel des étapes.
Ensuite, dans cesium, on peut choisir le nœud auquel on veut se rattacher, et il faut préférer des nœuds en SSL (port 443), j’ai eu aussi des problèmes avec d’autres nœuds.
C’est bien les étapes que j’ai suivi … Tout est bon jusqu’à “paramétrer le réseau”, je suis derrière une Freebox sans nom de domaine, avec UPNP activé dans DUniter, dans la box j’en sais rien (comment vérifier?). Toujours est-il que j’accède bien à l’API via mon ip publique, mais pas via localhost.
J’ai bien pu synchroniser la blockchain, je vois les infos de ḡ1 dans cesium embarqué.
C’est lorsque j’ai voulu créer un document d’identité via cesium embarqué que j’ai toujours ce problème de pool pleine, vu que mon cesium cherche toujours à parler à g1.duniter.fr . Ne devrait-il pas parler à mon noeud fraichement installé à la place? Quand j’essaie de changer ce noeud dans les paramétres de cesium embarqué, il me dit “impossible de joindre” peut-importe que j’essaie avec localhost:port, ip public :port ou bien un noeud quelquonque dans la liste proposée (vos noeud membres).
Quel est l’interêt d’avoir un cesium embarqué avec le noeud si c’est pour pointer vers le noeud principal? Autant utiliser g1.duniter.fr directement dans ce cas…
Oui c’est possible car tu consultes depuis un navigateur, or celui-ci mémorise l’adresse utilisée dans la version précédente.
Tu peux tout oublier en supprimant les données du localStorage de ton navigateur, ou en consultant en navigation privée, ou encore en testant avec un autre navigateur jamais utilisé pour le Cesium embarqué.
Ce comportement gênant n’apparaît pas sur la version desktop.
Après il y a peut-être une autre subtilité que je loupe …
! on tombe sur 365² naissances max par an dans Ğ1, joli hasard du nombre).