Inscription metadata #2421

casey · 2023-09-04T18:36:42Z

Add metadata, based on #2053.

elocremarc · 2023-09-04T20:25:57Z

We should map keys to the Open Graph Protocol standard so metatags could also display on socials and SEO.
Example for /inscription page:

  <head>
    <meta property="og:foo">bar</meta>
    <meta property="og:this">that</meta>
    <meta property="og:title">dope title</meta>
    <meta property="og:image" content="/content/<inscriptionId>" />
  </head>

Edit: I think image needs the full path for images server would need to return origin

<meta property="og:image" content="https://ordinals.com/content/<inscriptionId>" />

This would work very well for image mime types without even encoding that tag. If say a HTML page wants SEO that one could specify an image. Will inscriptionId fit in the byte limit of this encoding?

docs/src/inscriptions/metadata.md

templates/inscription.html

src/inscription.rs

elocremarc · 2023-09-04T23:23:26Z

Needs a page ref on SUMMARY.md

 - [Inscriptions](inscriptions.md)
     - [Recursion](inscriptions/recursion.md)
     - [Metadata](inscriptions/metadata.md)

Eoous · 2023-09-05T03:07:22Z

Maybe we could support parse metadata in a file?

uzyn · 2023-09-05T16:51:36Z

Would be great if we can align with OIP-01, a non-breaking metadata implementation.

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "text/plain;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "Hello, world!"
OP_ENDIF

OP_FALSE
OP_IF
  OP_PUSH "ord"
  OP_PUSH 1
  OP_PUSH "application/json;charset=utf-8"
  OP_PUSH 0
  OP_PUSH "{\"p\":\"oip-01\"}"
OP_ENDIF

It's been implemented by Sado SDK, Ordzaar, Ordlify.

Here's an example of a defined metadata using OIP-01: https://explorer.ordzaar.com/inscription/105758bb912665f5f803ec0f5268d2218b51978b16de05622c64c9faafd2d22ei0

While remaining fully backward-compatible, so it shows up fine on Ordinals.com https://ordinals.com/inscription/105758bb912665f5f803ec0f5268d2218b51978b16de05622c64c9faafd2d22ei0

It has a looser format, JSON vs named key-value pairs, for metadata than #2053, allowing for more flexible use cases such as: verifiable ordinal collection and file chunking.

Happy to discuss further on this.

casey · 2023-09-05T18:39:26Z

Needs a page ref on SUMMARY.md

 - [Inscriptions](inscriptions.md)
     - [Recursion](inscriptions/recursion.md)
     - [Metadata](inscriptions/metadata.md)

Good catch!

casey · 2023-09-05T18:49:35Z

Would be great if we can align with OIP-01, a non-breaking metadata implementation.

We considered something like this, but I see a few issues with using a different inscription on the same sat to contain metadata, but it seems inelegant to make the metadata its own inscription, when it isn't interesting on its own, and shouldn't be displayed as an inscription in its own right.

kodemon · 2023-09-06T02:16:04Z

metadata its own inscription, when it isn't interesting on its own, and shouldn't be displayed as an inscription in its own right

This makes sense to me, as having secondary inscriptions on sats being interpreted as unbound leaves inconsistent representation in the consumer layers (eg. one place may support OIP where as another may not) and represents them as bad/invalid inscriptions.

I think a single layer approach with OP codes may be a little limiting. Having meta data as a flexible object with ability to add nested separation of concern and lists through JSON is more beneficial than a key value pair approach.

So something like:

OP_5 meta # marker, when value "meta" next value OP_7 should be JSON
OP_7 json

So I definitely like an approach where we don't create two inscriptions on the same sat, but would miss having the ability to add a somewhat more complex meta object (unless there are some elegant solutions to this using the proposed approach). 🤔

casey · 2023-09-06T02:32:52Z

but would miss having the ability to add a somewhat more complex meta object

What specific metadata did you have in mind? From what I've observed, a simple key-value store covers the vast majority of use-cases, and has the advantage that it's attractive and simple to display.

kodemon · 2023-09-06T02:36:54Z

