You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we use a manual process to generate an encoder mega-object (for protobuf messages that get passed to a keplr-wallet client to be signed and forwarded to the extension (via sendMsgs function). (See #1004 for updating to v13). Every time there is an interface change on chain-side, we need to use the zipped utility in #1004 to generate the encoder. Additionally, the keplr-wallet sendMsgs function requires that we manually compose an amino message in addition to the product of the encoder mega-object that is generated from protobufs. This manual process is error-prone. Last I checked, legacy amino messages are currently necessary for signing with ledger.
Proposed Solution
We should use the tool developed by @pyramation, to make supporting future versions of Osmosis chain a faster and less error-prone process. However, we're currently blocked on having telescope cherry-pick only the messages (from Cosmos SDK and Osmosis) that we need in the frontend, as the generated signer and queryer is quite large and would causes large bundles and thus slower initial load times, despite it's cacheablity). Additionally, since telescope generates the signing client, we can use this issue to start work on creating a proper account abstraction so that we can support wallets besides Keplr (like Leap), and reduce our dependence on keplr-wallet packages (which generate large bundles as well). This would involve creating an account interface that matches the current keplr account, and the ability to switch between implementations of that account in the new account store. Complexity may arise around handling mobile Keplr, and WalletConnect; these may need to be separate implementations of the account interface, or a dynamic Keplr interface implementation.
Add cherry-picked telescope client product
Create new account abstraction to support arbitrary number of wallet abstractions.
The text was updated successfully, but these errors were encountered:
Problem
Currently, we use a manual process to generate an encoder mega-object (for protobuf messages that get passed to a keplr-wallet client to be signed and forwarded to the extension (via
sendMsgs
function). (See #1004 for updating to v13). Every time there is an interface change on chain-side, we need to use the zipped utility in #1004 to generate the encoder. Additionally, the keplr-walletsendMsgs
function requires that we manually compose an amino message in addition to the product of the encoder mega-object that is generated from protobufs. This manual process is error-prone. Last I checked, legacy amino messages are currently necessary for signing with ledger.Proposed Solution
We should use the tool developed by @pyramation, to make supporting future versions of Osmosis chain a faster and less error-prone process. However, we're currently blocked on having telescope cherry-pick only the messages (from Cosmos SDK and Osmosis) that we need in the frontend, as the generated signer and queryer is quite large and would causes large bundles and thus slower initial load times, despite it's cacheablity). Additionally, since telescope generates the signing client, we can use this issue to start work on creating a proper account abstraction so that we can support wallets besides Keplr (like Leap), and reduce our dependence on keplr-wallet packages (which generate large bundles as well). This would involve creating an account interface that matches the current keplr account, and the ability to switch between implementations of that account in the new account store. Complexity may arise around handling mobile Keplr, and WalletConnect; these may need to be separate implementations of the account interface, or a dynamic Keplr interface implementation.
The text was updated successfully, but these errors were encountered: