oui, encore de ma faute tt ça 
voulant aider à l’extension de la WOT, je me suis dit que j’allais certifier quelqu’un qui était proche de l’être, et ayant reçu des certifications par des membres dont j’ai confiance, ici cgeek et inso.
Je me suis donc dit que j’allais assister à l’ajout d’un nouveau membre en direct, mais hélas non ^^
j’allais ouvrir une issue demain, mais vous êtes déjà tous au courant
Bonjour, j’ai essayé de m’inscrire ce jour et effectivement full.
Mais avec mes identifiants j’ai pu voir mon compte (non membre). En voulant directement faire la demande de devenir membre depuis l’onglet option, ça me met la même remarque (full).
N’étant pas trop calé en informatique et sur ce sujet des nœuds, ce qui m’intéresse est ce que l’on peut faire de cette monnaie et la faire circuler. J’ai inscrit aussi ma société (KELCLIM) en tant que compte sans membre (vu que ce n’est pas un être humain). Je la vois sur mon profil, quand je fais une recherche dans l’annuaire aussi. Mais par défaut n’apparaissent que les membres (actifs ou en demande). ça serait cool que l’on voit aussi les “partenaires” non membres, avec qui on peut commencer à utiliser G1.
Et juste une remarque de débutant sur ces nœuds ; s’il n’y en a pas assez par rapport aux demandes de nouveaux entrants (et il faut espérer qu’il y en ait de plus en plus pour que G1 soit une véritable monnaie qui donne confiance au plus grand nombre), il n’est pas possible de ne compter que sur les bonnes volontés de ceux qui mettent à disposition ces noeuds. Sans tomber dans le bitcoin, une rémunération, même minime, inciterait à la création de noeuds pour offrir la puissance de calcul suffisante au développement viral de cette monnaie.
Bonjour @gdangin 
En fait le secret c’est que tout les comptes existent déjà, ou qu’aucun compte n’existe jamais, ce qui reviens au même
Tu peut tester en saisissant n’importe quel phrase de protection et mot de passe, tu arrivera toujours sur un compte, enfin sur une clé et c’est ça le secret 1 compte = 1 paire de clés public/privé et c’est tout.
Nous utilisons un algorithme de chiffrement asymétrique (ed25519) pour générer à la volée ta paire de clé chaque fois que tu saisi ton couple (phrase de protection, mot de passe).
Ce qui est inscrit en blockchain, c’est seulement un sous-ensemble particulier de toutes les clés publiques existantes, l’ensemble des clés publiques qui correspondent à un membre de la toile de confiance (64 a ce jours).
Oui car en réalité créer un compte membre = demander à devenir membre depuis n’importequel compte, c’est pareil. Cela consiste a créer un document identité et le publier sur le réseau de nœuds, le problème actuellement c’est que les nœuds refusent les nouvelles identités car leurs piscines sont déjà pleines.
Cela était a l’origine présent dans cesium, il me semble que @kimamila à prévu de le réintégrer plus tard 
Comme signalé sur un autre thread, ce n’est pas un problème de nombre de nœuds, on pourrait en avoir 1 million ce serait pareil, les nœuds se partagent les documents entre eux, ce qui est nécessaire pour avoir la même vision de la monnaie.
Nous pourrions en revanche, étendre la taille des piscines, ou coder un algo de nettoyage en supprimant par exemple les pending identities ayant toujours 0 certifs depuis x jours. Ce qui inciterai les nouveaux entrants a ne formuler leur demande d’adhésion que lorsqu’il ont déjà une personne dispo pour les certifier, qu’en pense tu @cgeek ?
Nous avons déjà mis en place un système qui rémunère les membres qui exécute un nœud duniter sur leur ordinateur : il s’agit de remuniter.
elois, merci pour toutes ces informations. Et la réactivité. Chapeau bas ! ! !
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 ?
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.
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.
Mais carrément !
Je dirais même plus : sphériquement !
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.
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.
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…