Add strategy to track NFTs curated on present materials

[neatonk]

My comments adapted from discord:

• The right way to do this for neume would likely involve using the call-block-logs strategy. Since the zora drops contracts are deployed by a factory, they would be handled very much like sound is currently.
• This is still WIP... See Statefully filtering by CreatedArtists event in call-block-logs-transformator stops later events to be picked up #252
• Another way to do this would be to use the subgraph provided by Zora: https://thegraph.com/hosted-service/subgraph/iainnash/zora-editions-mainnet
• Since much effort has gone into removing the web3subgraph I imagine, using call-block-logs would be preferred.
• In either case, the result would be a new platform (zora-drops?) including every drops contract deployed by the Zora drops factory.
• The next hiccup would be in defining present materials as a platform. Since all of the NFTs are curated, they will likely be associated with another platform already. See Amend schema to accomodate curation-based meta-platforms schema#34

[neatonk]

Yet another way to do this would be to get the contract addresses from the present materials contract first and then get metadata for each contract. This approach could lead to a situation where the same contract is reached by multiple strategies—leading to multiple outputs with potentially differing results.

[TimDaub]

• Since much effort has gone into removing the web3subgraph I imagine, using call-block-logs would be preferred.

yes. But we're open to use other data sources too.

[TimDaub]

• song camps nft contracts https://github.com/ourzora/nft-editions

[neatonk]

• song camps nft contracts https://github.com/ourzora/nft-editions

Yep. To be clear this only applies to the contracts curated on https://www.presentmaterial.xyz/ and not other songcamp projects.

[neatonk]

EDIT This comment is incorrect. See #256 (comment)

---

Implementation notes:

• On the deployed SingleEditionMintableCreator contract...
  • listen for CreatedEdition event to get the new editionId (not an address).
  • call getEditionAtId with the new editionId to get the contract address.
• Deployed factory is at: 0x91A8713155758d410DFAc33a63E193AE3E89F909
• Event topic for logs filter is: 0x152014b245a12a32e125b8a4227ff155636ca7ca6ba15d04c5d07966e55c5cc7

[neatonk]

Steps to add zora editions strategies:

• Add zora-editions-filter-contracts strategy to https://github.com/neume-network/strategies. This should be similar to soundxyz-filter-contracts strategy, which has a transformer, but no extractor. Follow the implementation notes above to filter logs and get the contract address for each edition. Note: This could be split into two strategies: one which filters the logs and one which calls getEditionAtId to get the contract addresses.
• Add simple zora-editions-call-tokenuri and zora-editions-get-tokenuri strategies using the provided strategy-factories.

Steps to include the zora editions strategies in the active crawl path.

• Add zora-editions-call-tokenuri and zora-editions-get-tokenuri strategies to crawl path in https://github.com/neume-network/data/blob/main/steps/3.mjs.
• Add a step run zora-editions-filter-contracts strategy in https://github.com/neume-network/data/blob/main/scripts/generateBlockLogsCrawlPath. side note: this is a bash script, that generates a javascript module. The script is called in https://github.com/neume-network/data/blob/main/.github/workflows/node.js.yml.
• Include zora-editions-filter-contracts-transformation results in https://github.com/neume-network/data/blob/main/steps/1.mjs
• Add lines to "Update neume-network/data files" step in https://github.com/neume-network/data/blob/main/.github/workflows/node.js.yml to copy relevant files.

[neatonk]

@TimDaub Does this look legit to you? I'd like to get started on this tonight or tomorrow morning.

[TimDaub]

Add zora-editions-filter-contracts strategy to https://github.com/neume-network/strategies. This should be similar to soundxyz-filter-contracts strategy, which has a transformer, but no extractor. Follow the #256 (comment) above to filter logs and get the contract address for each edition.

I've looked into this and I think it sounds legit. https://etherscan.io/address/0x91A8713155758d410DFAc33a63E193AE3E89F909 This contract essentially emits the edition creation event and basically a different contract handles the edition to tokenId translation, right?
As you described to implement it would be a good first step. Happy to advise whereever I can!

[neatonk]

EDIT This comment is incorrect. See #256 (comment)

---

I've looked into this and I think it sounds legit.

Thanks

This contract essentially emits the edition creation event and basically a different contract handles the edition to tokenId translation, right?

For whatever reason, the getEditionAtId funciton is on the proxy contract instead of the implementation, so you won't see it on etherscan unless you look at the "Read Contract" tab...

[neatonk]

Getting started now on the steps described here: #256 (comment)

[TimDaub]

Getting started now on the steps described here: #256 (comment)

awesome, looking forward

[neatonk]

@TimDaub Are non-audio NFTs filtered globally or per strategy? If not filtered, most NFTs produced by this strategy will be images.

[TimDaub]

sound, catalog v2 and mintsongs only have music NFTs. And for zora, we filter by catalog v1 ids

[neatonk]

The details provided above were based on the wrong set of contracts. The following values should be used instead.

• The contract contracts source code is here: https://github.com/ourzora/zora-drops-contracts
• The contract creation events are emitted by: https://etherscan.io/address/0xf74b146ce44cc162b601dec3be331784db111dc1#events
• The event topic to filter by is: 0xad59ebba8bfb06ba01a615a611467ca3bef86a275bd5e9704d3b295112550ba5
• The editionContractAddress is the next topic in the event.

[neatonk]

The tokenURI method on the drops contracts returns a data URI. To address this I'll:

• add a 'data-uri' message type to the extraction worker message schema
• add a handler for the data-uri type using https://www.npmjs.com/package/data-uri-to-buffer

[TimDaub]

The tokenURI method on the drops contracts returns a data URI.

like this, right:

data:application/json;base64,eyJuYW1lIjogIlByZXZpYSB4IENyYXRlciBMYWtlIDEiLCAiZGVzY3JpcHRpb24iOiAiVG95b3RhIFByZXZpYSBhdCBDcmF0ZXIgTGFrZSBOYXRpb25hbCBQYXJrXG5BdWd1c3QgMzEsIDIwMjAiLCAiaW1hZ2UiOiAiaXBmczovL2JhZnliZWliYzM2dTc0aW00ZDJ4Z3licXp6N2Y3bHZ1Z2NrZXg3eWpwaTN5bTNqbGhuZXF2M2VjbDZxP2lkPTEiLCAicHJvcGVydGllcyI6IHsibnVtYmVyIjogMSwgIm5hbWUiOiAiUHJldmlhIHggQ3JhdGVyIExha2UifX0=

[neatonk]

Yes, although I see that the ZoraNFTCreatorV1 contract has createDrop and createEdition methods which use different metadata renderers. One, which returns a data-uri as described above and one which uses a base uri and token id. The base uri can potentially use any scheme.

This can be addressed in the strategy by looking the tokenURI scheme to determine the message type. Or, it can be addressed in the extraction worker by adding a message type that can handle any URI. I'm leaning towards the latter as it a more generic solution.

[neatonk]

Thezora-drops-get-tokenuri strategy requires some thought. As mentioned above, the uri shceme and metadata format may vary.

For now, I think it is good enough to handle drops which use the EditionMetadataRenderer and ignore the rest. This is helpful because the uri scheme and metadata format are known and can be transformed to match the required schema. Also, this covers all editions created using the https://create.zora.co/create/edition interface and is sufficient to handle the present materials curated contracts.