-
Notifications
You must be signed in to change notification settings - Fork 212
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
Orch api factoring #9356
Orch api factoring #9356
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Considering we paired on this, I suspect you may also want a ✅ from @dtribble before merging
dfbc592
to
7d51e2f
Compare
Taking out of draft. There's one lint failure but it's on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's talk more before going to .ts for vat code.
export type * from './cosmos-api.js'; | ||
export type * from './exos/chainAccountKit.js'; | ||
export type * from './exos/icqConnectionKit.js'; | ||
export type * from './orchestration-api.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks circular. I can imaging that's not a ts error, but it seems unhelpful for thinking about things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a blocking request for the PR? I can untangle the circularity but I wouldn't want to do that until the API surface is agreed upon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a blocking request for the PR?
no.
I'm trying to understand the proposal.
* Chain. Some operations accept any member of the equivalence class to | ||
* effectively designate the corresponding token type on the target chain. | ||
*/ | ||
export type Denom = string; // ibc/... or uist |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This we would like to NOT be cosmos-specific.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have heard that Gravity has an encoding of eth etc. denoms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/PeggyJV/gravity-bridge/blob/main/module/x/gravity/types/ethereum.go
I think they use gravity/ethcontractadress
but that doesn't include the Chain ID. So we would want something more like eth/<chainId>/<contractAddress>
. The key is that it fits into the Denom formats, so we can just use Denom everywhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we might have better luck with an object here. You are right to call out that for ethereum (and solana) the important identifiers are contractAddress
and chainId
- denom
s do not come into play until someone decides to make a representation on an IBC chain.
Aside - other evm-interop chains do not follow the same baseDenom
pattern as gravity . On axelar they look something like: dai-wei
, dot-planck
, uusdc
, weth-wei
. And on kava: erc20/tether/usdt
. I think we'll want to preserve these values in the denom
name space, and use additional keys (contractAddress
, chainId
) to facilitate building messages for non-IBC chains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The general that we don't need to commit a particular, I don't think I would want an object for all of these, since we get a lot of them back that are well known in context. All those fit just fine in the model of string encoding. these are just arms that someone on their chain can decide to use. Everyone else uses indirect references to them.
packages/orchestration/src/types.ts
Outdated
}; | ||
cosmos: { info: CosmosChainInfo; methods: {} }; | ||
agoric: { | ||
info: Omit<CosmosChainInfo, 'ibcConnectionInfo'>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Omit is magic. What's this mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems more clear to construct types additively rather than with subtraction. So what is the name of the type that doesn't include those operations?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair. Agoric is one special case among Cosmos chains so I don't think it needs its own type alias, but I'll change it to Pick instead of Omit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use info so it looks like a localhost connection. Eventually it may be replaced with that implementation.
packages/orchestration/src/types.ts
Outdated
export type DenomArg = Brand | Denom; | ||
|
||
/** Amounts can be provided as pure data using denoms or as native Amounts */ | ||
export type AmountArg = CoinAmount | Amount; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Order of "agoric type | low level type" should match between DenomArg and AmountArg.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For usability, I expect the low-level type should be first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turadg and I walked through comments and agreed on the results. I consider it auto-approved after he makes those changes.
refactor(types): extract ethereum-api
refactor(types): Chain, OrchestrationAccount
to fix build order sensitivity
c2fedbc
to
952045a
Compare
no ticket ## Description Started as documentation for #9356 (comment) , then I carried out the new best practice so it would be consistent. That was a bit of a rabbit hole. It's in a better place, though I don't see it reflected obviously in the type coverage report. ### Security Considerations n/a, types ### Scaling Considerations n/a, types ### Documentation Considerations This documents the new beset practice ### Testing Considerations CI ### Upgrade Considerations n/a, types
closes: #9207
Description
Refactoring the API types and perhaps implementation to satsisfy:
Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Upgrade Considerations