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

Create Repository Structure #1

Merged
merged 15 commits into from
Mar 30, 2023
37 changes: 37 additions & 0 deletions CODE_OF_CONDUCT.md
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.
36 changes: 36 additions & 0 deletions CONTRIBUTING.md
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 :-)

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

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

Copy link
Member

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

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.


## 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..."

Choose a reason for hiding this comment

The 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:

  • Actively developing an ibc app or middleware that is / will be in this repo
  • Has previously made a substantial contribution to an app housed in the repo and plans to contribute more going forwards
  • Already has write access to an app that will move into the repo

- [ ] After approval, write privileges will be granted to a member of an external team.

Choose a reason for hiding this comment

The 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

Choose a reason for hiding this comment

The 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)

Choose a reason for hiding this comment

The 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.
64 changes: 63 additions & 1 deletion README.md
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)

Choose a reason for hiding this comment

The 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?

Copy link
Collaborator

Choose a reason for hiding this comment

The 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?
Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

  1. What is IBC? (short and succinct)
  2. Why have an ibc-apps repo?
  3. Who's it for?
  4. How to use this repo?
  5. Bonus content

================================

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?
Copy link
Collaborator

Choose a reason for hiding this comment

The 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:

The Inter-Blockchain Communication protocol (IBC) allows blockchains to talk to each other. This end-to-end, connection-oriented, stateful protocol provides reliable, ordered, and authenticated communication between heterogeneous blockchains.

This IBC implementation in Golang is built as a Cosmos SDK module. To understand more about how to use the ibc-go module as well as about the IBC protocol, please check out the Interchain Developer Academy section on IBC, or our docs."

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe link to the middleware spec?

Copy link
Collaborator

Choose a reason for hiding this comment

The 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?
Ditto for apps btw

Copy link
Member

Choose a reason for hiding this comment

The 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).

Choose a reason for hiding this comment

The 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

Choose a reason for hiding this comment

The 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. |
3 changes: 3 additions & 0 deletions docs/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Docs

Documentation for IBC apps
10 changes: 10 additions & 0 deletions examples/README.md
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
Binary file added ibc-apps.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
5 changes: 5 additions & 0 deletions middleware/README.md
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)
3 changes: 3 additions & 0 deletions modules/README.md
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call this directory apps instead of modules?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about having the base apps and the middleware both under an apps directory? What top level directories will be shared between the apps?

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.
Empty file added tests/README.md
Empty file.