[Inscription] Problème d'envoi de document d'identité

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 :smiley: ! 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 ?

2 Likes

A propos de @canercandan : en fait il y a une erreur d’affichage dans la disponibilité de la certification d’inso dans le tableau : celle-ci est indiquée disponible, alors qu’il a vu écrite une certification interne samedi, en même temps que l’entrée de nouveaux membres. Donc au mieux, la disponibilité devrait être au 23 mars.

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.

2 Likes

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…

Du coup hop, petite issue Cesium !

J’ai l’impression que ça va bloquer l’entrée de membres qui devraient être validés, non ?

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.

Ok toute cette histoire me revient à présent.

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.

5 Likes

Mais carrément !

Je dirais même plus : sphériquement !

4 Likes

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.

J’ai juste ?

Tu as juste pour la 1ère assertion.

Concernant la 2ème assertion, bien que le nœud n’ait pas l’identité, la certification contient l’identité. Et donc le nœud peut l’enregistrer simultanément. C’est d’ailleurs ce qu’il fait.

3 Likes

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)

Pour la générer oui, mais pas pour l’envoyer.

Oki merci pour ces détails, la proposition d’inso me semble alors bien plus fonctionnel.

Bref via un partage de fichier quelconque. :wink:
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…

Hello,

Alors comme prévu j’ai installé un noeud sur Raspberry pi3, après pas mal de galère voilà DUniter installé…

Je n’arrive toujours pas à créer mon identité:

  • est-ce normal que mon Cesium embarqué pointe toujours vers g1.duniter.fr? (dans les paramètres et lors de la creation d’un compte?
  • j’ai voulu configurer vers mon noeud, mais
  1. impossible de lui parler via localhost:port, je doit utiliser ip-public:port
  2. impossible e changer la config de cesium, quoi que soit l’adresse que je tente, j’ai “impossible de joindre”

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.

Salut @jytou,

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 …