Les clients stockent en local des listes de clés publiques et de portefeuilles, et cette pratique va probablement se généraliser avec les HD wallets et les seeds aléatoires.
Mais si j’ai plusieurs clients sur ma machine (Cesium, Tikka, Ğcli, Silkaj, ĞMixer…), je n’ai pas envie d’avoir à modifier les portefeuilles et adresses dans chaque client, ou réimporter tout à chaque fois…
Ça pourrait donc être utile d’avoir un stockage partagé entre tous les clients (avec éventuellement la possibilité d’utiliser le stockage du client). Quelque chose genre ~/.config/wallets-g1/.
Ça permettrait, par exemple, de se créer un HD wallet opaque dans un client, puis de transférer des Ğ1 dessus depuis son compte membre via le ĞMixer, sans se tromper de clé publique.
Le format pourrait autoriser des métadonnées personnalisées, afin que tous les clients s’y retrouvent.
Questions techniques :
Est-ce possible sur Android ?
Comment faire avec les clients dans le navigateur ?
Réponse rapide: Non parcequ’on utilise un espace dédié à l’application en question: /data/user/0/com.example.gecko/app_flutter/wallets
Réponse bis: Mais on peut imaginer plutôt stocker cette liste dans le dossier ~/Document d’Android, à priori je ne vois d’impossibilité technique à faire cela.
je n’ai pas envie d’avoir à modifier les portefeuilles et adresses dans chaque client, ou réimporter tout à chaque fois…
On te dit qu’on veut pas importer !
@tuxmain, ce que tu proposes en fichier maison stocké en local ressemble fortement à “un carnet d’adresses”.
Et plus on va avoir de besoins, plus l’implémentation en serveur se fera sentir. Donc, pour ne pas réinventer la roue, je propose plutôt de stocker nos infos dans un serveur de contacts standard. Il y a sûrement des champs qui peuvent nous servir, à commencer par le champ description/note.
On aura alors, sans rien coder “en plus” une synchronisation automatique des clients sur un carnet unique !
Moi j’utilise Radicale, un serveur de calendrier/contacts en Python.
Du coup moi pour ne pas réinventer la roue, le propose d’utiliser les g1-datapods et leurs noeud ES permettant dès maintenant d’ajouter n’importe-quel champs libres, clair ou chiffré selon les besoins.
Le chemin $HOME/.config n’est valable que pour les systèmes linux. Sur mac c’est /Users/UserName/Library/Preferences et sur windows c’est C:\Users\UserName\AppData\Roaming.
Et c’est encore un autre chemin pour Android, comme le dit @poka.
Donc ça n’a aucun sens de vouloir standardiser un chemin commun. En revanche, or peut standardiser un nom de dossier commun, ce dossier devant se trouver dans le chemin standard spécifique au système pour la configuration des applications
Sachant que ce sera de toute manière impossible pour iOS, car chaque application n’a accès qu’a une sandbox isolée :
Oui, c’était bien le nom du dossier pour lequel je souhaitais proposer un autre nom.
Tu fais bien de préciser que c’est pas partout pareil selon le système.
