Galleries and legacy collections

[casey]

Parent child has slowly been getting more adoption, but it hasn't been universal, and many important collections exist which cannot adopt it retroactively.

If a collection does not use parent-child, there is no on-chain reference for which inscriptions are part of the collection and which aren't, which is extremely important for collectors, forcing them to rely on centralized sources like the collection project's socials or exchanges.

I'd like to create some way for these legacy collections, as well as new collections which can't use parent-child (for example because they mint on demand) to have an on-chain indication of which inscriptions are in the collection.

I'm a bit hesitant to introduce something which overlaps in functionality with parent-child, but since adoption of parent-child has been relatively slow, I think it makes sense to start at least talking about it and seeing what it would look like.

My current idea is to add something called a "gallery", which is a list of inscription IDs that are included in an inscription, either under a new tag, or in the existing CBOR metadata. The inscriptions in a gallery would be displayed below the inscription on /inscription, separately from any children.

For example, if the skulls under inscription 0 used a gallery instead of parent/child, they would be displayed as:

Galleries have the following pros and cons:

• Unlike parent-child, it is not possible to add additional inscriptions to a gallery, it is one and done.
• Like parent-child, it is not possible to remove an inscription from a gallery.
• Unlike parent-child, which requires the inscriber to have custody of the parent and be the creator of the child, anyone can create a gallery with any inscriptions.

Because of the last point, that anyone can create a gallery with any inscriptions, we cannot display backlinks from a gallery item to the gallery inscription itself. You could navigate to the gallery, then click an item and go to that item, but you could not go to an item and see a backlink up to the galleries that contain it. If we allowed this, anyone could spam inscriptions that they don't hold into galleries, and imply a relationship which does not exist.

There are a few ways that galleries could be encoded in inscriptions:

1. Add a new odd tag, and include gallery member inscription IDs under this tag
2. Add a new odd tag, for structured CBOR metadata, and include gallery member inscription IDs under this tag
3. Allow including gallery member inscriptions IDs in the existing CBOR metadata in tag 5

The difference between 1 and 2 is that in 1, we would have a new, dedicated tag for gallery members, and in 2, we would have a more general purpose tag for structured metadata.

For 3, we would reuse the existing metadata tag, and would need to have some way of avoiding conflicts. Let's say that we went with 3 and used the top-level key gallery. This could conflict with existing metadata which contains a "gallery" key. A way of avoiding that, which ties into some thoughts about more structured metadata that I've been having, would be to introduce a way of opting into a more structured metadata schema, perhaps with a new odd tag which gave the metadata schema version. If this additional tag was set, metadata would be interpreted according to a schema that we define, with all keys being reserved for our use, except for a top level gallery key for gallery item inscription IDs, a top level unstructured key, for the continued inclusion of unstructured metadata. New keys could be defined as time goes on, for example a more structured, standardized, and richer "attributes" tag.

I think 3 is appealing from the point of view of the ord codebase, since we already have functionality to allow users to provide JSON and CBOR metadata, and this would allow them to provide the gallery member entries via the same features.

For example, to inscribe with the new metadata schema, and provide the metadata, including gallery member entries in metadata.json:

ord wallet inscribe --metadata-schema 1 --json-metadata metadata.json …

This would also allow inscriptions to use the recursive metadata endpoint to fetch metadata, and avoid having to define new endpoints to fetch gallery members.

Feedback is welcome!

[SmarakNayak]

This is a great idea

Have long wanted to curate related inscriptions that weren't necessarily created by the same person

Are galleries themselves inscriptions? It will be useful to allow galleries to have parents

[casey]

@SmarakNayak Yup, galleries are themselves inscriptions, so they can have parents, children, content, and their own metadata.

[okra-sf]

I've come at this problem from a different angle. I've been thinking that converging on standard format from outside of ordinals implementation is a good starting point. Ofc trraction would be much harder w/o support from the founder.

