TIP-27 IOTA NFT standards #65

coodos · 2022-03-04T14:09:06Z

This PR creates a TIP about

IOTA NFT Metadata Standards
~~Decentralised PolicyID registry to prevent fake collections~~ moved to TIP 33
Defining Creator Royalties

rendered version

Update tip-0027.md

lzpap

Thanks for the contribution, you are amazing! 🚀

There are some things we need to figure out but it's going in the right direction.

tips/TIP-0027/tip-0027.md

Added TIP-1 headers to the sections and re-ordered out of place segments.

Updated Section headers

Added a comment for future versioning to be submitted as a separate TIP

nalim2 · 2022-03-09T16:01:41Z

tips/TIP-0027/tip-0027.md

+}
+```
+
+### Creator Royalties


Does it make sense to include royalties in an NFT standard? From our side, we would like to support royalties, but there are scenarios where it is necessary to have them not immutable, or it is not enough to represent them as a percentage of a sales price traded against something that is not a currency.

Royalties as a standard is included as an optional key. These are not a must but having a standardised royalty schema makes an ecosystem royalty system a lot more interoperable between dApps. It is further possible to expand the royalty options for edge cases through Smart Contracts also.

adamunchained

just add few comments! Great effort guys!

adamunchained · 2022-03-30T05:30:26Z

tips/TIP-0027/irc27.schema.json

+    // human readable name for the collection
+    "policyName": "My Collection of Art",
+    // Key Value pair collection of royalty addresses, where address is mapped to the percentage of payout to be sent to it
+    "royalties": {


You should consider index here. You might want to define sequence as not all royalties might be paid every time. For example, what happens if the royalty is below dust?

tips/TIP-0027/irc27.schema.json

adamunchained · 2022-03-30T05:39:43Z

tips/TIP-0027/irc27.schema.json

+    // description of the asset
+    "description": "A little information about my NFT collection",
+    // define optional attributes for NFT metadata
+    "attributes": {


I would recommend to get inspired from ERC-721 / ERC-1155 metadata standard:

for keys definitely should be all lower case

you should consider support for localizations, rich formatting ( display value, css) - as recommended standard ofc

We are heavily inspired by the ER721 standards, camelCase or snake_case are acceptable in word separation as per JSON schema standards. For example the fromBlock key as defined by the ERC-721 Standard which is used regularly in examples on the Ethereum Foundation docs. If you are referring to the value, as this is simply a text string this is not an issue.

I am sure Merul can comment a little further in regard to the localisations.

I am not sure what you mean by localization here but if you mean glyphs from other languages than that shall be covered by unicode already

adamunchained · 2022-03-30T05:41:40Z

tips/TIP-0027/tip-0027.md

+---
+
+
+# iNFT Standard - IRC27


tbh I'm not a big fun of the iNFT prefix. It wasn't even obvious to me that it's for IOTA....It's confusing. Why don't just call it NFT Standard - IRC27 ?

I love it! 💯

adamunchained · 2022-03-30T05:49:04Z

tips/TIP-0027/tip-0027.md

+- `IRC27`
+
+
+The schema is defined by one of the following:


this just feels way to limiting and I would be really careful introducing your own system for this.

The schema is expandable and versioning is implemented from the offset, introducing schema definitions is extremely advantageous for interoperability, forward and backwards compatibility across dApps in the ecosystem

Removed the section on registry and updated a couple of sections. STILL NEED TO ADD A LINK TO TIP30 - upon submission.

Made a couple of minor edits

Edited out the registry section and updates

Updated example royalties

Created new TIP 33 - IOTA Public Token Registry

lzpap

Looks good to be merged as Draft.

adamunchained

looks good, we will get this implemented within Soonaverse within next 2 - 3 weeks. We'll let you know asap if further changes are required.

huhn511 · 2022-10-14T12:18:31Z

Hey 👋

im thinking to remove the collectionId from the metadata. This could be used to scam people, if dApps not validate, if the collectionId is valid. So for example the NFT creator can add an collectionId from another NFT collection and copy it. This feature is already solved by the "issuerId" which can not be changed or add manually. Also, we need less data so we need less tokens for storage deposit.

What do you think?

Dr-Electron · 2022-10-23T20:24:55Z

Hey 👋

im thinking to remove the collectionId from the metadata. This could be used to scam people, if dApps not validate, if the collectionId is valid. So for example the NFT creator can add an collectionId from another NFT collection and copy it. This feature is already solved by the "issuerId" which can not be changed or add manually. Also, we need less data so we need less tokens for storage deposit.

What do you think?

As collectionId is optional I think it is ok to keep it. It can be useful sometimes for easier access to the ID but you can always also just ignore it 🤔

Dr-Electron · 2022-10-23T20:26:45Z

I was thinking about adding something 😅 .
What about having an additional data property. And than you either have to provide an uri or data property.
Because otherwise how would you use this standard if you want to store your data on-chain in the output? 🤔

adamunchained · 2022-10-23T23:55:21Z

I was thinking about adding something 😅 .
What about having an additional data property. And than you either have to provide an uri or data property.
Because otherwise how would you use this standard if you want to store your data on-chain in the output? 🤔

I wouldn’t complicate. You can always store it within uri. Same way as you would set src attribute in html

for example
<img src="data:image/png;base64,iVBORw0KGgoAAA ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4 //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJggg==" alt="Red dot" />

Dr-Electron · 2022-10-24T08:14:17Z

I was thinking about adding something 😅 .
What about having an additional data property. And than you either have to provide an uri or data property.
Because otherwise how would you use this standard if you want to store your data on-chain in the output? 🤔

I wouldn’t complicate. You can always store it within uri. Same way as you would set src attribute in html

for example <img src="data:image/png;base64,iVBORw0KGgoAAA ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4 //8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU 5ErkJggg==" alt="Red dot" />

My bad. I totally forgot the data URI scheme 😅

huhn511 · 2022-10-24T18:11:47Z

As collectionId is optional I think it is ok to keep it. It can be useful sometimes for easier access to the ID but you can always also just ignore it 🤔

Yes, the collectionIdis optional in the metadata but required as ìssuerID` on a collection. So its optional to store the data twice :P

