CIP-0068 | Small change in 333 FT sub standard

[alessandrokonrad]

decimals in metadata don't need to be big_int, but can be int also. @KtorZ pointed that out before for theversion field, but I have overseen it for decimals.
I also realized it makes little sense to follow the same constraints of the cardano-token-registry for logo, which only allows you to use PNGs as bytestrings. Here the image is in the datum and potentially in an inline datum. Having only the option to store the image as bytestring on-chain wouldn't be ideal. A URI is much better suited here, which gives more flexibility and allows you to use also other image types e.g. .jpg
@rphair

[KtorZ]

neat-picking: why specifically png ? I assume the intent is to forbid inline image data payload, regardless of their mime type.

[alessandrokonrad]

I expressed that wrong maybe, will rework that. In the cardano-token-registry you have to specify a PNG bytestring.
It's not even a valid URI. logo here (in the 333 standard) of course allows you to use a PNG, but not as bytestring, it needs to be a valid data uri if you want to inline it: data:image/png;....
I just wanted to be explicit here and say that using logo like in the token-registry is wrong and it cannot be used like that here.

[KtorZ]

Might be worth defining an alias uri with a comment?

metadata = 
    { 
        ...
        ? logo: uri, 
        ...
    }

; A URI as a UTF-8 encoded bytestring.
; The URI scheme must be one of `https`, `ipfs` or `data`
; Do note encode plain file payloads as URI.  
uri = 
    bounded_bytes 

Also, side question: what for URIs that are longer than 64 bytes?

[alessandrokonrad]

Also, side question: what for URIs that are longer than 64 bytes?

I'm a bit confused about this one because in the serialization-lib there is this function to serialize bounded_bytes:

pub(crate) fn write_bounded_bytes<'se, W: Write>(
    serializer: &'se mut Serializer<W>,
    bytes: &[u8],
) -> cbor_event::Result<&'se mut Serializer<W>> {
    if bytes.len() <= BOUNDED_BYTES_CHUNK_SIZE {
        serializer.write_bytes(bytes)
    } else {
        // to get around not having access from outside the library we just write the raw CBOR indefinite byte string code here
        serializer.write_raw_bytes(&[0x5f])?;
        for chunk in bytes.chunks(BOUNDED_BYTES_CHUNK_SIZE) {
            serializer.write_bytes(chunk)?;
        }
        serializer.write_special(CBORSpecial::Break)
    }
}

Whenever my bytestring is longer than 64 bytes it is automatically split into 64 bytes chunks in an array. I assume this works, because plutus_data in the CDDL can be turned into an array [ *plutus_data ]? But a BuiltinByteString in PlutusCore will still be represented as single long string right?

I was under the impression this is somehow a standardised thing for bounded_bytes, but maybe it's only how the serialization-lib is handling it. Then we should be explicit about it and turn the type into: bounded_bytes / [ *bounded_bytes ].

[KtorZ]

That's indeed the behavior of the ledger / plutus regarding long indefinite bytestring. I was hoping to find a definition of bounded_bytes in the ledger's CDDL but there's none (nor there's any in the RFC describing CDDL...). So I guess It's fine to leave as such 🤷

[alessandrokonrad]

Ah damn it, now I changed it😅. Do you want me to revert it or leave it like that bounded_bytes / [ * bounded_bytes ]?

[KtorZ]

I'd say: we should provide a non ambiguous definition of bounded bytes somewhere, this CIP is likely not the right place. So maybe a PR to cardano-ledger to add a definition that somewhat reflects how implementations treat it.

[alessandrokonrad]

Sounds good. Then I'm gonna revert my change. I could temporarily add a comment here to bounded_bytes until it's part of the cardano-ledger.

[alessandrokonrad]

@KtorZ I found this in the CDDLs: https://github.com/input-output-hk/cardano-ledger/blob/8a8daef6d88b4f7b6f4ca7dafb0d5bde54617d8f/eras/babbage/test-suite/cddl-files/mock/extras.cddl#L36-L45

bounded_bytes is already described as we thought it behaves.

I'm going to revert my changes. I think the PR should be good then.

[rphair]

Thanks @alessandrokonrad for tagging me in the OP but the best I can do with this discussion (which is beyond my expertise) is to follow the outcome of your dialogue with @KtorZ - as well as @SebastienGllmt if he wants to jump in 🤓

[alessandrokonrad]

Thanks @alessandrokonrad for tagging me in the OP but the best I can do with this discussion (which is beyond my expertise) is to follow the outcome of your dialogue with @KtorZ - as well as @SebastienGllmt if he wants to jump in 🤓

I think it's looking good now. @KtorZ corrected me already :)

[rphair]

as far as I can tell, last remaining issue has been resolved by 452dca2.