I put together a repo with thoughts along these lines to capture thoughts I'd had for a while as an active collector in the space and as some one who is slowly getting to delivering generative art myself:

https://github.com/okra-sf/ordmeta

Some key differences from what you say here:

1. reinscribing on a manifest sat would allow for evolving collections not just adding/deleting new members. Some similar issues as with an open-ended parent (unburned) and the same way to seal finally.

2. gallery vs a neutral term e.g. collection - not to be a "language prescriptionist" but this general mechanism needn't be any more use case implied than parent-child itself was

3. consider CBOR vs Brotli-compressed JSON, Brotli does an excellent job of eliminating redundancy and is already there. I ran both against real metadata I would use in the collection I have out and that I'm working on.

4. Though I very much like the idea of the Ord client presenting the metadata and a standard "wallet experience" to guide UX (the space has much work to do here), I still lean toward seeing what can be done outside of the ord client changes as first steps.

Will sleep on the rest and be back.

[currytay]

Love this idea, but have a few thoughts:

Even though this feature could be used as a way to create an onchain reference for legacy collections, I think it's best thought of as a new inscription type that enables onchain curation. This opens up interesting possibilities beyond just collection management - for example, creating immutable galleries of thematically related inscriptions across collections (e.g., the first 100 books to be inscribed).

I think the current challenges with legacy collections stem from two problems: mutability and centralized control/trust. Galleries would solve the first problem - once inscribed, the gallery/collection list is immutable and can't be changed (by creator, marketplace, etc.). However, the trust problem remains since anyone can create a gallery including any inscriptions. If multiple parties create galleries claiming to be the "official" reference for a legacy collection (even if they're not different), marketplaces and explorers would still need to make centralized decisions about which gallery to treat as authoritative. This means galleries, while providing valuable immutability guarantees, would still require ecosystem-wide consensus for the legacy collection use case.

[lifofifoX]

What does this give us over inscribing a JSON of Inscription IDs and recursively loading it on a gallery inscription, and promoting that as the on-chain reference for the collection?

I can see two primary benefits for having protocol level support for this:

1. Streamline the process
   We already have social consensus around collection data. People could have consensus around having a specific delegate inscription for gallery and feed it collection JSON to render gallery.

2. Gallery feed similar to /collections
   I am not sure if this is worth potentially devaluing parent/child importance.

[wesleyygg]

First starting with a standardized JSON metadata that represents a collection and then referencing that inscription ID for the gallery could be another approach. Having an on-chain and off-chain tool to confirm inscription formatting would be cool too!

Overall, I think this gallery approach is great!

[RabbiGains-eth]

This is a cool solution for legacy collections.

I would like to see something that addresses inscribe-on-demand mints that are unable to use parent/child.

Verified Galleries:

• create a new metadata field for inscriptions (ex: manifest)
• the creator of an inscribe-on-demand collection reserves a sat that they have custody of
• all inscriptions use the manifest field with the value of the creator's reserved sat number
• once fully minted, the manifest sat is inscribed as a gallery referencing the entire collection
• a new charm type is added to Verified Galleries if all items in the gallery contain the proper manifest field

[sayoooooh]

The parent-child inscriptions are amazing, but it's unfortunate that once inscribed, I can no longer register it as a child.
It would be great if the gallery could complement this, but if I can’t add more once it’s registered, that would be disappointing.

[afxal]

Love the idea! I would love to see a way we can create a gallery from a single parent before a gallery gets created.

One of the ideas we’ve been playing around with at Oviato Studio/Launchpad is how we can facilitate a parent for the collection’s main inscription, which holds the information of the collection with a cover image and metadata using tag 5. The rest of the traits are then created using the parent.

Similar to this, it would be super cool to have a structured way of defining the high-level metadata of a gallery (or collection details) and passing it down to the gallery.

I’m also leaning more towards option 3 using CBOR.

[casey]

@okra-sf