I was thinking in line of the meta presented in this example: https://ordinals.com/content/105758bb912665f5f803ec0f5268d2218b51978b16de05622c64c9faafd2d22ei1

So for example a trait key with a list of traits. or the creator with its own key value pair object. The one thing I could think of was doing:

OP_5 creator.name
OP_7 TheArtist

But for the traits list it may be a little more complicated 🤔

Eoous · 2023-09-06T02:40:03Z

a simple key-value store covers the vast majority of use-cases, and has the advantage that it's attractive and simple to display.

Many traits need nested key value pairs. In the scene, simple key-value pair could make no sense. Maybe json is a good way to store traits.

OP_5 json metadata

uzyn · 2023-09-06T04:43:54Z

@casey

We considered something like this, but I see a few issues with using a different inscription on the same sat to contain metadata, but it seems inelegant to make the metadata its own inscription, when it isn't interesting on its own, and shouldn't be displayed as an inscription in its own right.

Agree on all the above. OIP-1 was designed, in order to not break existing support, based on a specific negative test case at the time of proposal (where trailing inscription is expected to be ignored). It seems to now no longer true, due to #2145

Trying to be as accommodating as possible to existing adopted social standards, e.g. https://www.oips.io/oip-02-verifiable-ordinal-collection utilizes OIP-1 but is proposed based on BRC-20.

I would adopt the model, but would highly recommend doing a more structured data in a similar style of BRC-20 for more extensibility.

orkunkilic · 2023-09-06T08:48:31Z

What do you think of supporting inner metadata with smth like this @casey:

 OP_5 just_key 
 OP_7 just_value
 OP_5 outer_key
 OP_7 
   OP_5 inner_key_and_outer_value
   OP_7 inner_value

We can limit inner depth with some const like 3? I am just brainstorming to have more flexible metadata structure while avoiding json.

casey · 2023-09-06T19:06:11Z

@kodemon

I was thinking in line of the meta presented in this example: https://ordinals.com/content/105758bb912665f5f803ec0f5268d2218b51978b16de05622c64c9faafd2d22ei1

There are some nested fields, but I feel like they could avoided and expressed as key-value pairs:

key	value
Title	Elemental
Description	Azuki Elementals are a collection of 20,000 characters within the four domains of the Garden.
Hair	Electrified Long - Black
Offhand	Elemental Blade - Lightning
Eyes	Enticing
Type	Blue
Creator	TheArtist [email protected]
Tips	1FFBzYT55auox4boSaQUYcsQ9LCaJJWhRw

@0xEclair

Many traits need nested key value pairs. In the scene, simple key-value pair could make no sense.

Examples of traits that need nested key value pairs would be great.

@orkunkilic

What do you think of supporting inner metadata with smth like this @casey:

In that case it would probably be better to use JSON, instead of rolling a new serialization format.

@uzyn

I would adopt the model, but would highly recommend doing a more structured data in a similar style of BRC-20 for more extensibility.

The purpose of the inscription metadata proposed here is to always for it to be human readable. My worry with structured data is that it won't be possible to display it to the user in an appealing format.

Eoous · 2023-09-06T22:26:14Z

There are some nested fields, but I feel like they could avoided and expressed as key-value pairs

Yeah. Normal key value pairs could be like this. But for developers, maybe they need to distinct types of keys(for display or for using in app). If only for display, it's no problem. I think metadata also needs more information to help developer to use them.

kodemon · 2023-09-07T01:24:51Z

The purpose of the inscription metadata proposed here is to always for it to be human readable. My worry with structured data is that it won't be possible to display it to the user in an appealing format.

I think this is probably where the mindset deviates as I am third party consumer of ord and shape the data it provides into product specific requirements. So for my use cases structured data is more important than ease of display as that is something I deal with during formatting.

So lets imagine the following object:

{
  "p": "super",
  "traits": [
    {
      "power": "anything",
      "strength": 10
    },
    ...
  ],
  ...other
}

The tricky part with this requirement is that its hard to flatten because the traits array may be dynamic, so if I flatten this it becomes hard to identify what is part of a trait and what is not. Where as when I am processing traits as part of my application I may have some internal logic specific for handling dynamic trait information.

