Extend AssetDetails data type

[euonymos]

No description provided.

[sorki]

LGTM!

[euonymos]

Thank you @sorki! I will add more changes since we need extra fields from CIP25. It's not obvious how to implement it to preserve backward compatibility, so for now, I added a Value to keep everything and an additional parser to read "standard" fields. Writing a manual instance is an alternative. Please let me know if you have any ideas about improving it.

[sorki]

Your solution is actually neat as writing a custom instance would add a lot of boilerplate and the additional parsing step is not visible to user / API anyway.

[sorki]

Ready? 😸

[euonymos]

@sorki probably it is. We decided to change the way we encode metadata -- basically move most parts into the first cip68 argument. Now we see the following in the responses:

"onchain_metadata": {
    "GameY": "a449416c69676e6d656e74474e65757472616c46736368656d614d47616d65595f4578616d706c654d736368656d6156657273696f6e014776657273696f6e01",
    "description": "Description goes here",
    "games": "9f4547616d65584547616d6559ff",
    "image": "9f5840697066733a2f2f516d5439387267536b50376f766b76645857424568466e506d6258424364326d58674d334b687350334b574559792f746f6b656e3734323635442e6a7067ff",
    "mediaType": "image/jpg",
    "name": "000643b052464c58545f545354233036",
    "powered by": "4572666c7874"
},

So not all parts of metadata are decoded - some are still CBOR-encoded. While it might be not ideal for those who cannot/don't want to work with CBOR it's not a problem for us, but I cannot get the pattern here. I would say only short strings are decoded - but not, the last field powered by seems to me structurally identical to mediaType. So we guess only some known fields and decoded. Not sure we really want to upstream the corresponding changes though. Looks like a good set of defaults.

[sorki]

@sorki probably it is. We decided to change the way we encode metadata -- basically move most parts into the first cip68 argument. Now we see the following in the responses:

Cool, this seems to be flexible enough to include additional fields.

So not all parts of metadata are decoded - some are still CBOR-encoded. While it might be not ideal for those who cannot/don't want to work with CBOR it's not a problem for us, but I cannot get the pattern here. I would say only short strings are decoded - but not, the last field powered by seems to me structurally identical to mediaType. So we guess only some known fields and decoded. Not sure we really want to upstream the corresponding changes though. Looks like a good set of defaults.

+1, I think that decoding the rest is out of scope and IIRC it can only be done for some fields that decode to ascii/text but the fields can contain arbitrary data so we would need to try/guess which might lead to wrong results. It is done in similar fashion in our API, decode the known ones and keep the rest as CBORs so you are right about the handling.

[sorki]

I'll merge this, add a changelog and release it in the next round soonish.

[sorki]

Thank you!

[sorki]

Released in api-0.9 & client-0.8