And i can add everything i like to the collectionId field - also collectionIds from other existing collections which i could use to scam people on dApps like marketplaces where this collectionId not gets validated.

So why using an extra attribute which information is already present and add an potentially scam potential? Or am I misunderstanding something?

robertf26 · 2022-10-27T11:15:17Z

I agree that it does not make sense to include the collectionId. Besides opening the door for scammers, if it is accidentally messed up by the creator of an NFT collection and not noticed in time, there might be invalid NFT collections out there.
So why even make it complicated and give minters another possibility to make an error when we can just check the NFTid of the collection NFT?
No dapps will/should implement relying on the collectionId for verification if it is well known that it can be set as any arbitrary value.

Dr-Electron · 2022-10-27T12:09:22Z

Yeah makes sense thinking about it 👍

sdellava · 2022-11-15T14:04:17Z

Hi team. I'd like to suggest to add an additional (optional) key in the NFT schema.

We are used to thinking of NFTs in relation to digital artworks and in general use cases where a single token can represent an object of value after it has been created and published by the author.

However, there are many use cases where a non-fungible token can represent a physical object that belongs to a collection of objects, i.e., a production batch, and which is very interesting to be able to follow the history of the production process from the beginning of the process.

From pharmaceutical to fashion to automotive, the number of real-world cases where this scenario applies is endless.

Sometimes the life of the post-production object is normally of little interest, especially if they are consumable products, but it is almost always interesting to trace the production process of these products. Addresses can be used to represent the stages into which the production process of each object is divided. Thus transactions that spsot the NFT from one address to another represent optimally the production process.

The optional key I suggest adding contains an array of addresses that where NFT can be sent. If this key is present, the transaction that moves an NFT from one address to another must be valid for the array. An "any" operator allows the NFT to be freed from the last address.

For example:
allowed_address_sequence: add1, add2, add3, any

A tx that moves the NFT from add1 to add2 is valid.
A tx that moves the NFT from add1 to add3 is invalid
A tx that moves the NFT from add1 to addx is invalid
A tx that moves the NFT from add2 to add3 is valid
A tx that moves the NFT from add3 to addx is valid

sdellava · 2022-11-15T14:21:31Z

An additional use case for the suggested key is a public voting process where one person can vote once.

In these voting scenarios a voting authority is normaly requred present and required to identify the voters and authorize them to partecipate to the pool process. The vote, in most of the cases need to be secret, but this point is out of topic here.

A simple solution to provide an authorization to the voters is to mint and sent to them an NFT that have to send to a final destination address with the vote included in the tx metadata.

