You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 3, 2023. It is now read-only.
@dblodorn@Javier-Szyfer had a great meeting with Felt Zine on friday, but found out that they want to be able to do generative editions (audio metadata same for each token w/ diff cover art - unun style) which uses the dropsMetadataRenderer rather than the editionsMetadataRenderer. Because we'll have to build that strategy out for them, I suggest we also add that flexibility to Neosound as well (this will allow us to curate unun on the platform, which is strongly desired imo since this was one of the key sources of inspiration for the project).
After doing some digging through the drops subgraph, I think I have an idea for a multi part query that will give us flexibility to render either type correctly (this would be run for each contract curated in the curation contract):
To get specific metadata for drops style contracts you have to specifiy a token Id. The initial idea is for drops style contracts (which we know before making this second query since we got the metadata renderer address in the first query), we will render metadata for token public-assembly/audio-player-ui#1 of the contract, while still providing the sales config informaiton (mint price, total Minted, max supply, mint start time, etc.) for the contract so it can be minted.
Drops currently act weird in the subgraph, trying to get the drops metadata base info using the query for it returns a null currently. Another thing im thinking is that this could instead be done switching over to the zora indexer to make the follow up query for drops, since the zora api returns parsed metadata files directly
Drops Metadata Query using subgraph (this or something like this):
query MyQuery {
erc721Drops(where: {address: "${dropAddress}"}) {
name
owner
address
creator
maxSupply
totalMinted
symbol
rendererAddress
salesConfig {
publicSaleStart
publicSaleEnd
publicSalePrice
maxSalePurchasePerAddress
}
dropMetadata {
base
contractURI
extension
}
}
}
Drop Metadata Return (this or something like this):
I would imagine we would want to normalize all of the data, so that the final cleaned info for both drops/editions can be passed into an NFTCard style component in the same way. So pretty much we would be fetching + normalizing the collection wide metadata for edition style contracts, and fetching + normalizing the metadata for token Id public-assembly/audio-player-ui#1 for drops style contracts. imagine that being something like:
This also will make it easy for ppl to swap in and out metadata fetching strategies (ex: for ppl who want to curate things other than zora style nft contracts), as there will be a standardized prop list required to pass into the NFTCard component
@dblodorn @Javier-Szyfer had a great meeting with Felt Zine on friday, but found out that they want to be able to do generative editions (audio metadata same for each token w/ diff cover art - unun style) which uses the dropsMetadataRenderer rather than the editionsMetadataRenderer. Because we'll have to build that strategy out for them, I suggest we also add that flexibility to Neosound as well (this will allow us to curate unun on the platform, which is strongly desired imo since this was one of the key sources of inspiration for the project).
After doing some digging through the drops subgraph, I think I have an idea for a multi part query that will give us flexibility to render either type correctly (this would be run for each contract curated in the curation contract):
editionMetadataRenderer = "0xd167b7a408c65306d5a2abead63986540110b28b"
dropMetadataRenderer = "0x5914d9a241008b9f02f22811bf3a77e02b84d226"
Edition Metadata Query (this or something like this):
Editition Metadata Return (this or something like this):
Notes on Drops
To get specific metadata for drops style contracts you have to specifiy a token Id. The initial idea is for drops style contracts (which we know before making this second query since we got the metadata renderer address in the first query), we will render metadata for token public-assembly/audio-player-ui#1 of the contract, while still providing the sales config informaiton (mint price, total Minted, max supply, mint start time, etc.) for the contract so it can be minted.
Drops currently act weird in the subgraph, trying to get the drops metadata base info using the query for it returns a null currently. Another thing im thinking is that this could instead be done switching over to the zora indexer to make the follow up query for drops, since the zora api returns parsed metadata files directly
Drops Metadata Query using subgraph (this or something like this):
Drop Metadata Return (this or something like this):
Drops Metadata Query using Zora Indexer (something like this):
Drops Metadata Query Return from Zora Indexer (something like this):
The text was updated successfully, but these errors were encountered: