# Relayer v2

## Changes

The new relayer has several improvements with big goals in mind
- Eliminating Bech32 issues by relying on [lens](https://github.com/strangelove-ventures/lens) as a dependancy as a means for avoiding the global singleton in the Cosmos SDK
- Paving the way for other ecosytems to integrate with IBC and find support in the go-relayer, this is achieved through the concept of a `Provider` interface which is a feature rich API that can be implemented
- Creating a consistent cli experience for users which is both easy to use and feature rich
- Better tx flow where you submit a tx and wait until it is included in a block

## Adding Additional Provider implementations

For those interested in finding support in the go-relayer a few steps must be adhered to.

A light client implementation is necessary for integration with ibc-go, Tendermint light client implementation can be found [here](https://github.com/cosmos/ibc-go/tree/main/modules/light-clients/07-tendermint) as an example

The Provider API must be implemented in a third party library which will be imported in the go-relayer

Once these prerequisites are met integration in the go-relayer can be easily achieved. The relayer uses a reflection based system for parsing a ProviderConfig, this provides the flexibility needed to create arbitrary configuration settings for specific ecosystems

Example Config:

{
  "type": "cosmos",
  "value": {
    "key": "test-key",
    "chain-id": "cosmoshub-4",
    "rpc-addr": "http://34.102.4.160:26657",
    "grpc-addr": "https://gprc.cosmoshub-4.technofractal.com:443",
    "account-prefix": "cosmos",
    "keyring-backend": "test",
    "gas-adjustment": 1.3,
    "gas-prices": "0.025uatom",
    "debug": true,
    "timeout": "10s",
    "output-format": "json",
    "sign-mode": "direct"
  }
}

The type field here is used in the relayer to differentiate between which Provider implementations are being handled. All Cosmos based chains, for example, will have the value "cosmos" whereas Substrate based chains may opt for an agreed upon "substrate" value that will be used for all chains using the Subsrtate implementation of the Provider API.

We register the config in the relayer in two locations to ensure the relayer can successfully parse the config files and build the Provider instance

The Provider 'type' must be registered in this map [here](https://github.com/cosmos/relayer/blob/8cc5b1ece06741a8dea94a1d54aa48df4b3c853b/cmd/config.go#L369)
with the key being the Provider type (e.g. cosmos, substrate, celo, etc) and the value being a struct literal for the underlying concrete implementation of the ProviderConfig API. This allows JSON based config files to be accurately parsed.

customTypes := map[string]reflect.Type{
		"cosmos": reflect.TypeOf(cosmos.CosmosProviderConfig{}),
	}

We must also register the config in [this](https://github.com/cosmos/relayer/blob/8cc5b1ece06741a8dea94a1d54aa48df4b3c853b/cmd/config.go#L419) switch statement, which will allow for successful parsing of YAML config files. There should be one case with the condition being equal to the 'type' field found in the config file. This should then allocate memory for a new Provider Config

switch iw.Type {
	case "cosmos":
		iw.Value = new(cosmos.CosmosProviderConfig)
	default:
		return fmt.Errorf("%s is an invalid chain type, check your config file", iw.Type)
	}

## New Path Generation

To generate a new path between two IBC enabled zones the general workflow looks something like the following.
- Users generate a new empty path via
`rly paths new [src-chain-id] [dst-chain-id] [path-name] [flags]`
- Optionally, you can create each client in a seperate command before linking the paths.
This is useful when queries are timing out/you are dealing with node performance issues
`rly tx client [src-chain-id] [dst-chain-id] [path-name] [flags]`
- Users link the paths via
`rly tx link [path-name]`
- Users are now ready to relay against the new path

## Contributing

## Notes