Should we update the naming for existing curation types?

[salieflewis]

I'm looking over the curation types outlined in CurationStorageV1, and finding that all the types are not necessarily super intuitive. For instance, the first type, GENERIC, I'm not really too certain on what that means, it only really makes sense in the context of all the other types.

I'm proposing that we come up with simpler or more specific naming, as well as add comments above each type to describe when it should be used. I began this as a discussion rather than an issue because it'd be helpful to get some fresh eyes/opinions on this particular matter.

@projectmehari @0xTranqui @ioeylim

[0xTranqui]

thx for getting this convo started @salieflewis. to adequately answer this, its also necessary to have a discussion about what is getting stored in the Listing struct

Based on work from the various proof of concepts, I have a feeling that we should simplify the curation struct, remove the "curator" field which is redundant since the owner of the curation receipt token will always be the curator (since its issued to the minter + is soulbound) -- and potentially the curationTargetType field all together (which would mean we could skip the question about what the target types represent.

the reasoning behind removing the curationTargetType is that it seems like we may be able to use offchain methods to interpret what a contract is (ex: the alchemy indexer returns whether a given contract is a 721 or 1155). the problem that arrises with this is that the same contract could be listed for different reasons (ex: assigned a different curationTargetType), and this would reduce the ability of generic clients to know how to renderer contracts without previous context.

will leave it at that for now, and will also provide an attempt at explaining what the current curation types mean/should be used for, and offer any improvements that immediately come to my attention:

CURATION_TYPE_GENERIC = 0;
^ this is used when you dont want to give an address any context. u are purposefully labeling it as a generic address, that should not be rednered as an nft, a wallet, etc. this could be used in a situation where someone is curating a list of approved minter modules for example

CURATION_TYPE_NFT_CONTRACT = 1;
^ this is used when you want to reference an nft contract at the collection level. this is confusing because the collection level means something different for 721 + 1155. historically, this curation type is what we have used when curating 721 editions -- in conjunction with hasTokenId == false in the curation struct.

CURATION_TYPE_CURATION_CONTRACT = 2;
^ this one is much more obvious. you use this when you are trying to call attention that the contract you have listed is itself a curation contract, meaning you probably want to drill down deeper into it to understand its contents (or perhaps do a lookup to figure out who the admins on it are)

CURATION_TYPE_CONTRACT = 3;
^ after typing out the reasoning behind generic, it is clear that this type is redundant. the thinking here if i remember correctly is that generic (being the 0 value) is the default "i have made no decision about what this listting is" -- which is techincally less opinioanted than actually specifying that the contract you are curating should be observed as a generic contract. it may actually make sense to keep both of these for that reason (default null values are helpful), but perhaps we can simplify

CURATION_TYPE_NFT_ITEM = 4;
^ this is used when trying to list a specific tokenId. this historically has been used when curating a token on 1155, which itself represents an edition -- it is also paired with hasTokenId == true and a specific value in selectedTokenId in the curation struct. this can be kind of confusing because tokens represent different things in 721 vs 1155

CURATION_TYPE_WALLET = 5;
^ this is used when listing a contract address that you want to define as a wallet (be it EOA or smart contract wallet). this feels helpful as wallets are generally used these days as identifiers of users, but could become confusing as the line between eoa/user/smart contract wallet potentially blurs in the future

[salieflewis]

I'll defer to you about whether or not we should ultimately get rid of curationTargetTypes. It sounds like, they could still be useful in the future. My suggestions for this then revolve around some potential naming changes (given your descriptions) as well as adding comments to each type. And I agree that the curator should be removed from the Listing struct if that information is readily available without needing to define it.