Consider using in-house frameworks

[Slesarew]

We have all the good things:

• https://github.com/Alzymologist/substrate-constructor to make transactions from metadata
• https://github.com/Alzymologist/mnemonic-external and https://github.com/Alzymologist/substrate-crypto-light to derive keys and sign (these are also actually better zeroized)
• https://github.com/Alzymologist/substrate-parser to parse blocks and storage

All you need to do is add rpc bridge and possibly a smoldot and you'll have all client daemon functionality without nasty sp deps (except for a few really lean and clean ones) and wasm things, plus proper no-std.

Example how to quickly and dirtily slap everything together is Lempi except for blocks parsing that is documented in substrate-parser

[fluiderson]

subxt is still more mature, complete & customizable IMO. The dependencies amount is huge but this is because I used all-included features to implement things faster. In the future, when we will know what we absolutely need & what we don't, we can significantly reduce total dependencies number by replacing heavy on dependencies parts with our own implementations (even with some of our frameworks) for corresponding traits. There's also an ongoing work to make subxt usable in #[no_std] environments and add the light client backend, which we may integrate without changing too much.

[Slesarew]

Just keep this possibility in mind, we'll reduce maintenance overheads a lot this way.

Signing tools must be changes, sp implementations are just bad for shared memory space which is most probably the case for this daemon (unlike nodes for which those implementations were made). We've had a careful look at them recently and it's just disturbing.