Discussion for ARC-0003 - Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens

fabrice102 commented 3 years ago

Draft is https://github.com/algorandfoundation/ARCs/blob/main/ARCs/arc-0003.md See also proposed PR that may be listed below.

Included but not limited to the following points of discussion:

Adding the possibility to store the JSON metadata file in the note of the transaction creating the asset. If such an option is added, the indexer should ideally be modified to be able to more easily read such a note.
Comment on the integrity format for localized JSON metadata files.
Use of the terms "NFT" and "fractional NFT"

barnjamin commented 3 years ago

Overall I very much like this, thank you for taking the time to put it together.

Adding the possibility to store the JSON metadata file in the note of the transaction creating the asset. If such an option is added, the indexer should ideally be modified to be able to more easily read such a note.

I like this idea in theory. To me the creation of an asset should be treated with some special consideration. If the note field was used to store the metadata document the URL field should either contain:

A Direct link to the digital media
A URI constructed to reference the note field, maybe something like algorand://{txnid}/note

Use of the terms "NFT" and "fractional NFT"

The term "fractional NFT" seems to contradict itself, I'd like to suggest completely removing it from the ARC. If the ASA is not 1 of 1, I don't think it can be referred to as non-fungible since Algorand doesn't uniquely identify the underlying units, making them completely fungible.

Perhaps there should be another ARC or an addendum or separate section to prescribe how one might "fractionalize" an NFT (ASA with supply of 1 unit) to make some supply of tokens > 1 that represent ownership of the underlying NFT.

If the name for an NFT was different I'd take no issue with fractional ownership of some digital media. If it were called a Tokenized Digital Asset the fractional aspect would seem natural.

ChrisAntaki commented 3 years ago

People commonly refer to tokens with supplies of 1-100 or so as "NFTs"

Ex: https://niftygateway.com/collections/warnymphvolume1

Constraining the spec to just 1/1 NFTs seems unnecessary, and could hurt this spec's adoption among the NFT community

ChrisAntaki commented 3 years ago

If the indexer could return the creation note field, along with the other ASA details, that would be incredibly useful, beyond this spec even

ChrisAntaki commented 3 years ago

A Direct link to the digital media

The Algorand NFT community is doing this currently. It's nice because clients can fetch the media ASAP, right after fetching ASA details. If the indexers and APIs started including the creation note with the ASA details, and the JSON was in that note, clients could keep on fetching the media ASAP 👍

barnjamin commented 3 years ago

People commonly refer to tokens with supplies of 1-100 or so as "NFTs"

If it is common use already, OK. I don't want to die alone on this hill and I don't want to try and argue with the hoards of folks already calling them NFTs.

Maybe I'm being pedantic but it is still is a misnomer since >1 supply of indistinguishable units makes them absolutely fungible, right?

ChrisAntaki commented 3 years ago

Haha, I think you're totally right

Meeting the audience where they are just seems like the best move, in my opinion

Here's another example: https://www.dahai.uk/lot/1057#ARTB

This is a non asset backed NFT that may not be redeemed for the original artwork.

Sold as an edition of 10.

NFT has come to mean digital collectible trading card, essentially

cusma commented 3 years ago

I know this argument may sound a little contradictory with respect the concept of uniqueness and fungibility but I think we should reason about "intrinsic fungibility" and "extrinsic fungibility", extending the NFT definition to “Fractional-NFT”. I don't want to sound wordy but I will try to point out why it is not just a "wording" matter.

“Pure NFTs”, like collectibles or identities are ASAs with total supply 1 and decimals 0, which uniqueness is ensured by the Asset ID itself. “Fractional-NFT”, in my opinion, are ASAs representing wider non-fungible asset classes with huge cardinality of instances, like intellectual property, whose ownership/management can be fractionalised.

In this sense you may have tokens whose fractional parts are fungible among themselves but, taken as a whole, they are different and non-fungible instances of the same tokenisation class.

Let me give here a more concrete example: suppose we want to create a standard way to tokenize intellectual property. Now, nobody would disagree on the fact that the intellectual property is “non-fungible” per-se, in the sense that each right over any creative production is really different from one to another, so that these ASA IDs represent a really non fungible kind of real world assets. At the end of the day those assets are strictly personal and different among authors (Tom Jobim != Ennio Morricone).

Now, intellectual properties rights may have so many different attributes, like: reproducing music in public, use a lyrics, expose a piece of art, make use of a photo and so on.