So in this case the allowed_address_sequence can be a list of two address: voter's address where the NFT is minted, pool address where the NFT have to be sent.

huhn511 · 2022-11-15T14:31:01Z

Hey Stefano, thanks for your input! This sounds like an ideal use case for Smart Contracts. I see the problem, that all dApps needs to check if the address is valid or not. That means, the protocol could just send the NFT to an address which is not allowed. There is no "if/else" here on protocol level, this needs a smart contract. Because of this reason, i would say this should not be part of the NFT standard. You could extend the standard for your applications. If i miss something, please let me know. Is there anything like that on other NFT standards?

sdellava · 2022-11-15T15:45:44Z

I understand your point. In fact, my first thought was to use a SC for these kinds of scenarios, but objectively for some of these cases it might be too much of a heavy duty.

Instead of modifying the NFT standard, it might make more sense to propose a new Unlock condition so that we can limit the displacement of a genenric token on specific addresses?

sdellava · 2022-11-15T16:57:31Z

On second thought, both Unlock condition and Smartcontract are not safe solutions.

In fact, Unlock conditions, if I have not misunderstood, are related to the individual tx, not to the object being moved. This implies that the next "owner" can freely define his own Unlock condition that replaces the previous one.

More or less the same applies to Smartcontract, which being deplyoed by an owner, can always be replaced.

In my initial idea these validity conditions are to be included in the immutable part of the NFT.

Obviously it would be useful for the network to take them into account by considering invalid a tx that moves an NFT to an address not authorized by its author because if the NFT is moved, then there is no way to avoid the new owner to use as he prefers.

huhn511

LGTM 👍

adamunchained · 2022-11-16T22:52:11Z

I've spoke with @Phyloiota the other day as he asked me to review Shimmer OG NFT collection. I've provided him with feedback and he asked me to share it here so here it goes:

Alias should have been used to issue NFT collection. We do this because it was suggested by various people from IF after we did many reviews/testing with various parties. It's great suggestion. Alias can be used for various things (i.e. Alias can be transferred to new owner or even to a party that wants temporary do something with the collection). TIP27 does not specify how collections / NFT should be minted and I think it should be more specific!
Collection NFT metadata have "type": "text/html" and "uri": "https://shimmer.network". This is more an additional attribute. Uri should be reserved for preview image so it can show collection banner. Right now, this NFT collection will have no image once it's imported into various NFT marketplaces.
I noticed Shimmer OG NFT has no props/stats. This significantly decrease value of the NFT and it's rarity. Owner will not know anything about the NFT. NFT should always have some stats/props and it should be encouraged.
NFT uri could have just been ipfs://QmPoYcVm9fx47YXNTkhpMEYSxCD3Bqh7PJYr7eo5YjLgiT to save on storage deposit.

I'm not sure if above is something we want to enforce within the specification but it might be worth to consider some of them. Some of them can also be great "suggestions" for artists to follow.

adamunchained

I think we should discuss and establish specification on how NFT Collection/NFTs are minted and standardize that process.

huhn511 · 2022-11-17T11:32:39Z

Hey Adam, thanks for you feedback!

TIP27 does not specify how collections / NFT should be minted and I think it should be more specific!

It's defined here - but it should be more specific and the Alias part is missing - https://github.com/Kami-Labs/tips/blob/main/tips/TIP-0027/tip-0027.md#minting-l1-nft-collections

Collection NFT metadata have "type": "text/html" and "uri": "https://shimmer.network". This is more an additional attribute. Uri should be reserved for preview image so it can show collection banner. Right now, this NFT collection will have no image once it's imported into various NFT marketplaces.

Very Good point - so the example is a bit miss leading and we could need something like homepage

"uri": "https://my-awesome-nft-project.com",

Dr-Electron · 2022-11-17T14:47:30Z

I've spoke with @Phyloiota the other day as he asked me to review Shimmer OG NFT collection. I've provided him with feedback and he asked me to share it here so here it goes:

Alias should have been used to issue NFT collection. We do this because it was suggested by various people from IF after we did many reviews/testing with various parties. It's great suggestion. Alias can be used for various things (i.e. Alias can be transferred to new owner or even to a party that wants temporary do something with the collection). TIP27 does not specify how collections / NFT should be minted and I think it should be more specific!

