Attributes

[casey]

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.

[RobertClarke]

Thank you @casey and @raphjaph for your work on galleries! An important step to reduce the dependency on centralized services for Ordinal collection metadata.

A few more asks in addition to the individual inscription attributes (apologies I'm not more help on the implementation side or if these were already implemented):

• Collection Title support
• Collection Description support
• Collection thumbnail support
• Collection Discord link support (updatable over time if possible)
• Collection Discord link support (updatable over time if possible)

With these features, a centralized collection metadata coordinator is no longer necessary, so they would be great additions!

[casey]

These are all pretty doable, I think.

Attributes which can be set on gallery items can also be set on inscriptions. So, since there will be title and description attributes, you can set these both on gallery items, and on the gallery inscription, so the gallery's title and description can serve as the collection title and description. Since the gallery is an inscription, it can be an image and serve as the collection thumbnail.

Galleries and attributes will initially be immutable, with no plans to ever make them mutable. Mutability is a serious footgun and adds enormous protocol complexity, so it's unlikely that we'll ever add mutable attributes.

Links can go stale, which makes me wonder if it's better to have immutable links (like a Discord link) which might go stale, or not have links at all. I think the reality is that if there isn't a dedicated link attribute, people will still add them in freeform metadata fields like descriptions, so maybe we should just add them because they'll do it anyways and dedicated fields will look nicer.

[lifofifoX]

Having attributes for an inscription without any gallery seems conflicting with metadata.

Why not start by having attributes only for the gallery and gallery items?

Properties = {
  ? 0: [*GalleryItem],
  ? 1: text,  ; title (optional)
  ? 2: text,  ; description (optional)
  * any => any
}

GalleryItem = {
  ? 0: bstr .size (32..36),
  ? 1: { * any => any },  ; attributes (optional map of key-value pairs)
  * any => any
}

[casey]

Inscription metadata is free-form, whereas the metadata I'm talking about has a schema. Metadata with a schema is much more useful than free-form metadata, since it's actually machine readable.

Also, I do not want to add any features to galleries or gallery items which are not available to inscriptions, so if gallery items can have a dedicated title field which displays nicely, inscriptions should also.

The implementation will be like this:

Properties = {
  ? 0: [*GalleryItem],
  ? 1: Metadata,
  * any => any
}

GalleryItem = {
  ? 0: bstr .size (32..36),
  ? 1: Metadata,
  * any => any
}

Metadata = {
  ? 0: text, ; title
  ? 1: text, ; description
}

So Metadata is identical between a gallery item and an inscription.

There are so many improvements possible with structured metadata. For example, the description could be Markdown. Also, I'm not contemplating any => any for attributes, I'm actually thinking text => Attribute, where Attribute is an enum type.

[lifofifoX]

Thanks for explaining! I don't see description being used much for gallery items, if at all. But I suppose it makes sense to have it for parity with Inscriptions.

[casey]

See #4243 for a first stab at defining the schema for traits. It's broken down into attributes, a top-level struct with fixed keys, and traits, a member of attributes which has arbitrary text keys mapping to values of a few different types.

[lifofifoX]

@casey Looks good! Do you expect attributes to essentially replace metadata for the majority of the inscriptions? Also, curious to know why you added alt text.

[casey]

Do you expect attributes to essentially replace metadata for the majority of the inscriptions?

I think so. I think that they are pretty complementary: Use attributes for anything structured that fits into the schema, to aid search/discoverability/etc, use metadata for anything extra or unstructured.

Also, curious to know why you added alt text.

Just kind of a random idea, maybe useful for accessibility for the blind degens. Although the alt attribute is only valid on <img> elements, so it would actually have to translate into a title or aria-label tag.