Add field for suggest-chain documentation?

[JeremyParish69]

Proposing the idea of removing 'suggest-chain' from the features array, and instead creating its own optional object.

e.g.,:

"suggest_chain_feature": {
  "docs": "https://docs.keplr.app/api/suggest-chain.html",
  "parameters": {
    "optional": [
      "walletUrlForStaking",
      "alternativeBIP44s",
      "features"
    ]
  }
}

"suggest_chain_feature": {
  "docs": "https://docs.leapwallet.io/cosmos/connect-to-leap-on-dapps/suggest-chain",
  "parameters": {
    "optional": [
      "rpcTest",
      "restTest"
      "walletUrlForStaking",
      "alternativeBIP44s",
      "features"
    ],
    "extra_required": [
      "image_url",
      "theme_leap"
    ]
  }
}

"suggest_chain_feature": {
  "docs": "https://docs.leapwallet.io/cosmos/connect-to-leap-on-dapps/suggest-chain",
  "parameters": {
    "required": [
      "rpc",
      "rest",
      "chainId",
      "chainName",
      "stakeCurrency",
      "bip44",
      "bech32Config",
      "currencies",
      "feeCurrencies",
      "theme_leap",
      "image_url"
    ],
    "optional": [
      "rpcTest",
      "restTest"
      "walletUrlForStaking",
      "alternativeBIP44s",
      "features"
    ]
  }
}

This allows us to define a standard for the suggest chain feature, and so we can much more easily programmatically determine whether a chain can be added to a dApp, based on whether the chain's registration is compatibile with the dApp's supported wallet's suggest_chain feature.

[pyramation]

I guess my first thought is that, what does required refer to? Properties inside of chain-registry chain.json? Or properties in an object that come from their app?

That's not super clear, and if it's the later, we almost may want to embed the entire schema as a nested schema JSON.

[JeremyParish69]

I guess my first thought is that, what does required refer to? Properties inside of chain-registry chain.json? Or properties in an object that come from their app?

That's not super clear, and if it's the later, we almost may want to embed the entire schema as a nested schema JSON.

required refers to the required parameters (is parameters the wrong word?); they are the required properties of the object that is input for the experimental Suggest Chain feature--i.e., you cannot suggest a chain without these. As seen, e.g., here: https://docs.keplr.app/api/suggest-chain.html

Embedding the schema could have some benefits, but I also wanted to make sure that all the requirements are written the same way and easily mapped to data in the chain registry. E.g., if one schema calls it chain-id and another calls it chainId--yes, it's easily understood by a human reader, but I wanted it to be simple for a script to work with too. With easily translated requirements, a script will know which chain registrations can be suggested to a wallet, whereas chain registration missing a required parameter would not be eligible for chain suggestion to that wallet.

Maybe it could use some work...

[JeremyParish69]

After re-reading you comment, I think I understand better what you mean. Maybe it's better to exactly name the chain.json's properties that compose the requirements for the feature, and have it just signal eligibility rather than a complete instruction set for generation. From there, if an app wants to actually generate the input, they can investigate the official documentation (not sure if it's wise to try to implement that generation here due to the maintenance it might require). Here's what it'd look like with exact properties:

"suggest_chain_feature": {
  "docs": "https://docs.leapwallet.io/cosmos/connect-to-leap-on-dapps/suggest-chain",
  "requirements": {
    [
      "rpc",
      "rest",
      "chain_id",
      "chain_name",
      "staking",
      "slip44",
      "bech32_prefix",
      "assets",
      "fees",
      "logo_URIs"
    ]
  }
}

[JeremyParish69]

Or we could try this. (example for Keplr):

{
  "api_input_structure": [
    {
      "parameter_name": "rpc",
      "corresponding_property": "$.chain.apis.rpc.0.address",
      "required": true,
      "type": "string"
    },
...
    {
      "parameter_name": "chainId",
      "corresponding_property": "$.chain.chainId_property",
      "required": true,
      "type": "string"
    },
    {
      "parameter_name": "chainName",
      "corresponding_property": "$.chain.chainName_property",
      "required": true,
      "type": "string"
    },
    {
      "parameter_name": "stakeCurrency",
      "required": true,
      "type": "object"
    },
    {
      "parameter_name": "stakeCurrency.coinDenom",
      "corresponding_property": "$.assetlist.asset.{stakeCurrency}.symbol",
      "required": true,
      "type": "object"
    },
 ...
    {
      "parameter_name": "bip44",
      "required": true,
      "type": "array"
    },
    {
      "parameter_name": "bip44.coinType",
      "corresponding_property": "$.bip44.coinType_property",
      "required": true,
      "type": "integer"
    },
    {
      "parameter_name": "alternativeBIP44s",
      "corresponding_property": "$.alternativeBIP44s_property",
      "required": false,
      "type": "array"
    },
   ...
    {
      "parameter_name": "features",
      "corresponding_property": "$.features_property",
      "required": true,
      "type": "array"
    }
  ]
}

[JeremyParish69]

Something like 'features' would be based on a condition rather than a corresponding property, so perhaps we can include something like:

    {
      "parameter_name": "features",
      "values": [
        {
          "value": "ibc-go",
          "condition": "$.chain_registry.chain.codebase.ibc_go_enabled",
        },
        {
          "value": "cosmwasm",
          "condition": "$.chain_registry.chain.codebase.cosmwasm_version",
        },
        ...
        {
          "value": "ibc-transfer",
          "condition": "$.chain_registry.chain.codebase.ics_enabled.#.ics-20",
        }
      ],
      "required": true,
      "type": "array"
    },