Cela fonctionne pour un message de type String signé par mon code, mais pas pour un Uint8List.
Est-ce que c’est censé fonctionner pour un Uint8List graphiquement ici ?
Non, polkadot js ne peut vérifier que les signatures émises via la lib polkadot/api, car ça ajoute des wrapping bytes, je suis d’ailleurs persuadé que c’est la cause de ton problème.
Pour ne pas avoir les wraping bytes, il te faut descendre plus bas niveau en js, et utiliser directement la fonction sr25519Sign du paquet npm @polkadot/util-crypto.
Pour vérifier, tu peux check la signature avec un bout de code python, je peux aussi le faire avec un bout de code rust, si tu me fournis pubkey et sig.
Je vais tenter une question bête, mais ne serait-il pas possible de changer côté duniter la vérification de la signature du message en hexa plutôt que Uint8Array pour cet extrinsic ?
Non pas possible, le runtime wasm doit être léger et rapide, il contient les SCALE codec nais c’est tout, il ne contient rien pour gérer ou parser les chaînes de caractères, et ne le peut pas, car c’est du no_std.
En plus ça ne résoudrait en rien ton problème, puisque c’est un souci de signature, pas de génération du message.
Faut pas te décourager @poka, tu as déjà énormément avancé, c’est normal que tu galères surtout que tu dois composer avec une couche javascript que tu ne maîtrises pas bien.
Après quelques précieuses indications d’elois et une bonne nuit de sommeil, j’ai pu mettre à jours mon fork de polkawallet_sdk pour permettre la signature unwrap du message Uint8List:
Et cela a fonctionné ! L’identité zombie (initialement sur l’adresse corresponsant à Cesium(test,test)) a été migré vers mon adresse 5D2HHRj6zCEL9iY3CBpKy1mBMtpXUJCFDNvevBqVQAWdzqSS (dérivation de mon coffre gecko) !!
Par contre l’indexer de @cgeek n’a pas compris ce qu’il s’est passé lol, c’est normal ce cas d’usage n’était pas encore prévue.
@ManUtopiK@cgeek , il faut que l’indexeur écoute l’event Identity.IdtyChangedOwnerKey, cet event contient 2 paramètres: le IdtyIndex et la nouvelle adresse.
Ce n’est pas mon code, c’est le package polkawallet_sdk, je n’ai fait que changer wrap to unwrap pour régler le problème de signature que j’avais.
Je ne sais pas à quoi correspond keyPair.lock(), je ne m’en sert nul part dans mon code.
C’est une interface JS, je n’ai pas été voir à quoi ça correspond. Je suis d’accords que c’est étrange de voir lock et non unlock ici, mais bon ça fonctionne j’en demande pas plus pour cette partie pour le moment ^^
Je n’arrive plus à migrer d’identité sur le nouveau runtime 700. Je test uniquement sur mon noeud de dev local, car tester la gdev aujourd’hui à m’a permis de me rendre compte que je n’étais plus membre de la Ğ1 au moment du lancement pour non renouvellement de mon adhésion …
Voici l’erreur que j’obtiens:
Uncaught Error: createType(Call):: Call: failed decoding identity.changeOwnerKey:: Struct: failed on args: {"new_key":"AccountId32","new_key_sig":"{\"_enum\":{\"Ed25519\":\"SpCoreEd25519Signature\",\"Sr25519\":\"SpCoreSr25519Signature\",\"Ecdsa\":\"SpCoreEcdsaSignature\"}}"}:: Struct: failed on new_key_sig: {"_enum":{"Ed25519":"SpCoreEd25519Signature","Sr25519":"SpCoreSr25519Signature","Ecdsa":"SpCoreEcdsaSignature"}}:: Unable to create Enum via index 212, in Ed25519, Sr25519, Ecdsa
Est-ce que vous pouvez me confirmer qu’il s’agit bien d’une erreur de signature (new_key_sig) invalide ?
Si c’est le cas, le message d’erreur a été modifié depuis la dernière fois (et tant mieux).
Vous n’avez pas changer quoi que ce soit à ce niveau ? Toujours le même préfix icok par exemple (je n’ai pas encore été vérifier dans le code) ?
Arrivez-vous à effectuer une migration d’identité avec d’autres clients avec d’autres clients que Gecko ? Ou arrivez-vous à le faire avec Gecko sur la gdev (ou terminez-vous en timeout) ?
edit: Je viens de tester sur l’image du runtime 300 (debug-sha-4d5e08be), et je confirme que la migration d’identité fonctionne avec gecko sur ce runtime, il a donc eu un changement depuis côté Duniter.
Ah zut, j’avais oublié de tenir au courant. Je l’ai bien implémenté dans Ğcli en permettant aussi les clés ed25519 générées “méthode Cesium” (c’est comme ça que j’ai fait pour migrer mon identité forgeron) et ça ressemble à ça :
/// change owner key
pub async fn change_owner_key(
data: &Data,
address: AccountId,
keypair: KeyPair,
) -> Result<(), subxt::Error> {
let (_payload, signature) = generate_chok_payload(data, address.clone(), keypair);
// this is a hack, see
// https://substrate.stackexchange.com/questions/10309/how-to-use-core-crypto-types-instead-of-runtime-types
let signature = match signature {
Signature::Sr25519(signature) => MultiSignature::Sr25519(
runtime::runtime_types::sp_core::sr25519::Signature(signature.0),
),
Signature::Nacl(signature) => MultiSignature::Ed25519(
runtime::runtime_types::sp_core::ed25519::Signature(signature.try_into().unwrap()),
),
};
submit_call_and_look_event::<
runtime::identity::events::IdtyChangedOwnerKey,
Payload<runtime::identity::calls::types::ChangeOwnerKey>,
>(
data,
&runtime::tx()
.identity()
.change_owner_key(address, signature),
)
.await
}