proto: allow more information in ValueView #3800
Conversation
This attempts to make the ValueView more useful for frontends, and prevent frontend code from having to invent its own handling of numeraires. Here, we make two extensions to the ValueView: 1. Allow adding a list of "equivalent values" in different numeraires. We want to have support for multiple equivalent values because it may be useful to relate the viewed value to multiple different assets. For instance, a delegation token has at least two relevant numeraires: how many staking tokens it represents (using the per-validator exchange rate) and what its cash value is (in, say, USDC). 2. Allow adding arbitrary extended data using an `Any`. This could be used to insert a `component.dex.Position` with the complete position state into the `ValueView` of an LPNFT, allowing frontend code that has knowledge of LPNFTs to show a rendering of the position's current reserves, price, etc. Using an `Any` provides extensibility and graceful degradation. These extensions are not added to the Rust domain types yet, since they're intended for the web context.
hdevalence
temporarily deployed
to
smoke-test
GitHub Actions
Inactive
| // with their position information (trading pair, etc). However, because | ||
| // this is in an extension, a frontend that does not have special handling | ||
| // logic would fall back on the ordinary asset metadata. | ||
| google.protobuf.Any extended_metadata = 4; |
There was a problem hiding this comment.
Would it not be better to have a oneof that we add to when we have more needs? Or does having it strongly typed like this make it not forward compatible?
There was a problem hiding this comment.
Having a oneof means we need to write out the types explicitly, and because the ValueView is in a "base" proto depended on by other packages, this causes problems — we can't import the dex proto package, because it depends on this one, for instance.
Using Any allows runtime type checking and extensibility to any kind of metadata.
| repeated EquivalentValue equivalent_values = 3; | ||
| message EquivalentValue { | ||
| // The equivalent amount of the parent Value in terms of the numeraire. | ||
| core.num.v1.Amount equivalent_amount = 1; | ||
| // Metadata describing the numeraire. | ||
| Metadata numeraire = 2; | ||
| } |
There was a problem hiding this comment.
Does this mean:
A) every item in this list is equal to the original (aka many options)
or
B) when summed, the list in total is equal in value to the original (aka parts of a whole)
It appears that it's option A, however, in the case of an LP NFT, option B is more helpful in communicating the equivalent value
There was a problem hiding this comment.
It means (A).
For the LPNFT case, we probably don't just want to have reserves but also information about the position state, price, etc. So rather than try to shoehorn that into a "price" mechanism I think it's better to put the Position state into an Any.
|
closes #3795 |
This attempts to make the ValueView more useful for frontends, and prevent frontend code from having to invent its own handling of numeraires. Here, we make two extensions to the ValueView:
Allow adding a list of "equivalent values" in different numeraires. We want to have support for multiple equivalent values because it may be useful to relate the viewed value to multiple different assets. For instance, a delegation token has at least two relevant numeraires: how many staking tokens it represents (using the per-validator exchange rate) and what its cash value is (in, say, USDC).
Allow adding arbitrary extended data using an
Any. This could be used to insert acomponent.dex.Positionwith the complete position state into theValueViewof an LPNFT, allowing frontend code that has knowledge of LPNFTs to show a rendering of the position's current reserves, price, etc. Using anAnyprovides extensibility and graceful degradation.These extensions are not added to the Rust domain types yet, since they're intended for the web context.