Add self/ Endpoint for Accessing Inscription Metadata

[a6b8]

I'm currently thinking about the new interaction possibilities created by the new metadata standard. The existing API can import metadata using /r/metadata/<INSCRIPTION_ID> and then decrypt it with CBOR.

But to my knowledge, there's currently no way for the Inscription Block (0) to read data from its own metadata (5). This is because it's not possible to determine the Inscription Id. It would be interesting to have a self/ endpoint that provides basic information about the inscriptionId and its creation block height.

/r/self/inscriptionId
/r/self/blockheight

This would help parameterize generative art using metadata. It could also define time periods for Inscription based on block height.

[elocremarc]

You can get inscriptionId out of the URL object.

let inscriptionId = window.location.pathname.split('/')[2]

See how I did it on the child endpoint here

This would help parameterize generative art using metadata. It could also define time periods for Inscription based on block height.

Once we get the inscription recursive endpoint we will get information about an inscription.
#2628

[a6b8]

let inscriptionId = window.location.pathname.split('/')[2]

Interesting, with this solution, you would exit the Ordinals container and fetch the Inscription Id from outside.

In essence, my search is for an Ordinals Native solution that works regardless of the use case. From what I understand in #2628, it involves a much broader scope. I'm a bit unclear on how to obtain the context directly from the Inscription there.

My thought was, currently, we have the following routes:

/r/*
/r/children/*
/r/metadata/*
/r/sat/*

Adding a self/ route would be straightforward and comprehensible. It could also be considered whether all information is gathered or queried individually: [1, 3, 5, 7, 9]. This endpoint would be the initial entry point for many use cases.

/r/self/*

Example Response:

{
    "content_type": "...",
    "pointer": "...",
    "parent": null,
    "metadata": "...",
    "metaprotocol": "...",
    "content_encoding": "...",
    "blockheight": n
}

[elocremarc]

you would exit the Ordinals container and fetch the Inscription Id from outside.

I am confused what your saying. The ordinal container is the routing of how its displayed /content/:id
The id is part of the context of the inscription because it always needs to be served from /content/
See #2175 (comment)

{
    "content_type": "...",
    "pointer": "...",
    "parent": null,
    "metadata": "...",
    "metaprotocol": "...",
    "content_encoding": "...",
    "blockheight": n
}

A lot of this can be accessed via the metadata endpoint or the new inscription endpoint in PR 2628.
parent and metaprotocol could be added to that PR as well either now or at a latter time.

[casey]

@a6b8 How would /r/self/inscriptionId know which inscription ID to return?

[a6b8]

@a6b8 How would /r/self/inscriptionId know which inscription ID to return?

To the best of my knowledge, the InscriptionID cannot be determined before the Inscription is created. Later modification of the Inscription is not possible. Therefore, a way must be found to enable a self reference retroactively.

The actual Inscription can/must include the following fields:

0 content
1 content_type
...
5 metadata
...

To retrieve an Inscription, you use the route /content/:inscription_id The response then returns the content of 0 and uses 1 to specify the content type. This route also allows for the loading (importing) of Inscriptions. The InscriptionID is known when loading Inscriptions.

The real problem arises at the initial entry point. While the user triggers the request with knowledge of the InscriptionID, the returned content is unaware of it. However, the information can be accessed in certain places:

1. window.location.pathname: The Window object is only used in web browsers. It also remains unclear whether the correct URL is always returned here (iframe...). While it is a web standard, every web browser behaves slightly differently.
2. header: The server could include the information in the header. However, this information is not readily accessible in web browsers by default.

The window object appears to be a solution for web applications but is not a universal solution. Risks arising from different web browsers also remain.

My proposed solution:
The information should be obtained on the backend side, not the frontend side. Since the Indexer (Ord) already provides other information in a trusted manner, it should also take on this task.

When creating the Inscription, the Creator could include a reference under 5 metadata, confirming that the content should be modified. The name, for example, self, indicates the type of modification.

An example Metadata could look like this:

{
	...
	"_permissions": {
		"self": true
	}
}

If _permissions.self === true, the Indexer searches in the content (0) for /r/self/*/ and replaces all instances with the correct /r/self/:inscription_id/*/ It then provides the modified Inscription to the user. This would create a new (potentially) modified content that is initially the same as 0 but is modified according to the specified permission.

Derived from this, a distinction arises between:

1. /content/:inscription_id: Returns 0 in the possibly modified state.
2. /r/self/:inscription_id/0: Returns 0 in the unmodified state.

The separation has many advantages, especially for validating individual sections. The content can also perform self-validation by using externally imported validation and determining whether all parameters adhere to a specific protocol standard.

[casey]

Modifying the content is not a good idea, since there might be false positives. I think to explore this feature, there would need to be a context where getting the inscription ID from the URL doesn't work.

[l2xl]

There is another way to determine inscription self ID. Unfortunately it has its own drawback: the inscription need to have a parent. The parent inscription ID is known in advance as well as its child-number. In this case one can get its inscription id like this:

let s=(await(await fetch('/r/children/<parent_id>',h)).json()).ids[<child_num>]

here is working example: https://ordinals.com/inscription/b6fd036e1ec8e57f09b1a7a7e0dd68f905241ccf867820bd9a38b862c6d92685i0