Dès lors que pour une donnée connue du protocole, son authenticité n’est pas assurée par lui, alors celle-ci provient d’un système externe : c’est-à-dire d’un autre protocole.
Ainsi si Duniter introduit la notion de “BrightID” mais sans en définir les règles d’authentification, alors ce BrightID provient d’un système externe. Par contre si Duniter intègre totalement le protocole BrightID dans son propre protocole, alors il ne s’agit plus d’un système exerne mais juste du système Duniter, nouvelle mouture.
Inversement : les identités créées par les utilisateurs de Duniter ne proviennent pas d’un système externe, car toutes les règles nécessaires et suffisantes permettant d’établir leur authenticité son gérées par le protocole Duniter.
Une solution type “oracle” est en fait un pont vers un système externe.
À la condition que Duniter référence BrightID, et inversement.
Car sinon on n’a pas de système exerne, on a juste le protocole dans lequel on se place et depuis lequel on observe. Si Duniter ne référence pas BrightID alors tout simplement BrightID n’existe pas, de son point de vue.
Je cite @elois sur ce point avec lequel je suis plutôt en phase.
Les enjeux de BrightID sont les mêmes (avoir une identité unique par personne).
Les moyens diffèrent (ils s’appuient sur Ethereum).
Duniter aura toujours ses identités en interne
Le seul risque serait que la politique de reconnaissance des identités de BrightID ne nous convienne plus (par exemple, la manière dont sont créés les seed-groups). Dans ce cas, il faudrait des moyens de “forker” tout en continuant de faire tourner la monnaie.
Oui mais plus authentifiées par lui. Ce qui introduit en fait une faille.
Passer par un système externe c’est comme découper une grosse fonction en plus petites : chaque fonction est alors plus simple, mais délègue la responsabilité à la fonction appelante. En l’occurrence, Duniter délèguerait la responsabilité des identités à un Oracle et BrightID.
Ce qui est une faille. Possiblement acceptable et même nécessaire vis-à-vis de l’objectif fixé certes, mais une faille quand même.
Une faille, je trouve le mot fort, même si je comprends bien ce que tu veux dire.
S’appuyer sur BrightID apporte 3 risques selon moi :
Que les développeurs de BrightID changent leur politique d’authentification et qu’elle ne nous convienne plus
Qu’une faille ou un bug soit présente dans le code/protocole de BrightID
Qu’une faille ou un bug soit présente dans l’interface entre BrightID et Duniter (l’Oracle)
Ces trois risques me semblent limitables par une simple mesure de “débranchement” de BrightID en cas de problème. Ça empêcherait Duniter de prendre en compte le flux d’humain temporairement, le temps de trouver une solution.
En contre-partie, je vois plusieurs avantages :
S’appuyer sur un système qui se spécialise dans la reconnaissance d’identité uniques
Simplifier le code de Duniter et donc les contributions
Se concentrer sur les problèmes monétaires
Dans tous les cas, si ça devait être réalisé, il faudrait d’abord passer par une période de test intense. BrightID aurait besoin d’être mis à l’épreuve. Peut-être même qu’il faudrait le faire avec une monnaie Ğ2, orientée “international via BrightID”.
Pour garder la compatibilité entre un code Ğ1 (WoT) et Ğ2 (BrightID), il faudrait que Duniter s’appuie sur une interface. Cette interface pourrait soit pointer sur la WoT, soit sur BrightID, soit sur autre chose.
Mais comme dit précédemment, il se peut qu’un tel branchement, qu’une telle rupture soit nécessaire pour passer à une autre échelle. Sans quoi nous ne serions encore que des organismes mono-cellulaires.
Faut juste se rappeler que quand le foie lâche, c’est la mort qui pend au nez. Une fois ce risque connu et maîtrisé, a priori, tout peut très bien rouler.
Le protocole Duniter n’y fait aucune référence. Ce n’est donc pas un système externe.
De plus comme je l’ai dit, les identités ne sont pas non plus issues d’un système externe que seraient les humains : il n’y a que des clés publiques, des signatures, des identités, des certifications, adhésions et règles d’ajout à la blockchain.
D’ailleurs tu ne trouveras pas le mot “human” dans le protocole. Duniter est agnostique d’eux, de BrightID, des chats ou de Ğaluel. Et c’est parfaitement cohérent de ce point de vue
@Inso alors on s’est peut être mal compris mais il n’y aura pas besoin d’Oracle pour s’interfacer avec BrightID.
C’est @nanocryk qui a parlé d’Oracle mais pour d’autres cas d’usages (comme par exemple faire on sorte que tous les nœuds n’aient pas a calculer la distance dans notre wot actuelle).
Non, je parlais bien d’oracles pour une interraction avec BrightID ainsi que pour des calculs externes (BrightID pouvant en être un). Il suffit d’avoir un oracle publiant la liste des comptes membres, et ayant comme source soit la toile de confiance Duniter (externalisée), soit se basant sur BrightID, soit sur encore autre chose. L’interet, c’est que la monnaie elle s’en fiche et que la source est remplaçable sans modifier le protocole (il suffit que l’ensemble des participants de l’oracles se mettent d’accord pour changer de source d’information, ce qui pourrait être géré côté logiciel sans être interne à la blockchain).
Je peux essayer de travailler sur une explication plus détaillée de comment ça pourrait fonctionner pour éviter toute ambiguité sur ma proposition.
Comme dit par d’autres précédements, même si l’utilisation de BrightID n’est pas pour tout de suite, une extraction de la logique de la WoT pourrait permettre de l’améliorer plus facilement.
Il ne faut pas courir deux lièvres à la fois, si on se lance dans des tests d’un pont Duniter<->BrightID ce sera sans Oracle.
L’utilisation d’un Oracle pour la WoT est intéressante et je suis favorable a très long-terme mais c’est un autre sujet qui n’a pas de rapport avec BrightID et qui n’a donc pas a rentrer en compte dans la future décision d’utiliser ou non BrightID
L’utilisation d’un oracle simpliferait largement ce pont. Pour le “ce sera sans Oracle”, il serait bon que ce genre de décision découle d’une decision commune et non d’un choix personnel. Des personnes ont l’air interessées par cette solution, pourquoi faire une impasse dessus ?
J’ai bien montré qu’il avait un rapport précédement, puisqu’il permet d’externaliser la gestion des membres, permettant à la suite de remplacer facilement la WoT par un autre système comme BrightID. On a donc de meilleures perfomances, une séparation des différentes parties de la G1 ainsi que la possibilité de remplacer celles-ci.
Cela n’empèche pas de réfléchir à des méthodes qui pourront être utiles pour d’autres besoins.
Il ne s’agit pas d’une “impasse” mais de séparer les sujets !
Il n’est pas “certain” que passé par un Oracle soit pertinent, ça rajoute un intermédiaire donc ça rajoute des sources d’erreur.
Et ce présent fil fut relancé par poka car l’un des dev de BrightID est intéressé maintenant par la réalisation d’un pont technique, donc soit on fait avec l’existant (donc sans Oracle) soit on ne fait rien et la collaboration est très mal engagée
Non, ça évite surtout d’adapter l’un des système à l’autre et réciproquement. BrightID ne dépend pas de Duniter, et Duniter ne dépends de BrightID que par son oracle qui abstrait la prise de décision. Je ne vois pas en quoi ce n’est pas pertinent.
Mais l’oracle est le pont technique ! C’est quelque chose de plutôt simple et qui permettrait de récupérer la base des utilisateurs de BrightID sans incorporer la logique de BrightID dans Duniter. C’est exactement ce qu’il nous faut pour réaliser une connexion avec BrightID. (surtout qu’avec le système d’identité unique il est assez simple de faire un oracle sans risque de manipulation tant que le premier est fonctionnel)
Il faudrait aussi que tu explique comment faire “à partir de l’existant” ? Comment l’existant permettrait d’utiliser BrightID sans modification ? Il ne peut pas. On doit remplacer le code de la WoT par quelque chose qui gère BrightID. Donc soit on fait un développement spécifique à BrightID (ce qui pose problème dans le cas où BrightID n’est finalement pas une bonne solution), soit un développement permettant de remplacer de manière générique la WoT (par BrightID, une WoT améliorée, autre chose), soit on ne fait rien et il restera laborieux de mettre à jour la système d’identité (qui est clairement la partie la plus complèxe de Duniter actuellement).
Je suis plutôt d’accord avec @nanocryk : si on veut utiliser BrightID pour Duniter, il faut d’abord découpler Duniter de la WoT et de la gestion de la légitimité des identités.
Je ne sais pas si l’oracle est la seule solution pour faire ça, mais c’est une des solutions possibles.
De plus, il n’est pas envisageable de publier une “liste d’identités membres” et de s’y référer. Pour des millions d’utilisateurs, ce n’est pas du tout utilisable. Il est a mon avis préférable que l’on ait plutôt un système de questions/réponse type “cette clé publique est elle membre?” -> oui/non (avec la preuve associée).
Je pense que @nanocryk utilise le terme “Oracle” de manière bien plus générique que les autres, d’où certaines incompréhensions.
L’Oracle est un service chargé d’entrer manuellement une donnée extérieure dans la blockchain. A l’instant T, qui aura été défini à l’avance, le service va récupérer l’information qui lui a été demandée et l’insère dans la blockchain à l’endroit qui lui a été désigné.
Donc il me semble qu’à peu près n’importe quelle transmission entre BrightID et la blockchain du protocole Duniter peut être qualifiée d’Oracle (du moment que c’est une API pas trop crado).
C’est aussi la définition que j’en retiens, pont = oracle, nécessairement. Car si Duniter intègre tout BrightID en lui-même alors on n’est plus sur un système externes.
Par contre @elois peux-tu détailler le lien que tu envisage avec BrightID “sans oracle” ? Je ne sais même pas de quoi on parle pour l’instant
Le problème c’est que cette question/réponse prend du temps et de la place (vote d’un grand nombre de membres pour s’assurer que la donnée est valide).
Par contre, au lieux de poster la liste entiere, on peut simplement poster la racine d’un arbre de Merkle stockant l’ensemble des membres, demandant alors uniquement la preuve à l’utilisation.
J’avoue que je ne comprend plus… quand je demande la binarisation du protocole on me dit que c’est trop compliqué et quand je demande de tester un pont avec BrightID sans Oracle via une simple API Rest comme expliqué dans ce post on me dit qu’il faut faire plus compliqué pour que ce soit générique
Puisque vous semblez touts d’accord pour passer par un Oracle je vous laisse voir ça avec castall (un dev de BrightID), vous pouvez le contacter sur decstack : https://hub.decstack.com/projects/channels/brightid.
Perso je n’ai pas la possibilité de me lancer dans un tel chantier, c’est pour ça que je proposait de faire au plus simple dans un premier temps.
