Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LSP8] Add explanation of hashed tokenId #136

Open
lykhonis opened this issue Nov 3, 2022 · 3 comments
Open

[LSP8] Add explanation of hashed tokenId #136

lykhonis opened this issue Nov 3, 2022 · 3 comments

Comments

@lykhonis
Copy link
Contributor

lykhonis commented Nov 3, 2022

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)

lykhonis added a commit to Universal-Page/contracts that referenced this issue Nov 3, 2022
@frozeman
Copy link
Member

frozeman commented Nov 4, 2022

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
Copy link
Contributor Author

lykhonis commented Nov 4, 2022

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
Copy link
Member

CJ42 commented Dec 7, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants