Global token ID

[the-frey]

Thinking longer term and for some of the stuff under #29 we need a URI like way of globally referencing a token ID.

Something like:

chain-id::contract-code::token-name

e.g.

juno-1::1::the-frey

Should it be code? Contract address? i.e. chain-id::contract-addr::token-id What else is available as meta at runtime?

[the-frey]

recent commentary on https://github.com/cosmos/ibc/pull/615 needs reading and parsing when less tired && moar coffee

[the-frey]

Gut feel is the ICS is so geared towards IBC it misses our use case which is the same token ID, on the same chain, from different instances of the same contract.

Welcome any thoughts on this @elsehow - don't want to show any prefix to users but seems like it might be worth writing it to storage and stripping it on read. Maybe exposing via a QueryRaw or similar where you can get non human friendly info. Or return it as a separate meta field.

However, separate fields or relying on the contract meta is less portable than having it all in the ID, as that makes it:

• referenceable
• deref'able

[the-frey]

[the-frey]

I think this probably is an implementation detail though that shouldn't generally be exposed to users, hence the QueryRaw question above

[the-frey]

So, thinking about it contract-code doesn't make sense, as you can instantiate multiple contracts off it. Only contract-addr is guaranteed to be unique (for the purposes of constructing a prefix that is addressable)

[the-frey]

[the-frey]

other thought: the token_id doesn't need to be unique because sending to another variant of this contract, you can't have duplicates, so actually a single dumb string, so long as it is validated #39 is acceptable.

HOWEVER you do still need the meta/global id for provenance. So clearly at mint time the NFT should have an extra field with this. the question is, should it be a straight uuid, or is a compound identifier that contains its own meta acceptable?

I think my preference is probably for chain-id::contract-addr::token-id as it preserves a lot of important info (even if long)

[the-frey]

Okay, so current working plan:

• ~compound key with embedded metadata in the NFT meta (or at root level?)~
• token id doesn't have to be unique except at contract-level, so it solves sending to another contract where that ID already exists
• extra query handlers I guess needed to specifically look up a name via this. Although, actually since on-chain it will always be referenced via contract, isn't it redudant to have the contract address?
• So actually in chain-id::contract-addr::token-id - the contract-addr part isn't useful until the NFT is transferred. AND when it is transferred, you can just mint the same again on the original contract. HMM

Actually, if this was on its own chain, you could reduce the problem back to an id that was unique at contract level.

[the-frey]

So the addressability issue is actually pushed to HTTP in web2 - because who cares if somebody mints the same name, if they can't route to it?

Which means that at contract level, you're back to network effects I guess. And/or "web of trust" to actually make the service useful.

[the-frey]

It feels like there is a missing primitive here. Or maybe that this is the primitive, but it is still too rudimentary.

[the-frey]

as a wise cat once said to me "this is probably solved by interchain accounts"