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.

We could make this metadata free form, and simply make it the dual of inscription metadata, which is also free-form. But I think it may be desirable to define a strict schema, so that attributes are more easily searchable, and are in a fixed format. If we define such a schema, we would also allow it to be used for non-gallery inscriptions.

[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.