To crawlpath, add NFT owner information

[TimDaub]

• we merged a new strategy to call a contract's owner: Add call-contract-owner strategy strategies#201
• to @neume-network/schema, we want to add an owner field: for erc721, add contract owner as a data field schema#24
• finally, once all those changes land on neume-network/core, we want to add call-contract-owner as an additional step right after web3subgraph (which it requires data from)
• adjust music-os-accumulator strategy to match owner for an address

/cc @neatonk

[neatonk]

Very cool @TimDaub. Let me know if I can be of any help with this.

[TimDaub]

I've attempted to work on this but eventually got blocked by neume-network/web3-music-subgraph#2, so I'm not sure if I can proceed here. It seems we need to get rid of web3-music-subgraph first :/

[neatonk]

I'll have some time to help with this over the next couple of weeks. I can assist in replacing the web3-music-subgraph or coming up with alternative workarounds.

Unless I'm missing something (likely), then the easiest way forward is to ignore the garbage that the web3-music-subgraph creates by filtering it's output. This is not ideal, but allows progress and is better than having garbage in the output.

[TimDaub]

This is unblocked now as we've deprecated web3-music-subgraph. But I still want to share some notes here:

• To keep all requests idempotent, we've decided to implement call-contract-owner such that its using a block number tag: https://github.com/neume-network/strategies/blob/d37bd0d944d86f174d30614ba263274b91894453/src/strategies/call-contract-owner/extractor.mjs#L37
• And to keep the amount of calls low, we've tried to implement a cache so that two contracts are never called twice in one crawl: https://github.com/neume-network/strategies/blob/d37bd0d944d86f174d30614ba263274b91894453/src/strategies/call-contract-owner/extractor.mjs#L52
• However, the issue is that virtually any music NFT is minted in a different block which means that we're essentially making the amount of contract owner calls that we end up having music NFTs and that's not efficient
• Also: I doubt people are generally interested in the contract owner at the time of the NFT's minting. They probably want the latest possible information
• So I propose that we request the most current contract owner but also make sure that we note down the block number in the metadata.
• We then make an adjustment to neume-network/schema such that the owner field is always accompanied with a block number field such that users can understand when that information was crawled: https://github.com/neume-network/schema/blob/5281beeaa53847ef121799e1b032a4162d751c66/src/schema.mjs#L231
• Finally: For a more extensive solution, but we might want to do this later, we could use the event OwnershipTransferred to index all ownership swaps in history of a music NFT contract. But for now and for music-os, I dont' foresee that as immediately useful.

[neatonk]

Thanks so much for adding this. Responding in kind with some notes of my own:

• I agree with your assessment above and think that recording the contract owner for a given block number is the right approach.
• Any block number in which the contract exists will likely do for the use case I have in mind, but the latest block number would be most useful.
• I do see value in tracking ownership over time as you have suggested, but do not have a use case for that right now.

[neatonk]

For context, the use case I have in mind is a curation UI in which only contracts owned by the connected wallet are allowed. This UI would include an auto-complete mechanism to make filling contract addresses easier. Because this is just a UX optimization, it does not need to be 100% accurate and even 60% may be good enough.

• I do see value in tracking ownership over time as you have suggested, but do not have a use case for that right now.

I can imagine a use case in which the auto-complete would include any contract that was ever owned by the connected wallet.

[TimDaub]

Here's a similar use case now: neume-network/strategies#321

[neatonk]

Here's a similar use case now: neume-network/strategies#321

Yep. And both of these would benefit from a global approach to historical data rather than ad-hoc tracking of previous states for specific fields. E.g. neume-network/strategies#302, which includes the block number in the id of each Datum.