Adding to_hex/from_hex

[alessandrokonrad]

This reduces a little bit of overhead in Js with the usage of Buffer.

[rooooooooob]

We should figure out #263 before we merge a PR like this.

[rooooooooob]

@alessandrokonrad Which format should we be using here for hex? The raw bytes? or the CBOR bytes? Currently from_bytes() can return one of those depending on which types. Most types are CBOR bytes, but Addresses, crypto keys and hashes are all raw bytes. See: #263

What is your thoughts on this? I proposed having to_raw_bytes() and to_cbor_bytes() but then if we add in hex to this too that's a lot of variants.

[alessandrokonrad]

Which format should we be using here for hex? The raw bytes? or the CBOR bytes?

to_hex/from_hex are simply wrappers around to_bytes/from_bytes. So it returns/takes whatever that is. The macro to_from_bytes is implemented for types that are fully in CBOR I think. I'm not sure how these would look like in raw bytes, for instance Value?

Most types are CBOR bytes, but Addresses, crypto keys and hashes are all raw bytes

I think it makes sense to return them in a format how the cardano ledger would take them, so probably as it is right now. Everything else would be more confusing.
Would to_cbor_bytes simply add a tag in front of the raw bytes, that says something is bytes?

[rooooooooob]

Would to_cbor_bytes simply add a tag in front of the raw bytes, that says something is bytes?

In the cases of the hashes/keys and addresses, yes. They're all defined in the .cddl as address = bytes (usually with size limits) for example. When they're used in the context of the CDDL CBOR encoding (e.g. when composed into the other CBOR structures in that spec) they need to have those extra bytes. This is related to our discussion in cardano-foundation/CIPs#148 which going by how the spec is written would need those bytes, which is something that we might want to change there. Either way it's a bit confusing IMO having these two notions of what a byte representation means and I'm not sure about the best way to go about it, which is why I opened up #263.

I think it makes sense to return them in a format how the cardano ledger would take them, so probably as it is right now

If we stay with this we should at least document it.

[alessandrokonrad]

This is related to our discussion in cardano-foundation/CIPs#148 which going by how the spec is written would need those bytes, which is something that we might want to change there

Yes I would be for a change there. Or we add a simple helper function in either the message signing library or the serialization-lib to add a tag in front of the raw bytes.

[SebastienGllmt]

Just as a historical note, the reason why we didn't add small utility functions like this is because projects like Yoroi Mobile rely on native bindings to the Rust code. We tried to minimize the amount of time spent on native bindings by trying to have a single way to do things in the Rust side

[lisicky]

/check

[vsubhuman]

Pulling this into a local branch so we can work on upgrading it

[vsubhuman]

Thank you, @alessandrokonrad !