It's handy that pallets have indexes. It'd be really nice to do this for calls as well! (just now I was manually building an extrinsic for a pallet and wanted to check on the call index for it, and realised I couldn't via subxt-explorer :)

Bumps rustix from 0.37.23 to 0.37.25.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Users can now use their own chain_spec.json files to connect via the Smoldot lightclient integration that subxt can use under the unstable-lightclient feature flag. Also at the start of the web app, chain spec presets are fetched from This Repo via the github API. Currently this amounts to 4 chain specs. They are loaded in about 100ms, so it is not that bad. Users can select these presets instead of supplying their own chain specs:

Also the app state has been cleaned up a little. Creating a client now involves two data structures, a ClientCreationConfig and ClientCreationData. At any point of the app lifecycle, a ClientCreationConfig can be derived from the query params. This is also done at app start. Any ClientCreationConfig can be used to generate ClientCreationData, which then is passed to the Rust Code in WASM to initiate the connection. However the opposite way (ClientCreationData -> ClientCreationConfig) is not always possible. That is because a ClientCreationConfig should be 100% representable in terms of query params. Which is e.g. not possible if a user uploads a file.

There is now the option to share URLs that use light client presets. For this a url needs to contain ?lightclient=Polkadot. This creates a ClientCreationConfig at app starts that is checked against any chain specs obtained from the aforementioned substrate connect repo.

Currently connecting with a light client is super slow. Ofter 30+ seconds. I think it is due to some state synching smoldot is doing. Also Smoldot makes a lot of P2P requests to random IP addresses that sometimes fail (sometimes a lot), which currently clutters the Javascript Console with error messages.

Introduce a mode variable to the app state: | Mode | User Input | Metadata | Connection | Sharable Links | | ---------------- | -------------------------------------- | -------------------------------------- | ---------------- | -------------- | | Metadata File | a metadata file, e.g. metadata.scale | decoded from uploaded file | - | No | | Node Url | a url to a a node, e.g. | Fetched when constructing OnlineClient | Jsonrpsee Client | Yes | | ChainSpec File | a chainspec file, e.g. polkadot.json | Fetched when constructing LightClient | LightClient | No | | ChainSpec Preset | selection of a chainspec file preset | Fetched when constructing LightClient | LightClient | Yes |

It should be possible to connect to a chain using the Lightclient in WASM. It needs a chainspec to connect to a chain. There should be two ways to connect:

• Drag and Drop a chainspec file, similarly how you can drag and drop metadata in right now.
• Have a list of chain specs ready to select from. These can be fetched via GET requests if they are hosted alongside the Webapp.

When using the Polkadot Explorer with wss://polkadot-asset-hub-rpc.polkadot.io navigating to https://paritytech.github.io/subxt-explorer/#/pallets/XcmpQueue/storage_entries#QueueConfig shows None for the QueueConfig storage item while polkadot Js can retrieve it: https://cloudflare-ipfs.com/ipns/dotapps.io/?rpc=wss%3A%2F%2Fpolkadot-asset-hub-rpc.polkadot.io#/chainstate