Documentation Structure Change and Cleanup (#2808)

* Update docs/sdk/clients.md
* organize ADR directory like tendermint
* docs: move spec-proposals into spec/
* remove lotion, moved to website repo
* move getting-started to cosmos-hub, and voyager to website
* docs: move lite/ into clients/lite/
* move introduction/ content to website repo
* move resources/ content to website repo
* mv sdk/clients.md to clients/clients.md
* mv validators to cosmos-hub/validators
* move deprecated sdk/ content to _attic
* sdk/modules.md is duplicate with modules/README.md
* consolidate remianing sdk/ files into a single sdk.md
* move examples/ to docs/examples/
* mv docs/cosmos-hub to docs/gaia
* Add keys/accounts section to localnet docs

CHANGELOG.md

@@ -245,6 +245,7 @@ IMPROVEMENTS
     * [cli] [\#2128](https://github.com/cosmos/cosmos-sdk/issues/2128) fixed segfault when exporting directly after `gaiad init`
     * [cli] [\#1255](https://github.com/cosmos/cosmos-sdk/issues/1255) open KeyBase in read-only mode
      for query-purpose CLI commands
+    * [docs] Added commands for querying governance deposits, votes and tally
 
 * Gaia
     * [x/stake] [#2023](https://github.com/cosmos/cosmos-sdk/pull/2023) Terminate iteration loop in `UpdateBondedValidators` and `UpdateBondedValidatorsFull` when the first revoked validator is encountered and perform a sanity check.
@@ -289,6 +290,7 @@ BUG FIXES
 * Gaia
   * [x/stake] Return correct Tendermint validator update set on `EndBlocker` by not
   including non previously bonded validators that have zero power. [#2189](https://github.com/cosmos/cosmos-sdk/issues/2189)
+  * [docs] Fixed light client section links
 
 * SDK
     * [\#1988](https://github.com/cosmos/cosmos-sdk/issues/1988) Make us compile on OpenBSD (disable ledger) [#1988] (https://github.com/cosmos/cosmos-sdk/issues/1988)

Makefile

@@ -66,15 +66,15 @@ endif
 
 build_examples:
 ifeq ($(OS),Windows_NT)
-	go build $(BUILD_FLAGS) -o build/basecoind.exe ./examples/basecoin/cmd/basecoind
+	go build $(BUILD_FLAGS) -o build/basecoind.exe ./docs/examples/basecoin/cmd/basecoind
-	go build $(BUILD_FLAGS) -o build/basecli.exe ./examples/basecoin/cmd/basecli
+	go build $(BUILD_FLAGS) -o build/basecli.exe ./docs/examples/basecoin/cmd/basecli
-	go build $(BUILD_FLAGS) -o build/democoind.exe ./examples/democoin/cmd/democoind
+	go build $(BUILD_FLAGS) -o build/democoind.exe ./docs/examples/democoin/cmd/democoind
-	go build $(BUILD_FLAGS) -o build/democli.exe ./examples/democoin/cmd/democli
+	go build $(BUILD_FLAGS) -o build/democli.exe ./docs/examples/democoin/cmd/democli
 else
-	go build $(BUILD_FLAGS) -o build/basecoind ./examples/basecoin/cmd/basecoind
+	go build $(BUILD_FLAGS) -o build/basecoind ./docs/examples/basecoin/cmd/basecoind
-	go build $(BUILD_FLAGS) -o build/basecli ./examples/basecoin/cmd/basecli
+	go build $(BUILD_FLAGS) -o build/basecli ./docs/examples/basecoin/cmd/basecli
-	go build $(BUILD_FLAGS) -o build/democoind ./examples/democoin/cmd/democoind
+	go build $(BUILD_FLAGS) -o build/democoind ./docs/examples/democoin/cmd/democoind
-	go build $(BUILD_FLAGS) -o build/democli ./examples/democoin/cmd/democli
+	go build $(BUILD_FLAGS) -o build/democli ./docs/examples/democoin/cmd/democli
 endif
 
 install: check-ledger update_gaia_lite_docs
@@ -82,10 +82,10 @@ install: check-ledger update_gaia_lite_docs
 	go install $(BUILD_FLAGS) ./cmd/gaia/cmd/gaiacli
 
 install_examples:
-	go install $(BUILD_FLAGS) ./examples/basecoin/cmd/basecoind
+	go install $(BUILD_FLAGS) ./docs/examples/basecoin/cmd/basecoind
-	go install $(BUILD_FLAGS) ./examples/basecoin/cmd/basecli
+	go install $(BUILD_FLAGS) ./docs/examples/basecoin/cmd/basecli
-	go install $(BUILD_FLAGS) ./examples/democoin/cmd/democoind
+	go install $(BUILD_FLAGS) ./docs/examples/democoin/cmd/democoind
-	go install $(BUILD_FLAGS) ./examples/democoin/cmd/democli
+	go install $(BUILD_FLAGS) ./docs/examples/democoin/cmd/democli
 
 install_cosmos-sdk-cli:
 	go install $(BUILD_FLAGS) ./cmd/cosmos-sdk-cli
@@ -159,8 +159,8 @@ test_cli:
 	@go test -count 1 -p 1 `go list github.com/cosmos/cosmos-sdk/cmd/gaia/cli_test` -tags=cli_test
 
 test_examples:
-	@go test -count 1 -p 1 `go list github.com/cosmos/cosmos-sdk/examples/basecoin/cli_test` -tags=cli_test
+	@go test -count 1 -p 1 `go list github.com/cosmos/cosmos-sdk/docs/examples/basecoin/cli_test` -tags=cli_test
-	@go test -count 1 -p 1 `go list github.com/cosmos/cosmos-sdk/examples/democoin/cli_test` -tags=cli_test
+	@go test -count 1 -p 1 `go list github.com/cosmos/cosmos-sdk/docs/examples/democoin/cli_test` -tags=cli_test
 
 test_unit:
 	@VERSION=$(VERSION) go test $(PACKAGES_NOSIMULATION)

README.md

@@ -17,27 +17,26 @@ It is being used to build `Gaia`, the first implementation of the [Cosmos Hub](h
 **WARNING**: The SDK has mostly stabilized, but we are still making some
 breaking changes.
 
-**Note**: Requires [Go 1.10+](https://golang.org/dl/)
+**Note**: Requires [Go 1.11+](https://golang.org/dl/)
 
 ## Gaia Testnet
 
+To install the binaries, read the [install instructions](./docs/gaia/installation.md)
+
 To join the latest testnet, follow 
-[the guide](./docs/getting-started/join-testnet.md).
+[the guide](./docs/gaia/join-testnet.md).
 
 For status updates and genesis files, see the
 [testnets repo](https://github.com/cosmos/testnets).
 
-## Install
-
-See the 
-[install instructions](./docs/getting-started/installation.md).
 
 ## Quick Start
 
-See the [Cosmos Docs](https://cosmos.network/docs/)
+To learn how the SDK works from a high-level perspective, go to the [SDK Intro](./docs/intro/README.md).
 
-- [Getting started with the SDK](./docs/sdk/core/intro.md)
+If you want to get started quickly and learn how to build on top of the SDK, please follow the [SDK Application Tutorial](https://github.com/cosmos/sdk-application-tutorial). You can also fork the tutorial's repo to get started building your own Cosmos SDK application.
-- [SDK Examples](/examples)
+
+For more, please go to the [Cosmos SDK Docs](./docs/README.md)
 
 ## Disambiguation
 

cmd/cosmos-sdk-cli/cmd/init.go

@@ -14,7 +14,7 @@ import (
 	tmversion "github.com/tendermint/tendermint/version"
 )
 
-var remoteBasecoinPath = "github.com/cosmos/cosmos-sdk/examples/basecoin"
+var remoteBasecoinPath = "github.com/cosmos/cosmos-sdk/docs/examples/basecoin"
 
 // Replacer to replace all instances of basecoin/basecli/BasecoinApp to project specific names
 // Gets initialized when initCmd is executing after getting the project name from user

docs/.vuepress/config.js

@@ -12,105 +12,39 @@ module.exports = {
     nav: [{ text: "Back to Cosmos", link: "https://cosmos.network" }],
     sidebar: [
       {
-        title: "Introduction",
+        title: "Overview",
         collapsable: false,
         children: [
-          "/introduction/cosmos-hub",
+          "/intro/README",
-          "/introduction/tendermint-cosmos",
+          "/intro/sdk-app-architecture",
-          "/introduction/tendermint"
+          "/intro/ocap"
         ]
       },
       {
-        title: "Getting Started",
+        title: "Gaia",
         collapsable: false,
         children: [
-          "/getting-started/voyager",
+          "/gaia/installation",
-          "/getting-started/installation",
+          "/gaia/join-testnet",
-          "/getting-started/join-testnet",
+          "/gaia/networks",
-          "/getting-started/networks"
+          "/gaia/validators/overview",
-        ]
+          "/gaia/validators/security",
-      },
+          "/gaia/validators/validator-faq",
-      {
+          "/gaia/validators/validator-setup",
-        title: "Cosmos SDK",
+          "/gaia/ledger"
-        collapsable: false,
-        children: [
-          ["/sdk/overview", "Overview"],
-          ["/sdk/core/intro", "Core"],
-          "/sdk/core/app1",
-          "/sdk/core/app2",
-          "/sdk/core/app3",
-          "/sdk/core/app4",
-          "/sdk/core/app5",
-          // "/sdk/modules",
-          "/sdk/clients"
-        ]
-      },
-      // {
-      //   title: "Specifications",
-      //   collapsable: false,
-      //   children: [
-      //     ["/specs/overview", "Overview"],
-      //     "/specs/governance",
-      //     "/specs/ibc",
-      //     "/specs/staking",
-      //     "/specs/icts",
-      //   ]
-      // },
-      {
-        title: "SDK by Examples - Simple Governance",
-        collapsable: false,
-        children: [
-          ["/sdk/sdk-by-examples/simple-governance/intro", "Intro"],
-          "/sdk/sdk-by-examples/simple-governance/setup-and-design",
-          "/sdk/sdk-by-examples/simple-governance/app-init",
-          "/sdk/sdk-by-examples/simple-governance/simple-gov-module",
-          "/sdk/sdk-by-examples/simple-governance/bridging-it-all",
-          "/sdk/sdk-by-examples/simple-governance/running-the-application"
-        ]
-      },
-      {
-        title: "Light Client",
-        collapsable: false,
-        children: [
-	  "/lite/",
-	  "/lite/getting_started"
-	]
-      },
-      {
-        title: "Lotion JS",
-        collapsable: false,
-        children: [
-	  ["/lotion/overview", "Overview"]
-	]
-      },
-      {
-        title: "Validators",
-        collapsable: false,
-        children: [
-          ["/validators/overview", "Overview"],
-          ["/validators/security", "Security"],
-          ["/validators/validator-setup", "Validator Setup"],
-          "/validators/validator-faq"
         ]
       },
       {
         title: "Clients",
         collapsable: false,
         children: [
-          ["/clients/service-providers", "Service Providers"]
+      	  "/clients/README",
-        ]
+      	  "/lite/", // this renders the readme
-      },
+      	  "/lite/getting_started",
-      {
+      	  "/lite/specification",
-        title: "Resources",
+          "/clients/cli",
-        collapsable: false,
+          "/clients/service-providers"
-        children: [
+      	]
-          // ["/resources/faq" "General"],
-          "/resources/delegator-faq",
-          ["/resources/whitepaper", "Whitepaper - English"],
-          ["/resources/whitepaper-ko", "Whitepaper - 한국어"],
-          ["/resources/whitepaper-zh-CN", "Whitepaper - 中文"],
-          ["/resources/whitepaper-pt", "Whitepaper - Português"]
-        ]
       }
     ]
   }

docs/DOCS_README.md

@@ -1,4 +1,8 @@
-# Docs Build Workflow
+## Updating the docs
+
+If you want to open a PR on the Cosmos SDK to update the documentation, please follow the guidelines in the [`CONTRIBUTING.md`](https://github.com/cosmos/cosmos-sdk/tree/master/CONTRIBUTING.md)
+
+## Docs Build Workflow
 
 The documentation for the Cosmos SDK is hosted at:
 
@@ -15,34 +19,34 @@ Besides, gaia-lite API docs are also provided by gaia-lite. The default API docs
 https://localhost:1317/swagger-ui/
 ```
 
-## How It Works
+### How It Works
 
 There is a Jenkins job listening for changes in the `/docs` directory, on both
 the  `master` and `develop` branches. Any updates to files in this directory
 on those branches will automatically trigger a website deployment. Under the hood,
 a private website repository has make targets consumed by a standard Jenkins task.
 
-## README
+### README
 
 The [README.md](./README.md) is also the landing page for the documentation
 on the website. During the Jenkins build, the current commit is added to the bottom
 of the README.
 
-## Config.js
+### Config.js
 
 The [config.js](./.vuepress/config.js) generates the sidebar and Table of Contents
 on the website docs. Note the use of relative links and the omission of
 file extensions. Additional features are available to improve the look
 of the sidebar.
 
-## Links
+### Links
 
 **NOTE:** Strongly consider the existing links - both within this directory
 and to the website docs - when moving or deleting files.
 
 Relative links should be used nearly everywhere, having discovered and weighed the following:
 
-### Relative
+#### Relative
 
 Where is the other file, relative to the current one?
 
@@ -50,7 +54,7 @@ Where is the other file, relative to the current one?
 - confusing / annoying to have things like: `../../../../myfile.md`
 - requires more updates when files are re-shuffled
 
-### Absolute
+#### Absolute
 
 Where is the other file, given the root of the repo?
 
@@ -58,12 +62,12 @@ Where is the other file, given the root of the repo?
 - this is much nicer: `/docs/hereitis/myfile.md`
 - if you move that file around, the links inside it are preserved (but not to it, of course)
 
-### Full
+#### Full
 
 The full GitHub URL to a file or directory. Used occasionally when it makes sense
 to send users to the GitHub.
 
-## Building Locally
+### Building Locally
 
 To build and serve the documentation locally, run:
 
@@ -94,12 +98,12 @@ python -m SimpleHTTPServer 8080
 
 then navigate to localhost:8080 in your browser.
 
-## Consistency
+### Consistency
 
 Because the build processes are identical (as is the information contained herein), this file should be kept in sync as
 much as possible with its [counterpart in the Tendermint Core repo](https://github.com/tendermint/tendermint/blob/develop/docs/DOCS_README.md).
 
-## Update and Build the RPC docs
+### Update and Build the RPC docs
 
 1. Execute the following command at the root directory to install the swagger-ui generate tool.
     ```

docs/README.md

@@ -1,24 +1,38 @@
-# Welcome to the Cosmos Docs!
+# Welcome to the SDK Docs!
 
-![cosmonaut reading the cosmos docs in space](./graphics/cosmos-docs.jpg)
+Welcome to the SDK docs!
 
-Cosmos is a decentralized network of independent parallel blockchains, each powered by classical BFT consensus algorithms like Tendermint.
 
-The first blockchain in the Cosmos Network is the Cosmos Hub, whose native token is the Atom. Cosmos is a permission-less network, meaning that anybody can build a blockchain on it.
+![cosmonaut reading the cosmos docs in space](./cosmos-docs.jpg)
 
-Cosmos can interoperate with multiple other applications and cryptocurrencies. By creating a new zone, you can plug any blockchain system into the Cosmos hub and pass tokens back and forth between those zones, without the need for an intermediary.
+## Learn the SDK
 
-## Quick Start
+### SDK Intro
 
-- [Getting started with the SDK](./sdk/core/intro.md)
+If you are a newcomer and would like to learn more about the Cosmos SDK, this **[intro](./intro/README.md)** is a good starting place.
-- [SDK Examples](../examples)
+
-- [Join the testnet](./getting-started/join-testnet.md#run-a-full-node)
+### SDK tutorial
+
+If you like to learn by doing, you can follow the **[SDK application tutorial](https://github.com/cosmos/sdk-application-tutorial)**. It showcases how to build an SDK-based blockchain from scratch, and teaches you about the basic principles the SDK in the process.
+
+## Use the SDK
+
+The following sections contain the information you need if you want to build a fully-functional SDK-based blockchain:
+
+>*NOTE*: We are currently working on improving the docs. Some info might be missing. If that is the case, try the Cosmos [Forum](https://forum.cosmos.network). Failing that, [open an issue](https://github.com/cosmos/cosmos-sdk/issues/new).
+
+- [Introduction](./intro/README.md): Contains introductory high-level material on the Cosmos SDK.
+- [Gaia](./gaia/README.md): Contains all documentation related to the gaia application (current name for the Cosmos-Hub).
+- [Clients](./clients/README.md): Documentation about SDK clients like the SDK Command-Line interface and the SDK Light-client.
+- [Specifications](./spec/README.md): Contains SDK and modules specifications.
+
+If you are reading this on the Cosmos Website, please know that you can find more information on [github](https://github.com/cosmos/cosmos-sdk/tree/develop/docs). Also if you find any issues with the documentation please [*open a Pull Request*](https://github.com/cosmos/cosmos-sdk/compare?expand=1), or at least [*open an Issue*](https://github.com/cosmos/cosmos-sdk/issues/new) to update the docs!
+
+## Join the public testnet for the Cosmos Hub
+
+To install the latest version of the `gaia` application and join the public testnet, **click [here](./gaia/README.md#join-the-cosmos-hub-public-testnet)**
 
 ## Edit the Documentation
 
 See [this file](./DOCS_README.md) for details of the build process and
 considerations when making changes.
-
-## Version
-
-This documentation is built from the following commit:

docs/architecture/adr-002-docs-structure.md

@@ -0,0 +1,94 @@
+# ADR 002: SDK Documentation Structure
+
+## Context
+
+There is a need for a scalable structure of the SDK documentation. Current documentation includes a lot of non-related SDK material, is difficult to maintain and hard to follow as a user. 
+
+Ideally, we would have:
+- All docs related to dev frameworks or tools live in their respective github repos (sdk repo would contain sdk docs, hub repo would contain hub docs, lotion repo would contain lotion docs, etc.)
+- All other docs (faqs, whitepaper, high-level material about Cosmos) would live on the website.
+
+## Decision
+
+Re-structure the `/docs` folder of the SDK github repo as follows:
+
+```
+docs/
+├── README
+├── intro/
+├── gaia/
+│   ├── overview.md
+│   ├── install.md
+│   ├── join-testnet.md
+│   ├── validator-node.md
+│   ├── validator-faq.md
+│   └── delegator-faq.md    
+├── reference/
+│   ├── baseapp
+│   ├── types
+│   ├── store
+│   ├── server
+│   ├── modules/
+│   │   ├── keeper
+│   │   ├── handler
+│   │   ├── cli
+│   ├── gas
+│   └── commands
+├── examples/
+│   ├── basecoin/
+│   └── democoin/
+├── clients/
+│   ├── lite/
+│   ├── service-providers
+├── spec/
+└── architecture/
+```
+
+The files in each sub-folders do not matter and will likely change. What matters is the sectioning:
+
+- `README`: Landing page of the docs. 
+- `into`: Introductory material. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`.
+- `gaia`: Contains all docs related to the `gaia` application. Will later be renamed to `cosmos-hub` or `chub` and probably moved to its own repository.
+- `reference`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`. 
+- `examples`: Contain a couple examples of sdk application like `basecoin` and `democoin`. Developers need to maintain them up-to-date and make sure they compile as the SDK gets upgraded.
+- `clients`: Contains specs and info about the various SDK clients.
+- `spec`: Contains specs of modules, and others.
+- `architecture`: Contains architecture-related docs like the present one.
+
+Website docs sidebar will only include the following sections:
+
+- `README`
+- `intro`
+- `gaia`
+- `reference`
+- `clients`
+
+`architecture` and `examples` need not be displayed on the website. As for `modules`, we might need to think about creating a modules manager, but this is out of scope for this document.
+
+## Status
+
+Proposed
+
+## Consequences
+
+### Positive
+
+- Much clearer organisation of the SDK docs. 
+- The `/docs` folder now only contains SDK and gaia related material. Later, it will only contain SDK related material.
+- Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example). 
+- Easier for developers to find what they need to update in the docs thanks to reworked architecture.
+- Cleaner vuepress build for website docs. 
+- Will help build an executable doc (cf https://github.com/cosmos/cosmos-sdk/issues/2611)
+
+### Neutral
+
+- We need to move a bunch of deprecated stuff to `/_attic` folder. 
+- We need to integrate content in `docs/sdk/docs/core` in `reference`.
+- We need to move all the content that currently lives in `docs` and does not fit in new structure (like `lotion`, intro material, whitepaper) to the website repository.
+- Update `DOCS_README.md`
+
+## References
+
+- https://github.com/cosmos/cosmos-sdk/issues/1460
+- https://github.com/cosmos/cosmos-sdk/pull/2695
+- https://github.com/cosmos/cosmos-sdk/issues/2611

docs/architecture/decision-records/README.md

@@ -1,22 +0,0 @@
-# Architecture Decision Records (ADR)
-
-This is a location to record all high-level architecture decisions in the cosmos-sdk project.
-
-You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t).
-
-An ADR should provide:
-
-- Context on the relevant goals and the current state
-- Proposed changes to achieve the goals
-- Summary of pros and cons
-- References
-- Changelog
-
-Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and
-justification for a change in architecture, or for the architecture of something
-new. The spec is much more compressed and streamlined summary of everything as
-it stands today.
-
-If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
-
-Note the context/background should be written in the present tense.

docs/architecture/decision-records/adr-001-message-counter.md

@@ -1,54 +0,0 @@
-# ADR 001: Global Message Counter
-
-## Context
-
-There is a desire for modules to have a concept of orderings between messages.
-
-One such example is in staking, we currently use an "intra bond tx counter" and
-bond height.
-The purpose these two serve is to providing an ordering for validators with equal stake,
-for usage in the power-ranking of validators.
-We can't use address here, as that would create a bad incentive to grind
-addresses that optimized the sort function, which lowers the private key's
-security.
-Instead we order by whose transaction appeared first, as tracked by bondHeight
-and intra bond tx counter. 
-
-This logic however should not be unique to staking.
-It is very conceivable that many modules in the future will want to be able to
-know the ordering of messages / objects after they were initially created.
-
-## Decision
-
-Create a global message counter field of type int64.
-Note that with int64's, there is no fear of overflow under normal use,
-as it is only getting incremented by one,
-and thus has a space of 9 quintillion values to go through.
-
-This counter must be persisted in state, but can just be read and written on 
-begin/end block respectively.
-This field will get incremented upon every DeliverTx,
-regardless if the transaction succeeds or not. 
-It must also be incremented within the check state for CheckTx.
-The global message ordering field should be set within the context
-so that modules can access it.
-
-## Corollary - Intra block ordering
-In the event that there is desire to just have an intra block msg counter,
-this can easily be derived from the global message counter.
-Simply subtract current counter from first global message counter in the block.
-Thus the relevant module could easily implement this.
-
-## Status
-Proposed
-
-## Consequences
-
-### Positive
-* Moves message ordering out of the set of things staking must keep track of
-* Abstracts the logic well so other modules can use it
-
-### Negative
-* Another thing to implement prelaunch. (Though this should be easy to implement)
-
-### Neutral

docs/architecture/decision-records/adr-template.md

@@ -1,32 +0,0 @@
-# ADR {ADR-NUMBER}: {TITLE}
-
-## Changelog
-* {date}: {changelog}
-
-## Context
-> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. 
-
-## Decision
-> This section explains all of the details of the proposed solution, including implementation details.
-It should also describe affects / corollary items that may need to be changed as a part of this.
-If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
-(e.g. the optimal split of things to do between separate PR's)
-
-## Status
-> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
-
-{Deprecated|Proposed|Accepted}
-
-## Consequences
-> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
-
-### Positive
-
-### Negative
-
-### Neutral
-
-## References
-> Are there any relevant PR comments, issues that led up to this, or articles referrenced for why we made the given design choice? If so link them here!
-
-* {reference link}

docs/clients/README.md

@@ -0,0 +1,18 @@
+# Clients
+
+This section explains contains information on clients for SDK based blockchain. 
+
+>*NOTE*: This section is a WIP. 
+
+## Light-client
+
+Light-clients enable users to interact with your application without having to download the entire state history but with a good level of security. 
+
+- [Overview of light clients](./lite/README.md)
+- [Starting a light-client server](./lite/getting_started.md)
+- [Light-client specification](./lite/specification.md)
+
+## Other clients
+
+- [Command-Line interface for SDK-based blockchain](./cli.md)
+- [Service provider doc](./service-providers.md)

docs/clients/cli.md

@@ -1,8 +1,3 @@
 # CLI
 
-See `gaiacli --help` for more details.
+> TODO: Rewrite this section to explain how CLI works for a generic SDK app. 
-
-Also see the [testnet
-tutorial](https://github.com/cosmos/cosmos-sdk/tree/develop/cmd/gaia/testnets).
-
-TODO: cleanup the UX and document this properly.

docs/clients/lite/getting_started.md

@@ -13,7 +13,7 @@ To start a REST server, we need to specify the following parameters:
 For example::
 
 ```bash
-gaiacli rest-server --chain-id=test \
+gaiacli advanced rest-server --chain-id=test \
     --laddr=tcp://localhost:1317 \
     --node tcp://localhost:26657 \
     --trust-node=false
@@ -22,7 +22,7 @@ gaiacli rest-server --chain-id=test \
 The server listens on HTTPS by default. You can set the SSL certificate to be used by the server with these additional flags:
 
 ```bash
-gaiacli rest-server --chain-id=test \
+gaiacli advanced rest-server --chain-id=test \
     --laddr=tcp://localhost:1317 \
     --node tcp://localhost:26657 \
     --trust-node=false \

docs/clients/lite/readme.md

@@ -16,65 +16,61 @@ maintaining any full blockchain nodes.
 
 ### What is a lite Client
 
-The LCD is split into two separate components. The first component is generic for any Tendermint
+The Cosmos SDK Light Client (Gaia-lite) is split into two separate components. The first component is generic for any Tendermint
 based application. It handles the security and connectivity aspects of following the header chain
 and verify proofs from full nodes against locally trusted validator set. Furthermore it exposes
 exactly the same API as any Tendermint Core node. The second component is specific for the Cosmos
-Hub (Gaiad). It works as a query endpoint and exposes the application specific functionality, which
+Hub (`gaiad`). It works as a query endpoint and exposes the application specific functionality, which
 can be arbitrary. All queries against the application state have to go through the query endpoint.
 The advantage of the query endpoint is that it can verify the proofs that the application returns.
 
 ### High-Level Architecture
 
-An application developer that would like to build a third party integration can ship his application
+An application developer that wants to build a third party client application for the Cosmos Hub (or any
-with the LCD for the Cosmos Hub (or any other zone) and only needs to initialise it. Afterwards his
+other zone) should build it against its canonical API. That API is a combination of multiple parts.
-application can interact with the zone as if it was running against a full node.
-
-![high-level](pics/high-level.png)
-
-An application developer that wants to build an third party application for the Cosmos Hub (or any
-other zone) should build it against it's canonical API. That API is a combination of multiple parts.
 All zones have to expose ICS0 (TendermintAPI). Beyond that any zone is free to choose any
 combination of module APIs, depending on which modules the state machine uses. The Cosmos Hub will
-initially support ICS0 (TendermintAPI), ICS1 (KeyAPI), ICS20 (TokenAPI), ICS21 (StakingAPI) and
+initially support [ICS0](https://cosmos.network/rpc/#/ICS0) (TendermintAPI), [ICS1](https://cosmos.network/rpc/#/ICS1) (KeyAPI), [ICS20](https://cosmos.network/rpc/#/ICS20) (TokenAPI), [ICS21](https://cosmos.network/rpc/#/ICS21) (StakingAPI),
-ICS22 (GovernanceAPI).
+[ICS22](https://cosmos.network/rpc/#/ICS22) (GovernanceAPI) and [ICS23](https://cosmos.network/rpc/#/ICS23) (SlashingAPI).
 
-All applications are expected to only run against the LCD. The LCD is the only piece of software
+![high-level](./pics/high-level.png)
+
+All applications are expected to only run against Gaia-lite. Gaia-lite is the only piece of software
 that offers stability guarantees around the zone API.
 
 ### Comparision
 
 A full node of ABCI is different from its lite client in the following ways:
 
-|| Full Node | LCD | Description|
+|| Full Node | Gaia-lite | Description|
 |-| ------------- | ----- | -------------- |
-| Execute and verify transactions|Yes|No|Full node will execute and verify all transactions while LCD won't|
+| Execute and verify transactions|Yes|No|Full node will execute and verify all transactions while Gaia-lite won't|
-| Verify and save blocks|Yes|No|Full node will verify and save all blocks while LCD won't|
+| Verify and save blocks|Yes|No|Full node will verify and save all blocks while Gaia-lite won't|
-| Participate consensus| Yes|No|Only when the full node is a validtor, it will participate consensus. LCD nodes never participate consensus|
+| Participate consensus| Yes|No|Only when the full node is a validtor, it will participate consensus. Lite nodes never participate consensus|
-| Bandwidth cost|Huge|Little|Full node will receive all blocks. if the bandwidth is limited, it will fall behind the main network. What's more, if it happens to be a validator,it will slow down the consensus process. LCD requires little bandwidth. Only when serving local request, it will cost bandwidth|
+| Bandwidth cost|Huge|Little|Full node will receive all blocks. if the bandwidth is limited, it will fall behind the main network. What's more, if it happens to be a validator,it will slow down the consensus process. Light clients requires little bandwidth. Only when serving local request, it will cost bandwidth|
 | Computing resource|Huge|Little|Full node will execute all transactions and verify all blocks which require much computing resource|
-| Storage resource|Huge|Little|Full node will save all blocks and ABCI states. LCD just saves validator sets and some checkpoints|
+| Storage resource|Huge|Little|Full node will save all blocks and ABCI states. Gaia-lite just saves validator sets and some checkpoints|
-| Power consume|Huge|Little|Full nodes have to be deployed on machines which have high performance and will be running all the time. So power consume will be huge. LCD can be deployed on the same machines as users' applications, or on independent machines but with poor performance. Besides, LCD can be shutdown anytime when necessary. So LCD only consume very little power, even mobile devices can meet the power requirement|
+| Power consume|Huge|Little|Full nodes have to be deployed on machines which have high performance and will be running all the time. So power consume will be huge. Gaia-lite can be deployed on the same machines as users' applications, or on independent machines but with poor performance. Besides, lite clients can be shutdown anytime when necessary. So Gaia-lite only consume very little power, even mobile devices can meet the power requirement|
-| Provide APIs|All cosmos APIs|Modular APIs|Full node supports all cosmos APIs. LCD provides modular APIs according to users' configuration|
+| Provide APIs|All cosmos APIs|Modular APIs|Full node supports all cosmos APIs. Gaia-lite provides modular APIs according to users' configuration|
-| Secuity level| High|High|Full node will verify all transactions and blocks by itself. LCD can't do this, but it can query any data from other full nodes and verify the data independently. So both full node and LCD don't need to trust any third nodes, they all can achieve high security|
+| Secuity level| High|High|Full node will verify all transactions and blocks by itself. A light client can't do this, but it can query any data from other full nodes and verify the data independently. So both full nodes and light clients don't need to trust any third nodes, they all can achieve high security|
 
-According to the above table, LCD can meet all users' functionality and security requirements, but
+According to the above table, Gaia-lite can meet all users' functionality and security requirements, but
 only requires little resource on bandwidth, computing, storage and power.
 
 ## Achieving Security
 
 ### Trusted Validator Set
 
-The base design philosophy of the LCD follows two rules:
+The base design philosophy of Gaia-lite follows two rules:
 
 1. **Doesn't trust any blockchain nodes, including validator nodes and other full nodes**
 2. **Only trusts the whole validator set**
 
 The original trusted validator set should be prepositioned into its trust store, usually this
-validator set comes from genesis file. During runtime, if LCD detects a different validator set,
+validator set comes from genesis file. During runtime, if Gaia-lite detects a different validator set,
 it will verify it and save new validated validator set to the trust store.
 
-![validator-set-change](pics/validatorSetChange.png)
+![validator-set-change](./pics/validatorSetChange.png)
 
 ### Trust Propagation
 
@@ -83,8 +79,8 @@ validator set evolution. Validator set is the foundation of trust, and the trust
 other blockchain data, such as block and transaction. The propagate architecture is shown as
 follows:
 
-![change-process](pics/trustPropagate.png)
+![change-process](./pics/trustPropagate.png)
 
-In general, by trusted validator set, LCD can verify each block commit which contains all pre-commit
+In general, by trusted validator set, a light client can verify each block commit which contains all pre-commit
 data and block header data. Then the block hash, data hash and appHash are trusted. Based on this
 and merkle proof, all transactions data and ABCI states can be verified too.

docs/clients/lite/specification.md

@@ -12,7 +12,7 @@ we need to extract name, height and store root hash from these substores to buil
 Merkle leaf nodes, then calculate hash from leaf nodes to root. The root hash of the simple Merkle
 tree is the AppHash which will be included in block header.
 
-![Simple Merkle Tree](pics/simpleMerkleTree.png)
+![Simple Merkle Tree](./pics/simpleMerkleTree.png)
 
 As we have discussed in [LCD trust-propagation](https://github.com/irisnet/cosmos-sdk/tree/bianjie/lcd_spec/docs/spec/lcd#trust-propagation),
 the AppHash can be verified by checking voting power against a trusted validator set. Here we just
@@ -65,7 +65,7 @@ type KeyExistsProof struct {
 The data structure of exist proof is shown as above. The process to build and verify existance proof
 is shown as follows:
 
-![Exist Proof](pics/existProof.png)
+![Exist Proof](./pics/existProof.png)
 
 Steps to build proof:
 
@@ -92,12 +92,12 @@ the postition of the target key in the whole key set of this IAVL tree. As shown
 out the left key and the right key. If we can demonstrate that both left key and right key
 definitely exist, and they are adjacent nodes. Thus the target key definitely doesn't exist.
 
-![Absence Proof1](pics/absence1.png)
+![Absence Proof1](./pics/absence1.png)
 
 If the target key is larger than the right most leaf node or less than the left most key, then the
 target key definitely doesn't exist.
 
-![Absence Proof2](pics/absence2.png)![Absence Proof3](pics/absence3.png)
+![Absence Proof2](./pics/absence2.png)![Absence Proof3](./pics/absence3.png)
 
 ```go
 type proofLeafNode struct {
@@ -147,7 +147,7 @@ in commitID equals to proof RootHash. If not, the proof is invalid. Then sort th
 commitInfo array by the hash of substore name. Finally, build the simple Merkle tree with all
 substore commitInfo array and verify if the Merkle root hash equal to appHash.
 
-![substore proof](pics/substoreProof.png)
+![substore proof](./pics/substoreProof.png)
 
 ```go
 func SimpleHashFromTwoHashes(left []byte, right []byte) []byte {
@@ -187,7 +187,7 @@ Above sections refer appHash frequently. But where does the trusted appHash come
 appHash exist in block header, so next we need to verify blocks header at specific height against
 LCD trusted validator set. The validation flow is shown as follows:
 
-![commit verification](pics/commitValidation.png)
+![commit verification](./pics/commitValidation.png)
 
 When the trusted validator set doesn't match the block header, we need to try to update our
 validator set to the height of this block. LCD have a rule that each validator set change should not
@@ -198,7 +198,7 @@ validator set update be accomplished.
 
 For instance:
 
-![Update validator set to height](pics/updateValidatorToHeight.png)
+![Update validator set to height](./pics/updateValidatorToHeight.png)
 
 * Update to 10000, tooMuchChangeErr
 * Update to 5050,  tooMuchChangeErr

docs/clients/rest.md

@@ -1,6 +0,0 @@
-# REST
-
-See `gaiacli rest-server --help` for more.
-
-Also see the 
-[work in progress API specification](https://github.com/cosmos/cosmos-sdk/pull/1314)

docs/clients/service-providers.md

@@ -83,7 +83,7 @@ It will display all the available commands. For each command, you can use the `-
 
 ## Setting up the Rest Server
 
-The Rest Server acts as an intermediary between the front-end and the full-node. You don't need to run the Rest Server on the same machine as the full-node. If you intend to run the Rest Server on another machine, you need to go through the [Installation and configuration](#installation-and-configuration) again on this machine.
+The Rest Server acts as an intermediary between the front-end and the full-node. You don't need to run the Rest Server on the same machine as the full-node. 
 
 To start the Rest server: 
 
@@ -109,4 +109,6 @@ The Rest API documents all the available endpoints that you can use to interract
 
 The API is divided into ICS standards for each category of endpoints. For example, the [ICS20](https://cosmos.network/rpc/#/ICS20/) describes the API to interact with tokens. 
 
-To give more flexibility to implementers, we have separated the different steps that are involved in the process of sending transactions. You will be able to generate unsigned transactions (example with [coin transfer](https://cosmos.network/rpc/#/ICS20/post_bank_accounts__address__transfers)), [sign](https://cosmos.network/rpc/#/ICS20/post_tx_sign) and [broadcast](https://cosmos.network/rpc/#/ICS20/post_tx_broadcast) them with different API endpoints. This allows service providers to use their own signing mechanism for instance. 
+To give more flexibility to implementers, we have included the ability to generate unsigned transactions, [sign](https://cosmos.network/rpc/#/ICS20/post_tx_sign) and [broadcast](https://cosmos.network/rpc/#/ICS20/post_tx_broadcast) them with different API endpoints. This allows service providers to use their own signing mechanism for instance. 
+
+In order to generate an unsigned transaction (example with [coin transfer](https://cosmos.network/rpc/#/ICS20/post_bank_accounts__address__transfers)), you need to use the flag `?generate_only`.

docs/examples/basecoin/app/app.go

@@ -6,7 +6,7 @@ import (
 
 	bam "github.com/cosmos/cosmos-sdk/baseapp"
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/basecoin/types"
+	"github.com/cosmos/cosmos-sdk/docs/examples/basecoin/types"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 	"github.com/cosmos/cosmos-sdk/x/auth"
 	"github.com/cosmos/cosmos-sdk/x/bank"

docs/examples/basecoin/app/app_test.go

@@ -5,7 +5,7 @@ import (
 	"testing"
 
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/basecoin/types"
+	"github.com/cosmos/cosmos-sdk/docs/examples/basecoin/types"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 	"github.com/cosmos/cosmos-sdk/x/auth"
 	"github.com/stretchr/testify/require"

docs/examples/basecoin/cmd/basecli/main.go

@@ -7,8 +7,8 @@ import (
 	_ "github.com/cosmos/cosmos-sdk/client/lcd/statik"
 	"github.com/cosmos/cosmos-sdk/client/rpc"
 	"github.com/cosmos/cosmos-sdk/client/tx"
-	"github.com/cosmos/cosmos-sdk/examples/basecoin/app"
+	"github.com/cosmos/cosmos-sdk/docs/examples/basecoin/app"
-	"github.com/cosmos/cosmos-sdk/examples/basecoin/types"
+	"github.com/cosmos/cosmos-sdk/docs/examples/basecoin/types"
 	"github.com/cosmos/cosmos-sdk/version"
 	authcmd "github.com/cosmos/cosmos-sdk/x/auth/client/cli"
 	bankcmd "github.com/cosmos/cosmos-sdk/x/bank/client/cli"

docs/examples/basecoin/cmd/basecoind/main.go

@@ -13,7 +13,7 @@ import (
 
 	"github.com/cosmos/cosmos-sdk/client"
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/basecoin/app"
+	"github.com/cosmos/cosmos-sdk/docs/examples/basecoin/app"
 	"github.com/cosmos/cosmos-sdk/server"
 	"github.com/spf13/cobra"
 	"github.com/spf13/viper"

docs/examples/democoin/app/app.go

@@ -17,11 +17,11 @@ import (
 	"github.com/cosmos/cosmos-sdk/x/bank"
 	"github.com/cosmos/cosmos-sdk/x/ibc"
 
-	"github.com/cosmos/cosmos-sdk/examples/democoin/types"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/types"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/cool"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/cool"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/pow"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/pow"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/simplestake"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/simplestake"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/sketchy"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/sketchy"
 )
 
 const (

docs/examples/democoin/app/app_test.go

@@ -5,8 +5,8 @@ import (
 	"testing"
 
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/types"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/types"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/cool"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/cool"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 	"github.com/cosmos/cosmos-sdk/x/auth"
 	"github.com/stretchr/testify/require"

docs/examples/democoin/cmd/democli/main.go

@@ -16,11 +16,11 @@ import (
 	bankcmd "github.com/cosmos/cosmos-sdk/x/bank/client/cli"
 	ibccmd "github.com/cosmos/cosmos-sdk/x/ibc/client/cli"
 
-	"github.com/cosmos/cosmos-sdk/examples/democoin/app"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/app"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/types"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/types"
-	coolcmd "github.com/cosmos/cosmos-sdk/examples/democoin/x/cool/client/cli"
+	coolcmd "github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/cool/client/cli"
-	powcmd "github.com/cosmos/cosmos-sdk/examples/democoin/x/pow/client/cli"
+	powcmd "github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/pow/client/cli"
-	simplestakingcmd "github.com/cosmos/cosmos-sdk/examples/democoin/x/simplestake/client/cli"
+	simplestakingcmd "github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/simplestake/client/cli"
 
 	sdk "github.com/cosmos/cosmos-sdk/types"
 )

docs/examples/democoin/cmd/democoind/main.go

@@ -21,7 +21,7 @@ import (
 
 	gaiaInit "github.com/cosmos/cosmos-sdk/cmd/gaia/init"
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/app"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/app"
 	"github.com/cosmos/cosmos-sdk/server"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 )

docs/examples/democoin/types/account.go

@@ -5,8 +5,8 @@ import (
 	sdk "github.com/cosmos/cosmos-sdk/types"
 	"github.com/cosmos/cosmos-sdk/x/auth"
 
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/cool"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/cool"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/pow"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/pow"
 )
 
 var _ auth.Account = (*AppAccount)(nil)

docs/examples/democoin/x/assoc/validator_set_test.go

@@ -10,7 +10,7 @@ import (
 	dbm "github.com/tendermint/tendermint/libs/db"
 
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/mock"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/mock"
 	"github.com/cosmos/cosmos-sdk/store"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 )

docs/examples/democoin/x/cool/client/cli/tx.go

@@ -6,7 +6,7 @@ import (
 	"github.com/cosmos/cosmos-sdk/client/context"
 	"github.com/cosmos/cosmos-sdk/client/utils"
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/cool"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/cool"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 	authcmd "github.com/cosmos/cosmos-sdk/x/auth/client/cli"
 	authtxb "github.com/cosmos/cosmos-sdk/x/auth/client/txbuilder"

docs/examples/democoin/x/oracle/oracle_test.go

@@ -10,7 +10,7 @@ import (
 	dbm "github.com/tendermint/tendermint/libs/db"
 
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/mock"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/mock"
 	"github.com/cosmos/cosmos-sdk/store"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 )

docs/examples/democoin/x/pow/client/cli/tx.go

@@ -6,7 +6,7 @@ import (
 	"github.com/cosmos/cosmos-sdk/client/context"
 	"github.com/cosmos/cosmos-sdk/client/utils"
 	"github.com/cosmos/cosmos-sdk/codec"
-	"github.com/cosmos/cosmos-sdk/examples/democoin/x/pow"
+	"github.com/cosmos/cosmos-sdk/docs/examples/democoin/x/pow"
 	sdk "github.com/cosmos/cosmos-sdk/types"
 	authcmd "github.com/cosmos/cosmos-sdk/x/auth/client/cli"
 	authtxb "github.com/cosmos/cosmos-sdk/x/auth/client/txbuilder"