Collection NFT metadata have "type": "text/html" and "uri": "https://shimmer.network". This is more an additional attribute. Uri should be reserved for preview image so it can show collection banner. Right now, this NFT collection will have no image once it's imported into various NFT marketplaces.

I noticed Shimmer OG NFT has no props/stats. This significantly decrease value of the NFT and it's rarity. Owner will not know anything about the NFT. NFT should always have some stats/props and it should be encouraged.

NFT uri could have just been ipfs://QmPoYcVm9fx47YXNTkhpMEYSxCD3Bqh7PJYr7eo5YjLgiT to save on storage deposit.

I'm not sure if above is something we want to enforce within the specification but it might be worth to consider some of them. Some of them can also be great "suggestions" for artists to follow.

Not sure if it has any benefits in this use case. Even an NFT can be transferred. The powerful part of Alias is the unlock conditions with state and governance controller I would say.
And I think if there is a valid case to use that, it should probably be a separate TIP. This one being the easiest Implementation. In the end the NFT has some features of the Alias. So why not use it for some use-cases?
But I have no strong opinion against using an Alias. (Maybe the only one being that maybe collection NFTs are a well known thing, alias NFTs not )
What do you mean with TIP27 doesn't specific how it should be minted? What needs to be more specific in your eyes?
NFTs can not just be images. So you could also specify in your guide that if someone wants to host on soonaverse he should add a image to the collection uri as a preview 🤔
In the end the TIP doesn't restrict you in what to put into uri.
I don't think we should add a homepage property tho tbh. You could add such additional properties to attribute to I guess 🤔
The TIP defines optional attributes. I even suggested to use them to define for example why you got the NFT (Won in Giveaway, participated in Singapur...). They didn't do it. And that's fine. we shouldn't force users to use those. But again, any marketplace could give such infos as tips in their guides. Want to increase value for your NFT? Add attributes.
After all again, not all NFTs are "just" images you try to sell.
This is a valid point which was actually also raised internally by @nicole-obrien afaik.

Thanks for your feedback ❤️ . I personally think most of this things should be optional.

Removed collectionId from immutable metadata.

robertf26

LGTM, also Linter passed 👍🏼

robertf26 · 2022-11-28T20:38:44Z

Thank you to everyone who worked on TIP-27! 💯

coodos and others added 4 commits March 4, 2022 19:25

feat: add IOTA NFT tip

f5f17c0

chore: update IRC-2 TIP

74b233a

Update tip-0027.md

eb0f15c

Merge pull request #1 from Kami-Labs/AdamCroply-update

5eb75b4

Update tip-0027.md

lzpap added Draft Interface IRC Standards and removed Interface labels Mar 4, 2022

lzpap changed the title ~~TIP-27 - IOTA NFT standards~~ TIP-27 IOTA NFT standards Mar 4, 2022

AdamEunson added 2 commits March 4, 2022 17:39

Update tip-0027.md

8fd3655

Update tip-0027.md

32b6734

lzpap reviewed Mar 7, 2022

View reviewed changes

coodos and others added 4 commits March 9, 2022 17:05

chore: bump standard name and commit suggested changes

066e1cb

Updated Section headers

ecac842

Added TIP-1 headers to the sections and re-ordered out of place segments.

Merge pull request #2 from Kami-Labs/AdamCroply-headers-update

edc7924

Updated Section headers

Added Versions as TIPs comment

a1d9bd5

Added a comment for future versioning to be submitted as a separate TIP

nalim2 reviewed Mar 9, 2022

View reviewed changes

coodos added 3 commits March 29, 2022 22:01

docs: added description for royalty system

4d5ea15

Create irc27.schema.json

5e1939e

chore: fix royalties part

02c16b9

adamunchained reviewed Mar 30, 2022

View reviewed changes

AdamEunson added 8 commits April 2, 2022 12:30

Edited out the registry section and updates

f12a5eb

Removed the section on registry and updated a couple of sections. STILL NEED TO ADD A LINK TO TIP30 - upon submission.

Edited tip30 to tip31

ae29bcf

Updated tip link and royalties

bf3120c

Made a couple of minor edits

Merge pull request #3 from Kami-Labs/AdamCroply-patch-removeregistry

096eaed

Edited out the registry section and updates

Merge branch 'iotaledger:main' into main

4083ba4

Updated example royalties

c658d1e

Updated example royalties

Updated example royalties

5dbf829

Updated example royalties

Create tip-0033.md

481a359

