[LSP8] Add explanation of hashed tokenId

[lykhonis]

Overview

LSP8 requires to set an explanation of what tokenId content means. The explanation is currently documented to be an integer of key LSP8TokenIdType:

• 1: address another contract
• 2: uint256 a number, which may be an incrementing count where each minted token is assigned the next number
• 3: bytes32 a hashed value (ie. serial number)

Problem

In a case of 3 when tokenId represents a hashed value, dapps and other contracts may need to be able to retrieve actual value (prior to it's been hashed).

Improvement Proposal

LSP8TokenIdHashFunction

Explains a hashing function applied to generate a tokenId.

{
    "name": "LSP8TokenIdHashFunction",
    "key": "0x200d7fc10771371795cceb6ad6d33d5959c47250486fb93f77f0c20088b90a97",
    "keyType": "Singleton",
    "valueType": "string",
    "valueContent": "String"
}

possible values:

• keccak256(bytes)

LSP8TokenIdValue:TokenId

Contains a value that's hashed to generate a tokenId.

{
    "name": "LSP8TokenIdValue:<bytes32>",
    "key": "0x60fcfd25909da10abc320000<bytes32>",
    "keyType": "Singleton",
    "valueType": "bytes",
    "valueContent": "Bytes"
}

If value is a string, it must be encoded in utf8 and read as Web3.utils.hexToUtf8(hexValue)

[frozeman]

But token if can be anything. From
A hash. A short utf8 encoded string. A number or a bit mask.
I think naming 3 a hashed value is a mistake, it was never meant to be just a hash.

maybe we should introduce more token types, rather than adding a second key (which would make it more expensive to deploy)

[lykhonis]

I would give an example. For Universal Page we require a user provided name to track pages. Each name is then hashed keccak256. The hash becomes a token id. This works great, because we do not have a min nor maximum requirements for possible names (more than 32 bytes). Token type id 3 makes sense in this case. Only problem is that we cannot recover a page name from a hash, but we can generate token id from a name.

I still think this type 3 makes sense though. It adds additional flexibility on token ids, but needs few more details to recover the value.

For example, ENS does similar thing: ETHRegistrarController.sol

[CJ42]

I think it's rather the description in the LSP8 standard that is misleanding.

1: address = the tokenId that is minted is represented as its own ERC725Y contract.
2: uint256 = the tokenId that is minted is represented as a number, which may be incremented every time a new token is minted.
3: bytes32 = a unique identifier. Depending on the implementation or use case, this unique identifier can represent":
- a serial number.
- a short utf8 encoded string.
- a hash digest.

The hash digest can be the hash of anything really. In your case @lykhonis , it's the hash of user provided name.

LSP8TokenIdHashFunction

Explains a hashing function applied to generate a tokenId.

{
    "name": "LSP8TokenIdHashFunction",
    "key": "0x200d7fc10771371795cceb6ad6d33d5959c47250486fb93f77f0c20088b90a97",
    "keyType": "Singleton",
    "valueType": "string",
    "valueContent": "String"
}

possible values:

keccak256(bytes)

Adding a new metadata key does not make sense to me in this case, because this standard data key only applies if tokenId type is 3. We should not create standard metadata keys if they exist only in a specific scenarios, but rather if they apply to any scenarios, no matter implementation details.

Otherwise, we would end up creating many metadata keys each for specific scenarios and it would not be standard anymore.

I think this information can simply be added either:

• in the custom description of the JSON metadata (relevant to the implementation contract)
• in a custom ERC725Y data key (relevant to the implementation contract).