The Inter-Blockchain Communication (IBC) protocol is a crucial component of the Cosmos ecosystem, enabling seamless interoperability between different Cosmos networks.
Over the past year, the following teams have experienced significant difficulty bringing new and important features to IBC, or have suffered because features aren’t visible or cannot easily be maintained.
Notional
SDK 46
Field length limits
Irisnet
IBC NFTs and SDK 46
Strangelove
Packet forward middleware
ICQ
WASM Clients
Quasar
ICQ
Composable
WASM Clients
Cosmos Hub
Packet forward middleware
The entire ecosystem loses when it is difficult to contribute to a key software repository.
It is our opinion that if this work was easily discoverable:
New SDK versions would get wider reach
Cosmos chains would ship ICQ and PFM by default
The list of chains using the work described above would be at least a dozen chains long and more likely three dozen chains
The work would be more mature because it would have been used in production
Use of even just ICQ and PFM in production would expand the IBC economy
Use of WASM clients in production would dramatically expand the IBC economy
Expansions in the IBC economy have historically driven value toward the cosmos hub, the hub would be able to capture more value
Recently, the Notional team realized just how much the ecosystem was missing out on:
This proposal aims to address these issues by appointing a dedicated Maintainer Coordinator for the IBC repository.
Proposal:
We propose that Strangelove, an experienced team and active members of the Cosmos ecosystem, be appointed as the Maintainer Coordinator for the IBC repository. In this role, Strangelove will be responsible for coordinating a diverse set of maintainers who oversee the review and merge process, ensuring timely responses to pull requests, and maintaining the repository’s overall quality.
Strangelove will also work with a team of developers to implement the following measures to improve the state of the IBC repository:
Transform the IBC-go repository into a repository maintained by multiple organizations. The current ibc-go team from interchain Gmbh would become one of the organizations maintaining the repository.
Define clear guidelines: The Maintainer Coordinator will establish clear guidelines for the review and merge process to ensure that it is transparent, efficient, and effective. The guidelines will be publicly available and will include criteria for code quality, testing, and documentation.
Implement a triage process: A triage process will be implemented to prioritize pull requests based on their importance and urgency. This will ensure that critical bug fixes and improvements are addressed first.
Encourage community participation: The Maintainer Coordinator will actively encourage community participation in the maintenance of the IBC repository.
Create short term (quarterly) and long-term (length unknown) roadmaps and measure progress against them.
Appointing strangelove as the maintainer coordinator for IBC would allow the IBC ecosystem and economy to grow more rapidly, and ensure that ibc-go’s development process becomes decentralized, matching the spirit and values of cosmos.
References:
ICQ
Packet forward middleware
WASM Clients
NFTs
SDK 46
Voting yes on this proposal means that you support:
Establish cosmos hub governance as the caretaker and standard bearer for github.com/cosmos/* repositories
Nominating Strangelove Ventures as the Maintainer Coordinator of ibc-go
An approvals process for code that involves reviews from at least 2 separate orgs before merging, as opposed to the current “monolithic” organizational design
Adding or removing maintainership roles based on governance decisions using the ~/.github/CODEOWNERS file as described here:
Hey so I just wanted to add a little detail to this, here is where I first discussed this concept:
I think that it is very important that:
Repositories be grouped by function like:
No one uses IAVL, ledger-cosmos-go, and cosmos-db without the SDK, therefore put all of them in the SDK
No one uses cometbft-db without cometbft, therefore put cometbft-db in cometbft
The vast majority of IBC enabled chains built using the cosmos SDK will want packet forward middleware, ICQ, and WASM clients, therefore those tools should go directly into the IBC go repository
Benefits of this approach
Faster onboarding
This approach saves time and money because developers are not needing to visit many different repositories in order to do their work and they don’t need to know where those repositories are because everything is where they need it.
Easier maintenance
In all of the cases mentioned above, maintenance is made much faster by removing the separate software components and placing them into the larger repository so that they can be maintained and tested alongside it.
Better integration testing
Historically one of the areas where we are weak is software integration testing. When more of the components are in the same repository it is much easier to use the continuous integration system to run tests both on them and between them. This leads to better security.
I’ve been thinking a lot about the question, “ how can we achieve an effective decentralized development model at the Hub? “
We have Informal, Binary, StrangeLove, Iqlusion, and now Notional active at the hub.
Coordinating & collaborating is non-trivial.
I have been thinking about tools such as: shared Slack, Ethereum EIP system, better role clarity (eg 1 org does MEV, 1 does IBC, 1 does ICS, etc), dedicated developer days where all 5 orgs can be around a table together to liaise.
It feels like this proposal moves in the right direction:
it clarifies roles & responsibilities for one of the 5 orgs in 1 functional area
it proposes a specific scope of work re improving the IBC repository
it proposes a 2nd org keeping up to speed & overseeing the repository (which seems a good practice for these important public goods)
Just so that you know, I’m definitely advocating for functional crossovers between the organizations. Just for example, SL should not be restricted to working on IBC and in addition to that, I have no interest in seeing the current IBC team displaced. This is instead a policy decision born out of about 18 months of personal frustration that I recently learned is shared widely with the community.
It seems to me that we are shipping highly strategic software more slowly than we should and that is specifically because of how we are administering the repository. That is why quite specifically, I am interested not in seeing SL be the sole maintainer but instead coordinate a team of maintainers.
These dedicated in person days would be pretty expensive but they’d also likely be worth it, highly worthy idea.
We support cosmos hub governance as the caretaker of the cosmos GitHub, as it provides a more transparent line of accountability for maintenance than the existing off-chain agreements. We also support nominating Strangelove as the first Maintainer Coordinator.
I am wondering why the current ICF/Interchain team cannot do that?
They could as well apply these multi-team principles, but I don’t understand why the need to change the maintainer.
Moreover, I don’t even think the Hub can decide that anyway.
Hi everyone, I’m Susannah. I am the product lead of the talented ibc-go team at the Interchain Foundation.
Thank you for raising this proposal. While the Interchain Foundation stands behind, endorses, and continues to pursue decentralised contributions to the Interchain stack via both fiscal and human resources, we feel that the stated goal of maintaining the highest quality ibc-go repo and the points stated in this proposal diverge. In everything we do, we keep in mind that ibc-go is fundamental infrastructure securing millions in value transfer, and it is vital to the entire ecosystem that we prioritise security over speed of development.
The contributions and features mentioned above are both meaningful and accessible to teams that want to use them. Like you, we hope that increased coordination and communication between teams can help play a role in increasing the visibility of these features. In line with this objective, we have been working with Strangelove and made what we hope to be a collaborative breakthrough in creating a new repository dedicated to ibc applications and middleware - GitHub - cosmos/ibc-apps: IBC applications and middleware for Cosmos SDK chains.
It’s worth noting that all application modules including token transfer are not enabled by default for a chain that wants to use ibc-go. Each chain developer has to wire up the application modules they want to use. This is also true for middleware. So, by putting middleware and apps into a consolidated repo managed across teams, we believe that we have a strong balance between the security of ibc-go and accessibility and visibility of new features.
However, we do not want to ossify ibc-go either. The work that is being done by Cosmos core teams is of both high quality and importance. At the moment, we are in the process of merging the wasm client into ibc-go because it is a core transport layer primitive. In this regard, both Composable and Strangelove are working to finish the spec, documentation, and testing on this feature. Once our collaborators have finished development and the PR has been reviewed, we will merge this feature into ibc-go.
Thank you again for laying out these suggestions for process improvements and we hope that the above provides an insight into our current thinking. We look forward to continued collaboration with the talented teams in the ecosystem and will continue to work alongside you all to do our utmost to ensure that the most important, innovative, and secure code finds its way into the Interchain stack.
I disapprove of this proposal and voice my support for the existing IBC team. The members of which do not frequent youtube videos or podcasts, or permeate your daily twitter feed, but continuously ship stable high quality protocols which work so flawlessly that you and I have the privilege of taking them for granted.
Furthermore, I implore you to entertain the inverse thought experiment. Perhaps the fastidious rigor, surgical meticulousness, and prophylactic acuity practiced by the IBC team are overdue for a paternalistic insurgency upon Strangelove’s repositories. Perhaps Strangelove needs a firm hand to dictate how they structure folders, when they merge pull requests, and whether they can contribute at all.
If this seems illogical, impractical, and inhibitory to Strangelove’s daily work, then please engage in the quandary that this proposal is just so, in an equal and opposite manner.
The IBC team remains one of the few quiet gardens in the industrial gabfest that is interchain development. They are a steadfast pillar of the cosmos ecosystem. We are fortunate to have them, and would be fortunate to preserve them.
Hey there Susanna, I want to let you know that personally I am satisfied with the way that things have been changed to have the IBC apps repository, I think. Is it cool with you if we give it a couple of months and basically just see if the maintenance burden goes down with IBC apps?
My biggest concern was just looking at all the stuff that’s strange love had built, finding that there was a legitimate maintenance problem because it doesn’t land in the main repository.
Oh dog, you did present the other side of this very well and I thank you for it .
I think that right now what I’d like to do is give it some time. I was super distraught when I found that I could not find or did not know about the work that strange love had been doing, but dog if you’re active on GitHub, then you know that even I need a firm hand from time to time.
Actually everybody does.
So I wouldn’t really single out strange love on that one and I think that for now we move this proposal to abandoned or something? Maybe? Do you have a woof here?
