Ce qui permet cela, c’est le fait de mettre le site web en lecture seule. On peut alors avoir confiance dans le module firefox ou l’application bureau/mobile gchange et ainsi un compte June peut enfin servir à réaliser des opérations sur gchange sans problème.
C’est décorrélé de la fusion des pods.
Oui ce que tu décris là, c’est comment ça marche aujourd’hui, et pourquoi c’est le bordel, les gens sont perdu, avec 2 comptes mais pourtant la même méthode de création de “comptes”, et pk ya des bugs dans gchange à ce sujet, dû à la complexité que cela engendre, complexité qui devient obsolète grâce aux propositions de ce topic.
Ok ok, merci pour la réponse, je vais relire du coup le topic, j’ai dû louper quelque chose… en fait justement vous cherchez à trouver des solutions pour pallier aussi à ce problème. 
Faire cela suppose effectivement de sécuriser Ğchange, en empêchant (ou en dissuadant suffisamment) de mettre des identifiants importants dans la version web.
Mais comme pouvoir commenter et poster des annonces est utile pour découvrir la Ğ1, même sans avoir de monnaie ni de certifs, je propose de seulement empêcher (dissuader) d’utiliser sur la version web des identifiants pouvant être utilisés dans Cesium.
Ce point me semble le plus compliqué à mettre en oeuvre concrètement pour pas grand chose.
Quand je dis concrètement, je veux parler de tous les effets de bords que ça amène:
Il faut faire comprendre à l’utilisateur qu’il peut se connecter sur gchange web, mais avec un login aléatoire qu’il ne maîtrise pas, et qu’il ne pourra pas utiliser ailleurs.
Au sujet de ta proposition de credential aléatoires, je suis un peu sceptique, principalement pour des raison d’UX donc.
Avec cesium web/cesium desktop, au moins c’est claire, AUCUN login sur cesium web. Moi je partirais sur cette option pour gchange également, mais il faudrait approfondir l’UX de ta proposition random SALT/PWD.
Je parlais de l’interface de Ğchange. Je pensais qu’on parlais de fusionner les données uniquement, pas les interfaces.
Bah non je ne parle pas de fusionner les interfaces ^^
Je parles aussi uniquement des données.
(j’avais laissé glisser un « cesium » au lieu de gchange sans faire gaffe, c’est corrigé, je sais pas si c’est plus clair ?)
Je pense que c’est une bonne idée, si c’est accompagné d’un load balancing entre les Pod.
Parce que ce qui gâche l’expérience utilisateur provient très souvent d’une indispo des serveurs par défaut
Je serais partisan d’avouer clairement qu’un compte Gchange est aussi un wallet Cesium.
Je comprends la peur de le révéler pour éviter qu’une clef gchange (à priori moins sécurisée) devienne “membre”. Mais qu’on le veuille ou non, cela se produit certainement déjà.
Ce problème serait arrangé si on n’avait pas à se connecter à son compte membre à tout bout de champs pour y récupérer ses DU.
Bah comme client+ mais en remplaçant le c par un ğ 
En lisant ce fil, je me dis que depuis le début, la confusion des gens est liée au fait que le même outil serve à faire les transactions quotidiennes pour les échanges et les certifications. Les spécificités de notre projet par rapport à une autre crypto sont :
D’un point de vue « client » ces fonctionnalités concernent des utilisations très différentes. La toile de confiance et les certifications, c’est des relations sociales, presque un réseau social. Les fonctionnalités associées sont donc :
La partie transaction, c’est plus comme paypal / applepay / tricount, pas besoin d’informations mais il faut pouvoir faire des virements simplement et surveiller ses dépenses et recettes.
La partie échange, c’est comme leboncoin, il faut une base de confiance et des infos pratiques.
Duniter est le logiciel qui fait fonctionner la blockchain de la june, mais ce qui fait fonctionner les métadonnés (avec compatibilité RGPD) c’est un mélange entre césium+ et gchange. Donc il faut renommer ça.
Junebook / Facejune XD
datajune / réseaujune / junesocial / metajune
(L’ennui quand on écrit depuis le téléphone, c’est que c’est vachement plus dur d’être structuré et cohérent !)
J’en arrive au même constat sur Tikka. Je ne m’intéresserai aux identités que lorsque j’aurai fini les bases de la gestion des comptes. Ce sont deux univers différents qui demandent des fonctionnalités différentes.
Ils seront bien séparés dans Tikka. Bref, je plussoie.