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

[fabrice102]

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]

the reason for it is that the metadata can be updated (eg with translation),

But the URL field and metadata hash field are immutable, so if the metadata changes and it points to an IPFS CID, this URL will also change. A hash of the underlying digital asset may be included in the metadata and that is addressed here https://github.com/algorandfoundation/ARCs/pull/13

[emg110]

I think this is the whole purpose of NFTs to be immutable and tamper-proof once they are created, so that no one, not even the owner can change or cheat on the content which is certified by NFT token on the blockchain. I do not see a scenario during which an NFT metadata needs changing! (This I might have understood your comment wrongly! If so, apologies in advance dear @barnjamin ) . Any required alteration and mutation in NFT's associated content and metadata has to be a destruction/recreation process, in my opinion.

[jannotti]

If you do have a need for mutable state in an NFT, the four addresses could be co-opted. For example, the reserve address serves little point. I like to imagine an NFT where the manager address is set to a logicsig in which the logcsig is willing to change the other addresses for anyone who owns the NFT.

If you own a Picasso, I guess you're allowed to scribble on it.

[algokittens]

Any thoughts on adding a suggested format for NFT "collections"? For example a NFT collection might span 10,000 assets, which would be minted across 10 different accounts due to the 1k asset limit. It would make sense to include these other addresses, or a collection identifier somewhere in the meta data.

My thought would be to include a sha-256 of the addresses that span the collection like so: "collection": { "type": "string", "description": "sha-256 of concatenated addresses spanning collection" } But there might be better solutions?

[Bhaney44]

Any thoughts on adding a suggested format for NFT "collections"? For example a NFT collection might span 10,000 assets, which would be minted across 10 different accounts due to the 1k asset limit. It would make sense to include these other addresses, or a collection identifier somewhere in the meta data.

My thought would be to include a sha-256 of the addresses that span the collection like so: "collection": { "type": "string", "description": "sha-256 of concatenated addresses spanning collection" } But there might be better solutions?

I think collections would just make it more confusing and create a barrier to entry. A collection is a marketing term, which certainly may be a good business strategy, but not a specification for NFTs on the blockchain. Moreover, I would consider using SHA-512 instead to ensure the cryptography is quantum secure.

hash0 = hashlib.sha256()
hash1 = hashlib.sha512()

Quantum computers are scaling faster than most suspect and brute forcing SHA-256 with a quantum computer may already be possible given the landscape in hardware architectures is so diverse. I think a better solution would be to simplify the architecture as much as possible and then handle collectable aspects through marketing. I generally like the idea of collections, just not as an ASA parameter.

[scholtz]

What about adding the licence to the metadata?

What about adding the link of optional other changes to the metadata so that the first metadata does not have to change, and users have option to update some things later.. Eg if you forget to put the licence to the first specs and people will want to specify the licence for the already minted nfts? Or the translations, or i dont know, whatever the ARC0003 will decide in the future?

[fabrice102]

