Traits and rarity

[casey]

Lots of generative collections have traits of different rarity. This is very interesting to collectors. We should consider supporting a way to add this to a collection.

One way to do this is to add a field for arbitrary textual metadata. This will get expensive fast, and will be limited to 520 bytes, but it would do the trick and be easy.

A better way to do this would be to allow multiple inscriptions on the same sat, and store traits and metadata in an inscription after the main inscription. We could use a tag or special title to indicate that it contains the traits. HTML inscriptions should be able to access this metadata.

[coding-hunk]

Hi @casey , I think your approach to adding traits in inscriptions is a great way to encourage new communities and projects to join the ecosystem. I've been working in the direction you mentioned and came up with given solution & raised a PR here.

Solution:

1. While running ord inscribe command, user can add '--metadata' flag (optional) and pass on traits in JSON form. The JSON will be added in the inscribing envelop as another segment and broadcasted on-chain. eg. ord wallet inscribe --metadata "data" An example of data passed:

   {
   "traits": [
   {
     "trait_type": "hair",
     "value": "Short Black"
   },
   {
     "trait_type": "cap",
     "value": "Blue Cap"
   }
   ]
   }

2. While showing the inscription details on explorer, we will show traits section if metadata is NOT NULL and has whitelisted key "traits" in it. Showing ss demonstrating the content passed in that key. image_link

Once collections and provenance gets established, we can easily compute rarity % for traits in items & collections. This can encourage more community-based NFT projects to join Ordinals and create new collections. Happy to incorporate changes if community has any thoughts.

Note: Validating JSON in metadata input and parsing key-value pair on explorer UI is pending. Will add it soon :)

[p0stcapone]

I'd like to propose leveraging BIP-322 for metadata (and many other things).

Off chain messaging which is provably associated to the creator and/or some later collector would allow for definitions of collections, metadata, artist information, and even evolving narratives as collectors may contribute along the way. Participants would have similar freedoms to storage options as they do with PSBT (public, private, centralized, distributed, etc).

It appears that for most of the extant NFT markets, metadata is critical for indexing/sorting features, and thus marketplaces, explorers, etc would all share some mutual incentives to ensure availability of the data (and the data could be trivially re-produced if necessary).

Food for thought, but I think the optionality and application space for BIP-322 is pretty massive. Introducing the notions here might spur more activity towards other use cases (like perhaps defining protocols for combining a number of artifacts).

I don't think that there's any reason why creators who consider the metadata worthy of block space costs should necessarily be limited in their options, though.

[ordinallyguy]

Good job! I think it is fairly easy to implement having familiar commands (like we set sats fees and other params).

@p0stcapone - With respect to utilising block space, I think the cost would be negligible (0.1kb on avg) as compared to the file size which will be in 10s or 100s kbs minimum.

Agree to the potential of BIP-322 where we have more complex use-cases. This one is fairly simple problem statement with simple solution. It is need of the hour to have on-chain traits for the inscriptions.

[lowkeycoders]

The potential which BIP-322 has is massive but implementing it here seems to be over-engineering for metadata use case.

[coding-hunk]

Hi @casey , Request your attention here! We think, this is something good which can help evolve ordinals platform more.

[nammaki]

Yes @casey please take time to respond 🙏

[coding-hunk]

Hi Casey, Getting quite interest from the community as on-chian traits seems to be a missing piece for collections on Ordinals.

Got 1 team already inscribed its collection using above approach. Sharing one such example: https://www.ordrare.org/inscription/79f14f5467c5ed92b28d44ed8c5469239cbe89ee88534b71e668f829303c5501i0

Need your support to review the changes and encourage on-chain traits for collections via native support. I've added more details in the PR to provide more technical context.

[tunnckoCore]

I've spent my last few months on ORD-721 (uh.. i started around 100-150k inscriptions), while Poyo.eth also work on BRC-721 for about the same time, started earlier than me but still. We are coming to the same stuff.

I believe that's the way forward, no need for a protocol level stuff. That's why a thin abstractions on top are usually born.

Check out at https://ord721.art (launching soon a collection using it). There's a working playground implementing it, but can't share it yet, maybe a few more days.

And Poyo's, https://brc721.com, who also have a ready playground too.

[casey]

2053 has an extremely simple proposal that I think provides 99% of what people want, which is text key value pairs. Check it out!

[casey]

We've added metadata, so inscribers can add arbitrary traits to their inscriptions.