Unified NFT naming for blockchain based Metaverses

readme.md

!! Migrated to https://github.com/common-metaverse/urn-namespaces !!

---

A common way to refer to assets across the metaverse projects

Identifying a blockchain asset is difficult. Wallets, exchanges, tools and other pieces of software need to know the specifics about how to interact with the project's infrastructure to get images or to render content. This proposal shows a temptative solution to the content addressing mechanisms to embed our crypto-art, assets, wearables and avatars into metaverse(s).

URN

A Uniform Resource Name (URNs) are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable.

The proposal

1. Agree on a URN schema to identify any assets. URN are composed of three main elements: Header (urn:), A namespace, and an NSS (namespace-specific string) forming a string in the shape urn:{namespace}:{nss}.

   The proposal only enforces that the namespace is part of a well-known list of namespaces with mappings to APIs or docummentation on how to resolve the NSS part of the asset.

   For Decentraland, we are evaluating the format urn:decentraland:{chain-identifier}:{contract}:{tokenid} which will fulfill all of our current use cases.

   In any case, after the NSS string, a query string component is a valid part of any URN, making extensions not only possible but very easy to parse and implement. Some examples of our implementation could be:

   urn:decentraland:matic:0x000000000123123:0x332
   urn:thesandbox:ethereum:LAND:0x1010
   urn:cryptovoxels:ethereum:COLR:0x1
   urn:decentraland:ethereum:LAND:0x1010?atBlock=1231411231
   urn:decentraland:matic:quests:1

   Sumarizing

   • Identify assets using urn:{metaverse-namespace}:{custom-string}.
   • {custom-string} is a namespace-specific string, hierarchically separating the parts of the custom-string with colon : is recommended and friendlyer than / for URL encoding (urn:decentraland:ethereum:LAND:0x1 instead of urn:decentraland:ethereum/LAND/0x1).

2. Create a Github organization to track the ownership of the urn:namespaces (pull requests) and potentially point to the documentation on how to resolve the assets based on specific URNs

Benefit

• Wallets and service providers like exchanges could start indexing assets unequivocally using a common ID.
• By documenting namespaces and its content resolution, tool developers would have a lower entry barrier fostering innovation of the ecosystem and the rise of the metaverse.
• Take an initial step to portability and interoperability of assets across the metaverse.
• URN are designed to last forever. Completely decoupled from URL and servers.

Does this apply to all of ERC-721, ERC-1155, ERC-20 formats? Currently, token standards will define the depth to which a token is defined -- in the case of the ERC-20, there is no identifier within the contract, the contract represents the token and maintains ownership. However, in the case of ERC-721 and ERC-1155, you could have contract + tokenId as defined above. I'm unsure if there are further levels of depth or alternative definitions yet.

Also, a somewhat related note, in reference to the ERC-1155 standard, there is an expectation of the token's ID within a generalized URI, which may impact how the URN routes to a generalized URI for an ERC-1155 token. Notably, in the ERC-1155 Metadata URI standard, the token ID is left-padded with 0s and 0x stripped from the front (which I'm not confident is a good practice, but this was the decision taken during the 1155 standard development, and wanted to share) -- https://eips.ethereum.org/EIPS/eip-1155#metadata

TL;DR: every ERC-721 and potentially most of ERC-1155 (following the EIP) could be addressed using this mechanism.

The idea behind this proposal is to formalize some namespaces for the URN and to define for each one of them: a content resolution mechanism.

As an example, to handle every LAND (ERC-721) we would specify a list of routing mechanisms, like web server routes:

• Every urn:decentraland:ethereum:LAND:{tokenId} will resolve to https://api.decentraland.org/land/{tokenId}.json
• Every urn:thesandbox:ethereum:LAND:{tokenId} will resolve to https://api.sandbox.game/land/{tokenId}.json
• Every urn:thesandbox:ropsten:LAND:{tokenId} will resolve to https://staging-api.decentraland.org/land/{tokenId}.json

And it will be open to extensions, for instance. We (at decentraland) are thinking about including the default wearables (not blockchain) as part of this schema. That is so, to use the same URN for the initial setup of the avatars without hacks, and the backpack will have a clean implementation with only URNs.

• i.e. every urn:decentraland:basic-wearables:{collection}:{assetId} will resolve to https://wearables-api.decentraland.org/{collection}/{assetId}.json

How strict would the rules be for {metaverse-namespace}?

I'd suggest adding examples that aren't clearly from single, large metaverses but more suitable to much more fragmented use cases, such as blizzard:wow:ethereum through to non game use cases such as artists and music, with publishers, artist, album potentially, and IoT use.

We're onboard with this for Webaverse, it seems flexible enough for addressing the Street.

How strict would the rules be for {metaverse-namespace}?
I'd suggest adding examples that aren't clearly from single, large metaverses but more suitable to much more fragmented use cases, such as blizzard:wow:ethereum through to non game use cases such as artists and music, with publishers, artist, album potentially, and IoT use.

I can't think of a consensus algorithm to assign namespaces other than pull requests. That would allow "blizzard" namespace to be registered via pull request. How they resolve the namespace-specific string is up to the documentation of the namespace. Another option that comes to my mind is to verifying ownership of top level domains (or delegating this via github org name + verified domain) and community based signaling in PRs.

Hey all, did not yet look into the details but there is already existing work on that front. see : https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md

It would probably be a good idea to collaborate. CAIP-19 seems to have been merged already and it might be sufficient for what you had in mind.

but there are things that could be improved, this could be yet another CAIP.