SIP: Standard URI Definition for Bitcoin Ordinal Inscriptions

[rafaelcr]

This SIP defines a simple URI format that Stacks developers can use to reference a Bitcoin Ordinal Inscription so its contents can be used in applications, token metadata, etc. This format supports referencing an inscription by its Inscription ID, Inscription number, Satoshi ordinal number, and Satoshi name.

[nickgamma]

Nice! Great to see standards of this kind.

Would propose that for a formal standard, inscription references should be inscription ID vs number as there is less potential for discrepancies in indexing on one platform vs another (esp. related to "off by one") which had been fairly common to see for a while. I'd liken inscription ID to a "fully qualified ID" which feels more appropriate given a frozen token URI is truly immutable and discrepancies would be unfortunate.

Additionally, while all Gamma Create contracts historically support a base URI format of this kind, the SIP should also consider the need to reference a manifest of all tokens within a collection/contract in a particular format, either on Bitcoin or on Stacks, for this to work for standard NFT contracts where many tokens exist (especially for backward compatibility).

Currently, based on the way IPFS works, you can set a base URI for the contract and then append /<token-id> to the end of the URI to get the token URI content. Most Gamma contracts (and most other Stacks NFT contracts) do not have a set-token-uri function (only set-base-uri), so backward compatibility wouldn't be possible without additional standards. Given the complexity of defining every single token URI for hundreds or thousands of tokens, I'd propose it's most practical even on a going-forward basis to use a manifest-style standard.

This might look something like the following:

1. Create inscriptions on Bitcoin for each token in your collection/contract
2. Create a manifest inscription that references each token ID (arbitrarily assigned) and its corresponding inscription ID in some agreed upon format (ideally minified for file size / fee considerations)
3. Set base URI at deployment (or call set-base-uri function post-deployment) and set it to ord://i/<manifest-inscription-id>
4. Applications on Stacks would refer to the content for the token inscription ID within the manifest that corresponds to the equivalent Stacks token ID

For what it's worth, what you've defined here could still work for Gamma's Continuous contracts, which have a set-token-uri function given each token is independently managed, but this represents only a portion of our contracts.

[rafaelcr]

@nickgamma

Would propose that for a formal standard, inscription references should be inscription ID vs number as there is less potential for discrepancies in indexing on one platform vs another

In the past, inscription number discrepancies have surfaced when one of the indexers does not recognize an inscription altogether (versus others that do). In that case, even the inscription ID would not work in the bugged indexer. ID and number are equivalent in the sense that they both work in indexers that follow the canonical ord indexing logic. Even when bugs have surfaced in ord, the missed inscriptions become cursed inscriptions to avoid affecting the numbering already in place.

Additionally, while all Gamma Create contracts historically support a base URI format of this kind, the SIP should also consider the need to reference a manifest of all tokens within a collection/contract in a particular format, either on Bitcoin or on Stacks, for this to work for standard NFT contracts where many tokens exist (especially for backward compatibility).

This is a cool idea, but I think it falls outside of the scope for this SIP. This proposal was only intended as a way to provide a general URI standard to reference inscription content. I think what you suggest could be proposed as an addendum to SIP-009 or something similar so contracts can declare such manifests in a standardized way.

[nickgamma]

In the past, inscription number discrepancies have surfaced when one of the indexers does not recognize an inscription altogether (versus others that do). In that case, even the inscription ID would not work in the bugged indexer. ID and number are equivalent in the sense that they both work in indexers that follow the canonical ord indexing logic.

There is a pretty common issue with "off by one" but perhaps it's less of an issue more recently. Just calling it out, but I get that flexibility is nice.

This is a cool idea, but I think it falls outside of the scope for this SIP. This proposal was only intended as a way to provide a general URI standard to reference inscription content.

Totally fair, I had contemplated whether this comment/line of thinking was appropriate given current scope. However, I still personally feel this is an important mention as I think a very common use case for this could be replacing IPFS links with inscription content for NFT metadata. To create a standard that doesn't allow for what I'd expect to be the top use case feels to me like it's missing a core piece of the equation. That said, I could be wrong about the main use cases of this standard.

In any case, if you think doing this in stages is ideal, that's a perfectly reasonable approach too. I'm supportive of this SIP in either case :smile:

[wileyj]

https://github.com/paradigma-cl/unreplaceableDigitalID

@paradigma-cl

[jio-gl]

My 2 cents: 🪙🪙

• it's important to ensure that any implementation or parsing of these URIs correctly validates and sanitizes user input to prevent potential injection attacks.
• it's essential to ensure that the <scope> field in the URI is restricted to the defined values, i or s. Any deviations from these values should be rejected, as they might lead to unintended behavior.
• the <identifier> field should also undergo validation to ensure it adheres to expected formats and length restrictions. Invalid or overly long identifiers could potentially be used to exploit or disrupt services that process these URIs.
• maybe adding section in the specification about how errors or invalid URIs should be handled. This can help prevent unintended behavior or information leakage in cases where URIs are not well-formed.
• minor suggestion: it's good practice to recommend the use of HTTPS when retrieving content from URIs.