So while I understand the appeal of human readable out of the box, as a third party developer relying on the data ord provides and the way that I personally prefer meta data to be presented I still think a flat key value pair representation is too limiting and I can see myself needing to hack around the limitation rather than just being able to use the data as is.

I would probably need to do something like

key	value
p	super
data	{ "traits": [ ... ], ... }

I think from a developers perspective consuming ord as a service, a structured meta object is more future proof.

For this specific issue I decided to be a little more vocal in my thoughts as it has a massive impact on the work I do with ord and we heavily rely on the ability add meta data to inscriptions 😅

casey · 2023-09-07T19:35:26Z

For this specific issue I decided to be a little more vocal in my thoughts as it has a massive impact on the work I do with ord and we heavily rely on the ability add meta data to inscriptions 😅

Your feedback is very welcome!

I think that, as much as I would like to constrain metadata to key-value pairs, it's a losing battle, so I changed the spec to use JSON instead. I've also included, as part of the spec examples of how ord will render JSON metadata as HTML on /inscription pages. Hopefully this will encourage inscribers to make their metadata legible, and to omit anything from metadata that isn't intended for human consumption.

bruffstar · 2023-09-08T08:44:37Z

It's great this was moved to a JSON setup. I think it would be really useful to have an endpoint where we get the metadata returned as JSON.

e.g. https://ordinals.com/inscription/<inscription-id>/metadata

This way, we can consume the JSON and display it any way we want.

Psifour · 2023-09-08T18:18:35Z

To confirm, the plan for ord going forward is uncompressed UTF-8 JSON as a metadata format?
Despite all the excellent ways to encode data we have chosen one of the least data efficient ones to implement?

casey · 2023-09-08T18:27:21Z

To confirm, the plan for ord going forward is uncompressed UTF-8 JSON as a metadata format? Despite all the excellent ways to encode data we have chosen one of the least data efficient ones to implement?

I'm not set on this, but I don't think it's an entirely unreasonable choice. Yes, JSON is inefficient, however it is ubiquitous, and being human readable and writable is a huge advantage.

stet · 2023-09-10T15:29:48Z

human readable and writable is a huge advantage

I encourage use of efficient CBOR etc encoding. Not sure why it matters if metadata is immediately readable if it is rendered for consumer in appropriate format (which could be transformed to JSON if needed). Saving on bytes and bandwidth and energy efficiency are important considerations esp in context of Bitcoin onchain data store.

This is a great opportunity to be smart about the broad impact as opposed to a narrow focus on display of data.

I don't think people and software should be writing and inscribing raw JSON moving forward.

kodemon · 2023-09-10T16:35:46Z

I encourage use of efficient CBOR etc encoding. Not sure why it matters if metadata is immediately readable if it is rendered for consumer in appropriate format (which could be transformed to JSON if needed).

I agree with the take that readability should be a consumer level concern and not dictate its storage format in a way that is less efficient than it can be.

It would be interesting to hear some good ideas on an efficient and flexible solution for storing meta data on inscriptions. I don't have in depth knowledge on the topic of optimized encode/decode topics, and I am mostly concerned with the ability to consume the data stored to transform it into output that is used in product and/or protocol level decisions.

raphjaph

LGTM!

Let's add special title and description display in another PR

casey force-pushed the metadata branch from 154078e to e836267 Compare September 4, 2023 18:37

ordinals deleted a comment from onepixelinscriptions Sep 4, 2023

onepixelinscriptions reviewed Sep 4, 2023

View reviewed changes

docs/src/inscriptions/metadata.md Outdated Show resolved Hide resolved

elocremarc reviewed Sep 4, 2023

View reviewed changes

templates/inscription.html Show resolved Hide resolved

elocremarc reviewed Sep 4, 2023

View reviewed changes

src/inscription.rs Outdated Show resolved Hide resolved

elocremarc referenced this pull request Sep 7, 2023