1. reinscribing on a manifest sat would allow for evolving collections not just adding/deleting new members. Some similar issues as with an open-ended parent (unburned) and the same way to seal finally.

If open-ended galleries are desirable, we can explore that as a follow up to an initial version which only supports closed-ended galleries. I think using a sat is a non-starter, since that would tie galleries to the sat index, which is expensive.

One option which doesn't require any protocol changes is inscribing multiple galleries under a parent.

2. gallery vs a neutral term e.g. collection - not to be a "language prescriptionist" but this general mechanism needn't be any more use case implied than parent-child itself was

I don't want to use the term "collection" because people already use the term "collection" to refer to a set of children under a given parent. Parent/child and galleries would both be ways of creating a collection, so I would want to stay away from the term collection.

3. consider CBOR vs Brotli-compressed JSON, Brotli does an excellent job of eliminating redundancy and is already there. I ran both against real metadata I would use in the collection I have out and that I'm working on.

CBOR is already used as the metadata format, whereas JSON isn't used for anything on the protocol level, so it makes sense to leverage CBOR, instead of adding a new format.

4. Though I very much like the idea of the Ord client presenting the metadata and a standard "wallet experience" to guide UX (the space has much work to do here), I still lean toward seeing what can be done outside of the ord client changes as first steps.

Will sleep on the rest and be back.

I think people expect functionality like collections to be built-in, so it would be nice to have an "official" way to do them.

[casey]

@currytay

Even though this feature could be used as a way to create an onchain reference for legacy collections, I think it's best thought of as a new inscription type that enables onchain curation. This opens up interesting possibilities beyond just collection management - for example, creating immutable galleries of thematically related inscriptions across collections (e.g., the first 100 books to be inscribed).

I definitely like the idea of curation. I intend the feature to support as many use cases as possible, and not just be narrowly tailored to legacy collections.

I think the current challenges with legacy collections stem from two problems: mutability and centralized control/trust. Galleries would solve the first problem - once inscribed, the gallery/collection list is immutable and can't be changed (by creator, marketplace, etc.). However, the trust problem remains since anyone can create a gallery including any inscriptions. If multiple parties create galleries claiming to be the "official" reference for a legacy collection (even if they're not different), marketplaces and explorers would still need to make centralized decisions about which gallery to treat as authoritative. This means galleries, while providing valuable immutability guarantees, would still require ecosystem-wide consensus for the legacy collection use case.

I agree that this is an issue. However, I think we would still be in a better position with galleries than without, and I'm not sure how to solve it.

[casey]

@lifofifoX

What does this give us over inscribing a JSON of Inscription IDs and recursively loading it on a gallery inscription, and promoting that as the on-chain reference for the collection?

I can see two primary benefits for having protocol level support for this:

1. Streamline the process
   We already have social consensus around collection data. People could have consensus around having a specific delegate inscription for gallery and feed it collection JSON to render gallery.
2. Gallery feed similar to /collections
   I am not sure if this is worth potentially devaluing parent/child importance.

• JSON is larger than CBOR. At 36 bytes per inscription ID, a 10,000 item CBOR gallery would take up 360,000 bytes, which is under the standardness limit of 400,000 bytes. At 65 bytes per inscription ID, a 10,000 item JSON inscription would take up 650,000 bytes, which is over the limit.
  Compression is a nonstarter for anything that ord has to decompress, since compressed data can uncompress to unreasonable sizes.
• A recursive inscription could only display the members within the inscription <iframe>, as opposed to having separate <iframe>s for each child.
• A recursive inscription wouldn't be able to use the special preview HTML/CSS/JS which handles image/video/model previews.
• A recursive inscription wouldn't be able to have an image for the whole collection, or it would have to somehow alternate between displaying the collection image and the collection members.
• Having a /items link on ordinals.com, for browsing a paginated list of gallery items

I think the main benefit would just be the technical consensus part, around a single standard and way of doing things, which would help adoption and cross-platform support.

