Kickoff on scoping this Epic

[geastwood]

• have a meeting to scope NFT requirements
• listen from @chenzongxiong on faced challenges
• talk about next step

Let's have initial discussion within @bdmason @chenzongxiong @markdavison and @jdomingos

[bdmason]

Some notes on indexing NFTs on EVM

1. Detecting all NFT contract creations

We have the logic for how to do this using the EVM transaction input, the issue here is how we listen for transactions. For Moonbeam EVM we are listening to Ethereum.Executed events on the substrate network using Subsquid. In The Graph you normally to specify the contracts you are interested in, but you can omit this and watch the blocks. See the docs.

2. Indexing NFT activity

This shouldn't be too hard, we've already done some of this here.

3. Indexing metadata links that work

This is a highly annoying task. Each contract (and probably each NFT from each contract) can store the metadata URI (if they have one) differently, sometimes just an IPFS hash, sometimes an actual URL, sometimes something in between... @chenzongxiong has done something in the past that we can adapt. Get the IPFS hash and hit all known IPFS hosts then use the first that gives a 200. This has been done when the user requests NFT content, and can take a while so it's not ideal. We could run scripts to do this in the background and store the useful URL. We could also consider creating our own IPFS node and storing the data ourselves, though I imagine the volume will be ludicrous.

Notes

BSC and other EVM networks

This should be straightforward. We just run the same code on other networks

The Graph - should we use it?

When indexing specific contracts The Graph is great, you get graphql schema to postgres scaffolding out the box with codegen, as well as automatically generated types from the contracts (via the ABI -> something we won't always have).

When developing on the graph the current flow is: make changes -> build -> deploy (to test environment on their hosted service) -> look at the results. It's slow and quite painful, and the logs are a pain to use. Also, when switching networks you need a new graph instance, it's not as simple as switching an environment variable.

I think The Graph is going to be more of a hinderance to us, and as we have very focused requirements simply looping through the blocks looking for what we want using our own custom code is more preferable. I did this on Substrate last year and it was trivial. We'd need to implement graphql and postgres ourselves, but that's also quite trivial. The advantage is complete flexibility in our approach.

[bdmason]

Regarding other networks

EVM is the original smart contract platform, so it suffers from legacy data & standards issues a lot. If we can crack EVM I think most of the hard work is done.

On Solana you can see your NFTs in all your wallets, so unless all those wallets are hooked up to indexed data somewhere that means Solana stores NFT ownership data differently to EVM (as you can't just query NFTs by account on EVM). So in terms of knowing who owns what I expect this to be easy without any indexing required. In terms of NFT analytics, that's a whole different issue, and the volume of data on Solana (due to it being a high throughput network) will be the issue. Nevertheless, it's a newer network so we might find the design makes things a lot easier for us to work with.

I (optimistically hope) that the same will hold true for other NFT networks, that being newer the implementation of NFTs on the networks might make our life a hell of a lot easier than it has been on EVM.