CHIP-0010: Owner-Editable Metadata Format for NFT1

[joshpainter]

This CHIP describes a simple way to enable owners to edit some or all of the metadata for an NFT without breaking the metadata hash. It is backwards compatible with NFT1 and CHIP-0007 and requires only a simple change to be supported by any NFT viewer.

[danieljperry]

CHIP 10 is now a Draft. This is the place to leave formal reviews.
For informal discussion, head over to Discourse.

[RightSexyOrc]

Hi! Neat idea!

We do something similar but use the NFT-tied DID for the xch.limo service, and it seems more elegant. The NFT-tied DID approach does require a bit more work to pull the info out and it is not within the NFT smartcoin, so that is the other side of it. So it depends on what the application needs are. However putting the editable info in the DID (using a key such as an NFT id) could be more elegant, at least until chia-blockchain repo adds rpc endpoints related to separate data fields in NFT1, per @cameroncooper and my comments in CHIP-9 discussion.

I hope these comments are of some use.

[DrakoPensulo]

I think that this CHIP should also address a possibility of adding new (non-existing in the original metadata) "trait_type"s with "value"s to the "attributes" field. I think such additions should be allowed by default. One of the possible use cases is to add traits which were not added by the creator at the mint time. Creator himself, instead of reminting the whole collection, could publish updated metadata files and provide instructions to owners how to update.
EDIT: If new (updated) metadata files come from the creator, the creator could include his signature to indicate that the files are approved by him. The way how and where to include the signature should be specified in this CHIP so that services are able to verify it.

[Rigidity]

One problem with this solution, as has been mentioned somewhere before, is that as you add more URLs to the NFT, all previous URLs remain. This causes the list to grow and increases the CLVM cost of each spend after the metadata update. However, if updates are infrequent, this should be reasonable in the short to medium term.

I feel that opt-in editable metadata and the ability to rename the NFT is useful for a variety of applications, including games utilizing NFTs as assets. And, the consequences of implementing this are pretty low, if used properly. It's an elegant solution that doesn't add much overhead, and can enable things that aren't possible today. Besides, it could be toggled on and off on an explorer since the original metadata is never actually replaced.

Seems like a low risk addition to CHIP-0007. And, in future versions of the NFT standard, the URL limitation mentioned could be improved, for example by rotating the old URLs out after the list grows to a certain length, or by storing edited metadata directly on-chain.

Overall, looks good to me.

[joshpainter]

I think that this CHIP should also address a possibility of adding new (non-existing in the original metadata) "trait_type"s with "value"s to the "attributes" field. I think such additions should be allowed by default.

I think this is an interesting idea, but there are a few things to think through:

• The metadata stores both the original "value" plus the "trait_type" whereas we only store the "value" in the URL. For this to work, we'd need to store the trait_type too, which would further increase the storage size requirements
• NFT viewers would need to look for trait_type in URL as well as adding more complex editing screens - before, it could just use metadata as schema. Now, it must look up schema in URLs too. It also must handle more complex screens that allow user to add new traits and trait types instead of just editing existing ones.
• What if someone included trait_type in the URL for an existing metadata value that already has a trait_type defined in the metadata?

Unfortunately this feature comes with a lot of baggage. IMHO it isn't valuable enough to sacrifice the existing simplicity.

HOWEVER I do have a possible compromise that would still be close to what you want AND allow all existing NFTs to participate!

We could define a standard custom metadata attribute called "nft-graffiti" of type text. We'd make sure no existing metadata out there uses this attribute name now. As part of this standard, NFT viewers would know that there always might be a custom editable metadata value on the URL called nft-graffiti, even for older NFTs that were created before this CHIP.

This would allow owners of all existing NFTs out there to add a "I was here" message on their owned NFTs. This nft-graffiti could include formatted data, links to other metadata, (very small) base64 encodes, etc.

In fact, I like "nft graffiti" so much that I want to change this CHIP's name from "editable metadata" to "NFT Graffiti" because I think people will "get it" when they hear about this feature.

"Oh, just like the owner of the mona lisa could draw a moustache on her if they wanted." 😂

[joshpainter]

One problem with this solution, as has been mentioned somewhere before, is that as you add more URLs to the NFT, all previous URLs remain. This causes the list to grow and increases the CLVM cost of each spend after the metadata update.

And, in future versions of the NFT standard, the URL limitation mentioned could be improved, for example by rotating the old URLs out after the list grows to a certain length, or by storing edited metadata directly on-chain.

Yep exactly! When I first wrote this, I actually assumed that each update to the URL only included THAT URL. I assumed the NFT viewer would try this "main" URL first and then if that failed, it would go look up the parent of this coin to try to find an older URL, and so on. This would add a bit more logic to the client but would save a huge amount of space on-chain!

[joshpainter]

Hi all, I've added a section for "Etchings" which describe a way for existing NFTs to join the fun. LMK what you think!