The four PRs above (#11 , #12 , #13 , #14) are now merged. An additional PR (#15) to clean up the style has been merged too, in particular to address the confusing duplication of the metadata with and without localization (thanks @scholtz - https://forum.algorand.org/t/arc-0003-algorand-standard-asset-parameters-conventions-for-fungible-and-non-fungible-tokens/4133/2?u=fabrice).

I've added a new PR #16 with changes to address OpenSea fields and MIME type. Let us push a bit the finalization of the ARC-0003 to decide on this PR.

What do you think? Please comment directly on the PR #16 when relevant.

Note that despite not being finalized we should not expect major changes of this ARC-0003, beyond the addition of new fields and recommendations in the JSON metadata file.

Comments on the posts above:

• @algokittens @Bhaney44 I think we should revisit collections through a different ARC and focus this ARC on single ASA/NFTs. Maybe let's first open another issue or a post on the forum for such discussion.
• @Bhaney44 I'm not an expert in quantum computers, but my understanding is that to find a collision on SHA-256 with a quantum computer you would need at least 256 error-corrected qbits (if not much more). Currently, only 53 qbits are supported (quantum annealing is not sufficient to break crypto). But more importantly, research seems to indicate that quantum computers may actually not be faster than classical computer for collision search (as opposed to breaking asymmetric crypto or preimage search - but note that SHA-256 provides 256-bit security against classical preimage search, so SHA-256 cannot be broken easily by quantum computers nor classical computers in the foreseable future): https://cr.yp.to/hash/collisioncost-20090517.pdf
• @emg110 @jannotti @scholtz Regarding mutability, I agree there is a need to think about options. We may want to open a different issue or a post on the forum. I think this is beyond the scope of this ARC-0003.

[wheresaddie]

thanks fabrice, moving additional comments to #16 re: MIME

[Bhaney44]

I think you are correct @fabrice102 regarding quantum computers. I am also not an expert in quantum computers, I have only written a few survey papers on the topic. As far as the worry of a quantum attack relating to SHA-256 encryption, it may come in the form of a successful implementation of Grover Search, which is faster than any classical search algorithm.

On the hardware side, I think the field has ruled out annealing too soon. The D-Wave machines are impressive and although they do not manipulate electrons directly, the technology may still provide speedup due to search sample equivalence. There is also the potential that photonic circuit boards will scale faster than gate model quantum computers, which as you mention only have about 53 qubits currently. PsiQuantum has raised more money than any other startup in the space for their photonic circuit board technology, which includes over one million qubits. This may simply be effective marketing, but I do not have the knowledge depth to rule it out as a possibility yet.

As far as whether to use SHA-256 or SHA-512, I think it would be important to consider the cost. SHA-512 is more secure and cryptographically my intuition is it may not be much more expensive to add an additional security later. Either way, I think the potential for inverting the SHA-256 will be more important on proof-of-work blockchains with respect to mining. But, I wanted to pull this data together for reference.

[Bhaney44]

What about adding the licence to the metadata?

What about adding the link of optional other changes to the metadata so that the first metadata does not have to change, and users have option to update some things later.. Eg if you forget to put the licence to the first specs and people will want to specify the licence for the already minted nfts? Or the translations, or i dont know, whatever the ARC0003 will decide in the future?

Regarding adding a license to metadata, see Issue #16.

[barnjamin]

The image field in the spec requires a URI but in the case of an IPFS directory containing both the metadata and the image, I don't know what the URI will be prior to hashing them and I can't change the metadata to include the CID or the CID will change.

Should I never use the directory feature of IPFS or does it make sense to change it to allow a relative path?

[emg110]

I think, @barnjamin, it would be the IPFS address of the image (file or directory) which you first create wrapped in a directory, then add the metadata json to that directory. add image file to IPFS (Wrapped in a directory or as a CAR)----> add metadata.json (image field filled with IPFS address returned from previous step)----> get last CID No logical loops this way I guess

[barnjamin]

then add the metadata json to that directory.

I thought the directories were immutable?

I could certainly upload the asset, then in a subsequent step upload the metadata using the CID of the image. But I don't think I can place them in the same IPFS directory since the CID of the dir would change

[scholtz]

Btw, what about some category tree of nfts? So that on the nft marketplace one can search by the category.. At the moment i can imagine categies like picture, sound, file, .. picture may be drawing, photography .. and I believe this can be changed later so that when the category tree is updated, the nft can be put also to other category It would be best to define the category tree in the form as NACE (defined tree, name description, multilangual support) Also there should be 1:N relation between asset and categories.

[emg110]

I know using only sha2-256 (V0) CID is a bit opinionated! but especially in scenarios like one with a folder that @barnjamin mentioned, there is no way but to be a bit opinionated. Over 60% of IPFS addresses and also the default IPFS setting to be v0 can be evidence enough to use this opinionated approach till metadatahash filed size increases (which I think is mandatory). I'm finishing arc3-ipfs repository (WIP, hopefully, finishes today) to address this correctly based on these 2 simple scenarios and in full compliance with ARC0003. Note: If you do not have a local IPFS node , using Pinata API is recommended!

[mxmauro]

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.

@cusma cards are not divisible by themselves. You cannot break a card into pieces (well you can but the card will be unusable hehe) so it is a NFT. And you can have different editions of the same card which should lead to a new NFT if you want to differentiate them.

1. 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.
2. 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"
3. 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".
4. 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.

@fabrice102 2 and 3 are actually the same.

I think we should keep things simple:

1 or more decimals, fungible. 0 decimals, NFT by default. The only thing I could consider a fungible object with 0 decimals is Monopoly money because of the definition of currency in the game.

[lrawicz]

I think we have 4 types of entities:

name	type	unit per type	decimals	example
ERC20	=1	>1	yes	DAI
NFT	>1	=1	No	CryptoKitties and artworks
Collectibles	>1	>1	No	Magic and pokemon cards
Shares	>1	=1	Yes	Stock markets and intelectual property

ERC 20

each unit share the same value so you can change thirty ERC 20 of one type of other thirty ERC 20 of the same type without winning or losing value.

NFT

each unit is unique and has his own value. You can't change between entities without winning or losing value

Example: if Alice change "Da Vinci's Mona Lisa" for Bob's "Picasso's Guernica", someone will lose money.

Collectibles

You have more than one type and more than one instance per type. The paradigm case of this is Magic the gathering or Pokemon TCG. The collectibles has properties of ERC 20 and NFT types.

Example 01: if Alice change "Charizard" for Bob's "Pikachu", someone will lose money. Example 02: if Alice change "Charizard" for Bob's "Charizard", noone will lose money.

Shares

You could want to represent the ownership of a thing divided by different owner in different proportions. Here the 20% of an enitity can be exchange for other 20% of the same share, and noone will lose money. But if you change 20% of an entitiy for a 20% of another entitiy someone will lose money

[cusma]

@cusma cards are not divisible by themselves. You cannot break a card into pieces (well you can but the card will be unusable hehe) so it is a NFT.

@mxmauro I think we agree on that: my comment on category 3 or "Collections" (as per @fabrice102 summary) was not meant to propose a card to be divisible by itself. That case is covered by category 2 or "Fractional NFT" (as per @fabrice102 summary), that does not apply to cards, and follows strict rules on the relationship between total supply and decimals.

And you can have different editions of the same card which should lead to a new NFT if you want to differentiate them.

Exactly, you can have a set of identical cards for the 1st edition (printed with a given print run) that would be identified uniquely by an Asset ID. Then you can have a 2nd edition of the same card (printed with another print run), identified by another Asset ID. Both the editions have 0 decimals (because cards are not divisible by themselves) and different print runs, expressed by ASA supply.

This being said, I'm not particularly incline in adopting the definition of NFT for the category 3 (as per @fabrice102 summary).

[emg110]

May I point to an uncared subject of NFT generation using ASAs: Unit Name UnitName does not mean anything with NFTs because there are no interchangeable units for Non-Fungibles, I think! On either scenario of NFT or Fractional NFT, I think the UnitName should be predetermined using values like, for example, NFT for NFTs and NFTF for fractional NFTs or even better left empty!

[emg110]

Updates on my previous comment: As @barnjamin correctly questioned the Pinata ability for scenario 2, I confirm he was right and that for scenario 2 there is a temporary need for a local IPFS node daemon (can be removed or shut down after process) because Pinata does not support all IPFS API features. Here are the results for two scenarios Scenario-1 results: https://ipfs.io/ipfs/QmSREN6qZ9Gs7KtBpR9eYoBABytHMwL6fM6dZu6vitieHp https://ipfs.io/ipfs/QmWrX1EmMQMSgQueYHqJw7a3SxEjSnMSPJdjM8QnhGFtXh Scenario-2 results : https://ipfs.io/ipfs/QmYAmMkWsuKQ44oPWkHduqJRbrCJQqdMfCmWnTLr1zwCAi https://ipfs.io/ipfs/QmYAmMkWsuKQ44oPWkHduqJRbrCJQqdMfCmWnTLr1zwCAi/asa_ipfs.png https://ipfs.io/ipfs/QmYAmMkWsuKQ44oPWkHduqJRbrCJQqdMfCmWnTLr1zwCAi/asa_ipfs.json

[fabrice102]

About licenses and other metadata

Re the following points from @scholtz and @Bhaney44:

https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-913376321 https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-912791534

Btw, what about some category tree of nfts? So that on the nft marketplace one can search by the category.. At the moment i can imagine categies like picture, sound, file, .. picture may be drawing, photography .. and I believe this can be changed later so that when the category tree is updated, the nft can be put also to other category It would be best to define the category tree in the form as NACE (defined tree, name description, multilangual support) Also there should be 1:N relation between asset and categories.

What about adding the licence to the metadata? What about adding the link of optional other changes to the metadata so that the first metadata does not have to change, and users have option to update some things later.. Eg if you forget to put the licence to the first specs and people will want to specify the licence for the already minted nfts? Or the translations, or i dont know, whatever the ARC0003 will decide in the future?

Regarding adding a license to metadata, see Issue #16.

I think that definitely makes sense to add this support but I think we should create another ARC for that and put it as part of the properties in metadata.json.

About the need of relative path

Regarding comments of @barnjamin and @emg110 (https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-915235836) and circularity when trying to use a folder for IPFS containing both the metadata.json file and the image file, my understanding is that any time you add a file you change the CID. This is necessary as otherwise it would not be possible to check the integrity of a directory from its CID. You can see details there: https://proto.school/mutable-file-system/06

So you can indeed add using command line asa_ipfs.png, get the CID, and then put it inside asa_ipfs.json and finally add asa_ipfs.json to the IPFS directory. But if you do so, the CID changes, so now the asa_ipfs.json points to a directory that still only contain asa_ipfs.png, and asa_ipfs.json will be in another directory. @Bhaney44, I have not had time to check your example and it seems to have been purged from IPFS. But I am 99% sure that the URL of the image in https://ipfs.io/ipfs/QmfMyv2QtpFDJyw7vnTRDL6kEaSM27dxod5B7canEXER3J/asa_ipfs.json is NOT https://ipfs.io/ipfs/QmfMyv2QtpFDJyw7vnTRDL6kEaSM27dxod5B7canEXER3J/asa_ipfs.png

I'm creating a PR to add relative paths

About the naming "NFT"

Re @mxmauro comment:

https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-913770620

1 or more decimals, fungible. 0 decimals, NFT by default. The only thing I could consider a fungible object with 0 decimals is Monopoly money because of the definition of currency in the game.

I think we cannot say 0 decimals = NFT as you may want to create a money that has no decimals. There are actually many FIAT currencies that do not have decimals. For example the Japanese Yen does not have subunits/decimals.

On the other hand, fractional NFTs have decimals by definition.

About the unit name

@emg110 proposes:

May I point to an uncared subject of NFT generation using ASAs: Unit Name UnitName does not mean anything with NFTs because there are no interchangeable units for Non-Fungibles, I think! On either scenario of NFT or Fractional NFT, I think the UnitName should be predetermined using values like, for example, > NFT for NFTs and NFTF for fractional NFTs or even better left empty!

I think it is ok to recommend unit name for NFT to be NFT and unit name for fractional NFTs to be FracNFT for example.

Note that ARC-3 also supports fungible tokens à la ERC-20 in which case it makes sense to have a real unit name.

Please discuss if you believe in such recommendation.

About the need for collections

From the above comments, it seems clear that the next step is to standardize collections. We should do that in a different ARC.

[fabrice102]

Issues to be confirmed before finalization:

1. agreement on https://github.com/algorandfoundation/ARCs/pull/21 that adds relative URI
2. do we want to merge https://github.com/algorandfoundation/ARCs/pull/10
3. do we want to recommend the unit name to be NFT for NFT, FracNFT (or something else) for fractional NFT? Or other recommendations as proposed by @emg110? Or just leave open? I think that we should not make it mandatory as people, in which case it may not be a blocking point.

For 1 & 2, please directly do thumbs-up or thumbs-down in the PR. For 3, please comment below.

Issues to be postoned in future ARCs:

• support for extra properties such as license, category, ... -> ideally this should be a cross-chain effort beyond Algorand
• support for collections
• support for very large assets beyond 10GB

[emg110]

Magnificent summation @fabrice102! Sorry IPFS links were broken! I updated them in related comment and they are working fine now (folder, metadata, file)!

You are 100% right about the image URL NOT containing directory IPFS address as it's impossible, but the case to that fact was not explored by these scenarios, according to which the goal was not to have the folder-based URL inside the JSON metadata file but instead to have only the original NFT file's IPFS address inside the metadata JSON and then have them both inside a folder.

Now for example, the URL of ASA can hold the folder IPFS address and the MetaDataHash field can hold the NFT digital asset file's hash part of CID.

Important note: The NFT digital asset can itself be a file or a directory and should not be mistaken with the directory (DAG node in fact) we are setting as upper directory during scenario 2.

As for integrity checks: the image and image_integrity fields of metadata JSON check and since we have the original NFT digital file's sha2-256 checksum hash in MetaDataHash field then it checks as well and therefore the scenario is tamper-proof through and through, I think.

[barnjamin]

For all the properties that are required, it would be helpful to denote that in the json schema: https://json-schema.org/understanding-json-schema/reference/object.html#required-properties

[fabrice102]

For all the properties that are required, it would be helpful to denote that in the json schema: https://json-schema.org/understanding-json-schema/reference/object.html#required-properties

Actually EIP-1155 does not require any property. Should we require any specific property?

[emg110]

I think including a similar convention to denote required fields like in json schema as @barnjamin said could be nice idea . E.g. "required": ["name", "size"]

[barnjamin]

Actually EIP-1155 does not require any property. Should we require any specific property?

Ah, I thought some of the MUSTs were applied to the properties but it looks like its only, "if they're supplied they MUST look like this"

[fabrice102]

Following draft conventions in #19 and PR #23, ARC-0003 is now marked as "Last Call".

ARC-0003 will be marked final in 14 days if nobody opposes it.

[runvnc]

I think I already said this, and I apologize if I am missing something, but if this standard is supposed to apply to media types that are not images or videos 100% of the time, then I believe animation_url_mimetype should be required if animational_url is specified. The type of media is a critical piece of information for cataloging or displaying, just as important or more important than the name. It should not require accessing the content with a HEAD request or anything to find that out. If there is another standard to handle general non-image/video media then disregard this comment.

[barnjamin]

One of the points of discussion here was around more advanced features around NFTs including things like Collections.

I created an issue to gather feedback on what advanced features folks might be looking for: https://github.com/algorandfoundation/ARCs/issues/22

And broke out the collections discussion to this issue: https://github.com/algorandfoundation/ARCs/issues/25

[DragonDev1906]

Currently the transaction note field (1kb) is not used/referenced by ARC3. I would suggest to take some fields of the JSON metadata (au) and additionally add them to the note field.

This would give some redundancy to the most important fields in case IPFS is not be reachable or reliable for some reason. While it would require another request to the indexer this could make fetching the image faster or allow faster display of the name. Even if the JSON metadata file is not available anymore (for some reason) the most important information will not be lost.

Suggested changes: The transaction note (when the asset was created) SHOULD contain a subset of the JSON metadata (as JSON). If set it

• SHOULD include name
• SHOULD include image
• SHOULD include image_integrity
• SHOULD include animation_url
• SHOULD include animation_url_integrity
• is RECOMMENDED to include image_mimetype
• is RECOMMENDED to include animation_url_mimetype
• is RECOMMENDED to include external_url
• MAY include any other fields of the JSON metadata

If the entire JSON metadata file is less than 1KB it MAY be included completely in the transaction note field on asset creation (in addition to the JSON metadata file referenced by au).

If the JSON metadata (au) can change in the future (the response on asset url can be changed in the future and Asset Metadata Hash (am) is not set) the JSON in transaction metadata SHOULD NOT contain any fields that can change in the future.

Clients MAY completely ignore the data in the transaction note.

[barnjamin]

Yes, I'd like to come back to the note field as well.

Discussing with @ChrisAntaki in the discord and he made several points:

1. Most platforms currently using the URL field to point directly to the media.
2. Storing the metadata in the Asset Create note field provides a faster way to look it up (concurrently with url field) and some additional peace of mind since it's on chain. Additionally the params and note field can be retrieved in a single call to the indexer (ex: https://algoexplorerapi.io/idx2/v2/transactions?asset-id=340692285&tx-type=acfg)
3. Possibly using the metadata hash field to describe details about the media including type/byte size/dimensions
4. The Name containing arc3 may be unnecessary and if we update the spec to allow the above, it will "break" the existing NFTs

I think we should at least consider modifying the spec to account for the way existing platforms are making use of the URL field.

[whereisrysmind]

It think @DragonDev1906's suggestion above makes a lot of sense to me. Im 100% for partial use of the Note field for replicating key pieces of data from the metadata.json.

[trinleysmanyfaces]

I agree with not dismissing use of the note field, and optimising the indexer so it can be fetched faster. And to be totally frank @runvnc proposal of adding metadata attached to each asset should also be genuinely considered.

On Cardano, each asset can have 16kb of metadata which is driving a lot of interesting innovation.... I am not a developer, but is it unreasonable to ask for at least enough space to add important metadata to assets on Algorand?

[barnjamin]

On Cardano, each asset can have 16kb of metadata which is driving a lot of interesting innovation.... I am not a developer, but is it unreasonable to ask for at least enough space to add important metadata to assets on Algorand?

I think to support something like this, the min balance for the asset would need to be increased to account for the extra storage. But there is already a precedent in the case of applications to request extra "pages" of storage. Technically possible but would take some time to implement.

[algokittens]

Interesting, I am not suggesting 16kb, but rather 1kb (or less). Although even that might be an issue as discussed here? https://github.com/algorand/go-algorand/issues/2714

On Tue, 21 Sept 2021 at 15:39, Ben Guidarelli @.***> wrote:

On Cardano, each asset can have 16kb of metadata which is driving a lot of interesting innovation.... I am not a developer, but is it unreasonable to ask for at least enough space to add important metadata to assets on Algorand?

I think to support something like this, the min balance for the asset would need to be increased to account for the extra storage

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/algorandfoundation/ARCs/issues/3#issuecomment-924054115, or unsubscribe https://github.com/notifications/unsubscribe-auth/ATZQ5RG5GKE5SKV7TAKE5HDUDCKIVANCNFSM5ABMMLBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[barnjamin]

@algokittens yea that'd be a protocol level change and might be tough to implement but I'm not sure. In the shorter term the create txn note field could be purposed for metadata and subsequent acfg txns might work to append or augment the initial metadata. It should be possible to make 1 query to the indexer to get all the acfg txns (including the create txn). Would that work for your needs?

[emg110]

This might be a bit wild but can we think of having a current field size (say note's 1kb) as maximum without extra op costs, then calculate used extra space(let's say 4kb is used by a base64 URL) as operational costs and apply it upon transaction submission. Think of it as letting every requirement scenario on field sizes be fulfilled if they are willing to pay extra op costs, calculated in real-time at the time of TXN submission using that much extra field space. People can have 16kb of URL field or note field if they accept the calculated operational costs.

[runvnc]

@DragonDev1906 thank you for throwing me a bone as making mimetype recommended. But unfortunately almost no one does things that are recommended.

So imagine you have some program that queries the assets and shows them in a list on the screen. Imagine you want to have a column "Media Type". What will happen is people ignore the recommended mimetype field. So then that column will be blank until you do 100 HEAD queries or something.

[DragonDev1906]

I've made non of them a MUST because of the 1kb size limitation and because I marked the whole data in the txn note as should, so we can't even be sure that parts of the metadata would be in there (unless other parts of ARC-3 change or it is made required)

[ChrisAntaki]

The metadata hash field works well for media type (important metadata) of the URL. HEAD requests run into CORS issues

[runvnc]

OK.. so @ChrisAntaki what you are saying if I understand is actually one step further than what I was asking for.

Because right now its like this for me:

• Get asset record
• Look in server cache for content-type
• If not found, do HEAD request for content-type (mime type)
• Repeat for each item in gallery/directory
• Sending data to be rendered in gallery

What you are saying is you are trying to avoid one of the steps or that its impossible to do one of them, so its more like:

• Get asset record
• MIME type is in asset's Metadatahash field
• Repeat for each item in gallery/directory
• Sending data to be rendered in gallery

What I was trying to say was that if people adopt this standard, the URL will not point to the actual content, and that will introduce a step. So for me it would be:

• Get asset record
• Get metadata record from asset URL
• Look in server cache for content-type
• If not found, do HEAD request for content-type (mime type)
• Repeat for each item in gallery/directory
• Sending data to be rendered in gallery

Whereas with the content-type stored in the metadata.json, it would be:

• Get asset record
• Get metadata record from asset URL
• Get content-type from metadata record
• Repeat for each item in gallery/directory
• Sending data to be rendered in gallery

The issue is that even though its only 1 extra step, it gets repeated for every single item in the gallery.

As far as using the Metadatahash, it does seem redundant when the content is a single media file at an IPFS CID, because if I understand correctly the CID is a hash. But to adopt placing the MIME-type in the MetadataHash field as the standard seems, at least, confusing.

But I feel like we should say it is required to put it SOMEWHERE just so that we can do a list of files or gallery without having to do extra requests for each item to find out what kind of media they are.

EDIT: got a few of those things scrambled on the first draft.

[ChrisAntaki]

What you are saying is you are trying to avoid one of the steps or that its impossible to do one of them, so its more like: Get asset record MIME type is in asset's Metadatahash field Repeat for each item in gallery/directory Sending data to be rendered in gallery

This is the (most efficient) way

If not found, do HEAD request for content-type (mime type)

Web browsers can't do this step (!), unless the media lives on the same origin as the webpage https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

From MDN: "For security reasons, browsers restrict cross-origin HTTP requests initiated from scripts. For example, XMLHttpRequest and the Fetch API follow the same-origin policy. This means that a web application using those APIs can only request resources from the same origin the application was loaded from unless the response from other origins includes the right CORS headers."

As far as using the Metadatahash, it does seem redundant when the content is a single media file at an IPFS CID, because if I understand correctly the CID is a hash. But to adopt placing the MIME-type in the MetadataHash field as the standard seems, at least, confusing.

Yep, CID is a unique hash, and it's longer than 32 bytes

The media type is the most important piece of metadata for NFT galleries. Having it right away can improve load times and UX significantly

Adding "@arc3" to asset names is way more confusing, especially for UX (not all apps will trim it out)

...if people adopt this standard, the URL will not point to the actual content, and that will introduce a step...

This proposal, as it is, could really harm adoption of Algorand NFTs by degrading UX across the board

I've used IPFS gateways a lot in the recent months. They often reject requests due to rate limiting. They're often quite slow too, especially when a CID hasn't been requested in some time

Doubling the number of IPFS requests would both (1) increase the frailty of the system (more rate limit errors) and (2) slow down rendering of NFTs

In UX, every second counts. Do we want Algorand NFT galleries to be engaging, or frustrating?

Ex: "40% of people abandon a website that takes more than 3 seconds to load" https://neilpatel.com/blog/loading-time/

[runvnc]

Well I agree with most of what you said, but just to clarify, Pinata is allowing HEAD requests to my private gateway. I have been replacing whatever IPFS gateway with my own and the HEAD requests are working fine. But yeah, really appreciate you backing me up on having the MIME type available. And its true that not all hosts will allow HEAD.

[ChrisAntaki]

Pinata is allowing HEAD requests to my private gateway

Good call! Looks like Pinata, Cloudflare, and IPFS.io gateways all include CORS headers

[runvnc]

Well, apologize if this is too crazy, but maybe they could add another 16-40 byte field to Assets that would be for some kind of compressed binary metadata. I mean, the using the Metadatahash is practical, but isn't there a reason that was setup as a metadata hash, or a case with a directory or something where we need that field? And also it is confusing if its called metadatahash. Unless you interpret it as "whatever metadata or hash or whatnot". But maybe with an IPFS directory it is also redundant somehow?

[ChrisAntaki]

This field is intended to be a 32-byte hash of some metadata that is relevant to your asset and/or asset holders. The format of this metadata is up to the application

https://developer.algorand.org/docs/reference/transactions/#metadatahash

They say "the format of this metadata is up to the application". For an NFT gallery, what metadata is more important than the media type?

But maybe with an IPFS directory it is also redundant somehow?

Yep, IPFS URLs must contain the CID

CIDs are based on the content’s cryptographic hash. That means:

• Any difference in the content will produce a different CID and
• The same content added to two different IPFS nodes using the same settings will produce the same CID.Yep, IPFS URLs already contain a CID (content identifier), which is based on a hash of the file contents

https://docs.ipfs.io/concepts/content-addressing/

And also it is confusing if its called metadatahash

In practice most NFT creators just leave this field blank. Even if the field could fit an IPFS CID, doing so would be redundant since the URL contains the CID already. Populating the field with useful metadata seems smarter, and would lead to better UX

[simonbelingar]

In UX, every second counts. Do we want Algorand NFT galleries to be engaging, or frustrating?

I understand your point, but there are few things that can be done to handle that on the "gallery" side, and do not neccessarily call for standardization. E.g. your "bad/slow" user experience will only happen 1 time, every other user will have a smoother experience (as you said, server cache, application side cache etc...),

other thing to keep in mind, you would want to validate the content type regardless of what nft provided string would say - what is to prevent me from creating nft, linking to a binary file and mark the content as image? You can handle this stuff with head requests, when it doesn't work you can read first few bytes of content(magic bytes). And again, you would probably only need to do this once for each nft, accessed through your gallery -and never again.

[DragonDev1906]

Trying to summarize:

• Ideally all metadata would be stored somewhere on-chain to remove an entire IPFS call
• Since that would probably limit the size (e.g. to 1kb) there MUST be a way to extend the metadata stored on-chain (for example via an "extended_metadata_url" field in the on-chain metadata
• The URL to the media (e.g. Image) and the Mimetype SHOULD be returned in the first (indexer) request to allow fast requesting of the media file in the second request (Mimetype in order to not need a HEAD request)
• Other basic information (e.g. name) SHOULD be in the first (indexer) request, too. To prevent having to send an additional request for every asset on Gallery views
• Creators MAY include additional information in that on-chain metadata, if there is space left (so they can get them faster in their project)
• Clients MUST expect the given Mimetype to be wrong, as there is no way to ensure correctness and not fail if the media type is different than expected

So ideally the Gallery could have requests like this?

• Get asset record (including on-chain metadata if possible)
• Request media (using Mimetype & URL from asset record/on-chain metadata
• Get additional metadata if needed
• Repeat for each item in gallery/directory
• Sending data to be rendered in gallery

---

but there are few things that can be done to handle that on the "gallery" side, and do not neccessarily call for standardization. E.g. your "bad/slow" user experience will only happen 1 time, every other user will have a smoother experience (as you said, server cache, application side cache etc...),

This may also affect other applications, I think. Let's say the application only needs information for one asset. If the media URL is in the metadata, the request time would be time_get_asset_record + time_get_asset_metadata + time_get_asset_media, while the last 2 steps could be made at the same time if the asset_media_url would be in the asset record: time_get_asset_record + max(time_get_asset_metadata, time_get_asset_media), and perhaps not all applications are able to cache the data easily.

[ChrisAntaki]

perhaps not all applications are able to cache the data easily

+1, we should not assume every application has a server that fetches/caches NFT metadata. Most websites I see, including my own, just fetch this information via frontend code. This helps with both scaling and server costs