Add subxt_signer crate for native & WASM compatible signing#1016
Add subxt_signer crate for native & WASM compatible signing#1016
subxt_signer crate for native & WASM compatible signing#1016Conversation
tadeohepperle
left a comment
tadeohepperle
left a comment
There was a problem hiding this comment.
Looks good to me, good work! :)
| //! need additional signing algorithms that `subxt_signer` doesn't support, and don't care about WASM | ||
| //! compatibility. | ||
| //! | ||
| //! Let's see how to use each of these approaches: |
There was a problem hiding this comment.
Good explanation, avoids confusion for users!
| all(feature = "web", feature = "native"), | ||
| not(any(feature = "web", feature = "native")) | ||
| ))] | ||
| compile_error!("subxt: exactly one of the 'web' and 'native' features should be used."); |
There was a problem hiding this comment.
This is a smart way to handle mutually exclusive features! Haven't seen that yet.
There was a problem hiding this comment.
the smart way is not to have mutually exclusive features :)
it's a PITA to deal with but we have no better option here.
There was a problem hiding this comment.
Doesn't really have to be addressed in this PR but would be great if we could have APIs similar to this to avoid having to deal with "mutually exclusive features`
but ofc it won't work for if something doesn't work for WASM.
There was a problem hiding this comment.
the smart way is not to have mutually exclusive features :)
Yeah, ideally the features would be purely additive in general!
Probably I need to keep thinking about feature flags here, and also which flags are enabled by default (it's annoying re doc examples etc if you don't have feature flags enabled that you want to use but might be surmountable).
When I did this I figured that a non additive "native or web" feature and then everything else being additive (in terms of APIs exposed at least) felt like the nicest way to handle it (otherwise you end up with the non-additiveness being pushed to other features anyway like jsonrpsee-web and jsonrpsee-native, or lightclient-web and lightclient-native not playing well together).
Def open to more thoughts on all of this though!
| use super::*; | ||
| use std::str::FromStr; | ||
|
|
||
| once_static_cloned! { |
| /// assert_eq!("0xe5be9a5092b81bca64be81d212e7f2f9eba183bb7a90954f7b76361f6edb5c0a", suri.phrase.expose_secret()); | ||
| /// assert!(suri.password.is_none()); | ||
| /// ``` | ||
| pub struct SecretUri { |
There was a problem hiding this comment.
you could maybe state that this code is extracted from substrate or something
I'm a little scared of it to be honest but looks identical to SecretUri in substrate...
There was a problem hiding this comment.
Yeah; in the mod.rs of the crypto folder I say that everything in the crypto folder comes from sp_core::crypto :) (though with tiny tweaks or doc comment updates).
I didn't like bringing it in particularly either but it is just a straight copy of the logic! Probably I could test this in isolation better too to prove it aligns.
There was a problem hiding this comment.
I added a note at the top of each file too to say it was taken from sp_core, and tweaked one of the tests to check more paths
| # Enable this to pull in extra Substrate dependencies which make it possible to | ||
| # use the `sp_core::crypto::Pair` Signer implementation, as well as adding some | ||
| # `From` impls for types like `AccountId32`. Cannot be used with "web". | ||
| substrate-compat = [ |
There was a problem hiding this comment.
so, features = ["jsonrpsee", "native"] should make it work but not bring in sp-core and all these deps, correct?
This will be great
There was a problem hiding this comment.
Yup exactly :)
The only reason I left substrate_compat in the default deps iirc was so that doc examples (well, one doc example iirc, and maybe a couple of tests or something) would work. Probably need one more go-over on these features to sort out niggles like that because would be nicer not to have it by default at all!
niklasad1
left a comment
niklasad1
left a comment
There was a problem hiding this comment.
very excited about this one, but I have a few questions :)
5 participants
The
subxt-signercrate replaces the need to usesp_core::sr25519::Pairfor sr25519 signing of transactions (which is something we allow via thesubstrate-compatfeature flag.Reasons to use
subxt_signeroversp_core::sr25519::Pairsp_coredeps.This crate can be used independently of
subxtby disabling thesubxtfeature flag, in case you'd like to use it to sign things independently of Subxt.I also rejigged the feature flags a bit with this in mind. Subxt now has these main feature flags:
jsonrpsee. Works with either of "native" or "web"