cosmology-tech / cosmos-kit Goto Github PK

some wallets, like trust, want to manage their own endpoints. We should provide a way for them to broadcast the messages after we sign w the provider offlineSigner.

https://github.com/trustwallet/trust-web3-provider/blob/12b20e3fd995394e456f6b7fa0b5d37e7d381ea8/src/cosmos_provider.js#L95-L104

https://github.com/trustwallet/trust-web3-provider/blob/master/src/cosmjs_adapter.js

you can request offline signer from window.trustwallet
https://github.com/trustwallet/trust-web3-provider/blob/12b20e3fd995394e456f6b7fa0b5d37e7d381ea8/src/cosmos_provider.js#L48-L58

Seems that most cosmos-kit published packages is using the convention to split CommonJS and ESM sources to separate directories (https://unpkg.com/browse/@cosmos-kit/[email protected]/). This results in poor source typings since the path for those typings are in a different directory.

Example edge case related to #106, while import { SimpleConnectModal } from "@cosmos-kit/react/main/modal/components" does exist, TypeScript does not detect types because @cosmos-kit/react/main/modal/components types are on a different directory at @cosmos-kit/react/types/modal/components. The hacky solution is to override module declaration like below:

Proposed solution for this issue is to use .mjs extension for ESM sources and merge into single directory, similar to what graz does: https://unpkg.com/browse/[email protected]/dist/

on this page:
https://docs.cosmoskit.com/use-chain

at the bottom, the examples section links are broken:

🚀 fetch address
🚀 fetch balance & send tokens
🚀 vote

This is the error users are experiencing:

It looks like one has to do a bit of special handling when using keplr, ledger live devices

Related Issue:
BitCannaGlobal/web-wallet#4

I know this might sound controversial, but I actually want to be able to import keplr mobile/extension separately because wallet connect brings in a ton of stuff that has awful commonjs modules that need pre-transpiling for non-react/next projects. I also don't necessarily want a WS ping/ack added for simply adding a keplr query provider.

See this line specifically: https://github.com/cosmology-tech/cosmos-kit/blob/main/packages/keplr/src/keplr.ts#L9

SO!
I am proposing that they get split into 2 packages, so it can be independently added.
I realize this is a breaking change for some projects, but I believe for future work, this pattern of context splitting for any provider (cosmostation, leap, you name it) is necessary for more granular inclusion.

Thoughts?
If there's a way to disable keplr wallet already - would love to know :)

related

• CosmWasm/ts-codegen#77
• CosmWasm/ts-codegen#84
• cosmology-tech/telescope#276

I have a navbar where a profile image will show if the user is connected.

If they are not connected it will show a connect button instead.

Current when they click connect it will show the wallet dialog and let them connect to a wallet. Once connected the connect button will hide and the profile image will show instead.

When the user clicks the profile image, they will get a drop down with some information. One of the items in the dropdown is a disconnect button. When the user clicks it, the profile picture should become hidden and the connect button should show again.

When initially clicking the connect button, the wallet dialog shows and if I click disconnect from there, then the profile image will hide and the connect button will show again on the navbar. So I just want to get the same functionality as that disconnect button.

Here is where I am calling disconnect.
https://github.com/cryptoclans/cosmoskit-tailwind/blob/bc6b2a7f0cbd4a424f92b01b2200a462975d62c2/src/Navbar.tsx#L71

some images to make it easier to understand:

also side note -
If I refresh the page the connect button will be showing again. On refresh does the wallet disconnect - is this data not stored in local storage?
Thanks

environment

brave browser (loaded with extensions, ad blockers, etc)

Seems that somehow the detection for whether or not we're mobile was triggering, even though the user agent was still chrome!

issue

errors happen with connecting

steps to reproduce

1. create template

create-cosmos-app --name cnfts-frontend --example --template cosmwasm

2. attempt to connect wallet

However, it looks that the browser was somehow choosing the keplr mobile — so this is maybe why the offlineSigner was undefined... but why was it 1. using mobile and 2. trying get get a signer before actually connecting?

idea to debug

Perhaps we should test using keplr mobile as the chosen wallet inside of chrome and see what happens

important note

as soon as developer removed all extensions by creating fresh profile only with keplr extension, everything worked fine

error - ./pages/_app.tsx:4:0
Module not found: Can't resolve '@cosmos-kit/react'

4 | import { WalletManagerProvider } from '@cosmos-kit/react'

let's look into using chain-registry to make this type of thing

https://github.com/cosmology-tech/cosmos-wallet/blob/2e66939d241f06516673598f035dbaa00ed6e828/packages/core/src/chainInfo.ts

oh, actually... @NoahSaso I just got an idea if we should parse JSON and generate objects, or if I should look into using ASTs + codegen haha

https://github.com/cosmology-tech/chain-registry and https://www.npmjs.com/package/chain-registry

query clients, for example, don't need to login in order to fetch data.

we should probably encourage usage of telescope here, and the ability to get a URL provider.

Include a package for SolidJS.

The similarities between @chakra-ui/react and @hope-ui/core should enable fairly easy replacement.

• get client detection working

import '../styles/globals.css';
import type { AppProps } from 'next/app';
import { WalletProvider } from '@cosmos-kit/react';
import { ChakraProvider } from '@chakra-ui/react';
import { defaultTheme, chainName } from '../config';
import { wallets } from '@cosmos-kit/keplr';

import { SignerOptions } from '@cosmos-kit/core';
import { chains, assets } from 'chain-registry';

function CreateCosmosApp({ Component, pageProps }: AppProps) {
  const signerOptions: SignerOptions = {
    // stargate: (_chain: Chain) => {
    //   return getSigningCosmosClientOptions();
    // }
  };

  return (
    <ChakraProvider theme={defaultTheme}>
      <WalletProvider
        chains={chains}
        assetLists={assets}
        wallets={wallets}
        signerOptions={signerOptions}
      >
        <Component {...pageProps} />
      </WalletProvider>
    </ChakraProvider>
  );
}

export default CreateCosmosApp;

bash

Type error: Conversion of type '(KeplrExtensionWallet | KeplrMobileWallet)[]' to type 'MainWalletBase[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.
  Type 'KeplrExtensionWallet | KeplrMobileWallet' is not comparable to type 'MainWalletBase'.
    Type 'KeplrMobileWallet' is not comparable to type 'MainWalletBase'.
      Property '_chainWallets' is protected but type 'MainWalletBase' is not a class derived from 'MainWalletBase'.

I'm running into the following type errors

Type error: Could not find a declaration file for module '@cosmos-kit/core'. '/0xArb/proposals-interface/node_modules/@cosmos-kit/core/main/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/cosmos-kit__core` if it exists or add a new declaration (.d.ts) file containing `declare module '@cosmos-kit/core';`

My versions are as follows

    "@cosmos-kit/core": "0.27.10",
    "@cosmos-kit/keplr": "0.32.11",
    "@cosmos-kit/react": "0.27.5",

• combine original icns/stars PRs into new PR/branch #126
• move all into 2 packages name-services and name-services-hooks
• remove swr and just use a simple caching mechanism w/o new dependencies
• create a NameService class

let resolver = new NameService({
   defaultService: defaultSvc, // 'icns' | 'stargaze'
   services: [
      {
         name: 'icns',
         contract: 'osmo1xk0s8xgktn9x5vwcgtjdxqzadg88fgn33p8u9cnpdxwemvxscvast52cdd',
         chainName: 'osmosis',
         getQueryMsg: (address) => {
            return {
               icns_names: { address }
            }
         },
         slip173: 'osmo'
      },
      {
         name: 'stargaze',
         contract: 'stars1fx74nkqkw2748av8j7ew7r3xt9cgjqduwn8m0ur5lhe49uhlsasszc5fhr',
         chainName: 'stargaze',
         getQueryMsg: (address) => {
            return {
               name: { address },
            }
         },
         slip173: 'stars'
      }
   ]
})

Then imagining an instance could so something like:

resolver('dan.stars'); // => stars1lkjsadfljsdflkjsdflkjsdf  

// this uses the stargaze resolver to get an osmosis address (but this requires changes to contracts)
resolver('dan.stars', 'osmosis');  // => osmo1alskjflkjsdflkjsdfkjsdf

tailwind styles overridden

since it has been indicated that tailwind styles don't break when using 0.24.7, seems that the commit after this one: 02ba6b0

which is this one: 3afd3e8

could likely be the reason why styles are being overridden

example of trying to load custom signer: https://gist.github.com/pyramation/d7d41cee608843a56c6315ea0c05b574

import {
  cosmosAminoConverters,
  cosmosProtoRegistry,
  cosmwasmAminoConverters,
  cosmwasmProtoRegistry,
  ibcProtoRegistry,
  ibcAminoConverters,
  osmosisAminoConverters,
  osmosisProtoRegistry,
} from "osmojs";
import { SigningCosmWasmClientOptions } from "@cosmjs/cosmwasm-stargate";

const protoRegistry: ReadonlyArray<[string, GeneratedType]> = [
  ...cosmosProtoRegistry,
  ...osmosisProtoRegistry,
  ...cosmwasmProtoRegistry,
  ...ibcProtoRegistry,
];

const aminoConverters = {
  ...cosmosAminoConverters,
  ...osmosisAminoConverters,
  ...cosmwasmAminoConverters,
  ...ibcAminoConverters,
};

const options: SigningCosmWasmClientOptions = {
   gasPrice: GasPrice.fromString("0.0025uosmo"),
   registry,
   aminoTypes
};

// when creating a client with these options, you will get this Error:
// this.registry.encodeAsAny is not a function 
// because there are different versions of cosmjs

from yarn/lock:

"@keplr-wallet/[email protected]", "@keplr-wallet/types@^0.11.3":
  version "0.11.6"
  resolved "https://registry.yarnpkg.com/@keplr-wallet/types/-/types-0.11.6.tgz#a0bd5c64b3e745bee0643cbded98e6ff989cb24b"
  integrity sha512-/CMpQ/n15RevwcMGp6GPWoLdMfEbTe+5u45qyoucTkfBB0lXIgKaOPW342rxxuFk/k6mWqisCu7OLaySP9XC+Q==
  dependencies:
    "@cosmjs/launchpad" "^0.24.0-alpha.25"
    "@cosmjs/proto-signing" "^0.24.0-alpha.25"
    axios "^0.27.2"
    long "^4.0.0"
    secretjs "0.17.7"



"@keplr-wallet/[email protected]":
  version "0.11.6"
  resolved "https://registry.yarnpkg.com/@keplr-wallet/provider/-/provider-0.11.6.tgz#41bda5851a4763b830bf6141fbc89995495a9d27"
  integrity sha512-AhLO5dIsMG3zEczcMGx1PYbTqC2oY8K5fTdSQXxjDhurBcCvu+ROoPRrcR1XeHCFhdipz5cwAfjAJlAohYyWWA==
  dependencies:
    "@cosmjs/launchpad" "^0.24.0-alpha.25"
    "@cosmjs/proto-signing" "^0.24.0-alpha.25"
    "@keplr-wallet/router" "0.11.6"
    "@keplr-wallet/types" "0.11.6"
    buffer "^6.0.3"
    deepmerge "^4.2.2"
    long "^4.0.0"
    secretjs "0.17.7"


"@keplr-wallet/wc-client@^0.11.3":
  version "0.11.6"
  resolved "https://registry.yarnpkg.com/@keplr-wallet/wc-client/-/wc-client-0.11.6.tgz#61e8e7cd22d603e9518c2d5409b4b8df1298291c"
  integrity sha512-LiPWImk6BAUCDa6MRZIdUscuM2TIGqhhGka2MnKc6WKMD8+LbWwvyMYSLmeuSaqUn11o36R5V3fKVHKCYkottg==
  dependencies:
    "@cosmjs/launchpad" "^0.24.0-alpha.25"
    "@cosmjs/proto-signing" "^0.24.0-alpha.25"
    "@keplr-wallet/common" "0.11.6"
    "@keplr-wallet/provider" "0.11.6"
    "@keplr-wallet/types" "0.11.6"
    "@walletconnect/types" "^1.6.4"
    "@walletconnect/utils" "^1.6.4"
    buffer "^6.0.3"
    deepmerge "^4.2.2"
    secretjs "0.17.7"

Compared to WalletProvider, apparently ChainProvider does not expose viewOptions on the provider component. The commented line does not explain the reason. It would be great if it's exposed so that it has the same behavior as WalletProvider.

The keplr logo has been updated!

hi.
I'm trying to build a dApp that uses multiple chains at once.

I'm doing

  walletManager.setCurrentChain('osmosis');
  await walletManager.connect();

which seems to switch the chain, and get the correct address.
but

  const res = await walletManager.signAndBroadcast(voteMessages);

fails with

 Query failed with (18): fee payer address:  does not exist: unknown address: invalid request

the same code appears to work fine when only 1 setCurrentChain has been executed. (it's like the second call doesn't setup something correctly

Hi, it seems that calling offlineSigner results to an error:

_app-3bf4a8d17e54b3b5.js:359 TypeError: Cannot read properties of undefined (reading 'client')
    at getOfflineSigner (_app-3bf4a8d17e54b3b5.js:352:1768141)
    at r (_app-3bf4a8d17e54b3b5.js:347:173988)
    at Object.getOfflineSigner (_app-3bf4a8d17e54b3b5.js:347:174777)
    at index-2158354431a91ef2.js:1:24801
    at j (main-1f17483a0f830ef3.js:1:92781)
    at Generator._invoke (main-1f17483a0f830ef3.js:1:94067)
    at a.<computed> [as next] (main-1f17483a0f830ef3.js:1:93184)
    at d (677-a6b8e863b5453eed.js:1:501560)
    at h (677-a6b8e863b5453eed.js:1:501757)

Reproduction here. Demo here

Just happened to stumble upon this issue while playing with another chain.

1. connect wallet
2. let sit for 10 mins
3. change the chain
4. without refreshing, change chains and wallets

You should see Keplr will work, Leap seems to just show spinning loaders.

It'd be awesome if all the packages in this monorepo were versioned and published at the same time, so users can just consume one version (ie. 0.27.5) instead of having to manually check each dependency to ensure we're on the latest.

See the cosmos-kit example project for how projects will look with different versions of everything. A little messy

Connection tends to occur quite quickly. When the wallet is already setup correctly and the page is loading, there's no need to flash a wallet popup. The page usually takes longer to load than the wallet does anyway, since dApps tend to load other chain queries.

apparently it is possible to enable() many chains at the same time!

the underlying implementation is to pass a list of chain ids to the client enable() function.

the edge case is non-keplr-native chains still need suggestChain

@Ebazhanov had a great idea to include testing. Let's leverage this issue to discuss what should be tested and how we can test them.

• UI tests
• Logic tests
• e2w tests

https://www.npmjs.com/package/@cosmos-kit/core?activeTab=versions

I just updated to the latest version of cosmos-kit and found out, that your ChakraProvider used in the modal overrides my custom theme entirely. I even replaced the modal with a custom one and it still overrides my entire chakra config. Any ideas?

Existing apps that uses Chakra UI will encounter an issue where the base theme will be overridden with cosmos-kit's default modal because it wraps its own ChakraProvider.

Having the option to disable provider wrapping or provide an escape hatch to pass custom themes would be better.

perhaps we need to use string names? not sure how to resolve this yet, but we apparently have react-icons in non-react packages.

Wallets should be defined in their own packages and either included in core automatically or included in another package that exports all wallets.

Telescope and CosmJS support HttpEndpoint which allows users to pass headers into requests, cosmos-kit should support this. Perhaps we just need to make a modified version of chain-registry/types to allow for this

https://github.com/osmosis-labs/osmojs/blob/843b315fa0bc304eebc7664c152c18cc1871792c/packages/osmojs/src/codegen/osmosis/rpc.query.ts#L6

export interface HttpEndpoint {
  /**
   * The URL of the HTTP endpoint.
   *
   * For POST APIs like Tendermint RPC in CosmJS,
   * this is without the method specific paths (e.g. https://cosmoshub-4--rpc--full.datahub.figment.io/)
   */
  readonly url: string;
  /**
   * HTTP headers that are sent with every request, such as authorization information.
   */
  readonly headers: Record<string, string>;
}

There are import issues within the package

./node_modules/@ledgerhq/hw-transport-webusb/lib-es/TransportWebUSB.js
Module not found: Can't resolve '@ledgerhq/devices/hid-framing' in '/node_modules/@ledgerhq/hw-transport-webusb/lib-es'

I like to verify, not trust.

Let's start with the fact that Metamask is the defacto most popular crypto wallet in the world.

10M metamask extension downloads
vs
700k Keplr extension downloads

https://helixapp.com/

Injective across all of their dapps have managed to hook into metmask, keplr and many other wallets.
They are cosmos, cosmwasm, not evm like evmos, incase anyone is wondering.

Unfortunately, they aren't open source about their wallet connect wrapper.

With the possibility of reducing the cosmos boarding friction to a group 10x current the user base, this has to be a strong priority for the team.

Let's make it happen.

Outside of cosmostation, Keplr's mobile is closed source, leap wallet is all closed source (as of writting). Let's make sure we provide users with a fully open source option to the community without having to trust the leap, keplr devs, not that I think they would bring harm to users. But I like to verify, not trust.

I think we should be clearing the WalletConnect localStorage that saves the state of the last session every time we disconnect.

Disconnection clears the connected wallet from localStorage to ensure it prompts the user to pick a wallet to connect to next time, but this doesn't clear the WalletConnect session state stored in the browser. On mobile, since WalletConnect is automatically selected, this presents itself as reconnecting to the same account even when Keplr Mobile has switched accounts. Disconnecting and reconnecting after switching accounts in Keplr Mobile should refresh the account info, but it doesn't seem to.

Ideally this account switch is automatically detected like on desktop with the keplr_keystore... event, but that doesn't appear to be working. Maybe an alternative is to just refresh wallet connection when the browser enters the foreground again, if that's possible...

https://developers.ledger.com/docs/live-app/start-here/

Keplr wallet connect says "Not yet implemented" when trying to execute a contract msg. Though using deep linking on DAODAO, they successfully are able to prompt keplr to sign a tx.

https://forecast.deliverdao.org/
leverages cosmos-kit, so likely a difference in implementation between daodao and cosmos-kit

"Adding localnet and testnet chains"

I am using:

"@cosmos-kit/react": "^1.0.4",
"@cosmos-kit/core": "^1.0.3",

import { wallets as vectisWallets } from "@cosmos-kit/vectis";
import { wallets as wcv2Wallets } from "@cosmos-kit/walletconnect-v2";
import { wallets as cosmostationWallets } from "@cosmos-kit/cosmostation";
import { wallets as keplrWallets } from "@cosmos-kit/keplr";
import { wallets as leapWallets } from "@cosmos-kit/leap";

 <ChainProvider
                    chains={chains}
                    assetLists={assets}
                    signerOptions={signerOptions}
                    walletModal={getModal("simple_v2")}

                    // error here
                    wallets={[
                        ...wcv2Wallets,
                        ...keplrWallets,
                        ...cosmostationWallets,
                        ...leapWallets,
                        ...vectisWallets,
                    ]}
                >

The error I am getting is:

(property) wallets: MainWalletBase[]
Type '(WCWalletV2 | KeplrExtensionWallet | KeplrMobileWallet | CosmostationExtensionWallet | CosmostationMobileWallet | LeapExtensionWallet | VectisExtensionWallet)[]' is not assignable to type 'MainWalletBase[]'.
  Type 'WCWalletV2 | KeplrExtensionWallet | KeplrMobileWallet | CosmostationExtensionWallet | CosmostationMobileWallet | LeapExtensionWallet | VectisExtensionWallet' is not assignable to type 'MainWalletBase'.
    Type 'WCWalletV2' is not assignable to type 'MainWalletBase'.
      Property '_chainWallets' is protected but type 'MainWalletBase' is not a class derived from 'MainWalletBase'.ts(2322)

I think it is something I am doing wrong, just can't find what it might be!

API is undocumented right now. Let's write some docs :)

I'm noticing @chakra-ui/react and other react deps in core packages like leap, trust, etc. Are these actually used?

https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-036-arbitrary-signature.md

Trying to build on top of a template created with create-cosmos-app and having connection issues with the latest version v0.13.3.

Deploying the vanilla template and trying to connect with Keplr Mobile on an Android phone, the wallet connection modal reads "Oops! Something went wrong", directs the user to Keplr Mobile where a confirmation modal pops up for a split second and disappears right away. This does not happen on iOS and did not use to happen on Android with version v0.13.0.

should we change our convention for the status constants?

for readability, states/constants could be UPPER_CASE to follow convention:

https://softwareengineering.stackexchange.com/questions/319688/what-is-the-history-for-naming-constants-in-all-uppercase#:~:text=Symbolic%20constant%20names%20are%20commonly,register%20names%20and%20everything%20else.

totally up for debate though, just my 2c happy to come to consensus here

while it's nice to only include mobile in mobile devices, there are cases where devs may want to override this option

so let's default to the current behavior, and then make an option, say, includeAllWalletsOnMobile or something

as-is: https://cosmostation.io/wallet/
to-be: https://cosmostation.io/wallet/#extension