Packs Metadata Standard

[austinkline]

Issue To Be Solved

Some NFTs on Flow are Packs. They can be opened to obtain the contents inside of them, but are largely useless afterwards. Two examples of this are NFL All Day packs, and Gaia NFT Packs. In both of these cases, there isn't a standard metadata view to designate them as opened. Because of that, users are at risk of purchasing a pack they might not know is empty.

This view adds a way to detect if something is a pack, letting marketplaces decide what they should do with that information. Perhaps that just means displaying that the pack is opened, or it could mean disabling trading altogether.

Suggest A Solution

#148

Context

Flowty recently launched a secondary marketplace on Dapper Wallet for the entire nft catalog. As a result, Gaia and All Day packs are technically supposed to be supported but there isn't a way to determine if they are empty or not, so we can't fully inform our users about what they're buying

Contributors

Some solutions have been proposed for this in these comments and in the PR. Please leave feedback here or in the PR for what you'd like to see in a packs standard. Or, propose a new view for packs!

[joshuahannan]

Thanks for creating an issue! An open question is how to display the status. The suggestions are:

• Enum: very straightforward, but cannot be easily upgraded
• String: easy to upgrade, but is almost too customizable
• Integer with switch statement to return a string: More boilerplate code but it can be upgraded.

I think there are good arguments for each. I lean towards enum because i think it is the cleanest and I can't think of other pack statuses that could be introduced in the future, but I'm not as familiar with those mechanics as others so we need some more input

[chriswayoub]

In my opinion, "pack" might be too specific for the use-case you are considering. I think the idea of a consumable NFT would make the most sense to tell if something has been used/opened/depleted. Potentially something simple like:

pub enum ConsumableState: UInt8 {
    pub case NotConsumed
    pub case PartiallyConsumed
    pub case Consumed
}

pub struct Consumable {
    pub let state: ConsumableState // current state of the consumable
    pub let description: String // human readable description of the consumable state (ie: "Opened", "Sealed", "Full", "Empty")
    pub let charges: UInt64? // could be used for something that has multiple uses or charges potentially
    pub let maxCharges: UInt64? // indicate the maximum number of charges for this consumable
}

I'm not married to this exact structure, but it has the properties that I think I would find useful to cover different scenarios:

• Packs
• Redeemable tickets
• Potion with multiple charges

I think that there could be additional views for more specific implementations like packs if necessary, but something like the above would allow me to easily indicate to a user the state of any consumable thing on a marketplace.

[cybercent]

I think Consumable is a more complex use case and it should be addressed separately.
Packs are mainly a container and have no value on their own, without the contents.

[chriswayoub]

I agree that packs and consumables are two separate concerns, but if the use-case of this proposal is to prevent the sale of a "useless" item in a marketplace then I would recommend thinking about it from a more generic perspective than just packs. Otherwise we'll end up adding support for packs, and then have to add support for other additional very specific metadata views as they are added.

I don't have a problem two views (pack and consumable), but knowing the intent of this proposal I don't think that the pack view should be added without also adding a more generic view to represent a "consumed" state

[cybercent]

Maybe for packs the correct behavior would be to have the NFT destroyed once opened.
This could be done in the pack opening function.

[bjartek]

Maybe for packs the correct behavior would be to have the NFT destroyed once opened. This could be done in the pack opening function.

I agree on this one. Resources that have no meaning should be destroyed.

[bjartek]

I prefer this one to packs to be honest. Is a voucher a pack? what about a float that can give you a one time benefit? I think this is abstracts it nicely.

[bluesign]

Maybe for packs the correct behavior would be to have the NFT destroyed once opened. This could be done in the pack opening function.

I agree on this one. Resources that have no meaning should be destroyed.

This can have value to the user though, I mean like keeping the box of product you bought. If I buy let's say doodles launch pack, it is more valuable then doodles 10th pack release ( even it has no function later )

I think @chriswayoub's idea of consumable covers the pack logic nicely.

[joshuahannan]

I like the consumable view a lot too and the additional fields provide a lot of flexibility for how you want to use the consumable view

[joshuahannan]

Anyone have more thoughts about this? This and the PR have been open for a couple months without much movement. I don't have enough knowledge about what apps want to see in a packs standard to be able to move this forward on my own, but I'm happy to help get this completed if the people here come to some consensus on a standard? Does everyone think that the consumable view from @chriswayoub is good?

[austinkline]

Anyone have more thoughts about this? This and the PR have been open for a couple months without much movement. I don't have enough knowledge about what apps want to see in a packs standard to be able to move this forward on my own, but I'm happy to help get this completed if the people here come to some consensus on a standard? Does everyone think that the consumable view from @chriswayoub is good?

Sorry @joshuahannan, crazy few months! I think with TopShot looking at making their packs into NFTs, settling on this and then getting hem to implement it is pretty important.

Consumable is good with me, it's more able to encompass things that aren't one-time actions. I'll slot some time in to amend the open PR with this and ping folks once it's done.