Attribute, trait, and gallery Feedback

[casey]

This issue is to collect feedback on attributes, traits, and galleries. There are many possible expansions and improvements to attributes, but I'd like implementation to be driven by actual user need and not speculation.

If you're making inscriptions or galleries which use attributes and traits, please comment with your feedback, requests, and bug reports!

Inscriptions and gallery items can now have attributes, which are structured metadata.

Attributes contain an optional title, as well as traits, a map of trait names to trait values. Trait names are strings, while trait values are booleans, integers, null, or strings.

Ideas for new attributes:

• Description text: Generally useful, and can be used with gallery inscriptions to provide a description of the gallery.
• URL links: Generally useful, and can be used with gallery inscriptions to provide relevant links for the collection. I'm hesitant to add URLs, since they are immutable and cannot be updated if the link goes stale.
• Inscription links: Links which go to another inscription on the same explorer.
• Rune links: Links which go to a rune on the same explorer.

Ideas for new trait values:

• Proportion from 0 to 100: Rendered as a progress bar. Pretty common NFT metadata type.
• Byte string: Rendered as hex.
• Floating or fixed point numbers
• Dates and times
• URLs

Additionally, large galleries with many traits may be very large, and contain many repeated trait names and values. We could add deduplication of trait names and values, which would shrink the size of such galleries enormously.

[notkarmelo]

@casey This is excellent progress, nice work. I'd recommend making artist name a first class attribute in your next update, probably at the same level as the Title attribute.

[0xbitwizard]

Happy to see this in discussion. Agree that attributes should grow from real creator needs, not speculation.

From what we’ve been building with Satoshi Relics at Pob Studio, a few things would be super helpful:

• Titles (huge for discoverability and for making inscriptions readable in explorers and wallets)
• Descriptions (this is great for context, highlighting history + overall telling the story of an ordinal)
• “Created By / Artist / Author” (lightweight attribution goes a long way for collectors and galleries)

Heres an example of a Relic using titles + descriptions today:
https://ordinals.com/inscription/3b821c00ace134051a9fccf3bb280cddaa0114a4df042b84f6b99b9a0eeb56a4i0

We also have an interesting edge case worth thinking about. Although we are the creators of the artwork, the minter can also add metadata (titles+description). The author of this metadata and the artist are different entities. An attribute field to distinguish this could work... something like “art by xxxx, metadata by zzzz". We wonder if there's a more standardized way to allow for collaborative authorship. A fair number of artworks aren't singularly made.

Also, check this out... years ago we created an "NFT Metadata Cheat Sheet". We’ve done a ton of metadata testing (100+ permutations) and put together this guide for NFT creators. It might be useful to think through traits + attributes:
https://www.pob.studio/learn/metadata-cheat-sheet

Worth noting: onchain metadata is one of the big advantages Ordinals has over typical NFT standards. Onchain titles, descriptions, etc., feel like something that should be first-class at this point. Most 721 metadata features are either deprecated or lack client support. This is unclear to most creators and has probably been one of the greatest losses to the NFT space by limiting innovation.

[lifofifoX]

+1 for description and author. Those two seem like a no brainer.

Re: trait types, IMO it makes sense to keep it as simple as we can. Cost of adding new type is low, but cost to remove is high. Maybe just float and date/time (unix timestamp that can handle both) to start with.