Created new TIP 33 - IOTA Public Token Registry

lzpap added 2 commits June 21, 2022 19:20

Clean up JSON schema

07510ab

Desscribe NFT Collections, add practical examples

ac9687f

lzpap approved these changes Jul 1, 2022

View reviewed changes

adamunchained approved these changes Sep 1, 2022

View reviewed changes

AdamEunson approved these changes Oct 14, 2022

View reviewed changes

huhn511 approved these changes Nov 16, 2022

View reviewed changes

adamunchained suggested changes Nov 16, 2022

View reviewed changes

robertf26 and others added 3 commits November 23, 2022 12:09

Removed from immutable metadata

cfa52f5

Updated header file

3a96412

Merge pull request #7 from iotaledger/Kami-Labs/main

61b4c5d

Removed collectionId from immutable metadata.

robertf26 self-requested a review November 28, 2022 20:24

robertf26 approved these changes Nov 28, 2022

View reviewed changes

robertf26 merged commit b2aa9f5 into iotaledger:main Nov 28, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TIP-27 IOTA NFT standards #65

TIP-27 IOTA NFT standards #65

coodos commented Mar 4, 2022 •

edited

Loading

lzpap left a comment

nalim2 Mar 9, 2022

AdamEunson Apr 6, 2022

adamunchained left a comment

adamunchained Mar 30, 2022

adamunchained Mar 30, 2022

AdamEunson Apr 6, 2022 •

edited

Loading

coodos Apr 6, 2022

adamunchained Mar 30, 2022

AdamEunson Apr 6, 2022

adamunchained Mar 30, 2022

AdamEunson Apr 6, 2022 •

edited

Loading

lzpap left a comment

adamunchained left a comment

huhn511 commented Oct 14, 2022

Dr-Electron commented Oct 23, 2022

Dr-Electron commented Oct 23, 2022 •

edited

Loading

adamunchained commented Oct 23, 2022

Dr-Electron commented Oct 24, 2022

huhn511 commented Oct 24, 2022 •

edited

Loading

robertf26 commented Oct 27, 2022

Dr-Electron commented Oct 27, 2022

sdellava commented Nov 15, 2022

sdellava commented Nov 15, 2022

huhn511 commented Nov 15, 2022

sdellava commented Nov 15, 2022

sdellava commented Nov 15, 2022 •

edited

Loading

huhn511 left a comment

adamunchained commented Nov 16, 2022

adamunchained left a comment

huhn511 commented Nov 17, 2022

Dr-Electron commented Nov 17, 2022

robertf26 left a comment

robertf26 commented Nov 28, 2022

TIP-27 IOTA NFT standards #65

TIP-27 IOTA NFT standards #65

Conversation

coodos commented Mar 4, 2022 • edited Loading

lzpap left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adamunchained left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamEunson Apr 6, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AdamEunson Apr 6, 2022 • edited Loading

Choose a reason for hiding this comment

lzpap left a comment

Choose a reason for hiding this comment

adamunchained left a comment

Choose a reason for hiding this comment

huhn511 commented Oct 14, 2022

Dr-Electron commented Oct 23, 2022

Dr-Electron commented Oct 23, 2022 • edited Loading

adamunchained commented Oct 23, 2022

Dr-Electron commented Oct 24, 2022

huhn511 commented Oct 24, 2022 • edited Loading

robertf26 commented Oct 27, 2022

Dr-Electron commented Oct 27, 2022

sdellava commented Nov 15, 2022

sdellava commented Nov 15, 2022

huhn511 commented Nov 15, 2022

sdellava commented Nov 15, 2022

sdellava commented Nov 15, 2022 • edited Loading

huhn511 left a comment

Choose a reason for hiding this comment

adamunchained commented Nov 16, 2022

adamunchained left a comment

Choose a reason for hiding this comment

huhn511 commented Nov 17, 2022

Dr-Electron commented Nov 17, 2022

robertf26 left a comment

Choose a reason for hiding this comment

robertf26 commented Nov 28, 2022

coodos commented Mar 4, 2022 •

edited

Loading

AdamEunson Apr 6, 2022 •

edited

Loading

AdamEunson Apr 6, 2022 •

edited

Loading

Dr-Electron commented Oct 23, 2022 •

edited

Loading

huhn511 commented Oct 24, 2022 •

edited

Loading

sdellava commented Nov 15, 2022 •

edited

Loading