awesome-cosmos
awesome-cosmos copied to clipboard
cosmos
add pokt
how should we treat users that have forked and rewritten parts of the sdk?
I can ask the pokt team if they would like to be included as well
yeah, good question. particularly as AIB is building out a new ecosystem page that includes these classifications. maybe @lovincyrus @nassdonald or others at AIB have ideas?
Hmm… I'd say a forked version of the SDK doesn't invalidate one's qualification as a 'Cosmos' project, but that's just my opinion. Ultimately the Cosmos ecosystem is bigger than just the Cosmos SDK – of which there may be many alternatives in years to come.
That being said, it does beg the question: what constitutes a Cosmos project? Perhaps this is a more challenging set of inclusion criteria that we need to define over time.
I think they’re qualified if: 1- it’s their wish to be featured on the website, and this will be known the moment we ask them to provide us the information... 2- if their project meets the standards we are trying to define, in order to select quality over quantity.
Example: IRISnetwork uses IRIS SDK and not Cosmos SDK, but they are very proud to be part of the Cosmos ecosystem and their project brings value to the community.
In my opinion, this is a type of reasoning that is worth tackling. It would be appropriate to define what we don’t want to see among the projects that will appear on the page.
how should we treat users that have forked and rewritten parts of the sdk?
If they're using and building their forked sdk, we could add it as one of our platforms with some defined criteria: active contributions, # of stars, used by # of projects, etc.
e.g.: "platform": ["cosmos-sdk", "another-forked-cosmos-sdk", "iris-sdk", "weave", "etc"],
Just adding my two cents here.
I think we just need to differentiate 'Cosmos ecosystem project' from 'Cosmos-SDK based project'. The former should have a smaller scope and a higher (and perhaps an arbitrary) standard and can be included in the ecosystems page, while the latter can have a wider scope to showcase the quality of the Cosmos-SDK but not necessarily be part of the 'Cosmos ecosystem' messaging.
From my personal opinion:
Cosmos ecosystem projects: Projects that may have modified the SDK and going the direction of interoperating with (Cosmos Hub?/other Cosmos-SDK based chains).
Cosmos-SDK based projects: Projects that have modified the SDK, but do not intend to join the 'Cosmos ecosystem' of interoperable blockchains.
having an understanding of which projects are on which version of the SDK is also useful for the module ecosystem as modules from different point releases currently aren't compatible. unifying modules also something the ICF also plans to work on this quarter.
To do this I believe that we will need technical support, I personally do not have the skills to make such an analysis. Anyway in my opinion these in-depth examinations can be done after a first evaluation based on the projects’ team willing to support or not Stargate, as suggested yesterday by Peng. In this way, you will not risk studying in detail cases that will not be included in the final list. I agree with the need to deepen the technical background of the projects and discover if their version is compatible, but I'm not sure the ecosystem page should have this as a primary focus. We must not forget that the page will be primarily a consultation tool for the community, so we should be careful not to fall into too many technicalities neglecting clear and incisive communication. As Cyrus mentioned above, you might consider using tags or icons to show their use of the SDK in a modified form.
that's fair. I think a first pass of just getting everything on one page and then making the information more granular is a good strategy.