Extract @comsmwasm/sdk about cosmjs HOT 12 CLOSED

Is that a correct understanding?

jap

a simple demo using @iov/keycontrol with @cosmwasm/sdk

Right. The way this could work in tests is making @iov/keycontrol a devDependency for @cosmwasm/sdk, but not a runtime dependency, like we do in @iov/bns.

I added an @cosmwasm/cli as a non-BCP application:

from cosmjs.

I created #31 and #32. Right now I can't think of smaller steps to break it down. Feel free to pick one if you have time.

from cosmjs.

Very nice diagram. A picture is worth 1000 words.

I assume the Codec would go into @cosmwasm/sdk as is. And then we would make a separate Connection that just exposed a much simpler interface, which is easier to write and maybe easier to understand for devs not familiar with @iov/bcp. @cosmwasm/bcp would then fulfill the @iov/bcp wallet-specific abstractions for reuse in other apps (faucet, wallet, extension), and (likely) support signing/decoding more tx types to fit in with the chrome extension. It doesn't need to have cosmwasm-specific queries.

Is that a correct understanding?

I also assume we would want a simple demo using @iov/keycontrol with @cosmwasm/sdk to drive a chain (this can be done in the cli with the proper imports, right?)

I like the idea. Let's just clarify a few details

from cosmjs.

Very nice decomposition.
Look forward to reviewing Monday.

Have a great weekend

from cosmjs.

I like this. Some thoughts on my side (spread over multiple comments, to make 👍 👎 easier)

RestClient is perfect inside sdk and keeps the arguments equal to the actual server on the other side (no abstraction here, just an adaptor). I will add some custom methods to support the wasm-specific queries #9 here. Just 1:1 with the rest server. Good?

from cosmjs.

Yes, good. Given yesterday's discussion about ticker symbols, I think we should just use raw Cosmos logic there and express values as quantity+denom, no fractional digits, no symbols.

I'd like to push all usage of amino-js down from @cosmwasm/bcp into @cosmwasm/sdk, where we can easier refactor it away.

Right now, a lot of encoding/decoding is still full of BCP types, so it might be a bit hard to extend the RestClient. But you'll see.

from cosmjs.

It seems important to move tx encoding/decoding here (sign bytes, etc). Basically the functionality in CosmWasmCodec (although we don't necesarilly need the class, it can exist in bcp and just call into the functions exported by sdk. I think the following belong in sdk: bytesToSign, bytesToPost, identifier and parseBytes. However, not working with the bcp abstractions, but rather with tx types defined in the sdk.

Which leads me to the point of the tx/msg format used in the sdk. I think this should be the amino json representation (or as close to it as possible). We can define a union type for all supported msgs (send and the various wasm ones), and allow the full amino.StdTx with an array of messages. This is a superset of what bcp allows, so bcp can always create tx with exactly one message (and fail on parsing multiple messages), but allow the sdk to send Tx with multiple messages - there are a number of useful workflows than can take advantage of that.

from cosmjs.

Yes, good. Given yesterday's discussion about ticker symbols, I think we should just use raw Cosmos logic there and express values as quantity+denom, no fractional digits, no symbols.

Okay, I was also thinking how we could auto-gen a skeleton of this TokenTicker map and then just require overrides from the user. Basically, query supply for a list of all denoms on the chain. Then if the denom starts with u, define ticker=uppercase(denom[1:]) and fractionalDigits=6. Otherwise, ticker=uppercase(denom) and fractionalDigits=0. These are reasonable guesses, but we should allow user input of TokenInfo to override the auto-gen (for example my nanostep token with 9 digits or ukulele token that is not "micro-KULELE").

But, I agree, that can go into bcp level. And that is just helper logic to be added later (to allow simpler config)

from cosmjs.

I'd like to push all usage of amino-js down from @cosmwasm/bcp into @cosmwasm/sdk, where we can easier refactor it away.

I agree completely. I want to remove amino-js as well, as it doesn't extend beyond hub, but it is useful for now. What I would like to keep is all the interface definitions, which we can use the same.

We could create src/amino.ts inside sdk with all the interfaces from amino-js, correct? Then we just left with marshal and unmarshal from the library, which I would replace with calls to the rest server. They are busy working on pulling out amino from the sdk and replacing it with protobuf, so mid-term (eg in 3 months), we can just use protobuf type encoding in the client, and not need either the rest server nor amino-js for that. But until then, I don't want to get suck into the amino implementation and take the lazy way of delegating it to the rest server (which was the "interim solution" I suggested May 2017... teaches me to ever offer a temporary solution to any problem)

from cosmjs.

Question: @webmaster128

The initial config is super useful, now is a question of porting more functionality. After getting your feedback on the above points, I think we will both have a shared view of the path forward here.

My question is do you want to work on the porting or should I? I am happy to do so with your reviews, but I won't have much time til tomorrow.

from cosmjs.

@cosmwasm/sdk is looking pretty much more complete these days.

Are there any other points you would add in here?

What I can think of is handling parsing the Bech32PubKey type into the other json PubKey type, and defining proper PubKey options (in bcp now -> move to sdk). (Basically all of address.ts)

Otherwise, maybe some logic from Connection could be pushed down one level. Other than these, they all seem to be about translating the raw cosmos messages with bcp ones. CosmWasmConnection.:

• identifier
• getFeeQuote

Also, some proper subscriptions (on account, header, txid). This could close two unimplemented errors and make postTx a bit cleaner

from cosmjs.

#44 is a nice addition to this ticket. The rest I'd sort on demand based on higher level goals. Closing this for now as the main point is done.

from cosmjs.