Facilitate the creation of offers via WalletConnect

[Ganbin]

In the current set of WalletConnectCommands, we can create offers only via wallet ids (createOfferForIds).

This makes the creation of offers complicated:

• We cannot get the wallet id by passing the CAT asset id. We would need the opposite command of the current getCATAssetId(walletId) -> getCATWalletId(assetId)
• I could not get the result of getWallets after confirmation in the Chia wallet. I always get an error in the console that repeats itself many times (I maybe should create an issue for that one):

code: -32602
message: "Request validation error: Message is too long. Maximum message length is 20000 characters"

• In both cases, a user would need to confirm multiple requests before to be able to create an offer.

Having a way to pass offer data with something similar to what we have in Goby wallet would be very nice Goby - Create Offer.

In a more generic way, it would be nice to have a new CHIP because CHIP-0002 don't cover enough methods for dApp to use today with all the new stuff we have (NFT, DID, Offers, etc.)

[Ganbin]

With the latest 1.7.1 I can get the getWallets method to work.

[Ganbin]

When doing a createOfferForIds request, the confirmation dialog is a too evasive, we only see [object Object]. The user must trust that the value are the one he have entered. For me it is a security risk because a bad actor could allow to enter data (someone want to create an offer for 1MRMT against 40XCH for example) and the bad actor could create an offer for 1MRMT against 1 mojo and accept it directly, or any other combination that could possibly drain the wallet.

[Ganbin]

I also post here my other issues that are related instead to open different issues.

Creating offer with NFT

I also have issue creating offer for NFT.

Request:

method: "chia_createOfferForIds",
  params: {
    walletIdsAndAmounts: {
      "1": 100000000000000,
      "50b9b503ed5d22e83502cdcb7b807e16c28867812401d7aebb0e595b5486d6e3":
        -1,
    },
    driverDict: {},
  },

Error:

error: 
  data:
    error: "invalid literal for int() with base 10: '50_b_9_b_503_ed_5_d_22_e_83502_cdcb_7_b_807_e_16_c_28867812401_d_7_aebb_0_e_595_b_5486_d_6_e_3'"
    success: false

The same request with chia wallet rpc works:

