Implement ics-31-crosschain-queries

[Woojinger]

Summary

Our team tries to implement ics-31-crosschain-queries

Forked IBC-go link

Forked IBC Relayer link

We want to know how to contribute code without duplication with other teams

Problem Definition

Hello, I’m a member of Decipher, Blockchain Research Group based in Seoul National University

Some developers in Decipher felt a need for crosschain-queries and we started to implement it.

But we found another team repo for interchain-queries in README a few days ago. So we are confused as to whether we can continue to work on our repo.

How can we contribute?

Proposal

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

Hi @Woojinger. Great to hear that you want to contribute to IBC.

Would your implementation of ICS31 be in any way different than the one that already exists? I think this implementation is the one that follows the ICS31 standard, so if your application would not deviate from ICS31, then I think it would make sense that you contribute to that implementation instead of creating a new one. As you say, that will prevent duplication of code and will help to concentrate the efforts.

[Woojinger]

Hello @crodriguezvega.
We see the implementation already exist but our repository is little different from that..

The implementation is about relayer and uses go. But what we're making is IBC-go module(31-ibc-query) and relayer by using Rust.

So I think it is little hard to contribute to that implementation.. sorry

[crodriguezvega]

Hi @Woojinger. Ok, I see... So if you're working on a different implementation of ICS31, what are your long term plans for it?

I am asking because we are considering at the moment restructuring the ibc-go repository and break it up into three separate repos: one for core, one for applications/middlewares, and one for light clients.

If you are interested in the future to upstream your implementation, then you could add it to the applications repo and be the maintainer of it. Would this approach be suitable for you? We are also at the moment maintaining a registry of apps in the readme of ibc-go, so if you prefer to keep the app in your own repository, then we could list it there. Would you have any preference between these two approaches?

Since there is no changes needed for ibc-go, I will close this issue for now, but please feel free to comment if you have any feedback or thoughts regarding the above. Thanks!

[Woojinger]

@crodriguezvega
Oh, that's interesting news!
We prefer to add our module to application repo! When should we complete our module for adding to the application repo?
Our team is so happy to contribute to cosmos repo :)

[crodriguezvega]

Hey @Woojinger, sorry for the late reply. We have been discussing internally in the team and we have decided to go in a different path: instead of creating a new repo where applications could be added, we are considering the following two options for external teams:

• Request maintenarship transfer of your code to the ibc-go team. We have just drafted a document explaining how this process would look like and you can have a look at it here.
• Teams would maintain their code in their own repositories and we could add a link to them in our registry.

How does this sound? Looking forward to your feedback!

[Woojinger]

Thank you @crodriguezvega

We choose first option and we will set up our module like this example

When we finish our setup, I will reply again in this issue and contact IBC product team.

our new repository link

Thank you!

[womensrights]

Hello, I tried to find a contact detail for you, @Woojinger but was not successful so feel free to send me an email on [email protected] and we can discuss the product use cases. Looking forward to it!