Filtering initial requirements and design

[ancazamfir]

Summary & proposal

Requirements from the Osmosis launch as well as the DeX launch helped us identify two specific use-cases for filtering:

• Channel filter: "allow" list by port & channel id #1140
  • a prototype exists, running for Osmosis, in Implement basic "allow" filtering mechanism based on channel identifiers #1107
• Channel filter: "deny" by port & channel id #1141
  • this is a requirement from DeX, which seek to deploy two instances of Hermes, the first using a certain predefined list of channel that are critical and high-value, and a second which will avoid relaying on (by blacklisting) critical channels, and may additionally blacklist channels that pose any risk

The two feature exclude each other -- only one (either allow or deny) can be configured for each chain specified in the config file.

---

Original summary & proposal

The IBC relayer has a configuration file that is used to identify chains, relaying "paths", etc. A preliminary proposal is included in https://github.com/informalsystems/ibc-rs/blob/master/docs/architecture/adr-002-ibc-relayer.md
This issue is to create a proper specification for relayer behavior.

Behavior specification should be allowed for the relayer. Here are some examples:

• relaying strategy, e.g. polling vs notification driven
• path filtering, e.g. only relay from A to B, over one or more connections/ channel, or maybe all, or all except one or more connections/ channels, etc.

Proposal

Create a specification for behavior and path filtering language. This is to be used in the configuration file and/ or maybe relayer commands, for example if filtering is adjusted at runtime.

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[adizere]

Relayer v0 will not handle this feature, so we postpone this for later versions.