Protobuf schema for transit messages

[cammellos]

We decided to move from transit to protobuf.

The main reasons for this are:

• Consistency. We use protobuf already for most of the messages, and transit only for the application layer.
• Better interop with other languages. Protobuf has better support in various languages then transit.
• Security. Protobuf has a set of well maintained libraries, which will avoid having to use less tested/popular libraries, which might not have gone through much scrutiny.

This is the proposed schema, the relevant changes are:

• Flatten Content field in ChatMessage, remove redundant fields
• Make members/member the same field in group chat, allow for raw-bytes signature
• Single ContactRequest message (they are handled identically, so no need to have a separation for now)
• Use enum instead of strings when possible (can be converted to strings on receiver end)

A few things to note:

Upgrades

No versioning is currently provided, if necessary it will be added at later times, any new field will be read as 0 by protobuf, so this is effectively v0. Accretion are done by adding a field to the map (non-breaking). Removing a field is always a breaking change unless the field is optional. No way around that.

Signatures

For those fields that we require a signature of (Message, MembershipUpdate), the strategy is as follow: 1) Set the field as bytes 2) Marshal the field as protobuf separately separately. 3) Sign the field.

This is because we don't want to sign the unmarshalled field, otherwise any schema change will break the signature scheme. Ideally, we would like to specify it like so:

type A {
}
type B {
bytes signature = 1;
A field_a = 2;
}

Decode it in one go, and be able to access the raw bytes of field_a, to get the best of both worlds (single conversion, changing a field won't break signature scheme). Not sure this is possible with protobuf, so unless this is possible, second best solution is to have:

type A {
}
type B {
bytes signature = 1;
bytes field_a = 2;
}

And convert in two steps.

Let me know if there's anything we should add, remove, change etc.

[yenda]

Would adding the following message content-types require changes? https://github.com/status-im/team-core/blob/d8f08de522c10e94f1e9528a9aedb2123b72878f/rfc-001.md#spec-of-the-messages

[cammellos]

@yenda yes, we'd have to add a new content-type, and add the various field to ChatMessage:

chain-id int32 asset string amount bytes or string maybe? and then convert to bigint locally account address of the recipient wallet account transaction-hash string