Embedding candid type in candid

Developers Language Support
1

Typically, when you to_candid something it doesn’t embed the key names for records or variants in the candid. Is there anything in the specification that would allow you to put that in the candid so that it were more self-descriptive? Perhaps if we were not interested in the storage being small? Maybe even just embedding the did?

I guess we could define a new object that might have a __candid key that we knew the key hash for? But maybe there is something more native to the spec? @chenyan

{
  __candid_object: XXXX
  __candid_spec: text; // the did file contents
}

Use case: we’re trying to convert candid to ICRC3 style Value and object key names are going to get lost if the parser doesn’t know the did file.

1 Like
2

Not possible with the current spec. We may extend the spec to take an optional hash → name mapping to help the decoder.

Let me understand the problem a bit more. So we are talking about serializing a Motoko value to ICRC3 Value? Maybe you don’t have to go through Candid for the conversion?

3

We are trying to define a set of standards for the ICRC3 Value type to inject external data into the object in instances where the data may be too big for a single block/response from icrc7_token_metadata. (or possibly in an ICRC3 log).

We’ve been targeting the ability to pull in a JSON file and have it translated as most NFTs out there use some kind of json for metadata, but most of the IC native pathways I’ve used have started as a form of candid(ICRC16) metadata. The current pathway from ICRC16 ->JSON → ICRC3Value is pretty ugly. I was hoping I could just have an endpoint serve it up as candid, but then I realized I’m going to lose my keys and variants.

See Reserved For Large Metadata Handling in Transaction Logs · Issue #61 · dfinity/ICRC · GitHub and Reserved For Large Metadata Handling in Transaction Logs · Issue #61 · dfinity/ICRC · GitHub

4

What if the endpoint emits both the serialized blob and a text of the did file, so that the parser can use the did file to recover the field names? Although the parser has to live on the agent side, as Motoko cannot parse the did file at runtime.

I haven’t thought too much about the serialization part of ICRC3 Value. But it should be possible to deserialize a ICRC3 Value into a concrete record type. For example, from Value to record { key_1: int; key_2: vec nat }, and get a runtime error if Value doesn’t conform to the concrete record type.