IA faible => depuis des années les algos sont a plein regime dans la vie courante
IA forte => bien malin celui qui peut affirmer
" on a le temps de vivre 100 vies avant qu’une telle réalisation ne voit le jour "
ce qui est " fake " :
c’est nier les travaux dans les domaines des NBIC et de l’IA et l’impact de ces technologies
Oui je penses qu’un simple champ commentaire à l’instar des transactinos suffirait au niveau du protocol, et puis ensuite c’est libre d’implémentation.
Comme pour les transaction, un client peut remplir ce champ à l’aide d’une syntaxe spécifiée quelque part…
Dès lors, nous pourrons certifier des objets de la blockchain par leur uid, qui pourront être juste indication, relié un autre système d’information externe, ou bien texte clair pour les humains.
Je penses que le protocol doit définir juste un chhamps text, comme pour les TX, et c’est aux différentes implémentation de clients de se mettre d’accord pour une syntaxe commune en dehors du protocol lui même…
Ou bien l’inverse: la certification (infalsifiable en blockchaîne) contient des liens vers des hash donné d’un système d’information externe…
Et pour ca le meilleur des candidats serait IPFS, un noeud companion de chaque noeud DUniter suffirait à pouvoir accéder de façon identique à tel ou tel document linké par son hash de contenu ds la certif et/ou les transactions…
Un hash IPFS peut pointer vers un dossier, un fichier, ou une données d’un arbre merkel, c’est assez souple pour permettre de référencer n’importe quoi, et le tout sans encombrer la blockchaîne.
L’intéret est qu’un hash donné pointera TOUJOURS sur le même contenu de fichier, si le fichier est modifé même de façon minime, le hash sera différent. Donc un hash IPFS ds un champ comm permet de pointer avec assurance vers TOUJOURS le même contenu… Infalsifiabilité !
De plus il y aurait moyen de déterminer un IPNS par personne ce qui lui donne un “dossier” perso dans lequel il peut mettre tout un tas de chose (publique) ou bien des choses privée à l’aide d’un hash non diffusé publiquement…
De même ici, IPFS étant un support possible de l’information. On pourrait très bien imaginer aussi un champ libre “commentaire” dans le bloc qui puisse par exemple stocker le hash d’un bloc d’une sidechain, permettant ainsi de faire du merge mining. Ces sidechains pourraient permettre de stocker de nouvelles informations pour des protocoles annexes, par exemple ce système de documents hachés.
Je pense rajouter ces différents champs dans la future version du protocole, ce qui pourrait permettre pas mal d’extensions de Duniter sans modifier le protocole central.
On est parti sur une idée de système généraliste permettant de renseigner une preuve biometrique pour ceux qui le souhaitent, ou tout autre preuves pertinentes pour les autres, sans forcer quoi que ce soit, juste laissant la possibilité de le faire. Du coup liberté totale des certifieurs de faire confiance à la “preuve biométrique” ou bien la “preuve de rencontre” ou encore la “preuve de réseaux sociaux cohérents” etc…
Et pour des cas de nom identiques? il va bien falloir trouver un élément distinct pour ces 2 personnes.
Par exemple j’ai déjà au moins 2 homonymes exacts sur FB (nom et prénom) et au moins 10 personnes avec le même nom que moi…
Il faut prévoir les cas particuliers… Maintenant je suis d’accord que la biométrie n’est pas souhaitable (pour moi) car ce n’est pas sûr ni certain à 100% et peut entraîner des abus sur les corps des gens à des fins de vol d’identité, ce qui est inacceptable!!
Par contre peut-être que adns 80% des cas le nom/prenom suffit, mais pour d’autres ils auront besoin, je sais pas, par exemple du lieu/date de naissance pour être différenciés…
Ouais bon alors carrement revoir la structure de bloc, pour n’avoir que les headers utiles aux clients light (style SegWit) et un champ “content” qui pointe un hash à récupérer sur IPFS…
Ce hash serait un lien vers un dossier IPFS listant les données des ce bloc en blockchaîne :
Pour vérifier la BC il faut lire les header de bloc 1 par 1 et faire un get du folder IPFS pour savoir ce qu’il y a eu ds chacun des block…
Par contre sa implique de la gestion de “pin” de document IPFS, car il y’a des données qui devront être loadé par chaque noeud et non garbage collectée, donc ya du dev à faire
Je pense qu’il est important de se dissocier de tout autre protocole. IPFS peut être intéressant pour des données annexes, mais pas pour les données de blocs. Ca fait une dépendance de plus et rajoute de la complexité, ce que j’essaye justement de limiter au maximum.
Sinon ma RFC va définir une nouvelle structure pour tous les documents actuels, avec entre autre l’utilisation d’arbres de Merkle qui pourraient permettre à des clients léger de vérifier que les sources sont valides en ne téléchargeant que les en-tête de blocs.
Attention : pas sur que ça soit nécessaire. Dans Duniter, les clients ne sont pas sybilizable (chaque noeud est identifié). Un client SPV qui ferait des vérifications suivant ce qu’on imagine pour l’API GraphQL n’aurait ainsi pas besoin de télécharger les entêtes des blocs, qui n’apporteraient il me semble aucune sécurité par rapport aux requêtes validées sur plusieurs noeuds distincts.
Ca peux permettre aussi à un noeud de télécharger les blocs, vérifier sa validé, puis de seulement stocker le Merkle root et les UTXO. Ca pourrait être très pratique pour des petites machines comme des Raspberry, surtout avec une probable augmentation de la taille de la blockchain quand la monnaie sera plus utilisée.
Même en dehors de cet usage les arbres de Merkle permettent de nombreuses autres optimisations.
Edit :
On pourrait alors avoir des clients SPV qui n’ont besoin de faire confiance à aucun noeud tant en vérifiant l’intégrité de la blockchain.
Sakia ne fait confiance à aucun noeud et n’a pas besoin vérifier l’intégrité de la blockchain ! Mais c’est juste qu’en comparant les réponses entre des noeuds pris au hasard et qui ne peuvent pas être démultipliés (puisqu’un noeud = un poids de 1 = une identité), il n’y a pas de risque à être trompé dans un réseau majoritairement honnête.
Il n’empêche que ça pourrait servir pour un serveur Duniter qui souhaite vérifier les blocs, mais stocker le moins d’informations possible sur disque (ici que les en-têtes, les documents en cours de validité et les UTXO).
Oui bien sûr ceux et celles qui souhaitent être marqués par des identités corporelles, qu’ils le fassent … On est libre de ne pas être libre (m’enfin, même pas sûre de ce que je dis là ^^ )
