client interface standardisation with cosmos-sdk #14
Comments
|
The intention of the Cosmos SDK proto files is to provide a common set of client facing interfaces which can be used by different chains and modules: https://github.com/cosmos/cosmos-sdk/tree/master/proto. Everything is structured around protobuf service definitions which could allow for dynamic service discovery of supported interfaces. Is that helpful? We could eventually store these proto files in a separate schema repository or maybe have dedicated schema registry. |
|
I think having a language-agnostic message/service format has been a big step for opening up client side possibilities. I was not aware of so many server side projects looking to plug into cosmos, but if they actually want to be considered part of the cosmos ecosystem, it would make sense to try to expose a similar interface. That is, for all functionality which overlaps with the cosmos-sdk, implement the same public services (or a backwards-compatible superset), so client libs/apps that work with the cosmos-sdk modules will work with this chain as well. Bank and auth are the most obvious examples that are pretty universal. This requires using the same tx format and signing mode (which seems a safe bet) and supporting 1-2 message types and a few queries. I'm sure an adaptor could be made into whatever internal representation is being used. And if the framework's representation/capabilities are so much more advanced, they should consider feeding back those ideas into the cosmos-sdk to improve the interface. All frameworks that support ibc will need to implement the spec, which constrains the data types used here, and they will need quite a bit of overlap with these cosmos-sdk proto types in any case. Having auth, bank, ibc, and ics20 providing the same interface (and same tx format) would be a great boon for relayers to be able to just plug into a chain with this new framework and give immediate liquidity without having to build out all that infrastructure as well. I would not see this as an immediate action item for other frameworks, but a good avenue to investigate and then to help shape some "1.0" cosmos-sdk protobuf definitions that would support. Right now, we are still building out robust client side support on these types which may give quicker feedback. |
|
@aaronc definitely not an immediate need, but if there was support for standardisation, creating a multi-stakeholder repo for proto files and related documentation makes a lot of sense. |
|
I personally felt the pain on not having this when writing kepler and trying to keep it close to the cosmos-sdk. I don't know how it is now, but at that time I think the cosmos-sdk used json for its message/storage types which made it even more of a manual process. Even assembling the protobuf files required to just run the ABCI server was a pretty manual process at that time because of the way haskell protobuf libraries work. A central repository would be nice, but even a central directory in each repository with the complete set of files relevant to that repo would already be enough imo. Kepler doesn't have a large module set at this time, but we already kind of do what you're talking about for standardizing transaction format, storage types, and message types: https://github.com/f-o-a-m/kepler/tree/master/hs-abci-sdk/protos |
Paraphrasing @ethanfrey:
This represents more than a cosmos-rust issue, rather it's a question about whether frameworks ecosystem-wide can or want to standardise around a minimal set of internal representations, like
bank, such that they can expose common interfaces to client applications.This may be relevant to projects like Agoric, Kepler, CosmosSwift, and other frameworks that could benefit from cosmjs, alan dart, or other client library support, as well as direct integrations with wallets, block explorers, etc.
cc: @mappum @keppel @blinky3713 @michaelfig @ratranqu @aaronc @webmaster128 @okwme @RiccardoM
The text was updated successfully, but these errors were encountered: