Open neatonk opened 2 years ago
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.
- Since much effort has gone into removing the
web3subgraph
I imagine, usingcall-block-logs
would be preferred.
yes. But we're open to use other data sources too.
- 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.
EDIT This comment is incorrect. See https://github.com/neume-network/strategies/issues/256#issuecomment-1258187447
Implementation notes:
SingleEditionMintableCreator
contract...
CreatedEdition
event to get the new editionId
(not an address).getEditionAtId
with the new editionId
to get the contract address.Steps to add zora editions strategies:
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.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.
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.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.zora-editions-filter-contracts-transformation
results in https://github.com/neume-network/data/blob/main/steps/1.mjshttps://github.com/neume-network/data/blob/main/.github/workflows/node.js.yml
to copy relevant files.@TimDaub Does this look legit to you? I'd like to get started on this tonight or tomorrow morning.
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 https://github.com/neume-network/strategies/issues/256#issuecomment-1239922568 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!
EDIT This comment is incorrect. See https://github.com/neume-network/strategies/issues/256#issuecomment-1258187447
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...
Getting started now on the steps described here: https://github.com/neume-network/strategies/issues/256#issuecomment-1241267105
Getting started now on the steps described here: #256 (comment)
awesome, looking forward
@TimDaub Are non-audio NFTs filtered globally or per strategy? If not filtered, most NFTs produced by this strategy will be images.
sound, catalog v2 and mintsongs only have music NFTs. And for zora, we filter by catalog v1 ids
The details provided above were based on the wrong set of contracts. The following values should be used instead.
editionContractAddress
is the next topic in the event.The tokenURI
method on the drops contracts returns a data URI. To address this I'll:
The
tokenURI
method on the drops contracts returns a data URI.
like this, right:
data:application/json;base64,eyJuYW1lIjogIlByZXZpYSB4IENyYXRlciBMYWtlIDEiLCAiZGVzY3JpcHRpb24iOiAiVG95b3RhIFByZXZpYSBhdCBDcmF0ZXIgTGFrZSBOYXRpb25hbCBQYXJrXG5BdWd1c3QgMzEsIDIwMjAiLCAiaW1hZ2UiOiAiaXBmczovL2JhZnliZWliYzM2dTc0aW00ZDJ4Z3licXp6N2Y3bHZ1Z2NrZXg3eWpwaTN5bTNqbGhuZXF2M2VjbDZxP2lkPTEiLCAicHJvcGVydGllcyI6IHsibnVtYmVyIjogMSwgIm5hbWUiOiAiUHJldmlhIHggQ3JhdGVyIExha2UifX0=
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.
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.
My comments adapted from discord:
call-block-logs
strategy. Since the zora drops contracts are deployed by a factory, they would be handled very much likesound
is currently.web3subgraph
I imagine, usingcall-block-logs
would be preferred.