Feature gap between Hermes and Go relayer

ancazamfir commented 3 years ago

Crate

relayer

Summary

This issue is to identify the missing features and guide hermes planning. (cc @colin-axner)

Problem Definition

As support for Go relayer will be reduced over the next months/ year we should ensure we close the feature gap in hermes.

Proposal

[ ] REST server (see rly api) #843
[ ] manage chain configuration via CLI (see rly chains). Can query, remove and add (by specifying a file)
[ ] manage configuration file via CLI (see rly config). Can print, create a default, add chains, connections and paths to the configuration file.
[ ] join and run relayer testnets (see rly testnets). Listens for token requests (faucet) and requests tokens from faucets (request)
[ ] fetch the genesis file for a chain (see rly dev genesis)

(WIP)

Acceptance Criteria

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

jackzampolin commented 3 years ago

fwiw rly testnets was designed for the early IBC testnet era and may want redesign or scrapping. The facuet similar. The genesis command was for me testing how to pull consensus params out of the genesis file and doesn't have any special usage.

colin-axner commented 3 years ago

Two other features that I think are missing:

[ ] Updating config after successfully creating clients/connection/channels
[ ] Reusing existing clients/connection/channels

For the first feature, if I run hermes create client ibc-0 ibc-1, I'd expect the resulting client to be logged in my configuration file. This feature is primarily useful if hermes is being used as a standalone binary, so if the intended userbase is expected to write code to interact with hermes then I see this as less useful

For the second feature, if I run hermes create client ibc-0 ibc-1 twice, I'd expect the same client to be returned unless there is a long delay between the commands (the client becomes expired). This reuse prevents users from accidentally spamming chains when the client with their desired parameters already exist

A couple good points to keep in mind if implementing these features.

There are many times users may not want to reuse the same identifiers, an override option should be provided. I find a flag is not sufficiently explicit enough for this functionality. The override should likely be an argument. Users should be aware they are reusing or creating new clients/connections/channels but reusing should always be recommended as the default.

Ensure that clients without a Status of Active are not re-used. The go relayer didn't initially have this check which can be troubling to debug.

adizere commented 3 years ago

Hermes dev is increasingly driven by relayer operators needs (Cephalopod, Gravity DeX).

informalsystems / hermes