-
Notifications
You must be signed in to change notification settings - Fork 170
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
Implement Message Signing WASM #281
Implement Message Signing WASM #281
Conversation
ee4dbbf
to
debc147
Compare
I think signMessage should be on private key class? |
fb4f893
to
cd6488d
Compare
@coderofstuff Before moving forward with merging this PR, I wanted to discuss/suggest perhaps converting these functions to receive not multiple arguments but a single For example, the following function receives arguments via an object: https://github.com/kaspanet/rusty-kaspa/blob/master/wallet/core/src/wasm/utxo/context.rs#L114-L128 This allows us to "future proof" these functions, allowing them to, in the future, if the need arises, to receive different types of arguments, without having to change function signatures. For example, if in the future, we want to add other types of signatures (as discussed during our KIP-005 debate) the function can decide what type of signature is to be used by examining the supplied object data... Arguments would need to be documented in the rustdoc section for each function. -- One more note - if one wants to document types on JS side, instead of receiving a JsValue, the function can receive a custom data type which is declared as JS type on the Rust side (example: https://github.com/kaspanet/rusty-kaspa/blob/master/wallet/core/src/wasm/tx/generator/generator.rs#L22) The only reason this is done is that all type documentation propagated to TypeScript, so when using such type in TypeScript/JavaScript, the user immediately gets full inline documentation of the data type in question. This is not currently used in many places but the long-term goal is to convert the majority of API calls to use custom types in such manner. This last part is not really needed at this point, just letting you know that this can be done. |
There have been a number of side discussions to support other types of signatures in the future, such approach allows us to extend these fns in the future. However, affixing these functions to ProvateKey plays against that (for example, in the future such function may accept a PrivateKey parameter or a wallet Account parameter). So I prefer to keep these functions disassociated from any specific data types (classes). |
e817dbf
to
041a15b
Compare
041a15b
to
038ccb8
Compare
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.
Looks great. Merging.
* Implement Message Signing WASM * Simplify getting structs from JsValue * Update sign/verify to use single object input * Result handling optimizations --------- Co-authored-by: aspect <[email protected]>
New JS functions:
signMessage(message, privkey)
- privkey can be a hex string orPrivateKey
objectverifyMessage(message, signature, pubkey)
- pubkey can be a hex string orPublicKey
object