ics27 controller API review

[damiannolan]

Summary

As we move towards a beta-1 release of interchain accounts I think we should take a moment to review the API exposed to authentication module developers via the controller submodule. When we finalise a release these APIs become harder to change, if not impossible to change without causing disruptions. Raising this issue to open a discussion on this and make a proposal.

Proposal

Rename both functions exposed to authentication module developers.

InitInterchainAccount -> RegisterInterchainAccount

Originally I believe this was named InitInterchainAccount as it is initialising a channel handshake by creating and routing a new MsgChannelOpenInit via the sdk's msg service router. I propose we rename this to RegisterInterchainAccount as essentially its implicit that we are using ibc and channel creation should be opaque from the user's perspective. This function is part of the controller submodule and as such, there is no naming collision with RegisterInterchainAccount in host, in my opinion it aligns nicely.

TrySendTx -> SendTx / ExecuteTx

We should remove Try from the function name here. I think this implies that something could often go wrong on packet execution, when in reality we want all valid packets to succeed. Try is a word seen commonly with error handling syntax and libraries and with that in mind I think it makes a clearer API to just remove it from the function definition.
I propose either SendTx or ExecuteTx. The latter aligns with the enum naming of Type used in InterchainAccountPacketData, but I don't feel particularly strongly in favour of either.

Thoughts on this?

---

For Admin Use

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

[crodriguezvega]

My vote goes for RegisterInterchainAccount and SendTx

[damiannolan]

My vote goes for RegisterInterchainAccount and SendTx

+1 from me, they would be my preference

[colin-axner]

+1 on SendTx

RegisterInterchainAccount sounds fine with me. I'm interested in potentially other suggestions?

[colin-axner]

Food for thought: BeginInterchainAccountCreation()

[seantking]

+1 on SendTx

I will ponder on the RegisterInterchainAccount suggestion. Maybe it's totally fine.

I am just hesitant to hide all the magic we are doing with channel creation behind the Register concept.

[seantking]

Food for thought: BeginInterchainAccountCreation()

This is interesting.