Batch 3: Support Generative Editions

[dblodorn]

This batch will add configuration to allow for the support of conventional drops style contracts, metadata will be token not contract specific.

This batch could introduce the usage of the Zora API for simplified token data request. If user's want additional data they can combine with nft hooks or whatever other preference they have for nft data fetching.

TODO:

• Create stub with an array of curator data, including both edition and generative contracts
• Support within data fetchers, normalizing the metadata response between both contract types
• Make adjustments to any libraries already consuming the drop-utils

[0xTranqui]

@dblodorn this loom I recorded explains exactly how we will be able to support generative editions, and also just a review of the new public facing data structures more broadly in the new curation protocol https://www.loom.com/share/92fd2144b65f41669ddd390b6d4902ca

[dblodorn]

@0xTranqui
The data shape that is returned by the curator contract has changed, now it looks like this:

you call getListings

you get an array of this object:

listing: {
    curatedContract: string (erc721 contract address),
    tokenId: number (if this is a generative / convention nft contract - it will be the tokenId otherwise it will be set to 0),
    curator: string (wallet address of curator of the token),
    curationTargetType: number (see types below) 1 | 4 - for this pass (ie edition vs generative contract),
    sortOrder: number (0 in this case - sort order not implemented),
    hasTokenId:  bool (true if generative contract - CURATION_TYPE_NFT_ITEM, false otherwise),
 }

/**
* curationTargetTypes:
*/
uint16 public constant CURATION_TYPE_GENERIC = 0;
uint16 public constant CURATION_TYPE_NFT_CONTRACT = 1;
uint16 public constant CURATION_TYPE_CURATION_CONTRACT = 2;
uint16 public constant CURATION_TYPE_CONTRACT = 3;
uint16 public constant CURATION_TYPE_NFT_ITEM = 4;
uint16 public constant CURATION_TYPE_EOA_WALLET = 5;

[0xTranqui]

Yep dain this is it 👍