In this example specifically, for each author you can have a bunch of ASAs, with the same name (maybe related to the author), with the same unit name (maybe related to the common issuance application) but with different attributes (which identifies the intellectual properties categories that are common to the whole tokenisation class). What really differentiate the ASAs is always the Asset ID and their supply just enables a shared ownership/management of that non-fungible tokenisation class.

Given the fact that for such use cases the cardinality of different ASAs will be huge, making them fractional does not make them, in my opinion, fungible among themselves. Their fungibility is only "intrinsic" if you wish.

So, although there will exists 100 units of “Tom Jobim musical work” this copyright is really non-fungible with “Ennio Morricone musical work”.

Just my 2 microALGO.

KBryan commented 3 years ago

1, I think I have enough backstory on why this is a suggested option. If this is the case, it should be more flexible or abstract but have some predefined properties to build on.

2, Possibly a content hash that is { "title":"Asset Data", "type":"object", "properties": { "creator":"string", "assetid":uint, "description":"string", "media_url":"string", ...// option for extended properties } }

3, The term fractional NFT is new to me. If I understand this correctly, would it allow partial ownership say x% of the NFT?

fabrice102 commented 3 years ago

There seems to be many definitions of NFTs. Let me try to illustrate with examples 4 cases:

A single unique object like the original "Mona Lisa" painting. Total supply = 1, decimals = 0. The ASA represents ownership of this single unique object. I think everyone agrees to call this an NFT. That is what @cusma calls pure NFTs.
Shares of a a single unique object, e.g., share of a specific rental building or share of a specific intellectual property asset (like “Tom Jobim musical work” to re-use @cusma examples). Total supply = 100, decimals = 0 for example, if we want 100 shares. That is what @cusma calls fractional NFT. Each share itself is fungible but the ASA globally represent an "NFT"
Small number of exact copies of the same object: for example, 10 identical printings of a piece of arts. Total supply = 10, decimals = 0. Some people seem to consider those as NFT, but at least formally, the 10 copies are actually fungible. It is an NFT in the very extended meaning of "ownership of some piece of art or physical object".
Multiple sculptures created from the same mold but with a way to distinguish them (e.g., a serial number on them). If the goal is to keep distinguishing them, I think the only solution is to create a pure NFT for each of the sculptures.

Questions: a. Do you think this represent all the cases people name NFT? b. Should case 3 be also called an NFT? Or a "..." NFT? c. If case 3 is an NFT, should there be a way to indicate the intention that this is an NFT? Can this be a field in the metadata?

Personally, I would tend to think case 3 should not be called an NFT, but I'd like to understand what the consensus is.

ChrisAntaki commented 3 years ago

Cases #1 and #3 sound closest to how real-life NFT creators/collectors use the term, at least from my experience

https://www.dahai.uk/lot/1057#ARTB (Dahai)
https://niftygateway.com/collections/warnymphvolume1 (Grimes on Nifty Gateway)

barnjamin commented 3 years ago

I think you summed it up well @fabrice102. And @cusma thanks for explaining how you think about it. I do not want to try and go against the common use even if it isn't TeChNicalLy correct use of the term fungible.

b. Should case 3 be also called an NFT? Or a "..." NFT?

If this is something we do want to change, I would say we take out the N completely and make it SFT/PFT for Semi Fungible or Pseudo Fungible tokens.

Another topic, I started using https://nft.storage/ instead of the vanilla ipfs client to deal with storing the Images/Metadata and the structure is required to be as ERC-1155 but the metadata.json and image are stored in a directory together.

e.g. at ipfs://bafybeigtnw6qqyv7a4b4mgpm7fovfw6phme6xddzu5ycl5eqnmbhsxyfoy/metadata.json is the payload:

{
  name: "surfboi",
  description: "hawaii 2018",
  properties: {
    file: {
      name: "QmUNPvC36Du4pGEpbzaBzGhi5xP51sQkYT6MrcJhTSx9BV.jpg",
      size: 2470195,
      type: "image/jpeg"
    },
    artist: "mother earth"
  },
  image: "ipfs://bafybeigtnw6qqyv7a4b4mgpm7fovfw6phme6xddzu5ycl5eqnmbhsxyfoy/QmUNPvC36Du4pGEpbzaBzGhi5xP51sQkYT6MrcJhTSx9BV.jpg"
}

So what should the URL in the token be? the full metadata URL with ipfs:// protocol? the IPFS gateway? just the directory and metadata.json is assumed?

cusma commented 3 years ago

@fabrice102

Questions: a. Do you think this represent all the cases people name NFT? b. Should case 3 be also called an NFT? Or a "..." NFT? c. If case 3 is an NFT, should there be a way to indicate the intention that this is an NFT? Can this be a field in the metadata?

a. Yes, I believe so.

b. We should not call case 3 "NFT". I don't know how many of you are passionate about card games, a-la Magic the Gathering, but I think playing cards are a good example of case 3. If a Magic the Gathering card has the same name, the same art-work, obeys the same rules of the game then that card, even from the point of view of a regulated use in a tournament, is completely fungible or exchangeable with other players. There may be N copies of a card - not necessarily a power of 10 - and possibly be reprinted in the future modifying the print run. When present in multiple copies in the same deck these cards are indistinguishable from each other. So although there could be over tens of thousands of different cards in Magic the Gathering today, copies of each of these cards are fungible (even at the game rules level), so assets of this type shouldn't be classified as NFT in my opinion.

c. See point b.

fabrice102 commented 3 years ago

So what should the URL in the token be? the full metadata URL with ipfs:// protocol? the IPFS gateway? just the directory and metadata.json is assumed?

From my quick look at nft.storage, I would say, you need to put ipfs://bafybeigtnw6qqyv7a4b4mgpm7fovfw6phme6xddzu5ycl5eqnmbhsxyfoy/metadata.json.

I think it's best to use ipfs:// protocol instead of gateways when using the ipfs protocol. The reason is gateways may disappear while hopefully the ipfs protocol won't.

What do you think?

barnjamin commented 3 years ago

I think it's best to use ipfs:// protocol instead of gateways when using the ipfs protocol.

Def, not to mention with that url and a medium length domain for the gateway you're getting close to the char limit for url in the asa

shaih commented 3 years ago

I mostly agree with @cusma on this matter, here is my suggestion for naming, hopefully it is not too far from what people are using:

One unit, decimal = 0: NFT
Many units, sharing rights in a "non-fungible object": maybe Shared NFT? For this we require decimal = log_10(units)
A few units, identical objects: this is not a NFT at all, so let's not call it this (even if some others do). Is there anything to standardize for this type? If so then we need a different name, maybe Collection?

cusma commented 3 years ago

One unit, decimal = 0: NFT

Many units, sharing rights in a "non-fungible object": maybe Shared NFT? For this we require decimal = log_10(units)

A few units, identical objects: this is not a NFT at all, so let's not call it this (even if some others do). Is there anything to standardize for this type? If so then we need a different name, maybe Collection?

Since we are trying to classify different kind of Algorand Standard Assets I think that, at least on a more formal level (like internal specs and docs), we should start adopting an Algorand-oriented naming convention.

I'm suggesting this because the general concept of token (inherited form other blockchains) do not always re-map exactly just to the concept of ASA (with all its properties like, the role-based management and so on). To be future-proof with respect to Algorand itself, we should avoid confusions with other protocol features that may be used to model "tokens": someone can come up with an ASC1-based implementation of a "token".

Since here we are trying to define naming conventions strictly related to the Algorand Standard Assets, I think we should clearly specifying an ASA-oriented naming convention, at least for formal contents (internal specs, docs, etc.), something like:

Non-Fungible ASA (commonly NFT in other blockchains): total supply = 1, decimal = 0
Fractional or Shared Non-Fungible ASA (commonly Fractional NFT in other blockchains): decimal = log_10(total supply)
ASA Collection (to reuse @shaih example), in this case I would say that decimal = 0 should be a requirement, otherwise this type would be indistinguishable form any other Fungible ASA.

KBryan commented 3 years ago

I agree with having an Algorand angle to the asset as it behaves on a specified blockchain. Although, having a new name for an "asset" with cross-chain characteristics seems a bit much. The word NFT is the word used by the blockchain and greater community but have the 'a' in front of it to define the specific features that Algorand adds. Like aNFT.

runvnc commented 3 years ago

I know that media is only one use case, but would it be possible to standardize somewhere a field for MIME type (such as video/mp4, image/png, etc.)? Maybe if it has to go in the sub-properties, would be nice to have a standard field name for it. mimeType or contentType maybe.

barnjamin commented 3 years ago

Definitely think mimetype would be a good recommended field. Also things like byte size and for an image maybe dimensions or for audio maybe duration

runvnc commented 3 years ago

Overall I very much like this, thank you for taking the time to put it together.

Adding the possibility to store the JSON metadata file in the note of the transaction creating the asset. If such an option is added, the indexer should ideally be modified to be able to more easily read such a note.

I like this idea in theory. To me the creation of an asset should be treated with some special consideration. If the note field was used to store the metadata document the URL field should either contain:

A Direct link to the digital media

A URI constructed to reference the note field, maybe something like algorand://{txnid}/note

Use of the terms "NFT" and "fractional NFT"

The term "fractional NFT" seems to contradict itself, I'd like to suggest completely removing it from the ARC. If the ASA is not 1 of 1, I don't think it can be referred to as non-fungible since Algorand doesn't uniquely identify the underlying units, making them completely fungible.

Perhaps there should be another ARC or an addendum or separate section to prescribe how one might "fractionalize" an NFT (ASA with supply of 1 unit) to make some supply of tokens > 1 that represent ownership of the underlying NFT.

If the name for an NFT was different I'd take no issue with fractional ownership of some digital media. If it were called a Tokenized Digital Asset the fractional aspect would seem natural.

I hope you guys will really seriously think about taking advantage of the space in the note field for this. For NFTs, what are those 1000 bytes being used for really? Seems perfect for metadata.

TheWolfWhoSaidWoof commented 2 years ago

There may be N copies of a card - not necessarily a power of 10 - and possibly be reprinted in the future modifying the print run

There may be cards which are true NFT with no future print run. The ASAs in algorand are fixed at creation so it should be clear to owners how many there are. I don't think using powers of 10 is a good way to identify an NFT. It is rather limiting to the economics of games using NFTs that may need subtle balancing.

I picked a Rand Gallery collection and there were a number of non power 10 NFTs e.g. https://www.randgallery.com/algo-collection/?address=ROBOTWCDPDJ5YUOSG443OIZEDYFZ67RALBBNKWJWMMS2744HLBIR4WAVYM

Nice to see this discussion going on!

ChrisAntaki commented 2 years ago

I picked a Rand Gallery collection and there were a number of non power 10 NFTs

Nice! Rand Gallery is my side project, hope you're liking it! 🖼️

I don't think using powers of 10 is a good way to identify an NFT

Haha, yeah real creators definitely aren't limiting themselves to powers of 10

cusma commented 2 years ago

@TheWolfWhoSaidWoof, @ChrisAntaki I think there could be a misunderstanding regarding the power of 10.

Just to clarify:

A total number of units equal to the n-th (n ∈ ℕ) power of 10 and the decimals equal to the logarithm in base 10 of total number of units, is a requirement that defines Fractional-NFT. This ensures that a Fractional-NFT will always have a unitary supply, while being divisible up to the n-th decimal position.

So:

for n = 0, we have a Pure NFT with total supply 1 and no shares.
for n > 0, we have a Fractional NFT with total supply 1 and 10^n shares.

Not having this specifications, allowing arbitrary total number of units and arbitrary decimals, would turn the definition of such a standard/convention impossible, bringing us back to the starting point: no rules and no clear definition of the concept of NFT within the ASA framework.

algokittens commented 2 years ago

The genesis message is already used to store NFT MetaData by AlgoGems and OriginMint. I think it makes sense to build on this and to support legacy NFTs by improving the indexer so it is easier to fetch the data.

Using the URL to add the metadata would also work (and seems to be what you are proposing), and I like that it provides a quicker solution than waiting on genesis indexing implementations.

However, if both are feasible why go with the off-chain solution?

In terms of defining "NFTs", if you must have a definitions, what about a "semi" or "pseudo" NFT, e.g. supply >1 but non-divisible (and maybe <1,000). Many artist mint digital art with supplies of 3, 5, 9, 12, 21 etc. why prevent them from following the MetaData convention?

TheWolfWhoSaidWoof commented 2 years ago

@cusma "Not having this specifications, allowing arbitrary total number of units and arbitrary decimals, would turn the definition of such a standard/convention impossible, bringing us back to the starting point: no rules and no clear definition of the concept of NFT within the ASA framework."

I see your point. Perhaps just don't allow both decimals and an arbitrary number. That leaves 2 ways to do an NFT. Either a fixed integer supply (no decimals) or a power of 10 fractions of 1 NFT. Both of those might have different use cases. The former being good for gaming tokens or card games. The latter for curency like cases, we don't use pieces of eight anymore.

I think I am repeating what you said above Cusma!

runvnc commented 2 years ago

I guess the issue for someone like me who has a gallery function is that standardizing on referencing JSON in the URL instead of the content means that the gallery system will have to do significantly more work, UNLESS everyone includes the MIME type in the sub-properties, before it can display the media. Right now I do one Indexer query per asset which I cache, then I hit the URL to look at the content-type header (unless this is already cached), then pass URL and content type to my web page to display.

So if the URL is a JSON file, this introduces another HTTP request before I can get the media URL to look up the content type. Now if we can just agree to put the media type like image/png in the properties of the properties and pick a name such as mimetype, then I will be able to use that instead of the HTTP request to the IPFS gateway to look at the content-type header. And so it will end up being the same amount of work per media.

As far as using the metadata in the Note field, I don't recall if this was mentioned already but I feel like it might be way better if the convention encoded this somehow. Like maybe using the unit name, possibly @arc3n or something.

The thing about it is, since NFTs can be literally anything and are not necessarily images or even media of any kind, the metadata is really critical and so I think my gallery will eventually need to stop assuming assets are media without checking it. Actually I think that not having a metadata field directly attached to the asset might have been an oversight. And since they are talking about all of these crazy massive changes to the AVM such as generating transactions inside of contracts and getting 7000 executions instead of 700, I am just going to go ahead and open an issue on go-algorand proposing that we get a metadata field in the asset. Probably not feasible but wth, it's Saturday, why not troll a little.

If we are not doing that, it would sure be nice if the Indexer could look up the origination note for us and give us that when we query the asset.

fabrice102 commented 2 years ago

Regarding mimetype

I guess the issue for someone like me who has a gallery function is that standardizing on referencing JSON in the URL instead of the content means that the gallery system will have to do significantly more work, UNLESS everyone includes the MIME type in the sub-properties, before it can display the media. Right now I do one Indexer query per asset which I cache, then I hit the URL to look at the content-type header (unless this is already cached), then pass URL and content type to my web page to display.

@runvnc, Do you need to know precisely the mimetype or whether it is an image or not? The current proposal follows ERC-1155 that essentially provides an image and other arbitrary property. My understanding is that if the media is not an image, the image would be a thumbnail and you would provide link to the actual document otherwise. For example, on opensea, they use a property called external_link (https://docs.opensea.io/docs/metadata-standards#metadata-structure).

fabrice102 commented 2 years ago

A question for everyone, since there are so many definitions of NFTs, would this be simpler to add a field nft that is either true or false in the metadata.json file. This way, every creator can decide for themselves whether they want to be considered an NFT or not.

In that case, should the field nft be mandatory? If it is not mandatory, what would be the default?

KBryan commented 2 years ago

@fabrice102 I'm liking this approach as this allows for flexibility. I don't see an issue with having an NFT property as mandatory. I'm actually for it. Would this allow the creator to add additional properties to the base construct NFT?

barnjamin commented 2 years ago

Idk the NFT param would break from the ERC and I think putting arc3 in the name already sort of flags that it should be treated as an NFT?

fabrice102 commented 2 years ago

I was thinking that arc3 is both for NFT and fungible tokens, the same way as ERC-1155

barnjamin commented 2 years ago

I was thinking that arc3 is both for NFT and fungible tokens, the same way as ERC-1155

ah, my bad. I guess either way the arc3 says its one of the 2, then supply should inform fungible/non?

emg110 commented 2 years ago

Hi everyone! Amazing discussion.

I think :

Fungibility and Non-Fungibility are pretty well and clearly defined economic terms.
The point of difference is not in information, type, structure or creation process but in functionality! Fungibility is a functional property of a valuable item!
Case 1 & Case 2 of what @fabrice102 modeled & simplified are exactly NFTs.
Case 3 (if contains a unique identifier like a serial...) & Case 4 , both could be considered NFTs as long as they are naturally (not by a rule) unable to be traded with each other in 1:1 or N:N direct interchange simply because they have different values.
Non-Fungibility is made possible by absolute uniqueness in value which brings guarantee on impossibility of one-one tradability (simply because there is no other identical one item in existence to interchange within an N:N trade scenario) .

SOLUTION for CASE3 & CASE4 to become guaranteed being NFTs: We can come up with a new added value to guarantee the value uniqueness (value difference is not caused by serial number difference but identified and recognized by it) . This means giving a unique purpose or unique value to every and each one of those identical assets to differentiate their values and therefore non-fungibility is naturally imposed.

Example: Fungible: 1000 identical copies of a single digital art , each carries a unique ID. Non-Fungible: 1000 identical in design copies of a single digital art , each carries a unique ID and unique color tone (guaranteed to be unique). The unique color tone make it disputable to assume the value of any pair from those 1000 to be considered the same value therefore directly interchangeable in 1:1 or N:N scenarios.

During ASA configuration, setting the total amount of asset to 1 and decimals to 0 is just one way of imposing that value uniqueness by guaranteeing a single entity existence on chain for that ASA but that's not the whole story to NFTs because it does not (easily and in one go) cover CASE2, CASE3 & CASE4 scenarios.

Usage of METADATA HASH field could help achieving this, for example having a CHECKSUM of the actual content in METADATA HASH field paves the road for a smart contract logic to provide equality checks and therefore overall uniqueness in value, hence non-fungibility. There is even the possibility of multi-part hash combinations in METADATA HASH field.

whereisrysmind commented 2 years ago

Hi All, great discussion, I wanted to share my own first pass at an extended metadata schema, specifically for artistic media ASAs. I'd be honored to get some reviews on it and perhaps, one day, see it incorporated into the official standard.

https://github.com/ZestBloom/ARCs-AAA/pull/1

emg110 commented 2 years ago

Regarding fractional NFTs, I think when you break an absolutely unique entity to fractions with unique identifiers and differentiators , the result is a set of absolutely unique fractions of that entity, for which there exists an algorithm for reconstructing it back as a whole (say NFT) given all set members being present. I think this way one can make sure there are no 1:1 or N:N direct exchangeability because every and each has unique value & identity to recognize it.

I think there can be two types of fractional NFTs: Hierarchical(or vertical) and Non-Hierarchical (or horizontal or mosaic).

If there is a parent NFT to which all fractional NFTs subside then we have a Hierarchical Fractional NFT which is well suited for asset portfolios and such nested asset structures. If there is no parent and all fractional NFTs together ensemble an NFT set entity , then it's a Non-Hierarchical NFT.

Note: the IPFS integration and also hierarchy are completely possible to implement via usage of MetadataHash field of ASA (no need for TXN note field), so just like there is no need to define any type or format to differ NFT and FT on Algorand ASAs (they can be reflected in functionality and determined by immutable configurations and structure of ASA).

fabrice102 commented 2 years ago

Following comments, we've added 4 new pull requests modifying the ARC-0003:

11 allows the use of {id} in URIs in order to later allow storing metadata in the note fields, following discussions in #6. The format for storing metadata in the note field is not yet defined but we should hopefully soon provide an ARC for that purpose.
Since it seems extremely difficult to get a consensus on what should be called NFT and what should not be called NFT, #12 renames "NFT" into "pure NFT" and leaves open the use of the name "NFT". After this change, ARC-0003 will only define "pure NFT" (i.e., total supply = 1, decimals = 0), and "fractional NFTs" (defined as before)
13 adds the support for integrity properties in order to ensure that the integrity of every file referenced by an NFT or an ASA can be ensured just from the metadata hash. Without these integrity properties, a seller may for example change the image of an NFT after selling it. An added advantage of using those integrity properties is that any marketplace can cache the image, and even if the image is no more available, the marketplace can provide it and prove its authenticity. These integrity properties are optional to be backward compatible with ERC-1155. However, they are strongly recommended.
14 adds support for extra metadata. This PR introduces important changes in the computation of the metadata hash when extra metadata are used. Asset creators do not need to worry about it if they do not use extra metadata. However, marketplaces and wallets need to be updated.

The goal is to finalize this ARC by the end of the week so that everybody can start relying on a common convention for NFTs and fungible tokens.

Please speak up by Thursday 2021-09-02 if you strongly oppose any of the above changes and the finalization of the ARC with those changes.

Some answers to comments above

From @whereisrysmind

Hi All, great discussion, I wanted to share my own first pass at an extended metadata schema, specifically for artistic media ASAs. I'd be honored to get some reviews on it and perhaps, one day, see it incorporated into the official standard. https://github.com/ZestBloom/ARCs-AAA/pull/1 I think it is a great idea to add clearer guidelines for specific use cases of NFTs. However, I think it might be better to have it as a separate ARC that extends ARC-3 metadata conventions, rather than merging it into ARC-3 and making ARC-3 too complex.

From @emg110

Usage of METADATA HASH field could help achieving this, for example having a CHECKSUM of the actual content in METADATA HASH field paves the road for a smart contract logic to provide equality checks and therefore overall uniqueness in value, hence non-fungibility. There is even the possibility of multi-part hash combinations in METADATA HASH field.

I'm not completely sure how you planned to use METADATA_HASH in this context, but I think #14 may provide some options.

fabrice102 commented 2 years ago

Also please vote/comment on the following PR https://github.com/algorandfoundation/ARCs/pull/10 by @Bhaney44.

runvnc commented 2 years ago

@fabrice102

Regarding mimetype

@runvnc, Do you need to know precisely the mimetype or whether it is an image or not? The current proposal follows ERC-1155 that essentially provides an image and other arbitrary property. My understanding is that if the media is not an image, the image would be a thumbnail and you would provide link to the actual document otherwise. For example, on opensea, they use a property called external_link (https://docs.opensea.io/docs/metadata-standards#metadata-structure).

On our website which supports auctions, NFT minting, and a gallery, the media in the gallery can be an image, or an audio file, which is rendered into the gallery as an audio element, or a video (using the video element), or HTML (currently shown with a sandboxed iframe). It is not desirable to replace the audio, video, and iframe tags with a thumbnail as this adds a step for people to access their media. We have also had a request to support PDF documents (for writers).

So as it currently stands, I don't see anywhere that there is a recommendation for mimeType or contentType in any document.. which seems a pretty big oversight. So what I am anticipating is that as this is adopted, the main effect, besides hopefully having an artist name in there somewhere? and me spending quite a bit of time going through the various formats to prevent blank galleries, is going to be my server or the client browser doing more work and possibly taking more time to display the gallery media properly.

EDIT: from reading the OpenSea thing, it looks like they are implying that the type is described in the file extension for animation_url or something like that. That doesn't necessarily have as much information as a MIME type (for example, MP4 could be Quicktime or some other format), but its better than nothing. It also doesn't make sense really for audio, PDF, or HTML that is not just an animation. But again, if we want to default to following opensea then maybe that is adequate. My apologies if everyone was just assuming we would use animation_url and the description of content in the filename at the end of the URL, without mentioning and I did not realize it. Or if it was already mentioned.

EDIT 2: Not sure how I can put a file extension describing the content type in an IPFS CID URL or IPFS Gateway URL.

emg110 commented 2 years ago

Regarding https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-908787196 I think Just changing the word transferred to into interchanged would make it perfect because FTs can be transferred between addresses but cannot be intechanged or exchange in 1:1 (or N:N) scenarios.

emg110 commented 2 years ago

I don't think MIME TYPE or FILE EXTENSION can be considered directly part of ASA context and nor is Metadata itself. The functional domains on ASA as a certificate token and Digital Asset (asset's content data + metadata), are different I think. I would prefer to see these two concerns separated! That's why I suggested leaving everything regarding asset digital content and metadata to IPFS (which is built for this) and just keep a CID (checksum and address at the same time) in metadatahash field. Blockchain stores and manages the ASA token and IPFS stores the digital asset content and metadata. Surely file type will not be transparent on the blockchain directly (that's an advantage I think) and if I'm authorized to access the file on IPFS (privacy and security practices can be simply applied separately from blockchain) then I can read and index whatever metadata and content data there is to that digital asset, without having to store and/or reveal them on the blockchain.

runvnc commented 2 years ago

@emg110 I appreciate your participation, and hope everyone doesn't mind too much my own. Unfortunately, I have to be honest, your comment makes no sense whatsoever to me.

emg110 commented 2 years ago

@runvnc, And I appreciate yours, but I would be grateful if you could be kindly more specific by copying the link to the comment you mean! (Changed last comment's text to be more clear anyway! Thanks for reminding me, sometimes I write as I think).

To put it even more simply: I suggest storing digital asset's data + metadata on IPFS and putting the CID (just sha2-256 checksum part of multihash) inside metadatahash field upon ASA creation to guarantee immutability of content and metadata of digital asset (NFT). Then having ASA record would be enough to access metadata and content per say and does not need an indexer to be present to keep transactions (& therefore configuration TXN) to access metadata stored on note field of it. I hope it makes any sense now?

runvnc commented 2 years ago

Ok I understand better what you are proposing. Going to have to bow out of the discussion because I don't want to sound like a broken record.

fabrice102 commented 2 years ago

From @runvnc

from reading the OpenSea thing, it looks like they are implying that the type is described in the file extension for animation_url or something like that. That doesn't necessarily have as much information as a MIME type (for example, MP4 could be Quicktime or some other format), but its better than nothing. It also doesn't make sense really for audio, PDF, or HTML that is not just an animation. But again, if we want to default to following opensea then maybe that is adequate. My apologies if everyone was just assuming we would use animation_url and the description of content in the filename at the end of the URL, without mentioning and I did not realize it. Or if it was already mentioned.

Up to now, we were trying to be close to EIP-1155. But we can consider adding directly the OpenSea fields animation_url, external_url, and youtube_url. We can also allow for any URI field xxx to have a xxx_mimetype property. But I don't think we can make it mandatory.

What do people think?

fabrice102 commented 2 years ago

From @emg110

@runvnc, And I appreciate yours, but I would be grateful if you could be kindly more specific by copying the link to the comment you mean! (Changed last comment's text to be more clear anyway! Thanks for reminding me, sometimes I write as I think).

To put it even more simply: I suggest storing digital asset's data + metadata on IPFS and putting the CID (multihash including sha2-256 checksum of content) inside metadatahash field upon ASA creation to guarantee immutability of content and metadata of digital asset (NFT). Then having ASA record would be enough to access metadata and content per say and does not need an indexer to be present to keep transactions (& therefore configuration TXN) to access metadata stored on note field of it. I hope it makes any sense now?

ARC-0003 is exactly putting the hash of the JSON metadata file (that you can store on IPFS) inside the metadata hash field. It is not using CID but directly the SHA-256 hash because of size.

barnjamin commented 2 years ago

An HTTP request to the media itself, HEAD or otherwise will give the mime type but I don't think it'd be bad to have it as an optional field. There are some other "nice to have" fields like byte size or image dimensions or fps, but since they're different based on what the underlying digital asset is, I think it makes sense to keep them optional

fabrice102 commented 2 years ago

Another remark: OpenSea writes the ArWeave URLs as ar://.... However, this looks non-standard. https://docs.opensea.io/docs/metadata-standards#ipfs-and-arweave-uris So I don't think we should follow this approach here.

emg110 commented 2 years ago

about: https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-909240600 @fabrice102 ,I think that's a 100% correct way that ARC-0003 is doing it then and regarding the size problem : I agree on not using CID because of size (I corrected the comment, thanks!) as I did these PRs and example solutions to address it before: https://github.com/algorand/py-algorand-sdk/pull/229 https://github.com/algorand/js-algorand-sdk/pull/427 https://github.com/emg110/ipfs2bytes32 https://emg110.github.io/ipfs2bytes32/

runvnc commented 2 years ago

OK. For media NFTs, I don't think the MIME type should be optional. The reason it seems that way is because most people just think of them as images and assume they will be rendered as thumbnails at first. And yes, you can do a HEAD request, but that adds an extra request. Maybe I'm the only person who will ever try to render a gallery without assuming everything defaults to a thumbnail, including audio files. But if there is ever another person who wants to know whether it's an audio file or something that has a thumbnail even before they try to render the gallery without doing an extra HEAD request, then that person will wonder why there was no mimetype.

Or let's say you are not even displaying a gallery but making something like a written list of media for a wallet. You are really going to do a HEAD request for each one? I'm sorry that I am so stupid apparently but this is so strange to me that this is somehow controversial. Maybe I am missing something obvious.

Anyway, if there is no recommendation or anything official, I will go with mimetype since at least that's close to what fabrice mentioned.

scholtz commented 2 years ago

My comment is here: https://forum.algorand.org/t/arc-0003-algorand-standard-asset-parameters-conventions-for-fungible-and-non-fungible-tokens/4133

my main issue is with the hash which in my opinion should not be hash of the metadata but real data.. the reason for it is that the metadata can be updated (eg with translation), but the hash of the resource must not.. also in the metadata you do not even have the hash field of the nft which i honestly do not understand why

please read my comments in the forum, there is some more points which are wrong here

algorandfoundation / ARCs

Discussion for ARC-0003 - Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens #3

11 allows the use of `{id}` in URIs in order to later allow storing metadata in the note fields, following discussions in #6. The format for storing metadata in the note field is not yet defined but we should hopefully soon provide an ARC for that purpose.

14 adds support for extra metadata. This PR introduces important changes in the computation of the metadata hash when extra metadata are used. Asset creators do not need to worry about it if they do not use extra metadata. However, marketplaces and wallets need to be updated.

algorandfoundation / ARCs

Discussion for ARC-0003 - Algorand Standard Asset Parameters Conventions for Fungible and Non-Fungible Tokens #3

11 allows the use of {id} in URIs in order to later allow storing metadata in the note fields, following discussions in #6. The format for storing metadata in the note field is not yet defined but we should hopefully soon provide an ARC for that purpose.

14 adds support for extra metadata. This PR introduces important changes in the computation of the metadata hash when extra metadata are used. Asset creators do not need to worry about it if they do not use extra metadata. However, marketplaces and wallets need to be updated.

11 allows the use of `{id}` in URIs in order to later allow storing metadata in the note fields, following discussions in #6. The format for storing metadata in the note field is not yet defined but we should hopefully soon provide an ARC for that purpose.