Multichain app - second iteration

[exezbcz]

Abstract

On the last team call, we brainstormed how we could implement a multichain app. Users will only benefit a little from a multichain landing (mixing all the chains in all carousels, etc.). Another issue is that it could cause more harm on the dev side, generating even more bugs.

Multichain landing is generally good when mixing EVM chains (l2s and mainnet) since there are some bridging possibilities between these two, and it's possible to abstract the chain the user is on. Unfortunately, that is not our case, as we would have polkadot + EVM landing.

More chains will complicate it even more; all components would need to be revised when a new chain is added.

Proposed solution 1

with this in mind, my solution and a solution i proposed to the team consists of three main things:

• upgraded selector for chains
• chain-specific landing
• multichain profile

Chain selector

• selector will get a more visible location and visual upgrade, making a distinction between Polkadot ecosystem and the evm ecosystem
• making sure that all chains are visible all the time

Chain specific landing

• only one chain and artworks from that chain visible (including featured drops)

Multichain profile

• UX for linking wallets to a chain-agnostic profile
• profile could have two wallets assigned (polkadot + evm)
• linking and connecting the wallet will be only required when doing an action
  - browsing with a wallet from the other ecosystem is allowed, then switching as ^

Solution 2

• all multichain
• with this, there will be no network switch
  • there will be only filters in the sections that will display: all network, base, ahp, ahk .... etc.

[exezbcz]

any thoughts @kodadot/internal-dev ?

[preschian]

Hi @exezbcz,

For now, overall, proposal 1 seems easier. In this PR #10903, I made slight changes to align with that. I need your feedback on the following:

1. Only one chain and artworks from that chain visible (including featured drops)

It will only show featured drops from the selected chain (align with: https://github.com/kodadot/ops-internal/discussions/1845). In that section, we are currently showing drops that are not fully minted out. If all drops were minted out, it would show blank content. What if we show the recent n drops even if they're already minted out?

2. Add delay message after minting the drops

In that PR, I'm mainly unifying the minted count and total supply count. Previously, there were some cases where the count query was slow (ref: #10904). To accommodate that, I added cache to speed it up. However, the trade-off is that the data is not real-time (ref: #10903 (comment)). There might be a delay of roughly 2 minutes.

What if we add a delay message after minting? This is similar to the popup message on fxhash, as our indexer also has some delay in showing the minted drops.