-
Notifications
You must be signed in to change notification settings - Fork 65
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
Create Repository Structure #1
Changes from all commits
5d4cc04
4fdefc0
15ff2bc
baf1e0d
7966511
b2815ba
fea88a1
5709535
375b103
6095ac5
b0a507f
8fce598
5116051
845c68f
06a0a72
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# Code of Conduct | ||
|
||
## Our Pledge | ||
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. | ||
|
||
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. | ||
|
||
## Our Standards | ||
Examples of behavior that contributes to a positive environment for our community include: | ||
|
||
Demonstrating empathy and kindness toward other people | ||
Being respectful of differing opinions, viewpoints, and experiences | ||
Giving and gracefully accepting constructive feedback | ||
Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience | ||
Focusing on what is best not just for us as individuals, but for the overall community | ||
Examples of unacceptable behavior include: | ||
|
||
The use of sexualized language or imagery, and sexual attention or advances of any kind | ||
Trolling, insulting or derogatory comments, and personal or political attacks | ||
Public or private harassment | ||
Publishing others’ private information, such as a physical or email address, without their explicit permission | ||
Other conduct which could reasonably be considered inappropriate in a professional setting | ||
Enforcement Responsibilities | ||
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. | ||
|
||
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. | ||
|
||
## Scope | ||
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. | ||
|
||
## Enforcement | ||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at community@strange.love. All complaints will be reviewed and investigated promptly and fairly. | ||
|
||
All community leaders are obligated to respect the privacy and security of the reporter of any incident. | ||
|
||
## Attribution | ||
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
# Contributing to `ibc-apps` | ||
|
||
All development work should happen directly on Github. Both core team members and external contributors may send pull requests which go through the same process. Additionally: | ||
|
||
- A release and tag for _App A_ ought not be blocked on changes in other unrelated or upstream apps | ||
- Version management must be able to be handled independently. i.e. An _App A_ can upgrade to `ibc-go v8` and release a tag against it, while _App B_ may remain unsupported for `v8`. | ||
- Teams with general write access to the repo should not be authorized to write to apps that they do not maintain (only default branch/tags/etc). Of course, PRs welcome :-) | ||
|
||
|
||
## Repository Structure | ||
|
||
Every app should be its own module in it's own directory. | ||
|
||
|
||
## How can I contribute? | ||
|
||
All contributions should abide by the [Code of Conduct](./CODE_OF_CONDUCT.md) | ||
|
||
For issues, create a Github issue and include steps to reproduce, expected behavior, and the version affected. | ||
|
||
For features, every module should have [interchain-test](https://github.com/strangelove-ventures/interchaintest) coverage. | ||
|
||
For modules, ensure full test coverage and compatibility with the main branch. | ||
|
||
|
||
## New contributer approval process | ||
- [ ] Submit a Github issue titled "I should be a maintainer because..." | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be good to give a bit of an indication of why someone would be granted write access. Some thoughts I have:
|
||
- [ ] After approval, write privileges will be granted to a member of an external team. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this the team who opened the issue? |
||
- [ ] Merging PRs will require approval from more than one team | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the intention behind this requirement? Trying to gauge what issue it is trying to solve |
||
|
||
Privileges will be revoked in case of failure to comply with the [Code of Conduct](../CODE_OF_CONDUCT.md) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Who makes this judgement? In my experience, violations of code of conduct are usually not so straight forward and hard to enforce when no one is given the authority to make the judgement |
||
|
||
|
||
## Versioning | ||
|
||
We use [Semantic Versioning](https://semver.org/spec/v2.0.0.html) and Go modules to manage dependencies. The main branch should build with go get. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,64 @@ | ||
# ibc-apps | ||
IBC applications and middleware for Cosmos SDK chains | ||
|
||
![IBC-APPS Header](ibc-apps.png) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is just a general comment which probably needs a bit more discussion - do we want their to be a feeling of coherence between ibc-apps and ibc-go? Right now the readme's have a different flow of content and different descriptions of ibc for example. If we want a unified feel, I would suggest we align on this and that isn't to say ibc-go just sets the tone but we can adapt both in parallel? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should aim for a unified feel in terms of readme, documentation etc. Could be good to have teams sync on this given that the README revamp for ibc-go is still ongoing. cc @crodriguezvega |
||
|
||
IBC applications and middleware for Cosmos SDK blockchains | ||
|
||
🌌 Why have an ibc-apps repo? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This paragraph and the next talk about IBC and ibc-go without first defining them, how about we swap the order?
|
||
================================ | ||
|
||
Early IBC work started in the [ibc-go](https://github.com/cosmos/ibc-go) repo. As the repo grew, the need arose to parallelize the work among many teams. | ||
|
||
The ibc-apps repo is meant to be an easily discoverable, navigable, central place for modules and middleware. | ||
|
||
🌌🌌 Who's it for? | ||
=================== | ||
|
||
IBC-Apps is for: | ||
- _Core **ibc-go** contributors_; it frees them from having to maintain IBC Apps, | ||
|
||
- _Publishers of **ibc apps**_, so their apps can be easily found, and | ||
|
||
- _Everyone who uses IBC_ and wants to benefit from the full range of its capabilities. | ||
|
||
|
||
🌌🌌🌌 What is it? | ||
================== | ||
|
||
### What is IBC? | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we explain this here? Feel like one sentence about IBC and one about ibc-go would be enough with references for further prerequisite readings if the reader needs it. Given the comment above wrt coherency between ibc-go and ibc-apps, how about we use this:
Could be rephrased but likely good to have something similar in both repos |
||
|
||
The Inter-Blockchain Communication Protocol (IBC) is a protocol to handle the authentication and transport of data between two blockchains. IBC requires a minimal set of functions, specified in the [Interchain Standards](https://github.com/cosmos/ibc/tree/main/spec/ics-001-ics-standard) (ICS). These specifications do not limit the network topology or consensus algorithm, so IBC can be used with a wide range of blockchains or state machines. The IBC protocol provides a permissionless way for relaying data packets between blockchains, unlike most trusted bridging technologies. The security of IBC reduces to the security of the participating chains. | ||
|
||
IBC solves a widespread problem: cross-chain communication. This problem exists on public blockchains when exchanges wish to perform swaps. The problem arises early in the case of application-specific blockchains, where every asset is likely to emerge from its own purpose-built chain. Cross-chain communication is also a challenge in the world of private blockchains, in cases where communication with a public chain or other private chains is desirable. | ||
|
||
Cross-chain communication between application-specific blockchains in Cosmos creates the potential for high horizontal scalability with transaction finality. These design features provide convincing solutions to well-known problems that plague other platforms, such as transaction costs, network capacity, and transaction confirmation finality. | ||
|
||
|
||
### What is an IBC App? | ||
|
||
IBC apps can be split into two categories - modules and middleware. | ||
|
||
IBC Modules are self-contained applications that enable packets to be sent to and received from other IBC-enabled chains. IBC application developers do not need to concern themselves with the low-level details of clients, connections, and proof verification. | ||
|
||
IBC Middleware are self-contained modules that sit between core IBC and an underlying IBC application. This allows developers to customize lower-level packet handling. Multiple middleware modules can be chained together. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe link to the middleware spec? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why the spec? Would it not make more sense to point to ibc-go middleware docs? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed the docs are probably more user friendly |
||
|
||
|
||
🌌🌌🌌🌌 How to Use this repo | ||
============================= | ||
|
||
If you'd like to include software in this repo, please see [contributing](../ibc-apps/CONTRIBUTING.md). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should there be some information here about how to actually import the modules in the repo? Users would be not just contributors but chain devs |
||
|
||
🌌🌌🌌🌌🌌 Bonus Content | ||
============================= | ||
|
||
## Hello World | ||
|
||
An [example IBC app](./examples/hello-world/) | ||
|
||
|
||
## List of Apps | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe this should go earlier in the read me? Not a big point but I can imagine if you already know about ibc you might just want to know which apps and middleware are in the repo asap |
||
|
||
| Name | Type | Example | Stakeholders | Description | | ||
| ---- | ---- | ------- | ------------ | ----------- | | ||
| [Async Interchain Query](./modules/async-icq/) | Module | Link | [Strangelove](https://github.com/strangelove-ventures/) | Interchain Queries enable blockchains to query the state of an account on another chain without the need for ICA auth. | | ||
| [Packet Forward Middleware](./middleware/packet-forward-middleware) | Middleware | Link | [Strangelove](https://github.com/strangelove-ventures/) | Middleware for forwarding IBC packets. | |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
# Docs | ||
|
||
Documentation for IBC apps |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
# Examples | ||
|
||
This folder contains sample applications. | ||
|
||
- Async ICQ example app | ||
- Packet forward middleware example app | ||
- Global examples | ||
- ICS-20 | ||
- ICS-20 + ICQ + PFM | ||
- Tests for this app can be found in the /tests folder |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# IBC Middleware | ||
|
||
IBC Middleware is a term for a self-contained module that sits between core IBC and an underlying IBC application (which can also be middleware). Multiple middleware modules can be chained together. | ||
|
||
![IBC Middleware Diagram](https://ibc.cosmos.network/main/assets/img/middleware-stack.0aaa1f91.png) |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we call this directory There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the differentiation between modules vs. middleware, both of which are Apps There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about having the base apps and the middleware both under an |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
# IBC Modules | ||
|
||
IBC Modules are self-contained applications that enable packets to be sent to and received from other IBC-enabled chains. IBC application developers do not need to concern themselves with the low-level details of clients, connections, and proof verification. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will it then be up to the specific app developers to communicate the versioning and compatibility of their apps with ibc-go releases or should there be some information collated for all apps in the repo? i.e. as a user, is there an easy way for me to come to this repo and see which apps will work with which release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be helpful if this issue is implemented for ibc-go v8.0.0? cc @damiannolan
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great call out. This will need to be coordinated and collated for the repo, such as with a version matrix on the README. But we can keep the release cycles separate for different ibc-apps similar to how the Cosmos SDK repo does for different modules.