Closed ethanfrey closed 3 years ago
pub pinned: bool,
Is stored in a second index and available
pub ibc_port: Option<String>,
Is in the IBC queries already
pub created: AbsoluteTxPosition,
We are not exposing AbsoluteTxPosition to clients and should not do it here as well, IMHO
pub extension: Option<Any>,
I am not sure if we should support this. The extension would be chain agnostic and has impact on contract portability. It could lead to tight coupling with the persistence object. Custom queries may a be a cleaner way to get the information (when supported) and contracts won't have to deal with protobuf.
Taking in Alex's feedback, maybe we end up with:
pub struct ContractInfoResponse {
pub code_id: u64,
pub creator: String,
pub admin: Option<String>,
pub pinned: bool,
/// block this was created at
pub created_height: u64,
pub ibc_port: Option<String>,
}
I looked up the IBC query and it only returns the PortID for the current contract. Not for another contract. Not sure if this would be useful until loopback ibc connections are fully enabled (they exist in theory), but may already be interesting as None/Some(_) info. eg. "a token contract that doesn't want to be passed over IBC and thus disallows transferring tokens to any address with ibc_port set"
This is based on ideas from https://github.com/CosmWasm/wasmd/issues/584 which have come up in Discord several times from a number of different groups. Basically, people want to:
We may also want to allow to see if the contract (actually the linked code_id) is pinned per https://github.com/CosmWasm/wasmd/issues/596
We can model it on the existing grpc client response, particularly the ContractInfo type.
Query:
Response:
I would love feedback from @alpe and @webmaster128 on the API design here. It is a non-breaking addition to the API, and quite useful functionality. We should just review what data and in what format.