Donc tu peux effectivement avoir plusieurs identités avec le même UID ou la même clé publique ou la même date, mais une identité A qui aurait les mêmes 3 champs qu’une identité B voudrait simplement dire que A = B.
Ceci n’est pas vrai en blockchain : tout UID ou clé publique inscrit en blockchain est réservé. Il ne peut pas y avoir une nouvelle identité en blockchain qui réutiliserait le même UID ou la même clé publique.
Le hash dont parle Eloïs, c’est l’empreinte du document d’identité (= SHA256(identité)), donc l’empreinte des 3 champs.
C’est un petit peu chiant de s’entendre dire “t’as qu’a forker” à toute proposition! Je ne vais pas forker ton bébé pour renommer 1 ou 2 pages enfin!! Surtout que moi aussi je m’en fiche complet du nom! C’était une idée comme ça après avoir parcouru le topic sur les propositions de nom pour ḡ1, donc j’était très dans les noms…
Sérieux qu’est ce qui est compliqué?
DiG: Tu veux pas trouver un nouveau nom?
elois: non
Basta! Pourquoi balancer à la gueule un “t’as qu’à te débrouiller par toi même” ? Et alors si je te propose un css pour ces pages tu va me répondre de forker aussi? L’open source c’est pas “TG et fork” hein!
Je vais me faire un noeud spé, mais pas pour faire de la requette en DB! Ca ne m’interesse pas, je suis plus front moi Par contre @elois, je veux bien quand même un github, pas pour forker, mais plus pour étudier comment on fait un noeud spé… j’ai pas pu venir aux RML8 où a été présenté la spécialisation de noeud…
Merci @cgeek pour les précisions… Mais je comprends encore pas la “clé publique” c’est pas ce tas de char qui est généré à l’aide du couple passphrase et mot de passe?
Dans ce cas, 2 fois le même couple produit bien la même clé c’est bien ca?
Donc 2 personnes, qui ne se connaissent pas, peuvent (par hasard) choisir la même passphrase, le même mot de passe et le même psudo, il ne seront différent que de par leur date d’inscription ?
Le principe de base c’est de considérer que personne ne va choisir les mêmes phrases de protection que toi, même « par hasard ». C’est le cas dans Duniter, Bitcoin, etc.
Notamment avec quasiment autant de clés possibles que d’atomes dans l’univers observable, si l’on utilises des méthodes conseillées, alors le risque devient tellement faible qu’on le considère négligeable.
Une amélioration possible : afficher avec une couleur spéciale les certifications en erreur, par exemple en orange.
Ce sont les certifications dont le blockstamp (la date de référence) n’existe plus du fait d’un fork. Tu peux prendre l’exemple de ta certification à KennySLB @elois, son blockstamp est 8931-000007E256 alors que dans la blockchain on a 8931-00001784.