Guideline for bytes encoding for JSON input and outuput types (smart contracts)

[robert-zaremba]

I want to start discussion about hash encoding.
For response types, a hash should be encoded as a String. Currently the NFT standard uses base64 for hash encoding.

In the SBT standard, we followed up with that design and also set base64 there.

I'm working on a guideline for metadata, and now I am coming to reflection that base64 is not a good option:

• many standards
• implementation dependent

In various other works where consensus and interoperability is critical we decided to not use base64. In Cosmos, the decision was to stick with hex.

So, I would like to start a discussion to rather use z-base32 or base32 or hex. My personal preference is z-base32.
The problem is when base64 formatted string is returned from a function and expected to interoperate with various other implementations. For consensus base64 is not unique.
It's not a problem for cross-contract calls which operate in the same environment (eg: near wasm), but could be a problem where additional consensus for relayers is required.

I think it's important to quickly analyze this and update if needed, and establish a guideline in NEAR.

Reference: https://en.wikipedia.org/wiki/Base32#Advantages

[frol]

There has been quite an old discussion on nearcore about different encoding schemes: near/nearcore#2100

Personally, I prefer hex as it is commonly used for hash representation, straightforward, URI-friendly, stable in length (always 64 characters for 32 bytes input), and the only downside is the length of the payload (but it is not that bad)