[danieljperry]

Please take a look at the new "Etchings" section and leave your reviews here. We are looking to finalize this CHIP soon if it gets consensus approval from the community.

[greimela]

@joshpainter Love the etching idea and name!

One other idea, regarding the size implications of adding full URIs every time the editable metadata should change:
What if there was a magic keyword or protocol, like META:// or something like that, that just says "Don't mind me, I'm just updating the editable metadata".
Explorers that want to support editable metadata have to do implementation work anyway, so they can handle it
And for old explorers it would simply be an unusable URL and therefore ignored.

[tojump]

@joshpainter Love the etching idea and name!

One other idea, regarding the size implications of adding full URIs every time the editable metadata should change: What if there was a magic keyword or protocol, like META:// or something like that, that just says "Don't mind me, I'm just updating the editable metadata". Explorers that want to support editable metadata have to do implementation work anyway, so they can handle it And for old explorers it would simply be an unusable URL and therefore ignored.

This is an awesome idea and incidentally resolves the following issue which may arise with editing the original URL.

Query strings are sent to the server, and many web services actually make use of them. There is no guarantee that manipulating the query string would not cause the server to return different data. Some servers may even forbid unrecognized parameters.
If we go down this path, on the long term implementers are bound to end up with hacks to avoid conflicts.

A simple tweak would be to write the parameters after the "#" character (known as the URL fragment). It's a strong convention that nothing influencing the document content should go there, and browsers don't forward it to servers, so playing with this really shouldn't influence the content.

I still like the custom protocol scheme idea more for its cleanliness, saves some chain fees and simplifies the business logic for all implementers.

[joshpainter]

@joshpainter Love the etching idea and name!

One other idea, regarding the size implications of adding full URIs every time the editable metadata should change: What if there was a magic keyword or protocol, like META:// or something like that, that just says "Don't mind me, I'm just updating the editable metadata". Explorers that want to support editable metadata have to do implementation work anyway, so they can handle it And for old explorers it would simply be an unusable URL and therefore ignored.

Thank you! I really like this idea as it is much cleaner, but I'm worried about two things:

• Are we sure that the client will just ignore an unusable URL and that it won't cause any negligible performance (such as throwing internal exceptions, etc)? A new client could be better behaved, of course, but I'm worried about existing clients/web apps/dApps that don't know about this CHIP and don't expect to have to iterate through a bunch of unusable URLs. It just doesn't "feel right" to have old clients fail as part of a new spec, even if they do it silently and the end result is success.
• As a general rule, I'd rather not create "magic strings" or new conventions if possible for maximum compatibility. IMHO, the client expects whatever is in that URI field to resolve to a hashable data blob that can be verified according to the standard. This META:// convention feels like an addition to NFT1 standard instead of working within the existing standard as-designed.

However, I do recognize the potential data (and fee) savings here. Users could use URL shorteners as one workaround, but it won't ever be as compact as a new convention like META://. So I'm open to more discussion on it! Particularly interested in input from the NFT1 authors!

Query strings are sent to the server, and many web services actually make use of them. There is no guarantee that manipulating the query string would not cause the server to return different data. Some servers may even forbid unrecognized parameters. If we go down this path, on the long term implementers are bound to end up with hacks to avoid conflicts.

A simple tweak would be to write the parameters after the "#" character (known as the URL fragment). It's a strong convention that nothing influencing the document content should go there, and browsers don't forward it to servers, so playing with this really shouldn't influence the content.

This is a good point and at first I like just changing to fragment (#) but some counterpoints:

• AFAIK fragment doesn't normally contain name/value pairs like querystring, although name/value pairs could certainly be stored there with the same format and it could be parsed using the same logic. This adds a bit more work for implementors but not much. My main issue here is related to my first issue above about adding weird conventions like "treat fragment as a querystring." Is the juice worth the squeeze? 🤣
• If the host is acting weird when serving the metadata JSON file using querystring values, the owner could simply change hosts as a workaround since they can add multiple URIs. Again, I'd hate to add work to implementors and an extra convention if this doesn't happen much and has a workaround.

This discussion brings up another detail that I didn't cover in the CHIP though: when the owner updates an editable field, do ALL existing unchanged editable values PLUS the new edited value get saved to the querystring? Or just the actual value(s) that changed?

Just adding the changed value(s) makes most sense to me from a data(fee) usage perspective but it does add work to implementors, because they need to iterate through the URLs until they have most recent values for all editable fields. So we should discuss that more too!

Thanks again for input!! This is great, keep it coming!

[danieljperry]

Next week we are going to hold a meeting to finalize the features of CHIP-10. See this post for more info:
https://discord.com/channels/1034523881404370984/1103373485096575016/1137129611289952318

[danieljperry]

The author has chosen to withdraw this CHIP from consideration. The ideas contained within could be revisited at a future date. @joshpainter feel free to close this PR at your convenience.