Question on getting involved in the development of Relayer v2

[thaodt]

Hello team, I'm not sure if this is the best place to ask about Relayer v2.
I accidentally saw roadmap 2024 somewhere, please take a look on my screenshots below:

Taking a while to look around on our github org, I found out that we are developing a new Hermes Relayer (v2).

First of all, could you please tell me what is the difference between this Relayer v2 version and relayer-next version?
The next question may be rude and awkward, but could you please show me how I can participate in this development if possible? I couldn't find much information and how to contact the Relayer team at the interchain discord server, so I believe this related to internal team discussion. I'd like to have a hand in this development, especially on "Modularizing forwarder components and logic, Adding forwarding support between Wasm clients, and Supporting the forwarding needs of zero threads not SDK and not Cosmos".

[adizere]

Hi @thaodt your contributions would be more than welcome!

May I ask which part of Hermes v2 (Hermes "SDK") is of interest to you, are you trying to build something specific? Currently Hermes SDK is aiming as a PoC to work with Sovereign and Cosmos chains. If you tell us your needs or interest we could see how your goals align with the team's goals.

Some low hanging fruits for you to contribute could be: any open PR, or issues tagged with cli label, or we can add a good first issue label as well.

Let us know what you think.

[thaodt]

Hi @adizere thank you for replying me.
AFAIK the hermes v2 is trying to fulfill the whole picture of our Relayer's vision. It means we can enable IBC for non Cosmos-based chain and it can serve as a standard in relayer development.
I found out that every chain (non Cosmos-based) needs to be developed custom light client (if necessary), custom Relayer (with some improvements and some specific logic for that chain). Recently I was assigned a research to enable IBC for an appchain built on MultiversX Sovereign Shards chain (chain A) and it will talk to a Cosmos-based chain (chain B, for e.g. Juno, Composable). And if I understand exactly, the direction of data flowing back and forth between the two chains is directional. For example, chain A is Cosmos-based chain and chain B is some other chain, which will be different from the case I mentioned earlier. Is my understanding correct?
Furthermore, the data flow going back and forth will be unidirectional in the channel and when I want to talk back, I will need to open another channel.
I was thinking that I could build another in-house Relayer for my case, but why don't I contribute back to the original one? Because I think this is definitely a MUST requirement to complete the overall picture. I am very willing to contribute back to the projects (not only hermes-sdk).
I think I'll start with the issues labeled cli or if you feel like there's an issue I could start with, just give it to me.
One more question, because I haven't read the code for relayer-next, so I'm not sure what the difference is between hermes-sdk and relayer-next (which resides in the hermes repo). Can you please clarify it?

[thaodt]

Regarding to issues tagged with cli label, there are 4 issues atm, 2 among them seems already had the assignee.
And I think this one seems to have some space for implementations.
Some cli subcommands have the exclamation mark (!) which Im not sure what it means. Could you please elaborate more on it?
And you can point me to some subcommands which I can start contributions. Thanks.

[soareschen]

Hi @thaodt, thank you for your interest in contributing to Hermes SDK! A slight warning for external contributors at this stage is that we currently lacks documentation for navigating and understanding the Hermes SDK code base. As a result, it may be challenging if you get stuck on understanding some part of the code.

At a high level, Hermes SDK uses a new programming paradigm we developed at Informal, called context-generic programming (CGP). The core implementation of CGP is at https://github.com/informalsystems/cgp. We will add some documentation for CGP and Hermes SDK in the next few weeks. Until then, if you have any question, feel free to ask them at https://github.com/informalsystems/hermes-sdk/discussions or https://github.com/informalsystems/cgp/discussions.

I was thinking that I could build another in-house Relayer for my case, but why don't I contribute back to the original one?

Yes, one of the appeal for Hermes SDK is that you can implement any in-house chain client with your own implementation details such as having a custom light client. You can refer to https://github.com/informalsystems/hermes-sdk/tree/main/crates/sovereign to see one example of custom chain client we are building for Sovereign SDK.

If you are interested in contributing, I created a good first issue with high impact here: informalsystems/hermes-sdk#214

[thaodt]

@soareschen Thanks for the cgp's resource, while reading the hermes-sdk code, I do see the influence of cgp in most of the code structure.

A slight warning for external contributors at this stage is that we currently lacks documentation for navigating and understanding the Hermes SDK code base. As a result, it may be challenging if you get stuck on understanding some part of the code.

yes, I understand the challenges you mentioned about contributing at this early stage but the idea of the project really attracted me, after I saw the implementations for non-cosmos chains.

I'll continue digging into the codebase over the next few days and will try out the GFI you created for. If I have any questions, I will ask them in hermes-sdk discussions. Thank you for your enlightenment 💡 ❤️