This is the place to discuss CHIP 10, a standard that allows NFT owners to update some or all of the metadata attributes and store those updates on-chain.
Please leave formal reviews in the CHIP’s Pull Request .
1 Like
Love the creativity and this unlocks a lot of possibilities for the NFT standard.
A couple questions:
-
Any reason why this editable field can’t or shouldn’t be extended to other fields in the schema such as collection.properties.attributes or even sensitive_content? I can’t think of a reason of why either should be editable but there may be more creative minds out there that can.
-
I think it’s worth mentioning some standards expected in url encoding and decoding the query parameters so that applications will treat them identically. e.g. UTF-8 percent encoding
1 Like
Thanks for the kind words!
There’s not technical reason we couldn’t do this, but I couldn’t think of a good reason either.
I think “sensitive_content” applies to the image itself, which of course cannot change. I also know the online NFT viewers depend on this flag to blur out NSFW images, so I don’t think we’d want to give that particular power to trolls. 
As for the collection properties, I thought it would be odd to allow owners to edit these values because they are supposed to be the same for the whole collection. Again I would worry that this could upset some of the assumptions that different Viewer applictions/sites have made - specifically the assumption that “collection” properties should be the same across all NFTs of that collection.
Yes! Great point - I will add some more specifics around the querystring format.
Thank you!
That makes sense. Even though there’s nothing enforcing collection properties to be the same across the collection, creating something that deviates from that norm is probably not ideal.
There could be a use-case for properties.name to be editable. For example for some collections (e.g. Chia Friends) on FarmersMarket.cc allows verified NFT owners to edit what name gets shown on the website. Though this is probably better implemented as a separate predefined editable metadata trait by the NFT creator using this CHIP. Or alternatively FarmersMarket would instruct NFT holders to add a farmersmarket_name query string to the most recent URI.
Along those lines, query strings could pass any data to explorers/services beyond editing metadata. Though that’s probably outside the scope of this CHIP.
2 Likes
I LOVE this idea! Let owners “nickname” their NFTs. The viewer could even have an option - “show nicknames” which would just use the latest metadata value instead of the built-in name property BUT it would still allow users to easily see a list of the “real” names. There could be a little pencil icon next to the NFT name in the viewer to let the user edit the name. After edit, a pop-up would ask for a fee for the update transaction, then submit it!
Does it make sense to include this in the spec and retroactively give all NFTs editable nicknames? It could be a special case where the viewer looks for it on the URL regardless of whether it is marked “editable” in the metadata. Or should the original creator get to decide whether the NFT can be nicknamed?
1 Like
Josh will discuss this CHIP on Zoom on Thursday, Nov 10 at midnight CST / 7 AM CEST. Sorry for the awkward timing for many of you, but we have people from three continents joining. We will also record the meeting and post it later. The Zoom link for the meeting room will posted in the next couple days.
1 Like
It would be really cool to allow owners to rename their BattleKats to what ever they want instead of the randomized naming convention I used to generate them. 
1 Like
Here is the recording from Josh’s demo of this CHIP:
I watched the demo video and people were mentioning that enough edits could eventually become expensive. It seems to me an obvious mitigation strategy could be to off-chain the changes, similar to the image itself.
Instead of directly changing a value, one could change a URI to the whole json file, or one that covers the “off chain” part. Then any bit length of changes could be packaged in whatever the URI bit length would be.
If my understanding is not way off, this seems like something to keep in mind as a possible extensibility feature down the road if the expense of too many edits becomes a problem.
I believe what you are describing is the base of what this CHIP is presenting… updating the URI with a querystring that can override data from within the metadata file itself. To expand on what you have… @endertown wouldn’t it be possible to first create a short URL from something like bit.ly that expands to your full URI with the querystring? Would this allow us to minimize the size each time a new URI is added?
I’m talking about instead of having to do something like ?=name=myNewNameIsReallyLongOMG&otherthing=soManyFieldsToEdit&anotherthing=blahblahblahmoreandmore
one could do ?jsonlink=newPropertiesURI and change everything
2 Likes
Okay. I see what you are saying. What about using a url shortening service? So instead of
using
These seem like independent ideas (and both good ones).
Offloading a replacement JSON altogether is powerful and a similar method can be used to have license files editables.
Having a shortened URL as Andreas eluded to reduces how quickly cost builds up but obviously adds a centralized point of failure (the shortening service).
2 Likes
And I may have answered my own question because it looks like bit.ly is adding in a forward slash in front of the question mark, breaking the link.
Update: breaks the link for URIs that don’t have the actual filename. Such as https://bafkreidfxntax6u54i5blt2ybimcxcak76tn7z4tgevozt5dy7ipdnpzzq.ipfs.nftstorage.link/
This one does work:
https://bafybeic44qz6bsutjicccbogamijx3hmy7thupamutjtlshjsb36ppqyjm.ipfs.nftstorage.link/4.json?name=Thor
https://bit.ly/3UMLOKs
1 Like
Great demo Josh, love the visuals!
One suggestion I have is to be more explicit about the metadata JSON field that is being edited. Instead of assuming a query string of ?color=asdf refers to attributes.items.properties.trait_type.color, maybe we should have ?attributes.items.properties.trait_type.color=asdf as the query string directly. This leaves the door open for non-trait type values to be editable as well.
Downside is the added length (cost) of the parameter name of course.
1 Like
That breakage is specific to how bit.ly implemented their service, right? There could be others like tinyurl (or even something custom built) that has proper support
That seems likely. I’ll try to test a few more.
A URL shortening service might be a good project for Data Layer? lol (always trying to think of how something can be a Chia project)
Udpate: Tinyurl.com seems to handle those without issue.
Interesting CHIP, @enderTown!
An idea I had, which may be more suited to another CHIP or perhaps it could be related to this CHIP, was to have editable fields in the off-chain metadata which were simply ignored when calculating the metadata hash.
NFT viewers could simply strip those fields out of the JSON (in a standardised way) before the metadata hash, meaning that you could have unlimited updates of that field without having to make on-chain spends.
Of course, this comes with pros and cons. The pro being reduced cost, the con being that those editable fields are not verified on chain in any way and you also need to be able to update the metadata at its original URI.
For some use cases, on-chain updates are going to be ideal. But I can imagine some scenarios where you might want a field in an NFT to be updated many times which this could be useful for.
This would be a sort of “soft” editable field, whereas the proposal in CHIP-0010 is more of a “hard” editable field.
1 Like
These are all great ideas!
Love it! Since this is all viewer-dependent anyway, we could combine this idea with @riches:
Of course those stripped-out values would need to be stored somewhere else, where they are easily editable to a user via some other method (webapp, etc). But the “jsonlink” idea above could point to those “soft” values.
The “verbosity rules!!” part of my brain really responds well to those beautiful long specific json paths. But the fact that it would increase cost (at about 14k cost per byte IIRC?) has me actually thinking in the complete opposite way - I’m even wondering if we could build a “least unique chars” function that would be smart enough to allow the query string name to be as small as possible based on the other values. For example, instead of color, it could just be represented as c on the querystring if there are no other attributes that begin with c. Or co if there is another that begins with c but not another that begins with co, and so on. This way we’d save maximum bytes.
Another way to save max bytes would be to use the idea above for a link to a “soft values” json file (x bytes) along with a sha256 hash for that file (32 bytes). If x bytes + 32 bytes < number of bytes you need for your update, it will be cheaper to store it off-chain!
Finally, a small change to NFT1 standard (maybe NFT2?) would be a new rule for these URI lists: a “rolling list” of maybe 3-5 URIs in each list. The oldest one gets bumped out of the list when a new one is added. Viewers probably only ever need 2 or maybe 3 of these URIs assuming multiple services are down. But viewers could still go lookup the full URI list by parsing the NFT’s lineage if needed! This way NFT coins would not grow bigger with every URI addition but the benefits of multiple URIs (and our editable trick) remains.
In fact, if we are dreaming of NFT2, maybe we could even just have an “editable metadata” querystring-style name/value pair list similar to the URI list? Don’t really even need the hostname bit! 
Great feedback, keep it coming! I’ll probably spend some time this weekend on a second draft that includes lots of these revisions. Thanks again!
1 Like
This CHIP is now in Review. Please leave your Reviews in the PR. This CHIP will require consensus acceptance from the community before it can be finalized.