Ismail Khoffi

Just to double-check: In your example, the type in the rpc would be different, right (it currently says `2`).

> The better way would be to use protobuf-generated structs "at the end", i.e., convert first-class Go structures to protobuf-generated ones, serialize them, and then sign. That is basically the...

ref: https://github.com/tendermint/go-amino/issues/212

> It looks like develop is what got merged into tendermint, but it has more changes that aren't captured on master or in a release, so we can't actually say...

This is probably related: https://github.com/tendermint/amino_rs/issues/28 https://github.com/tendermint/amino_rs/compare/debugging_issue28 (similar issue about prefix bytes)

@jordansexton I think proto.Any is well supported by now in JS implementations. I have not experimented with it a lot though, at least not in JS. @mossid Thanks! If I...

`oneof` would be even more compact but has the downside that the order of fields (inside the `oneof`) has to be exactly the same for everyone involved. That makes it...

After chatting with @mossid over lunch: he is indeed proposing to use the prefixes as the field number. Some things to consider: > You also cannot use the numbers 19000...

I think using `proto.Any` instead of `oneof` providers users more flexibility & more convenience when they want to add their own types (any two side communicating just need to know...

Speaking in terms of protobuf this means introducing another wrapper type which is very similar to proto.Any. The wrapper would be message like this: ```proto message BytePrefixedAny { bytes amino_prefix...