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

Update 0064-token-data-standard.md #96

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 21 additions & 3 deletions text/0064-token-data-standard.md
Original file line number Diff line number Diff line change
Expand Up @@ -102,13 +102,30 @@ Data that does not fit in one cell can be stored in two ways:

Data that fits into one cell is stored in "Snake format".

If the prefix is not `0x00` or `0x01`, then the data is probably encoded by the TL-B schema (relating to a specific smart contract), for example, like in the [DNS contract](https://github.com/ton-blockchain/TEPs/blob/master/text/0081-dns-standard.md#dns-records).
If you need to save an array to content, then you need to use the format for array:

1. Array format allows you to store an array in content, this can be used when you need to store a list of attributes for a token. Array must be parsed as an array. Dictionary key is the index of the element. The keys must be numbered in order from 0 to (2^32) - 1.
Must be prefixed with 0x02 byte. TL-B scheme:
```
array_data#_ data:(HashMapE 32 ^ContentData) = ContentData;
```

If you need to save a dict to content, then you need to use the format for dict:

1. Dict format allows you to store an object in content, this can be used when you need to store attributes for a token. Dict must be parsed as an object. Must be prefixed with 0x03 byte. TL-B scheme:
```
dict_data#_ data:(HashMapE 256 ^ContentData) = ContentData;
```

If the prefix is not `0x00`, `0x01`, `0x02` and `0x03` then the data is probably encoded by the TL-B schema (relating to a specific smart contract), for example, like in the [DNS contract](https://github.com/ton-blockchain/TEPs/blob/master/text/0081-dns-standard.md#dns-records).

## Informal TL-B scheme:
```
text#_ {n:#} data:(SnakeData ~n) = Text;
snake#00 data:(SnakeData ~n) = ContentData;
chunks#01 data:ChunkedData = ContentData;
array#02 data:(HashMapE 32 ^ContentData) = ContentData
dict#03 data:(HashMapE 256 ^ContentData) = ContentData;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I oppose the introduction of dict (or hashmap) type without listing some expected value: it leaves developer without understanding what to implement. However, since dict can be presented in any place of ContentData tree it is probably hard to make list of keys.
What about PfxHashmapE?

onchain#00 data:(HashMapE 256 ^ContentData) = FullContent;
offchain#01 uri:Text = FullContent;
```
Expand All @@ -121,6 +138,7 @@ Note, that while TL-B scheme does not constrain bit size of each chunk it is exp
3. `description` - Optional. UTF8 string. Describes the asset.
4. `image` - Optional. ASCII string. A URI pointing to a resource with mime type image.
5. `image_data` - Optional. Either binary representation of the image for onchain layout or base64 for offchain layout.
6. `attributes` - Optional. A representation of a list of attributes: [{"trait_type"H:"trait_type", "value"H: "value"}]. List of attributes must be save to array format with prefix 0x02. Each element must be save to dict format with prefix 0x03: each attribute contains the keys "trait_type"H and "value"H. Key is sha256 hash of string. Values must be stored by Snake format and Chunked format, but the default is Snake format.

## Jetton metadata attributes
1. `uri` - Optional. Used by "Semi-chain content layout". ASCII string. A URI pointing to JSON document with metadata.
Expand Down Expand Up @@ -151,7 +169,7 @@ While on-chain data storage is preferred, off-chain/semi-chain options allow fle

1. Shall we authenticate offchain data to prevent it from changing? ([NoelJacob](https://github.com/ton-blockchain/TIPs/issues/64#issuecomment-1029900008))
2. Shall we support semichain layout, where only some metadata fields may be stored onchain? ([tvorogme](https://github.com/ton-blockchain/TIPs/issues/64#issuecomment-1028622110))
3. Shall we standardize attributes, traits, and non-image content? ([tolya-yanot](https://github.com/ton-blockchain/TIPs/issues/64#issuecomment-1041919338))
3. Shall we standardize non-image content? ([tolya-yanot](https://github.com/ton-blockchain/TIPs/issues/64#issuecomment-1041919338))

# Future possibilities

Expand All @@ -161,4 +179,4 @@ None

* 14 May 2022 - the standard is now used not only for NFT, but for all tokens in the TON. Added section "Jetton metadata attributes".

* 31 Aug 2022 - added note about data encoded in TL-B schema in "Data serialization" paragraph.
* 31 Aug 2022 - added note about data encoded in TL-B schema in "Data serialization" paragraph.