Macro system for standardizing wasm attribute emission/parsing

[0xForerunner]

So I was recently banging my head against the wall trying to parse wasm attributes and I came up with an idea for making this process painless and convenient. It looks something like this right now but I'd be open to suggestions.

#[derive(Attrs)]
#[cw_serde]
pub enum ExecuteMsg {
    #[attrs = "HelloAttrs"]
    Hello{},
    #[attrs = "WorldAttrs"]
    World{}
}

#[derive(MsgAttr)]
pub struct HelloAttrs {
    /// The action field should be mandatory and unique so parsing 
    /// any message can be fully automated. Perhaps the action field shouldn't even be part of the struct
    /// and just assumed to be present in the attributes.
    action: String, 
    sender: Addr // <-- fields must be `Serialize + Deserialize`
}

MsgAttr derives From<Vec<Attribute>> and Into<Vec<Attribute>> to make parsing extremely easy, and

Then in the smart contract we can have

let res = Response::new().with_attributes(HelloAttrs{
    action: "hello".to_string(),
    sender: "foo bar baz".to_string()
});

The Attrs macro the creates a new enum that looks like this:

pub enum ExecuteMsgAttrs {
    Hello(HelloAttrs),
    World(WorldAttrs),
}

and we can access to a parsing function like this:

pub fn parse_attrs(attrs: Vec<Attribute>) -> Option<ExecuteMsgAttrs>

This could be made a little more robust by including wasm events as well but I haven't really thought that far ahead. Let me know what you think!

[webmaster128]

I have a similar problem/use case but only for the attribute emission part. Here the focus is to ensure stability for clients and avoid to easily break them because keys change.

But what's not so clear to me is the parsing. I assume you are referring to SubMsgResponse right? Is event parsing working well for you there? I guess it would be kindof unreliable because events can change with different versions of the host, we do some filtering in wasmd and events are not even covered by consensus. So the question is here, should event parsing be embraced at all and if yes, under which constions.

Happy for any thoughts or use case descriptions. See also #1995

[0xForerunner]

But what's not so clear to me is the parsing. I assume you are referring to SubMsgResponse right? Is event parsing working well for you there? I guess it would be kindof unreliable because events can change with different versions of the host, we do some filtering in wasmd and events are not even covered by consensus. So the question is here, should event parsing be embraced at all and if yes, under which constions.

Ah sorry I wasn't clear. No, for my use case I would be parsing wasm events within a bot off chain. It's basically just a convenience feature for easily reconstructing these attributes.

#[derive(MsgAttr)] Would derive some trait like From<Vec<Attribute>> or something like that which could be used for parsing off chain.

[webmaster128]

Interesting, yeah that sounds more solid to me.

Do you already have that approach implemented somewhere? Is it working well? Or do you strictly need cosmwasm-std support here? I wonder if this is more a best practice question or in scope of cosmwasm-std.

[0xForerunner]

Do you already have that approach implemented somewhere? Is it working well? Or do you strictly need cosmwasm-std support here? I wonder if this is more a best practice question or in scope of cosmwasm-std.

I've posted this here because in my dream world, all smart contracts would use #[derive(Attrs)] (Or it would be included in #[cw_serde]). This would make parsing attributes off chain a dream and indexing protocols extremely easy. It also comes with the benefits that you mentioned above, standardizing attribute emission.

I currently have a prototype of this working, and if you're interested in including it I'd be happy to chat with you about what the api should look like, polish it up, and contribute.

[webmaster128]

Right, but just like cw2 it can become something well established in the ecosystem but not necessarily in the standard library. cosmwasm-std is the slowest area in which we can innovate due to the extreme care required to ensure compiled contracts keep working.

[0xForerunner]

Right, but just like cw2 it can become something well established in the ecosystem but not necessarily in the standard library. cosmwasm-std is the slowest area in which we can innovate due to the extreme care required to ensure compiled contracts keep working.

Yeah I totally get that! This derive wouldn't include any breaking changes so no need to worry about that. But I totally understand being hesitant to include changes like that. Ultimately your call, but I do think it would fit in nicely here ;)

[chipshort]

We should think about how to handle this with the new schema #2206