EPIC: Create buf registry for each extracted module

[julienrbrt]

Summary

Create a buf registry for each extracted module and move the proto module protos to their own folder.

Problem Definition

Currently, the modules' proto definition is located under https://github.com/cosmos/cosmos-sdk/tree/main/proto/cosmos.
From our DEV UX interview, this is not intuitive and does not align with the goal of a creating go module for SDK modules (#11899).

Proposal

We must ensure that pushing to the buf registry (https://buf.build/cosmos/cosmos-sdk) gives the same content.
Verify, if is better to have each of the modules have their own buf repo.

• Move each proto definition to their own folder: E.g. proto/cosmos/auth -> x/auth/proto.
• Create buf registry for each extracted module
• Update extraction module documentation
• Update UPGRADING.md of what to add in the buf.yaml of consumers (as buf.build/cosmos/cosmos-sdk won't contain the extracted modules).

[alexanderbez]

I love this idea!

[aaronc]

There's another thread where this got discussed but I think there needs to be a 1:1 correspondence between go modules and buf modules for versioning purposes. For each module we should (I think) only be pushing production proto files. The current state of buf is not right and contains a lot of unreleased stuff.

[julienrbrt]

There's another thread where this got discussed but I think there needs to be a 1:1 correspondence between go modules and buf modules for versioning purposes. For each module we should (I think) only be pushing production proto files. The current state of buf is not right and contains a lot of unreleased stuff.

Right, although, we could have a table too, like we are starting to do: https://github.com/cosmos/cosmos-sdk/tree/main/third_party/proto

[itsdevbear]

@julienrbrt @calbera is working on a version for berachain, will share with you and Marko once we get it working and clean.

[kocubinski]

Intuitive or not, a single API module instead of each logical SDK module containing 2 go modules (API and Implementation) seems easier to reason and maintain to me. See this comment in the ADR 054 discussion for why I came to that conclusion.

When we're closer to shipping SOA over an ABI (see #15410) I think it will make sense to make the changes described in this issue, but it seems a little early to me right now.

[julienrbrt]

Duplicated of #19503