[casey]

This is a cool solution for legacy collections.

I would like to see something that addresses inscribe-on-demand mints that are unable to use parent/child.

Verified Galleries:

• create a new metadata field for inscriptions (ex: manifest)
• the creator of an inscribe-on-demand collection reserves a sat that they have custody of
• all inscriptions use the manifest field with the value of the creator's reserved sat number
• once fully minted, the manifest sat is inscribed as a gallery referencing the entire collection
• a new charm type is added to Verified Galleries if all items in the gallery contain the proper manifest field

Some sort of way of back-linking, like you describe, can be done as a follow-up. Using a sat is a nonstarter, since it ties the feature to the sat index, which is expensive. However, I have an idea for this which uses a specific UTXO. Basically, you inscribe the gallery members, and include in a tag or metadata the UTXO which will be used to create the gallery. Then you inscribe the gallery referencing the members using that UTXO. If the UTXO tag matches a gallery that contains that inscription, you get a backlink.

[casey]

The parent-child inscriptions are amazing, but it's unfortunate that once inscribed, I can no longer register it as a child. It would be great if the gallery could complement this, but if I can’t add more once it’s registered, that would be disappointing.

Yah, it's tough. But we can think about this as a follow-up.

[casey]

I think my main concerns at this point is about adoption. If this gets a lot of buy in from collections and exchanges, then it's a great idea. If not, then it's just kind of an additional, confusing alternative to parent-child.

[RobertClarke]

Very very happy to see discussion around this issue! Parent/child is great but not often used as the source of truth by major marketplaces/indexers/lending platforms. To fully solve the "off chain collection" problem for legacy collections I think we need to ensure a few things:

Required:

1. Collection title + description
2. Collection logo inscription ID
3. Collection data/inscription list is immutable and can never be changed

Preferred:

1. Collection metadata for traits (for example, Nodemonke Aliens, Gold, etc.)
2. Lightweight on-chain footprint; consider leveraging inscription numbers instead of inscription IDs + compression to ensure more people can put a gallery on-chain without needing to go to a miner directly for inscription to bypass file-size limits

[casey]

@RobertClarke

1. Collection title + description

This could be done using the existing metadata feature. Since galleries are inscriptions, they can include metadata, which can be used to describe the gallery. Standardization is important here, since otherwise galleries might use different keys (title vs Title, etc). I'm thinking about developing galleries in tandem with a proper schema for inscription metadata.

2. Collection logo inscription ID

A gallery is an inscription, so the collection logo can be the gallery content. Is this good enough?

3. Collection data/inscription list is immutable and can never be changed

I think I see the merits in making galleries immutable. I commented a few times above that we could consider making open-ended galleries, but perhaps it's easier to just not to.

Preferred:

1. Collection metadata for traits (for example, Nodemonke Aliens, Gold, etc.)

This is an interesting one. A gallery is an inscription, so it can have metadata, but the default would be this metadata describes the gallery, not the items in the gallery. I can see the use for including the metadata for the gallery items in the gallery, since legacy collections often don't have individual metadata. I'd like to support this, and I think it requires a proper schema, so you can include structured metadata for children.

2. Lightweight on-chain footprint; consider leveraging inscription numbers instead of inscription IDs + compression to ensure more people can put a gallery on-chain without needing to go to a miner directly for inscription to bypass file-size limits

Compression is a nonstarter, since a compressed blob can decompress to unlimited size, and compression formats are complex.

I don't like using inscription numbers, since in order to know the inscription number of an inscription, you must index the entire chain up to that point, whereas an inscription ID contains a transaction hash, so you need only index that single transaction.

It's common to inscribe multiple inscriptions in a single transaction, and if the collection was inscribed this way, we can potentially omit repeated txids in inscription ids, bringing them down potentially to one byte apiece.

Having examples of collections which might use this, so we can ballpark how much data they would use would be good.