package cosmos.app.v1alpha1

Get desktop application:
View/edit binary Protocol Buffers messages

Query is the app module query service.

• rpc Config (QueryConfigRequest, QueryConfigResponse)

  query.proto:11

  Config returns the current app config.

  message QueryConfigRequest

  query.proto:15

  QueryConfigRequest is the Query/Config request type.

  (message has no fields)

  message QueryConfigResponse

  query.proto:18

  QueryConfigRequest is the Query/Config response type.

  • optional Config config = 1

    config is the current app config.

Config represents the configuration for a Cosmos SDK ABCI app. It is intended that all state machine logic including the version of baseapp and tx handlers (and possibly even Tendermint) that an app needs can be described in a config object. For compatibility, the framework should allow a mixture of declarative and imperative app wiring, however, apps that strive for the maximum ease of maintainability should be able to describe their state machine with a config object alone.

Used in: QueryConfigResponse

• repeated ModuleConfig modules = 1

  modules are the module configurations for the app.

• repeated GolangBinding golang_bindings = 2

  golang_bindings specifies explicit interface to implementation type bindings which depinject uses to resolve interface inputs to provider functions. The scope of this field's configuration is global (not module specific).

GolangBinding is an explicit interface type to implementing type binding for dependency injection.

Used in: Config, ModuleConfig

• string interface_type = 1

  interface_type is the interface type which will be bound to a specific implementation type

• string implementation = 2

  implementation is the implementing type which will be supplied when an input of type interface is requested

MigrateFromInfo is information on a module version that a newer module can migrate from.

Used in: ModuleDescriptor

• string module = 1

  module is the fully-qualified protobuf name of the module config object for the previous module version, ex: "cosmos.group.module.v1.Module".

ModuleConfig is a module configuration for an app.

Used in: Config

• string name = 1

  name is the unique name of the module within the app. It should be a name that persists between different versions of a module so that modules can be smoothly upgraded to new versions. For example, for the module cosmos.bank.module.v1.Module, we may chose to simply name the module "bank" in the app. When we upgrade to cosmos.bank.module.v2.Module, the app-specific name "bank" stays the same and the framework knows that the v2 module should receive all the same state that the v1 module had. Note: modules should provide info on which versions they can migrate from in the ModuleDescriptor.can_migration_from field.

• optional google.protobuf.Any config = 2

  config is the config object for the module. Module config messages should define a ModuleDescriptor using the cosmos.app.v1alpha1.is_module extension.

• repeated GolangBinding golang_bindings = 3

  golang_bindings specifies explicit interface to implementation type bindings which depinject uses to resolve interface inputs to provider functions. The scope of this field's configuration is module specific.

ModuleDescriptor describes an app module.

• string go_import = 1

  go_import names the package that should be imported by an app to load the module in the runtime module registry. It is required to make debugging of configuration errors easier for users.

• repeated PackageReference use_package = 2

  use_package refers to a protobuf package that this module uses and exposes to the world. In an app, only one module should "use" or own a single protobuf package. It is assumed that the module uses all of the .proto files in a single package.

• repeated MigrateFromInfo can_migrate_from = 3

  can_migrate_from defines which module versions this module can migrate state from. The framework will check that one module version is able to migrate from a previous module version before attempting to update its config. It is assumed that modules can transitively migrate from earlier versions. For instance if v3 declares it can migrate from v2, and v2 declares it can migrate from v1, the framework knows how to migrate from v1 to v3, assuming all 3 module versions are registered at runtime.

PackageReference is a reference to a protobuf package used by a module.

Used in: ModuleDescriptor

• string name = 1

  name is the fully-qualified name of the package.

• uint32 revision = 2

  revision is the optional revision of the package that is being used. Protobuf packages used in Cosmos should generally have a major version as the last part of the package name, ex. foo.bar.baz.v1. The revision of a package can be thought of as the minor version of a package which has additional backwards compatible definitions that weren't present in a previous version. A package should indicate its revision with a source code comment above the package declaration in one of its files containing the text "Revision N" where N is an integer revision. All packages start at revision 0 the first time they are released in a module. When a new version of a module is released and items are added to existing .proto files, these definitions should contain comments of the form "Since Revision N" where N is an integer revision. When the module runtime starts up, it will check the pinned proto image and panic if there are runtime protobuf definitions that are not in the pinned descriptor which do not have a "Since Revision N" comment or have a "Since Revision N" comment where N is <= to the revision specified here. This indicates that the protobuf files have been updated, but the pinned file descriptor hasn't. If there are items in the pinned file descriptor with a revision greater than the value indicated here, this will also cause a panic as it may mean that the pinned descriptor for a legacy module has been improperly updated or that there is some other versioning discrepancy. Runtime protobuf definitions will also be checked for compatibility with pinned file descriptors to make sure there are no incompatible changes. This behavior ensures that: * pinned proto images are up-to-date * protobuf files are carefully annotated with revision comments which are important good client UX * protobuf files are changed in backwards and forwards compatible ways