Case for Multi Parent

[lyndoco]

Overview:

We believe the use case for multi-parent inscriptions is strong. Below is a high-level overview of our current real-world situation, and why we're thinking multi-parent inscriptions would be a good primitive to utilize. Although I personally don’t understand all of the externalities of multi-parent, I do feel compelled to share our thinking and advocate for exploring it's implementation...

Situation:

Suppose we run an art gallery. As an art gallery (existing entity), we have decided to work with a well-known artist (existing entity) to, in collaboration, create “exhibit” (new entity) with 100 unique artworks (new entities).

Single parent structure:

If we are to structure this without multiple parents, we could structure a single artist exhibition as:

Gallery > “Exhibit” by Artist > “Artwork”

Or a multi-artist exhibit as:

Gallery > “Exhibit” > Artist > “Artwork”

The structure above makes it easy for people to navigate to what they are looking for, and provides us the ability to burn the “Exhibit” by Artist or Artist parent. That is great for verifiable scarcity, which is useful in many cases, but makes ongoing collaborations or repeat events a critical design consideration - albeit, not too complex.

The Real Issue:

The real issue lies in the single lineage provenance, which propagates 3 concerns:

1. Incompatible lineage:

In our case, let's say we (Gallery) collaborate with an Ordinals Artist that has a common parent for all of their existing artwork. In order for the Artist to collaborate with us, we must either abandon our parent structure, have the Artist abandon their parent structure, or both parties must compromise and create a new convention.

2. Artists signature:

In our case, how are we to prove the integrity of this art? Did the Artist we collaborate with really produce this work? Where is their signature on the work? I understand there are many creative methods for this, but wouldn't it be nice if this was baked into the lineage - which is being used to serve this exact purpose of provenance.

3. Limited discoverability:

In our single-parent structure from above, when browsing inscriptions with an explorer, users only have the ability to traverse within the Gallery's lineage. Those that wish to navigate and see more of an artists work can't do so easily.

Multi Parent:

For us, this would probably look like:

Gallery > “Exhibit” > “Exhibit” by Artist + “Exhibit” by Artist (Artist Parent) > "Artwork"

AND:

Artist > “Exhibit” by Artist + “Exhibit” by Artist (Gallery Parent) > "Artwork"

with the Gallery owing the top lineage, and the Artist owning the bottom lineage...

or for multiple artists, maybe:

Gallery + Artist + Artist + Artist ... > “Exhibit” > "Artwork"

This would allow for the "Exhibit" and its Artworks to fall underneath the canonical and verifiable work of both the Gallery, and the Artists, while also allowing us to burn the “Exhibit” by Artist or “Exhibit” (multiple artists) parent to prove scarcity.

Having the protocol recognize multiple parents is like having an ad hoc multi-sig for children outputs.

Multi-parent will allow for artists to keep all their work under one parent, and designate that inscription as both their signature, and their personal portfolio.

This will provide the tools for parties to collaborate in equal and fair ways in the future, where their collective children assign proper canonical attribution.

It will also lead to greater discovery within the ecosystem, with explorers enabling users to navigate throughout the inscription ecosystem, and not just within a tree of a single parent.

Multi-parent Issues:

There are a few non-negligible issues to consider with multi-parent:

1. Parent Custody Dilemma - given the current design of parent inscriptions with ord, one address must custody the parent inscriptions, which means parent inscriptions used in collaborations might be moved frequently, and must be held by trusted parties. This is not ideal and should be considered in the implementation.

2. Child Custody Dilemma - in the case that we implement a structure like: Gallery + Artist + Artist + Artist ... > “Exhibit” > "Artwork" (from above) where “Exhibit” is a single child - what is the destination of that single child output? And who gets to control the inevitable children of that child? If the Gallery retains control of “Exhibit”, and inscribes something that the Artists don't like, what affects does this have? Should only direct outputs from collaborations be considered "official" collaborations? If so, then how do we ensure scarcity as well? Should parents be able to inscribe/pass parameters that make children "valid" or "invalid" upon creation of a child - cap on children size, file type, etc?

I'm sure there are more considerations to be made, but these are two that we've been thinking around.

[stet]

This is good stuff. Relatedly, something I was thinking about in September and called it "Parent Invites Children Inscribers" which is conceptually similar to cater to multiple contributors and their own keys.

#2437 (comment)

#2437

[casey]

We definitely want to do this. Dupe of #2494.