Remove `anypb.Any` type url prefix "type.googleapis.com"

[amaury1093]

Summary of Bug

IMPORTANT: this is about the official google.golang.org/protobuf Any, not gogo where we already have a custom Any type to do this sort of stuff.

When wrapping a protobuf message inside a protoreflect-based anypb.Any, the type url is prefixed with "type.googleapis.com"

msg := &bankv1beta1.MsgSend{}
any, _ := anypb.New(msg)
fmt.Println(any.TypeUrl)

// Expected: "/cosmos.bank.v1beta1.MsgSend"
// Actual:   "type.googleapis.com/cosmos.bank.v1beta1.MsgSend"

The culprit is this line:

https://github.com/protocolbuffers/protobuf-go/blob/6875c3d7242d1a3db910ce8a504f124cb840c23a/types/known/anypb/any.pb.go#L266

Affected functions and methods are:

• anypb.New
• anypb.MarshalFrom
• anypb.Any#MarshalFrom

Note: anypb's Unmarshal functions are not affected, and work as expected, as our pulsar types register themselves without the prefix.

Version

v0.47+

Proposal

Idea 1: Create our own MarshalFrom function, add docs to not use anypb's ones

This means that we would replicate our own MarshalFrom and New functions inside the SDK (same one as anypb without the prefix), and tell users to not use the 3 functions mentioned above, but our own implementations

Con:

• There's a (pretty high IMO) risk that users won't be aware of this

Idea 2: Create our own Any type

It would be a copy/paste of anypb's Any, except for the typeURL prefix.

Con:

• not using the official version

Idea 3: Embrace "type.googleapis.com"

Start prefixing "type.googleapis.com" in all of our Anys

Cons:

• doesn't look nice, it's long
• migrations are needed

[amaury1093]

Current idea 2 is my preferred choice

[aaronc]

I think we need to clarify that this is about the official google.golang.org/protobuf, not gogo where we already have a custom Any type to do this sort of stuff.

[JimLarson]

@aaronc Should be be using cosmos-sdk/codec/types.NewAnyWithValue() and friends along with Pulsar, or the official protobuf library Any utilities?

[aaronc]

@aaronc Should be be using cosmos-sdk/codec/types.NewAnyWithValue() and friends along with Pulsar, or the official protobuf library Any utilities?

That only works with gogo proto. This issue is about the official protobuf API

[tac0turtle]

Is this a go only item or cross language thing with protobuf

Im a fan of 3, because we should embrace basic protobuf instead of creating more maintenance and mental overhead

[amaury1093]

3 will impact all languages. Take a tx JSON and imagine all the @type fields inside prefixed with "type.googleapis.com". What worries me about 3 is the migration path, both on the SDK and in the client ecosystem.

[aaronc]

I really think 3 is the wrong approach. That prefix isn't required by the spec, it's just a thing done by default in some implementations which unfortunately serves no purpose. And we will need to pay the price in every tx and that will be pretty ugly.

[tac0turtle]

But 3 is the default behavior is it not?

[amaury1093]

There's no default behavior in the Any spec. Some implementations include it (e.g. google). The SDK, when switching to proto in sdk v0.40, made the deliberate design decision to not include prefixes. So the behavior of Cosmos's implementation of Any is no prefix. We should keep this.

[alexanderbez]

So sounds like a decision between 1 and 2. The downside with 2 is that we need to keep up to date with the official implementation, no? Or do we not see that code changing much?

[amaury1093]

Code changes on upstream repo shouldn't be a concern, last meaningful one was 2.5y ago.

If we do 2, there are still some unanswered questions: where do we put our Any type? Inside api? In its own go module? Where do the MarshalFrom/UnmarshalTo functions go?

One idea is a codec/v2 go module, and we put our Any there. codec v2 could also hold the protoreflect-based Amino encoder.

[aaronc]

Code changes on upstream repo shouldn't be a concern, last meaningful one was 2.5y ago.

If we do 2, there are still some unanswered questions: where do we put our Any type? Inside api? In its own go module? Where do the MarshalFrom/UnmarshalTo functions go?

One idea is a codec/v2 go module, and we put our Any there. codec v2 could also hold the protoreflect-based Amino encoder.

We should probably put it in cosmos-proto because it needs to be used by codegen.