Is tokenId + issuer id a good approach in terms of usability?

[PaulBernier]

(copy pasted from Discord discussion)
I was thinking about tokenId, the one used in conjunction with issuer to create a chain. Initially tokenId was meant to be a global identifier, like a DNS, for a human to find a token. But we changed that to avoid squatting problem, and I'm wondering what does tokenId mean now. It is no longer a string that allows you to query for data easily, as you need to add the issuer chain, which is not really human friendly. Having token id + issuer id as global identifier requires for a user to pass 2 arguments, which is also annoying in term of UX. The chainId is the global identifier of a token in the end... If tokenId is for display, we also have a "name" attribute in the issuance that also serves that role... so in the end I'm not sure this tokenId brings any benefit to the table and more drawback. And related to that, the fact that you have to create first an entry with tokenId + issuer, and then only make an issuance, forcing you to wait up to 10 minutes to have a functional token is not cool from UX point of view.

My idea would be to just remove the chainId derivation based on tokenId + issuer, have a chain that starts with a first entry that is the issuance. And the chainId becomes the globally addressable tokenId, and the human readable name is the "name" field in issuance.

Let me know what you think and if I'm missing something

[drkatz]

I do think we can improve the UX here abit, but I'm personally not terribly worried about the UX of adding tokens affecting the outcome of the project, since there will eventually, hopefully soon, be a slew of very rich, user friendly links to and between FAT token resources in-wallet and online. For example, an implementation of a FATIP-102 token index in the wallet to obtain a database of available tokens would allow a simple search mechanism to be built, obviating the need to manually add the most popular tokens. As a mainstream example in a popular project, to send/receive Ethereum tokens I don't think it's required to know or input the contract address, instead good UI does the job. Power law distribution of popularity of ERC tokens makes it an issue that fades with time.

In term of the UX improvement the proposed solution is a middle ground with some consequences. It reduces the slug that needs to be shared to 64 characters by removing the additional token ID slug(was 65+ characters). As a consequence it changes the chain/entry scheme & validation we've worked out thus far for tokens.

Correct me if I'm wrong but Factom supports creating a chain and placing multiple entries on the chain during or immediately following creation, right? During identity creation many entries are placed on the new identity chain chain at once with only a 10 minute or less wait required. Regardless, to access the chain's data by chain ID(slug) it's still required to wait up to 10 minutes until the current block is completed. I'm not sure there's a way around that using DBlockConfirmed data.

My other slight concern (and definitely nitpicking) is that it moves the specification of the issuer's chain ID lower in the hierarchy from the chain ID derivation itself to the content/extids of the entry. It's cool to be able to "unwrap" issuance entries by already knowing the keys to validate issuer signatures against before looking at the entry content.

[PaulBernier]

I think I emphasized too much my concern about UX here. My real question is: what the purpose of a human readable tokenId when 1. It will almost never be written by a human (and we'll have to resort to UI tricks for that as you mentioned) 2. Never really read either because we have a displayName that is for purpose of UI. (having 2 human readable identifiers is at best unnecessary at worst confusing)

From FAT-0 spec:

A human readable string unique to the Issuer's Identity Chain ID. This ID and the Issuer's Identity Chain ID are the only pieces of data needed to retrieve the token's data from Factom. It should be something short and memorable related to your token. 

The short and memorable part doesn't make sense to me for the reasons above. I think this line of thought is just the remains of the days when there was no issuer id.

So ignoring my UX concerns, what purpose does a human readable tokenId serve?

[AdamSLevy]

I agree with the short and memorable bit being a bit useless given that you need to have the identity Chain ID.

Personally though I don't have much of a problem with the structure as is. I think it does allow easy lookup for chains if you do in fact know both the token id and the issuer. If the issuer is a given, perhaps because you are running an enterprise token just for your internal business, then you can easily lookup the chain for the various assets you have tokens for. Or if the issuer is a given because you are interested in token from this issuing authority, then it again becomes an easy derivation path for the chain id.

In the case where neither of these things is a given, then you might as well just be handed the chain id, and the derivation is mostly useless to you. However, even though the issuing identity chain id is equally arbitrary, if it becomes well know, an identity chain id becomes easier to verify than the chain id of a newly issued token. One quick way to know that you are using the token issued by the correct identity is to derive the chain id yourself and see if there is a token issued there.

[drkatz]

The short and memorable part doesn't make sense to me for the reasons above. I think this line of thought is just the remains of the days when there was no issuer id.

Agreed, I don't know that these guidelines are important for the reasons I mentioned. However I believe the current system works for our intended purposes and has some added benefits, while accomplishing what you've stated. In FATIP-0+100's current state, issuer identity chain ID + token ID chain ID derivation serves as:

• A way to make a virtual "directory" for tokens unique to each issuer & tie tokens to an issuer explicitly
• A way to add vital data needed for validation to the top level of the token scope
• A way to support verification in the case of just sharing the token chain ID(as per the previous bullet)

The current way of doing chain ID derivation supports just dropping the need for mentioning the token ID and issuer identity chain ID, and just using the resulting chain ID as the "globally addressable tokenId" as you called it. I believe @AdamSLevy has mentioned on discord, somewhere around here, or I saw in code about fatd allowing adding token's by chain ID.

The current structure allows me to verify all of the token's data against the issuer (without verifying who the issuer is necessarily). If I'd like, I can then use the issuer's identity chain ID from External IDs of the first entry in the token's chain to research and verify the issuer. In the solution you mentioned, I believe there would be no way to know which issuer truly own's the chain besides just being the first entry, right?

[PaulBernier]

Ok I think after this discussion I refined my thinking and my pain point is purely semantic, in my mind the chain id of the token is the token id in the sense that it's 1 string, uniquely global that allows me to query for all the necessary data of a token. But there is this tokenId field which took the name and even though that is only a token id within a "directory". Also "chain id of the token" is not really a proper name, in part because it exposes the underlying implementation of FAT.

To clarify, I'm not proposing anymore the changes from my initial post. But what about having a slightly better naming that could be used by both for end users and developers alike and avoid some confusion: for instance "chain id of the token" could be referenced as the Global Token Id (GTI) and the other one as Local Token Id (LTI) or maybe Issuer Token Id (ITI)?

[drkatz]

@PaulBernier Absolutely, I think the naming & terminology can be improved here to aid understanding

As a related side note there has been talk about creating a meta/info FATIP that is a glossary so we can standardize the way we talk about these topics. I think it could be very useful in cases like this 😄