chore: test serde stability in types

[boxdot]

Structures that are marked with WARNING are tested for stability when serialized to JSON and CBOR formats.

[boxdot]

Looks like we have now this in our format. Removing it breaks both JSON and CBOR.

[kkohbrok]

Looks good! This would also be great to do for protocol messages s.t. we know when we need to push a new protocol version.

[boxdot]

Looks good! This would also be great to do for protocol messages s.t. we know when we need to push a new protocol version.

The question whether we want to switch to protobuf there. In that case, this would be lost effort. For types stored in the database though this is important.

[kkohbrok]

Thanks!

[boxdot]

Converted to draft because I want to cover all types that implement serde in types.

[boxdot]

Looks good! This would also be great to do for protocol messages s.t. we know when we need to push a new protocol version.

The question whether we want to switch to protobuf there. In that case, this would be lost effort. For types stored in the database though this is important.

We decided not to switch to protobuf. So, this concern is obsolete now.

[joshsmith]

Looks good! This would also be great to do for protocol messages s.t. we know when we need to push a new protocol version.

The question whether we want to switch to protobuf there. In that case, this would be lost effort. For types stored in the database though this is important.

We decided not to switch to protobuf. So, this concern is obsolete now.

@boxdot Do you mind if I ask why you decided not to switch to protobuf there?

[boxdot]

@boxdot Do you mind if I ask why you decided not to switch to protobuf there?

The main reason is that many types originate from the OpenMLS implementation and are serialized using the TLS codec. So, if we were to use Protobuf, it would essentially be a thin wrapper containing binary blobs of MLS types. Mixing TLS encoding (TLS codec) with Protobuf in this way feels odd.