We recently merged #4212, which adds the ability to create "galleries". Any inscription can contain a gallery, which is a list of inscription IDs. These inscriptions appear in a dedicate section called "gallery" on /inscription, similar to how children appear.

There are many use cases for galleries, one of which is allowing off-chain collections to inscribe a gallery with the members of the collection, so that there exists an immutable on-chain record of the members of the collection, lessening ecosystem-wide dependence on centralized services.

However, off-chain collections, in addition to simply being a list of inscriptions, also include per-inscription metadata, such as title, background color, accessories, etcetera. Ideally there is some path for these collections to also migrate their metadata on chain.

Gallery items may currently only contain an inscription id, but they are encoded as CBOR maps, and so may be extended with additional attributes.

The goal of this issue is to define how attributes may be included with gallery items, to allow all off-chain collection data to be migrated to a single, immutable gallery inscription.

I think we also have an opportunity to improve metadata both for gallery items and normal inscriptions. Currently, metadata is free-form, which means that it has no structure, it is not easily machine readable, and there are a number of unfortunate conventions, like using value and trait_type keys which add nothing but bloat the byte size and display size of metadata. I think we should introduce structured metadata, including attributes, which must follow a fixed schema, and use this structured metadata for both inscriptions and gallery items. This structured metadata will in addition to unstructured metadata, and users may continue to use unstructured metadata as they wish.

We define an additional type, Attributes, and add it to both Properties and GalleryItem.

See #4243 for a draft PR.