Extensions des fichiers d’authentification

Applications
, ,
21

Je tombe sur la doc d’une lib cliente pour SSB.

// configuration:
var keys = ssbKeys.loadOrCreateSync('./app-private.key')
ssbClient(
  keys,                // optional, defaults to ~/.ssb/secret
  {
    host: 'localhost', // optional, defaults to localhost
    port: 8008,        // optional, defaults to 8008
    key: keys.id,      // optional, defaults to keys.id
   // ...
)

ils semblent utiliser une extension .key et un format Json. Et un chemin par défaut de la clef : ~/.ssb/secret.

je trouve cela assez intuitif, comme nommage, non ?

EDIT: la doc des ssb-keys est ici : GitHub - ssb-js/ssb-keys: keyfile operations for ssb

{
  "curve": "ed25519",
  "public": "<base64_public_key>.ed25519",
  "private": "<base64_private_key>.ed25519",
  "id": "@<base64_public_key>.ed25519"
}
22

La RFC#13 n’impose pas d’extension au fichier d’authentification DEWIF. Je pense que ça serait bien, après je ne sais pas si on obtient un consensus.

Avec Silkaj, je suis parti sur .dewif pour je ne sais plus quelle raison. Surement, car c’est le nom du format et de la RFC.

Tikka v0.23.4 impose le format d’import .dunikey 1, 2. J’ai modifié le code pour laisser passer des fichiers *.dewif générés par DuniterPy. Le problème est que ça échoue à déchiffrer un fichier chiffré (EWIF) ou sinon le bouton Ok reste grisé pour un fichier WIF non chiffré. Est-ce que Tikka implémente la RFC#13 DEWIF ?

23

Tikka ne supporte pas le format dewif par défaut, puisque la majeure partie des comptes V1 utilise Cesium et son format .dunikey.

Mais en relisant le code, je vois que tout est là pour le faire.

Ici je gère le chargement du fichier, en utilisant une lib locale issue de DuniterPy :

Et j’ai également la lib qui gère le format dewif dans le dossier libs :

J’ai d’autres priorités sur le feu. Mais si tu veux t’y coller, ça doit pas être bien compliqué.