That's great. Erlang has gen_statem as a built-in behavior so it seems appropriate to use it. Also Joe Armstrong had been talking about protocols for the longest time. He would say something like "Tell me what's on the wire! Don't give me some C++ API".
edit - I guess true interoperability? agency?
and as a matter of definition, yes, protobufs are just bit strings and a schema definition in a limited type language (just like xdr and asn before it).
but again, as a matter of usage, we're only really supposed to use them to map to and from structs.
and its not as if this doesn't work, clearly it does. as someone who used to do protocol implementation before all this, I find unsettling. and I don't know if I'm just being predudicial, or if we we are somehow losing something by adopting this model as essentially mandatory.
I do find it frustrating, that when I do want certain binary properties, or I want to encode a cyclic structure in a particular way, or use a richer schema. that I have to fight upstream to not use protobufs even if they don't bring anything except a useless wrapper around a byte string I am defining anyways.
Isn't protobuf just one such protocol definition. With a focus on being general.
If you don't like the trade-offs it makes then you can use your own specific protocol with your own tradeoffs.
But yes people will push back on you if you can't justify why that decision is better than the general solution especially if they have to use it.
Imo starting with an out of the box solution as a baseline and then moving to a more specialized solution when the need arises is pretty solid decision.
If you are low-level C shop that may make sense. But if you are trying to build some rpc service for usage between multiple teams and languages. Using protobufs or something similar is gonna give you more mileage.