Keep keyring file auth in cs2?

Par contre, l’utilisation de fichier trousseau, ou QR-code me semble intéressant, pour les personnes qui utilisent un appareil qui n’est pas le leur.

Peux-tu préciser “pour les personnes qui utilisent un appareil qui n’est pas le leur” ? Quel intérêt pour eux de pouvoir utiliser un fichier de trousseau ou QRCode dans ce cas précis ?

Dans le cadre d’import officiel par mnemonique, protégé par code secret, je ne vois plus trop l’intéret des imports par fichier de trousseau, ou qrcode.

J’ai volontairement décidé de ne pas proposé ces options dans Gecko par exemple. Et il serait judicieux de s’aligner entre les clients en terme de methodes d’imports.

Car si on veut vraiment implémenter la methode d’import par fichier de trousseau, alors se pose la question du format:

  • WIF/DEWIF: permet de garder une compatibilité avec les trousseaux v1, mais n’incite pas les gens à migrer vers mnemonique
  • Fichier de trousseau polkadot.js (probablement le plus judicieux)
  • Format Ginkgo (que j’ai déjà contribué à accepter les format ewif de cesium…)

Ma recommandation est de ne pas implémenter ces modes d’import, les phrases de restaurations étant censer se suffire à elles mêmes.
Mais à vous de voir ce qui vous semble le plus judicieux, on peut faire ce qu’on veut.

Il semble qu’il y a encore des personnes qui utilisent la Ǧ1 sans posséder d’ordinateur ni de smartphone, en se connectant sur un appareil d’un ami.
Comment faire pour leur rendre la vie plus simple ?

Autre utilisation du QR-code de connexion : les billets ou carte fidéliǧ1.
Quelles solutions sont envisageables dans la V2 ?

Je comprends le usecase, mais j’ai encore du mal à comprendre l’intéret des fichier de trousseau pour ces cas là.
Dans Gecko il suffit de faire plusieurs coffre par exemple, avec un code secret différent entre chaque coffre, plus besoin de ressortir un qrcode ou un fichier de trousseau à chaque fois…

Je propose même des scan des phrases de restauration par OCR, je suis allez assez loins quand même, je ne sais pas si vous avez testé ça …

Est-ce vraiment à Cesium2 de tenir ce rôle ? Il serait très facile de créer un petit outil, une page web, permettant de générer des qr-code de connexion, si ce n’est pas déjà le cas. Il suffit d’adapter les outils existant avec les nouveau formats d’adresse et de mnemonique.

En théorie même, par defaut ces outils devraient continuer de fonctionner en l’état, les pubkey étaient toujours utilisable telles quelles sur la v2.

Est-ce que Cesium1 gère déjà les génération de qr-code de clé privé?

3 Likes

Oui mais dans ce cas on est obliger de laisser ce coffre sur l’appareil de “l’ami”
Mais oui avec le scan de la phrase de restauration c’est tout simple, je n’y pensais plus.

En effet, il sera plus judicieux de créer une appli dédiée pour faire des billets, à voir plus tard !

Merci de m’aider à réfléchir :thinking:

3 Likes

J’ai finalement implémenté tous les formats de fichier de trousseau disponible sur Cesium v1 pour garantir une continuité (PubSec, WIF et EWIF).
A l’import uniquement, le temps qu’on se décide sur un format d’export commun.



3 Likes