-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: split associateAccountToChainArgs
#730
Conversation
The linter failed... |
|
||
const challenge = await getLinkingChallenge(did, validTill) | ||
|
||
const predictedType = accountAddress.length === 20 ? 'ethereum' : 'sr25519' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait we can't just assume it's an sr25519 address can we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are only two different wrapping strategies. ethereum
and the substrate way (sr25519
, ed25519
, ecdsa
). So for anything not ethereum, we can just pretend it's one of the others. Doesn't make any difference which one we choose.
But yeah it's an ugly place in code. Don't really like it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we merge this before changing the challenge? Does that make sense?
Also, this does not change the signature of associateAccountToChainArgs
right?
I would change the challenge, if we decide to, in another PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beyond perhaps a suggestion to change "raw challenge" to something else, I have nothing else against it, and I am glad we caught this stuff before the next release 🚀
Co-authored-by: Antonio <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good, pls figure out why some account linking integration tests started failing with "signature unverifiable"
oh and pls wait for https://github.com/KILTprotocol/sdk-js/actions/runs/4223205084 to be merged and rebase/merge bc we're not actually testing ethereum linking rn |
Try again after merging fea185f. Seems broken to me tbh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice, let's merge this
…hainArgs` (#730) This makes it possible to use the high level associateAccountToChainArgs in most cases, but also use the building blocks in edge cases where parts are already done by other parts of the app (e.g. the wrapping of bytes). fixes [#2484](KILTprotocol/ticket#2484) --------- Co-authored-by: Antonio <[email protected]>
This makes it possible to use the high level associateAccountToChainArgs in most cases, but also use the building blocks in edge cases where parts are already done by other parts of the app (e.g. the wrapping of bytes). fixes [#2484](KILTprotocol/ticket#2484) --------- Co-authored-by: Antonio <[email protected]>
fixes #2484
This makes it possible to use the high level
associateAccountToChainArgs
in most cases, but also use the building blocks in edge cases where parts are already done by other parts of the app (e.g. the wrapping of bytes).Checklist: