CW2: adding supported interfaces value about cw-plus HOT 7 OPEN

@uint I would love to hear you opinions here as well

If we want contracts to self-describe their interfaces and we're trying to make things modular with Sylvia, it makes total sense IMO to be able to reason which common interfaces (cw20 etc) they implement.

The cool thing is Sylvia might be able to autogenerate these in the future and it'd fit right into its model.

from cw-plus.

It goes and tries to deserialize contract_info with a deserializer that fails on unknown fields, and bam.

Since we don't use #[deny_unknown_fields] here afaik, I think this is safe if it is an extra Option<Vec<String>> field to give proper backwards compatibility.

We could also add another cw22 spec or something to just store this info in a different storage key.

I am fine with both solutions and pretty far from the code to see if there is a better one. I will defer to @uint on that point.

Idea: Another option is to extend cw2 to define 2 keys and helpers - get_version / set_version as well as get_interfaces / set_interfaces. Using the same spec (logical consistency) and separate storage key (ultimate backwards compatibility) may get us the best of both worlds.

from cw-plus.

Interesting idea.
it will have to be optional, as it will not exist for all currently deployed contracts but does seem like a nice hint.

We also discussed adding source code link, repeatable compilation Metadata, etc in a wasmd issue. This falls into that general category for me.

@uint I would love to hear you opinions here as well

from cw-plus.

Yes, it is optional. We have opened a pull request on it.

For source code link, binaries, etc. I think the block explorer should be the place to submit those information (like Etherscan did). I think they are just informative data while the supported interface value is quite helpful in interacting with other program.

We have built a small utility on our explorer for general information of a wasm contract here: https://github.com/aura-nw/contract-source-code-verifier.

from cw-plus.

So what is the general consensus on this ? @uint @ethanfrey

Should we modify the current cw2 interface or we make a new cw2-support-interface crate ?

from cw-plus.

Should we modify the current cw2 interface or we make a new cw2-support-interface crate ?

I worry about one scenario. Say there's an old client somewhere that doesn't know about this new supported_interface field. It goes and tries to deserialize contract_info with a deserializer that fails on unknown fields, and bam. It can't get the name/version of newer contracts because it doesn't know how to deal with some unrelated data.

I think I'd prefer if this was a separate spec with a separate storage item. @ethanfrey? is this a non-issue?

from cw-plus.

Since we don't use #[deny_unknown_fields] here afaik, I think this is safe if it is an extra Option<Vec> field to give proper backwards compatibility.

Okay, in that case I'm also fine with either. Let's get this in!

from cw-plus.