chia rpc wallet create_offer_for_ids '{"offer":{"1":100000000000000,"50b9b503ed5d22e83502cdcb7b807e16c28867812401d7aebb0e595b5486d6e3":-1},"fee":1000,"driver_dict":{},"validate_only":false}'
{
    "offer": "offer1qqr83...",
    "success": true,
    "trade_record": {
...

getNFTs

Doing a WalletConnect getNFTs on small wallet is working ( the max I tried was with 6 NFTs), but I have tried on one wallet with 50 simple NFTs and it fails, no error, just nothing until the timeout.
Same on another wallet with >200 NFT and few with asset data on chain.

[paninaro]

Thanks for the detailed report @Ganbin. I'll get these issues tracked for inclusion.

[paninaro]

@Ganbin I believe I've repro'd the issue you mentioned regarding getNFTs timing out. This is what I'm seeing in the dev tools:

Not immediately sure what to do about it...

[paninaro]

@Ganbin regarding the error:

error: "invalid literal for int() with base 10: '50_b_9_b_503_ed_5_d_22_e_83502_cdcb_7_b_807_e_16_c_28867812401_d_7_aebb_0_e_595_b_5486_d_6_e_3'"

You should be able to add disableJSONFormatting: true to the request as a workaround.

[Ganbin]

You should be able to add disableJSONFormatting: true to the request as a workaround.

Ho thanks a lot it actually works. During my tests I have made a typo : disableJsonFormatting: true

[Ganbin]

While I'm at it, It is also more common for dApp to deal with NFT ID instead of Launcher ID. For example, we can ask a user, who wants to create an offer for a NFT which NFT ID he like to trade.

With the getNFTInfo we need the Coin ID. This force to do more request in order to get the Launcher ID from the NFT ID where it could be nice to be able to gives the NFT ID directly when creating offers. Same with Asset ID instead of Wallet ID.

I know behind the scene, WalletConnect use the normal Chia RPC calls, that is why it was built that way. So I'm not sure if my requests are too complexe to be implemented, it would only create more RPC calls on the chia wallet side. So maybe it is for dApp to prepare the data correctly before hand.

[paninaro]

Glad to hear that the workaround is working.

The nft_get_info RPC actually does support specifying an NFT ID for the coin ID, but the GUI won't honor that at the moment.

I can see how having a WC command translation layer would help with these and other issues to simplify the WC API.

[Ganbin]

@paninaro Thanks for the different addition in the 1.8.0. I wanted to try again but I could not get the getWallets request to work anymore.

In the devtool on the chia wallet I get ws.ts:94 WebSocket is already in CLOSING or CLOSED state. again and again, until the timeout is reached. On the dApp I get an empty error message with wallet connect rpc request failed: Error at watch.ts:37:1

[paninaro]

Are you building the Chia GUI from source, or installing from one of the installer packages? If you're building from source, I wonder if you may have the older version of the WalletConnect SDK (2.4.9 is what we were using previously, we're on 2.6.0 now).

The other thing that may be causing issues is if you have an old pairing. Can you try disconnecting the Dapp from both the Chia GUI and from the Dapp and create a new pairing? I've been testing with the test Dapp (https://github.com/Chia-Network/chia-wallet-connect-dapp-test) and can get the chia_getWallets command to work.

Also, there's a way to enable debug logging in the Chia GUI. You can open the dev tools window, navigate to the Application tab and expand the Local Storage nav item on the left. Then you can add a key/value entry of debug (key) and chia-gui:* (value) as shown below. You'll need to reload the app after making this change. Hopefully this will provide some additional details that will be helpful in troubleshooting.

[Ganbin]

I'm actually using the 1.8.0 official release. I then tried the latest 1.8.1-rc1. But got the same.

I have also tried to recreate the pairing (I always create a new one when testing).

Thanks for the trick to activate debug. I think it only works if I build from sources.

[Ganbin]

With the connect wallet dapp test the chia_getWallets also works on my side, I have to check what would be the differences.

[Ganbin]

Ok the difference is includeData: false in dapp-test. If you try with includeData: true it also fail on my side.

I also think that is because my wallet contains a DID that have hundreds of parent_info coins. I suppose that this is because my DID contains all my NFTs (no I'm not a degen...)

For now I don't need the data so I will just put includeData: false

[Ganbin]

Another issue I have is with getNFTs, if I request my big NFT wallet with >200 NFT I got the same error as the getWallets. (ws.ts:94 WebSocket is already in CLOSING or CLOSED state.)

If I request a small wallet with only 4 NFT, when I click reject I got the standard 'Invalid Request' error. But if I click on Confirm I get an object with many attributes like status: "rejected", isError: true, isSuccess: false, requestId...

[paninaro]

I don't have a great solution for this yet. There's a limit to the amount of data that WalletConnect will allow (though I don't know what that limit is). In the meantime, I would recommend calling the chia_getNFTsCount command to figure out how many items are in the collection, and then using the pagination params startIndex and num when calling chia_getNFTs to pull smaller batches of NFTs.

I'm not sure what to make of the Invalid Request error. Maybe the above suggestion of turning on debug logging will illuminate the issue.

[Ganbin]

Thanks for the recommendation. I have tried out and here is what I found:

The count works great. it return me the correct number.

I tried to loop and fetch 25 by 25. The first request works, the second fail.
I then tried 10 by 10. The 2 first requests work the 3 fails.
5 by 5. 5 first requests work, the 6 fails.
1 by 1. 25 first request work, the 26 fails.

Tried on dapp-test and got the same issue pass the 25 first NFTs.

[Ganbin]

I think I found what is the issue. After looking with RPC, the 26th NFT is a AnnoyNation NFT NFT that have the image base64 content on chain. I suppose this get blocked somewhere in the web socket connection.

[paninaro]

Hah, well the annoynation name seems quite appropriate in this case. We'll see if we can do something to detect when a response is rejected because of its size. Thanks for the info!

[Ganbin]

I have opened an issue for this specific case: #15383

[Ganbin]

The createOfferForIds now shows the button to display the details of the offer. Great improvement!

But when I accept the offer, I get an error object { "error": { "data": { "error": "offer", "success": false } } }

[sargonas]

I spun this out into an issue for you @Ganbin, to help ensure it gets some visibility and traction.

#15380

[Ganbin]

Thank you!