Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move connection identifiers in interchain accounts port ID to version #615

Closed
3 tasks
colin-axner opened this issue Dec 9, 2021 · 4 comments · Fixed by #700
Closed
3 tasks

Move connection identifiers in interchain accounts port ID to version #615

colin-axner opened this issue Dec 9, 2021 · 4 comments · Fixed by #700

Comments

@colin-axner
Copy link
Contributor

Summary

Move the connection ID and counterparty connection ID numbers from the portID to the channel version.

Problem Definition

We recently discussed the possibility of creating ORDERED channels which do not close on packet timeouts. This makes channel recovery in interchain accounts a lot less necessary. If we decide to pursue this change in the future, changing the port ID format will be very difficult, thus it seems desirable to move these fields, which may not be necessary in the future, to the version which can be changed.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged/assigned
@damiannolan
Copy link
Contributor

I think if we are going with this we should probably JSON encode the payload into a typed Metadata field or something along those lines. What do you think?

@colin-axner
Copy link
Contributor Author

As in create a type for the version and JSON encode it? Seems reasonable to me. We won't have to do string parsing, client side representation of the version will be quite ugly I think

@damiannolan
Copy link
Contributor

Yeah exactly, what we were talking about before. I think with adding more fields to the version parsing could just get out of hand and JSON encoding would be somewhat cleaner.

Do you mean ugly with the JSON encoding or ugly with extra fields? I think it would be ugly either way I guess 🤣

@colin-axner
Copy link
Contributor Author

How will the JSON encoding look when printed as a string? I guess it might look fine?

I think using a type is probably a good idea in this instance

@colin-axner colin-axner self-assigned this Dec 15, 2021
@crodriguezvega crodriguezvega added this to the Interchain Accounts milestone Dec 30, 2021
@crodriguezvega crodriguezvega moved this to Todo in ibc-go Dec 31, 2021
@crodriguezvega crodriguezvega moved this from Todo to In progress in ibc-go Jan 4, 2022
@crodriguezvega crodriguezvega moved this from In progress to In review in ibc-go Jan 10, 2022
Repository owner moved this from In review to Done in ibc-go Jan 13, 2022
faddat pushed a commit to notional-labs/ibc-go that referenced this issue Feb 23, 2022
…hub.com/spf13/viper-1.9.0

Bump github.com/spf13/viper from 1.8.1 to 1.9.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants