Carnets d'adresses / HD wallets partagés entre clients

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 ?
2 J'aime

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.

1 J'aime

Si pas de stockage partagé possible ou trop compliqué, on peut peut-être imaginer un export/import des porte-monnaies avec option ajout ou remplace …

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 ! :wink:

@tuxmain, ce que tu proposes en fichier maison stocké en local ressemble fortement à « un carnet d’adresses ». :grin:

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.

2 J'aime

Je propose $HOME/.config/g1-wallets/

Pour ça il faudrait définir un format de fichier HD wallet commun. Je propose le format JSON.

Ça pourrait être quelque chose comme ça :

{
    "dewif": "AAAAARAAAAGfFDAs+jVZYkfhBlHZZ2fEQIvBqnG16g5+02cY18wSOjW0cUg2JV3SUTJYN2CrbQeRDwGazWnzSFBphchMmiL0",
    "accounts": {
        "0": { name: "mon compte membre" },
        "2": { name: "mon compte opaque", external_index: 17, internal_index: 3 },
        "3": { name: "mon compte transparent " },
        "6": {}
    }
}

L’idée est de stocker à minima :

  • Le numéro de dérivation de chaque sous-compte. Il est unique et ne peut pas changer, donc autant s’en servir d’id.
  • Les index externe et interne pour les comptes opaques

On peut ajouter en champ optionel pour chaque sous-compte :

  • Un nom
  • Ce qu’on veut tant que ça ne pose pas de problème de sécurité. Donc pas de clé publique.

Le champ DEWIF serait facultatif, s’il est absent, le logiciel client doit inviter l’utilisateur à saisir directement son mnemonic :slight_smile:

4 J'aime

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 :slight_smile:

Sachant que ce sera de toute manière impossible pour iOS, car chaque application n’a accès qu’a une sandbox isolée :
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

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.