BrightID propose un système de reconnaissance d’identité décentralisé. Dans leurs objectifs techniques, comme pour Duniter, ils ont pour souhait d’empécher les attaques sybilles et de limiter les inscriptions à une identité par personne.
Peut-être qu’un jour, on pourra externaliser la WoT de Duniter pour utiliser celle construite au sein de BrightID. En attendant, il y a surement pas mal de choses à apprendre sur leur fonctionnement interne.
Tu saurais résumer leurs idées ?
C’est en gros leur mécanisme de défense anti sybil : les sybils, créateurs de sybils et leurs collaborateurs vont devoir se grouper entre eux, puisque les utilisateurs honnêtes refuseront de se grouper avec eux
Globalement c’est intéressant, ça ressemble pas mal à ce qu’on fait côté Duniter avec la notion de distance et de % de membre sentries à joindre. Eux ils n’inventent pas grand chose, et s’appuient plutôt sur l’état de l’art dans la recherche anti-sybil (ils référencent 6 papiers). Ils combinent en fait les différents papiers pour aboutir à un système conçu pour la reconnaissance d’identité unique.
Hello,
Un peu hors sujet mais pas tout à fait, je pose ça ici : https://www.gravity.earth/#digital-id
Our mission is to allow anyone to create a secure, self-sovereign digital ID based on personal data. On the fly, using any mobile phone on the market, no matter the telecom operator or type of phone.
Ce que je ne vois pas dans leur système, et qui me semble utile/nécessaire :
Et effectivement, plus de lumière sur la partie seed.
Je parlais un peu avec castall de BrightID, ils prévoient une beta pour novembre.
Ils travail sur l’intégration etherum, il m’a demandé si il pouvait préparer une intégration avec la blockchain Duniter, je lui ai dit que oui ça serait chouette, mais que je ne pouvais pas parler à la place des dev.
Si jamais vous voulez vous ouvrir à cette idée, il est joignable via ce canal: https://hub.decstack.com/projects/channels/brightid
Je ne vois pas ce que signifierais une intégration de BrightID si ce n’est remplacer la WoT actuelle, ce qui ne me semble pas à l’ordre du jour.
Pour autant, BrightID me semble extrêmement prometteur comme alternative à la WoT Ǧ1 pour développer une autre monnaie libre n’ayant pas les limitation d’extension de la Ǧ1 (mais n’ayant pas certaines qualité de la Ǧ1 comme ça résistance à effondrement en cascade).
Il me semblerait donc pertinent développer/adapter Duniter, Juniter, DURS/Runiter, ou autre logiciel implémentant le DUP (Dividend Universel Protocol si je ne me trompe) de manière à pouvoir accueillir un code monétaire données (celui qui en fait une monnaie libre) et une WoT données (celui qui rend au DU de cette monnaie libre son caractère Universel).
Ou, si cela n’est pas faisable (ou demande un travail que personne ici ne souhaite prioriser) il me semblerais alors pertinent qu’une développement de code monétaire type Monnaie Libre soit construit par dessus la WoT BrightID plutôt que l’inverse.
En fait pour savoir ce qu’il faudrait faire ici, il faudrait que quelqu’un fasse la démarche de se renseigner sur BrightID et se documente. Sous quelle forme est-ce que ça s’interfacerait avec Duniter ? etc…
Si nous pouvions trouver le moyen de nous assurer paisiblement d’identités uniques, sans avoir l’impression de prendre le risque de transgresser un texte biblique susceptible d’entraîner l’humanité dans l’obscurité pour des siècles et des siècles. Alors nul doute que la monnaie libre pourrait enfin nous autoriser à nous faire confiance en nous même pour commencer.
Nous pourrions alors enfin nous préoccuper efficacement, d’un coté de mobiliser des codeurs, de l’autre des usagers ordinaires au lieu d’expliquer à longueur de posts et d’apéros, l’anathème de la transgression de la divine licence.
Cela nécessiterai de modifier le protocole Blockchain de manière a ce qu’il devienne agnostique du système d’identification utilisé, mais cela impliquerai que la blockchain DUP ne contiendrai plus les “preuves” qui attestent que les règles du système d’identification sont respectés (a moins de devenir une blockchain ultra générique type FYgg).
Il y a une autre solution plus simple et a laquelle je serait favorable : Avoir 2 types de nœuds : un qui gère la monnaie et un qui gère le système d’identification. On aurait alors deux réseaux superposés ayant chacun leur propre blockchain (dans le cas ou système d’identification repose sur une blockchain, ça peut être autre chose).
En tout les cas, rendre DUP agnostique du système d’identification est un chantier colossal et nous avons déjà beaucoup d’autre priorité pour les années a venir.
Il me semble donc en effet infiniment plus facile que l’équipe de BrihtID implémente leur propre protocole de monnaie libre par dessus leur système (avec l’aide de notre expérience pourquoi pas).
Je viens de discuter avec castall de BrightID, il est très intéressé techniquement par Duniter, et l’éthique du projet lui plaît. Il a toutefois quelques questionnements sur les aspects économiques, il en a déjà discuté avec @Inso sur reddit : https://www.reddit.com/r/CryptoUBI/comments/6udflu/how_do_crypto_ubis_arrive_at_their_chosen/
De mon coté je lui ai fait part de nos besoins techniquement parlant, et il pense que BrightID sera tout a fait en mesure d’y répondre.
En particulier il nous sera possible de définir des seuils différents pour le droit a co-créer sont DU et le droit a écrire dans la blockchain en demandant un “trust score” plus élevé pour le droit a écrire des blocs.
Il faut bien comprendre que BrightID est soumis au mêmes problèmes que notre toile de confiance, des mots mêmes de castall :
elois :
The difficulty seems to me to be to succeed in choosing a good threshold for the “trust score”.
castall :
yes, that will take some experimentation
It’s a trade off. Too high and it’s hard to get new users, too low and you have more sybils
But when the network becomes worldwide, the getting new users part won’t be an issue
It’s while the network is growing that the tradeoff needs to be made
L’avantage serait que la toile serait bien plus grande que notre communauté Ğ1 car le réseau BrightID a vocation à être utilisé par de nombreuses communautés pour tout types de besoins.
Concernant les considérations techniques, les nœuds BrightID fourniront une API Rest qui répond du JSON donc se sera assez simple à utiliser (Le développement de leur API viens tout juste de commencer mais ils devraient avoir une 1ère version beta pour Novembre).
L’idée serait que chaque document identité comporte un identifiant BrightID.
Et chaque fois qu’un membre émet un document membership, le noeud qui essayera d’écrire ce document membership dans son bloc vas contacter l’API BrightID pour obtenir une preuve de “trust score” de l’identifiant BrightID associé a l’identité correspondante, si le trust score est toujours au dessus du seuil que nous aurons défini le membre est renouvelé, sinon le membre expire.
Dans cette idée, les documents identity et membership seraient conservés, seul le document certification disparaîtrait.
Merci @elois pour avoir fait cette démarche de recherche.
Alors, ça signifie que l’API BrightID doit permettre de répondre à la question “Quel est le trust-score de l’identifiant BrightID X à la date T ?”. Puisque quand on va vérifier un bloc, on vérifiera le trustscore à la date du bloc 
Mais sinon, techniquement ça a l’air intéressant à plusieurs niveaux :
Les inconvénients sont qu’un des aspects critiques de Duniter reposerait alors sur un système annexe. Ceci dit, il est possible de prévoir des modes de secours, du type
en cas de défaut du système annexe, les noeuds Duniter gardent la dernière liste valide des membres pour faire fonctionner la monnaie en attendant un retour à la normale.
Ce qui implique de garder en cache une “liste des identités Duniter dont le trustscore a été suffisamment élevé pour le membership”.
En terme d’implémentation :
J’ai lu et le sujet est comme souvent très mal approché dû au manque de mathématiques dans l’explication et la compréhension pourtant simplissime.
La croissance est la part de monnaie créée sur la monnaie existante. Mais en relativité cela s’entend part de monnaie individuelle créée sur masse monétaire moyenne : DU(t+1) / (M/M)(t).
Or DU(t+1) = DU(t) + c² M/N(t), et donc il s’ensuit :
DU(t+1) / (M/M)(t) = DU(t) / (M/M)(t) + c²
Et donc lorsque N augmente fortement M/N diminue, et ainsi la croissance de la monnaie est très forte, ce qui correspond très exactement à la demande de l’interlocuteur.
Exercice : quelle est la croissance actuelle de la Ğ1 ? Quelle était sa croissance il y a 6 mois ? Quelle sera celle dans 6 mois dans des conditions similaires ?
Le grand avantage des mathématiques, vraiment, c’est de pouvoir écrire en 20 caractères ce qui demande des romans entiers et des approximations loufoques aux non-mathématiciens.
En effet, et cela peut être réalisé “simplement” avec un oracle qui gérerait la liste des membres. Ainsi on pourrait utiliser la WOT en insérant les résultats, mais plus tard passer à un autre système sans changer le protocole de la blockchain 
J’ai deux choses à dire sur l’utilisation de systèmes externes :
C’est bien le but d’un oracle : insérer une vérité en ayant la plus grande certitude qu’elle le soit. Un système de caution permet de motiver la participation et la coopération tout en réprimandant les initiatives personnelles. Ici Duniter reste hôte et la gestion des membres est gérée off-chain et considérée comme une boite noire, permettant une modification sans fork (tant que les participants utilisent le même protocole off-chain, mais permettant une transition moins lourde).
Tout à fait d’accord pour BrightID.
Pour le calcul externe en revanche (en supposant que l’oracle fonctionne bien) est utile car il permet de décharger les noeuds les moins puissants ou non interessés. Tant qu’un grand nombre de personnes vérifient les calculs, alors le système est sûr et les autres peuvent se permettre de ne pas vérifier eux même.
Oui bien entendu
C’est effectivement une question a creuser avec les dev de BrightID mais ils semblent très motivés pour pouvoir être utilisé par Duniter donc il est mais possible qu’il effectue les modifications nécessaires pour répondre a nos exigences (peut être même sont t"il déjà en mesure d’y répondre sans rien modifier); le seul moyen de le savoir c’est de continuer a en discuter avec eux
Les enjeux me semblent quand même très similaires. Quel différence voit tu a niveau des enjeux ?
Quand aux identités, nous aurons toujours nos propres identités de notre coté, on se servira de BrightID uniquement pour vérifier que l’identité créer est bien une personne physique vivante et qui n’a pas déjà un compte membre.
Je ne voit pas en quoi cela poserait problème dans le sens ou les nouveaux membres de Ğ1 devrons toujours faire la démarche de s’inscrire à la Ğ1 après s’être inscrits sur BrightID. Ils exprimeront donc clairement leur intention de rejoindre une monnaie libre.
En tout les cas leur système a du potentiel et il me semble que nous devons creuser davantage cette possibilité afin de prendre une décision.
Peut tu définir “système externe” ? BrightID est comme pour nous un logiciel libre porté par une infra décentralisé d’humains volontaires, chacun d’entre nous est libre de s’y impliquer tout comme nous avons choisi librement de nous impliquer sur l’écosystème Duniter.
Si j’ai un serveur Duniter et un serveur BrightID, pour moi les autres serveurs sont externes, qu’il s’agisse de serveurs Duniter ou de serveurs BrightID.
Et puis en cas d’évolution trop différente ou peut toujours forker le logiciel pour qu’il continue de répondre aux besoins d’une Monnaie Libre.
BrightID est externe à Duniter, et inversement.
Stéphane, j’ai essayé de retrouver ton résultat, que je trouve important, à partir de l’étude que j’avais faite sur l’évolution de la masse monétaire M lorsque la taille N de la toile de confiance varie :
Ce que j’obtiens confirme ton affirmation :
En effet, en régime stationnaire, j’avais obtenu que la masse monétaire moyenne en relatif :
était égale à :
où c est le taux de croissance de la monnaie et a celui de la toile de confiance.
En inversant ce résultat, on obtient :
ce qui est l’expression de la croissance de la monnaie. On voit donc, effectivement, que cette croissance augmente avec le taux de croissance a de la toile de confiance (et aussi avec c, bien sûr).