Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client interface standardisation with cosmos-sdk #14

Open
hxrts opened this issue Dec 16, 2020 · 5 comments
Open

client interface standardisation with cosmos-sdk #14

hxrts opened this issue Dec 16, 2020 · 5 comments
Labels
question Further information is requested

Comments

@hxrts
Copy link
Contributor

hxrts commented Dec 16, 2020

Paraphrasing @ethanfrey:

If Orga supported the Cosmos-SDK's Bank data structure and message interface it could get wallet support out of the box.

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

@hxrts hxrts added the question Further information is requested label Dec 16, 2020
@aaronc
Copy link
Member

aaronc commented Dec 16, 2020

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.

@ethanfrey
Copy link

ethanfrey commented Dec 16, 2020

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.

@hxrts
Copy link
Contributor Author

hxrts commented Dec 17, 2020

@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.

@martyall
Copy link

martyall commented Dec 18, 2020

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

@hxrts
Copy link
Contributor Author

hxrts commented Jun 3, 2021

https://github.com/forbole/cosmos-rust-wallet

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants