Add parsing for signed payload #63
Conversation
|
I'm working with my employer to sign the CLA. It might take a while. |
elliot-u410
force-pushed
the
noch3/signed-payload
branch
from
db8a92d
to
98f5bdb
Compare
| let address = <MultiAddress<AccountId32, u32>>::decode(data)?; | ||
| let signature = MultiSignature::decode(data)?; | ||
| let extensions = metadata | ||
| fn decode_call_data<'data, 'meta>( |
There was a problem hiding this comment.
I'm wondering if all of these sub-parsers should also be pub since they could be quite useful in non-standard scenarios.
There was a problem hiding this comment.
I've been hesitant to make too many things pub at the moment becaue this V14 crate is still fairly heavily WIP, so I've been learning towards avoiding exposing too many things from the start and making it a little harder to keep hacking on as we go forwards without breaking APIs.
w.r.t the parsing, I'd sortof have assumed that the top level parser + scale_info would be enough (given some type and some bytes, you'll get a decoded Value back), but I'd be interested to hear about any cases where the sub parsers were useful on their own!
There was a problem hiding this comment.
In my experience, instead of being afraid to break APIs, you can just put anything that isn't really stable inside of a unstable module. That way people (like me) who are ok depending on unstable features can do so without patching your library. Anyone who cares about that can avoid the module. This, to me, is the best of both worlds.
There was a problem hiding this comment.
The problem with the top-level parsers is that you can't compose them yourself. If I have call-data inside of a larger blob, it's harder to use your parser (although I can pull it out of the LateEof error in this case). But, for example, I had to manually write decode_call_data here because I couldn't compose that with the other parsers. If I had access to that directly I may not have patched this library (although you could argue it was a good thing that the patch got upstreamed).
|
Thank you! It might take me a few days to get to looking at this, but it looks like something worth wrapping my head around :) |
The SignedPayload (or SignerPayload, as it's called in polkadot-js) is just |
|
Ah, I understand! Basically, you'd like to expose the ability to decode the payload that would then be signed; got it! I had a chat with @insipx and I think we're arriving at a decision on an API for this, so if it's OK with you @Noch3, I'll push a couple of commits to this PR tommorow (most likely) to shuffle a couple of bits around and keep the API consistent and such, but I'll keep the functionality you've added here, so you'll be able to decode the pre-signed payloads :) |
|
If these commits are blocked by the CLA, you may not want to build on them directly. |
Have you signed CLA or is it just not working? |
|
|
If you want to reimplement this on your own I won't be even slightly offended. Just so long as I can use it. :D |
|
I've opened #66 as my attempt to take this code, plus the request for more information form your previous PR, and mash them together into something, and would like to get your feedback on it :) |
|
Closing in favor of #66 |
Looking for initial thoughts.