Is there any known limit for Salt and Pepper maximum length?
Quelle est la longueur maximum des identifiants, mots de passe Ceisum, Silkaj et autre générateurs de clefs compatibles Duniter
Tout trousseau de clés ed25519 est compatible avec Duniter, Duniter est agnostique de la manière dont ils sont générés.
Dans toutes les implémentations d’ed25519 que j’ai pu voir, la seed fait toujours 32 octets.
Quand a la manière d’obtenir la seed, Cesium et Silkaj ont choisi scrypt, dont si taille maximale il y a, cela dépend de l’implémentation de scrypt utilisée, mais en théorie nul besoin de limite, si tu veut générer ta seed a partir du contenu d’un livre de 1000 pages c’est théoriquement possible 
Donc n’importe quelle clef ed25519 de 32 octets est un porte-feuille de G1 potentiel pour Duniter?
Cette phrase n’a pas de sens, on ne parle pas de clé ed25519 mais de trousseau de clés ed25519. Il faut préciser si tu parle de la clé publique, la clé privée ou du trousseau (donc des 2 clés associés).
En revanche, oui, n’importe quelle clé publique ed25519 est un porte-feuille de G1 potentiel pour Duniter.
Mais attention, j’ai parlé de seed pas de clés, c’est tout a fait différent. La seed sert a générer un trousseau de clés mais elle n’est pas le trousseau :
seed → (secret_key, public_key)
Il s’avère que la clé publique fait aussi 32 octets, mais je ne l’avais pas précisé donc je pense que tu a mélangé seed et public key.
Oui, il faut préciser tu as raison… En fait, je cherche à comparer le authfile (que silkaj produit)
silkaj generate_auth_file ...
cat authfile
da67c028e4132ae4e6db9058cac3cac72df373fec984fa3bf45e7464be2209ff
D’ailleurs est-ce la clef privée correspondant à la publique renvoyée ou son seed?
Et la clef que je fabrique pour IPFS…
ipfs key gen --type=ed25519 --size=32 maclef
12D3KooWRae4bp8rQZAbM4hPvVwtVLhPUXdZs78J1Fa22tZ6sYoq
cat ~/.ipfs/keystore/maclef
���^�#�U����(p�kp��X�@d�6Ի��7e��b��.q�-O�
��;�%�O
�� X
Pour les rendre compatibles
Une histoire de base64 peut-être??
cat ~/.ipfs/keystore/maclef | base64
CAESQBWWVFGQMQ2whPJegCOnVdUSkr/AKHDka3DO1xVYmEBk6jbUu5G0N2WQhGKq6y5xgi1P3wqs
iTvHJZpPCoGuH1g=
Ou une transformation en hexa… Suis un peu paumé
Si j’arrivais à utiliser la même clef ed25519 entre Duniter et la clef de signature IPNS dans IPFS.
Je pourrai alors obtenir une correspondance entre la valeur d’un wallet sur l’un et sur l’autre.
Ce serait de la balle 
Et simplifierait mon code d’un coup de verrou et d’une clef en moins
Alors dans ce cas il faut regarder dans la doc de silkaj et si ce n’est pas dans la doc il faut demander aux dev de silkaj de l’ajouter cc @Moul
Car en effet il y a un infinité de façon possibles de stocker un trousseau de clé ( d’ailleujrs silkaj supporte plusieurs formats).
Je ne connais pas le format authfile mais déjà on vois que c’est 64 caractères hexadécimaux donc ça stocke 32 octets donc oui c’est très probablement la seed 
(je doute que ce soit la clé privée puisqu’elle fait 64 octets).
OK, merci @elois
@vit sait peut-être aussi?
En tout cas, je regrette de ne pas avoir une interface CLI propre et rapide avec Duniter ou un de ses clients…
Avec https://docs.ipfs.io/reference/api/cli/
Je viens de coder « G1tag » un stockage de wallet façon blockchain à consensus « ma gueule » sur IPFS en 200 lignes Reste à voir comment ça tient la synchro quand ça monte en charge et en noeuds et finir d’ajouter au consensus la synchro avec les G1 wallets…
Faut qu’on en parle, je crois bien avoir attrapé une Licorne 