Add provenance to docs summary (#2427)

4b1709d

rot13maxi mentioned this pull request Sep 7, 2023

Add arbitrary metadata to inscription #2134

Closed

elocremarc mentioned this pull request Oct 2, 2023

Inscription metadata in rune deploy. casey/runestone#18

Closed

casey force-pushed the metadata branch from 69207a1 to a478a7c Compare October 3, 2023 18:16

casey force-pushed the metadata branch from a478a7c to 423ca99 Compare October 3, 2023 18:17

Add CBOR metadata

b6f0ab8

casey force-pushed the metadata branch from 423ca99 to b6f0ab8 Compare October 3, 2023 18:17

casey added 13 commits October 3, 2023 11:22

Update docs

12cdd56

Sort inscribe arguments

c67fa90

Add tests

fde83c3

Test float metadata

f7ecd1c

Add more tests

3d26354

Add more tests

ad48132

Update display info

fef1c66

Update spec

1760a15

Fix spelling

44fbe35

Fix test name

6707147

Merge remote-tracking branch 'upstream/master' into metadata

2f20a96

Link cbor spec

6f978c8

Fix spelling

2e55463

raphjaph approved these changes Oct 3, 2023

View reviewed changes

casey merged commit 26a755f into ordinals:master Oct 3, 2023
6 checks passed

casey deleted the metadata branch October 3, 2023 19:57

elocremarc mentioned this pull request Oct 23, 2023

Parse inscription metadata cypherpunklab/bord#13

Open

hans-crypto mentioned this pull request Nov 17, 2023

Parse & display inscription metadata ordpool-space/ordpool#4

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Inscription metadata #2421

Inscription metadata #2421

casey commented Sep 4, 2023

elocremarc commented Sep 4, 2023 •

edited

Loading

elocremarc commented Sep 4, 2023

Eoous commented Sep 5, 2023

uzyn commented Sep 5, 2023

casey commented Sep 5, 2023

casey commented Sep 5, 2023

kodemon commented Sep 6, 2023 •

edited

Loading

casey commented Sep 6, 2023

kodemon commented Sep 6, 2023 •

edited

Loading

Eoous commented Sep 6, 2023 •

edited

Loading

uzyn commented Sep 6, 2023

orkunkilic commented Sep 6, 2023

casey commented Sep 6, 2023

Eoous commented Sep 6, 2023 •

edited

Loading

kodemon commented Sep 7, 2023 •

edited

Loading

casey commented Sep 7, 2023 •

edited

Loading

bruffstar commented Sep 8, 2023

Psifour commented Sep 8, 2023

casey commented Sep 8, 2023

stet commented Sep 10, 2023 •

edited

Loading

kodemon commented Sep 10, 2023

raphjaph left a comment

Inscription metadata #2421

Inscription metadata #2421

Conversation

casey commented Sep 4, 2023

elocremarc commented Sep 4, 2023 • edited Loading

elocremarc commented Sep 4, 2023

Eoous commented Sep 5, 2023

uzyn commented Sep 5, 2023

casey commented Sep 5, 2023

casey commented Sep 5, 2023

kodemon commented Sep 6, 2023 • edited Loading

casey commented Sep 6, 2023

kodemon commented Sep 6, 2023 • edited Loading

Eoous commented Sep 6, 2023 • edited Loading

uzyn commented Sep 6, 2023

orkunkilic commented Sep 6, 2023

casey commented Sep 6, 2023

Eoous commented Sep 6, 2023 • edited Loading

kodemon commented Sep 7, 2023 • edited Loading

casey commented Sep 7, 2023 • edited Loading

bruffstar commented Sep 8, 2023

Psifour commented Sep 8, 2023

casey commented Sep 8, 2023

stet commented Sep 10, 2023 • edited Loading

kodemon commented Sep 10, 2023

raphjaph left a comment

Choose a reason for hiding this comment

elocremarc commented Sep 4, 2023 •

edited

Loading

kodemon commented Sep 6, 2023 •

edited

Loading

kodemon commented Sep 6, 2023 •

edited

Loading

Eoous commented Sep 6, 2023 •

edited

Loading

Eoous commented Sep 6, 2023 •

edited

Loading

kodemon commented Sep 7, 2023 •

edited

Loading

casey commented Sep 7, 2023 •

edited

Loading

stet commented Sep 10, 2023 •

edited

Loading