Add function to create a SignedMessage without using types from sp-core version 6

[ameba23]

Due to #15 we cannot use the encrypt_and_sign function from environments using sp-core / subxt-signer, so we need to use SignedMessage directly as we do in entropy-core.

This crate depends on sp-core version 6, as new versions don't compile to wasm. Since SignedMessage::new has two arguments with types from sp-core this is inconvenient to use from crates which depend on a newer version of sp-core.

This PR adds an extra constructor which takes a 32 byte seed and generates a keypair from it internally, meaning the Pair type doesn't need to be given as an argument.

This is a hacky fix. In the long term i would like to switch this crate to using subxt-signer but that will be a breaking change and until then i would like to do it this way.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
x25519-chacha20poly1305	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Nov 20, 2023 7:50am

[ameba23]

For context, this is where this new function is called from the test client i am playing around with, and we could do the same in server if we wanted to use this crate there instead of repeating the SignedMessage code.

https://github.com/entropyxyz/entropy-core/blob/adcea5200884a5a2cdd2e73c80668937a5124ecb/crypto/testing-utils/src/test_client/mod.rs#L145

[HCastano]

This crate depends on sp-core version 6, as new versions don't compile to wasm. Since SignedMessage::new has two arguments with types from sp-core this is inconvenient to use from crates which depend on a newer version of sp-core.

Hmm, that version of sp-core is quite old - like almost 2 years old. I'd expect newer versions to compile to Wasm without any issues either. If we can upgrade, is this PR still needed?

This PR adds an extra constructor which takes a 32 byte seed and generates a keypair from it internally, meaning the Pair type doesn't need to be given as an argument.

I guess not being tied to sp-core could be useful functionality to have, but if we can just bump the dep I'd rather that

[ameba23]

This crate depends on sp-core version 6, as new versions don't compile to wasm. Since SignedMessage::new has two arguments with types from sp-core this is inconvenient to use from crates which depend on a newer version of sp-core.

Hmm, that version of sp-core is quite old - like almost 2 years old. I'd expect newer versions to compile to Wasm without any issues either. If we can upgrade, is this PR still needed?

If we can get sp-core 21 with the features needed to do sr25119 signing to work on wasm, this would definately not be needed and nor would a lot of the extra code and workarounds in entropy-protocol (which uses subxt-signer). We could also fix this issue: entropyxyz/entropy-core#440

But in my understanding subxt-signer was created for exactly this reason - that the newer versions of sp-core no longer have an sr25519 implementation that works on wasm (if i remember rightly the crate itself will compile but not with the needed features).

[HCastano]

But in my understanding subxt-signer was created for exactly this reason - that the newer versions of sp-core no longer have an sr25519 implementation that works on wasm (if i remember rightly the crate itself will compile but not with the needed features).

There is the full-crypto feature which compiles to no_std, but it doesn't say anything about necessarily working in a Wasm context. I guess we could try that out and if it doesn't work then we can merge this PR and switch to subxt-signer later.

[HCastano]

Suggested change

	recip: &PublicKey,
	recipient: &PublicKey,

[ameba23]

But in my understanding subxt-signer was created for exactly this reason - that the newer versions of sp-core no longer have an sr25519 implementation that works on wasm (if i remember rightly the crate itself will compile but not with the needed features).

There is the full-crypto feature which compiles to no_std, but it doesn't say anything about necessarily working in a Wasm context. I guess we could try that out and if it doesn't work then we can merge this PR and switch to subxt-signer later.

You are right, thanks!

I am closing this in favor of #19