Je n’ai pas d’UI qui face ça, mais l’API js qui le fait depuis peu est documenté là :
Du coup, hors partie réseau, ça devrait être très simple à faire :
Chiffrer : → résultat chiffré
Déchiffrer : → message déchiffré
S’il y a un cas d’usage, je peux faire une page web qui fasse ça.
De manière générale, c’est très pédagogique pour montrer comment ça marche (je m’en servirais volontiers dans une vidéo). Et le cas d’usage auquel on avait pensé avec @poka c’est de signer un message type “clé v1 → clé v2” avec la clé v1 et avec la clé v2. Comme ça on anticipe la migration dès le bloc zéro.
J’ai vu qu’il était question de relancé une gdev ou gtest avec les données de la Ğ1V1.
Mais les clés finales de dev n’ont rien de commun avec celle de prod.
Du coup comment ça va se tester ce truc ?
Le format d’affichage des clés publiques est différent entre DUBP et Substrate mais la crypto est compatible (on peut obtenir l’une à partir de l’autre).
Pour l’instant les clés de la gdev sont les mêmes que celles de la Ğ1, et ça pourra encore être le cas avec la Ğ1v2 (avec juste un changement de préfixe).
Pour la sécurité il faudra par contre migrer les comptes vers d’autres ayant une clé plus sécurisée (générée avec mnemonic et non mot de passe), et pour que ça se fasse automatiquement dans le bloc zéro, les propriétaires des comptes pourront signer la nouvelle clé publique avec l’ancienne.
Donc un outil de conversion/crypto de n’importe quel format dans n’importe quel autre est toujours pratique. C’est le but de natools (surtout pour faire des scripts), mais un outil web c’est plus pratique dans certains cas.
Dans la Gdev toutes les clés commence par 5 et si j’ai bien compris dans la Ğ1V2 elle commenceront toutes par G1.
Du coup à quoi ressemblera la clé V2 lors des tests ou migration à blancs ?
Pour l’utilisateur lambda, comment vérifier que la clé finale sera bien la bonne, lors des tests ?
J’ai justement un cas d’usage à proposer.
J’aurai aimé intégrer G1lib.js à Tiddlywiki de façon à pouvoir chiffrer signer des tiddlers (json internes à TW) selon le salt/pepper de “connexion” ou avec la “clef d’un ami Gchange”
Voici un exemple de TW d’un utilisateur Gchange hébergé sur IPFS
http://ipfs.copylaradio.com/ipns/k51qzi5uqu5dioeckikst5f8jw1tbljom6acjbw9zerl3671921krs4nm1531r
L’idée serait de remplacer le chiffrage par “code secret” actuel avec un chiffrage “perso ou pour destinataire” des tiddlers afin que seul ceux à qui est partagé la data stockée dans IPFS en sont les bénéficiaires 
NB: Pour le moment, le chiffrage est réalisé en “batch offline” par natools et tiddlywiki node.js
ça, ça implique d’autres choses que ce que j’ai codé :
Dès que ce sera fait, effectivement on pourra faire une interface avec :
@Frederic_Renault de ce que je comprends pour ton cas d’usage, tu n’a pas besoin d’une interface qui fasse ça, tu l’as déjà dans Tiddlywiki, tu as besoin d’une lib/api qui puisse tourner dans le navigateur et qui sache faire ça (pour ne pas avoir besoin de le faire coté serveur et pouvoir faire du chiffrage end2end de navigateur à navigateur). Si c’est bien ça, G1lib le propose depuis la v3.4.0 et dont tu as un exemple d’utilisation dans les tests unitaires.
As-tu besoin de plus pour t’en servir @Frederic_Renault ?
natools sert à initialiser les disques IPFS des utilisateurs (TW en est l’index)
Puis sert au travers d’une API qui permet de créer puis passer son TW en lecture/ecriture
Utiliser G1Lib pour contrôler le login, le chiffrage et la signature directement dans TW serait cool.
Au stade de compréhension actuel de Glib et TW, oui, j’aurai bien besoin d’aide.
Je ne comprends pas l’intérêt de ce cas d’usage. A part pour les membres forgerons éventuellement.
Mais pour les membres lambda ça me semblerait bien trop compliqué de leur demander de passer par un site web spécial pour préparer un changement de clé.
Je pense qu’il est préférable de n’exiger à l’utilisateur des actions que dans la nouvelle application qu’il utilisera (gecko ou cesium-v2).
Ca c’est parceque tu n’a aucune idée de l’UX et l’archi derrière qu’on songe à mettre en place.
Si on ne partage pas ces infos là, c’est justement parceque la conception n’est pas terminé de notre côté, ce n’est pas notre priorité, donc comme d’hab on fera un poste quand on aura une proposition claire et définie.
bah pareil, et pourtant je le fais.
C’est d’ailleurs pour ça qu’il y a déjà un topic à ce sujet qui date du 17 octobre: V2S: smooth gradual migration (clients and indexers side)
Tu n’as pas participé à cette discutions publique dédié à ce sujet.
Ta réponse ici confirme que tu n’as pas lu le contenu de cette discutions, qui n’est pourtant pas bien longue, claire et synthétique (et en Français de surcrois).
C’est qui “on” ? Peut tu stp prendre l’habitude de remplacer on part la liste des personnes concernées ? (Au moins une fois au début de ton post).
Non pas pareil. J’ai 3 contraintes que tu n’a pas:
Je réagissais à une proposition de Hugo qui ne faisais pas le lien avec la discussion que tu mentionnes. Tu aurais pu gentiment me répondre que l’explication est sur tel autre sujet à lire avec le lien, et j’aurais été le lire avant de continuer.
Rappelle toi aussi que nous ne sommes pas sur un pied d’égalité niveau temps de lecture que l’on peut consacrer à ce forum, tu ne peux pas exiger de moi que j’aie lu tous tes posts publics explicatifs.
Si tu relis mes réponses aux critiques/remarques formulées par d’autres, tu constateras que je commence toujours par une 1ère réponse sans invective fournissant le lien vers le post d’explication à lire. C’est seulement si la personne ne va pas le lire et continue ses critiques que je change de ton.
Je viens de la lire en entier, et elle n’apporte aucun élément qui remette en cause la pertinence de ma réponse, je maintiens que c’est une très mauvaise idée.
Je viens de te répondre 
Appel moi si c’est pas clair, plus le temps de te répondre par écrit.
Qu’il a raison. Il y a 2 dépendances qui font la même chose : node-fetch et cross-fetch.
Et ces dépendances ne devraient pas être dans g1lib, seulement en peerDependencies. Fetch est supporté dans le browser, donc ça ne sert à rien de le mettre dans la lib…
Pourquoi tu as besoin de ces dépendances @1000i100 ?
La partie crypto de g1lib n’en as absolument pas besoin, et son build static n’a aucune dépendances.
Les premières briques de réseau présentes dans g1lib ont besoin de node-fetch ou assimilé pour fonctionner coté serveur, mais coté navigateur, zero dépendances.
Il y a deux package.json sur ce projet. Celui qui me sert à construire et tester la lib, et celui pour la publication sur npm, qui indique les dépendances en production, à savoir aucune :
Je t’ai répondu là ou tu m’a posé la question la première fois : intégration et usage de G1lib.js (#8) · Issues · libs / G1lib.js · GitLab
Ah ok, le package.json à la racine est seulement pour le dev (construire et tester g1lib) du coup ?
Ca fait 170ko du coup !
Super! Alors G1lib doit pouvoir trouver sa place dans TW !