trustory / truchain Goto Github PK

• genesis accounts
• story categories

This file is loaded before the chain is started, and can be used to initialize / bootstrap new chains.

Cosmos removed the init command by default, so now we have to manually at it to truchaind. Without this, we can't generate a genesis file and start the chain.

Retrieves a story given an ID.

Thoughts:

Queriers for a list of stories don't need all the story data, maybe just the body, creator, and some metadata. Might be useful to have a stripped-down story type for these.

This query however will retrieve all story data for the detailed story view.

• Rename StartChallengeMsg to something less ambiguous, since "start" can imply starting the challenge and validation game. It is inactive until the stake is met. Maybe InitiateChallengeMsg?

• Give expiry queue its own KVStore instead of living in the “challenge” keyspace. Currently keepers are built around one main store key. Make them more flexible to handle more than one store keys.

• Make separate KVStore for Challengers? This will make them more available to future entities like user profiles. Currently they live at "challenges:id:[ID]:userAddr:[0x...]"

• Delete old challenges and rely on immutable KVStore or keep them around? Currently we are deleting, but we want to make historical challenges easy to access. Make sure challengers are also deleted with a challenge if we go that route.

• refactor all types to take a user id instead of sdk.AccAddress because the user's public key can change due to key recovery

From whitepaper:

The conversion price from TruStake to category coins is determined by the measure of the health of the category. The health of a category is measured using:

Total coins users have staked on stories in the category
The rate of new coins being staked on stories in that category
The rate of new coins being staked on stories across all categories
Total coins in the category (across all users in category)
Number of accounts with category coins in the category

HTTP API needs to implement the following GraphQL resolvers:

• Account
• -> Submissions
• -> Votes
• -> Bonds
• -> Challenges

• Story
• -> Votes
• -> Bonds
• -> Challenges

• Vote
• -> User
• -> Story

• Bond
• -> User
• -> Story

• Challenge
• -> User
• -> Story

• Feed
• -> Stories
• -> Pagination

• update types
• implement messages
• validate min/max bonding period
• move story actions (vote/back) to story keeper
• implement keeper
• implement handler
• conversion of backed trustake to category coin
• implement backing queue
• implement interest logic
• check math precision in interest logic, use sdk.Ratinstead?
• write backing tests using new sdk.Dec library
• make 1 cat coin = 10^x sdk.Int
• validate backing params in Msg handler (including coin balance?)
• handle backing with category coins + trustake
• move common testing functions into it's own place so they can be shared
• handler tests
• test terminal case of processing backing queue by changing block time

• create new story on each block
• load stories from CSV file
• create user

Thinking of doing this after we have an API. Can create a Paw project that populates the DB. Then we get API integration tests for free along with it.

I reverted #48 because:

• master wasn't compiling

• 26 commits were added since the last person approved the PR, with over 2,000 new files

• lots of library code was checked in, including multiple node_module directories and binary artifacts (also it seems these should be in their own repo, since we decided against a monorepo for now)

Library code and binaries should never be checked in and it bloats up the repo. I'm going to fix the history to remove them. Let's fix the issues with this feature and do another PR that includes all additional commits. Then lets make sure CI tests pass (CircleCI is working now), and ignore any library code in .gitignore.

HTTP API needs to support the following presigned message types:

• SubmitStoryMsg
• BackStoryMsg

Branch: WIP-go-mod.

Not currently supported by cosmos-sdk. Switch after they switch.

cosmos/cosmos-sdk#2253

Have it working all the way until it uploads to codecov in branch bug53. Works locally, just not in a CircleCI container.

To run locally:

bash <(curl -s https://codecov.io/bash) -t cac96896-60bf-49d5-8690-bf6e6509dbad

To run in a CircleCI Docker container:

circleci local execute --job test_cover

AFAIK I'm setting the environment variable correctly. But it doesn't work even if I hardcode it in config.yml.

Error:

====>> Upload to codecov.io
  #!/bin/bash -eo pipefail
bash <(curl -s https://codecov.io/bash) -t $CODECOV_TOKEN

  _____          _
 / ____|        | |
| |     ___   __| | ___  ___ _____   __
| |    / _ \ / _` |/ _ \/ __/ _ \ \ / /
| |___| (_) | (_| |  __/ (_| (_) \ V /
 \_____\___/ \__,_|\___|\___\___/ \_/
                              Bash-0b37652


==> Circle CI detected.
    project root: .
    Yaml found at: .codecov.yml
==> Running gcov in . (disable via -X gcov)
==> Python coveragepy not found
==> Searching for coverage reports in:
    + .
    -> Found 1 reports
==> Detecting git/mercurial file structure
==> Reading reports
    + ./coverage.txt bytes=15419
==> Appending adjustments
    http://docs.codecov.io/docs/fixing-reports
    + Found adjustments
==> Gzipping contents
==> Uploading reports
    url: https://codecov.io
    query: branch=bug53&commit=8fe3b184eeb1a3b52371c44aa018d6e94c53158c&build=&build_url=&name=&tag=&slug=%2F%2Fgithub.com%2FTruStory%2Ftruchain&service=circleci&flags=&pr=&job=0
    -> Pinging Codecov
    -> Uploading
    X> Failed to upload
    -> Sleeping for 30s and trying again...

• use sdk.List (or create a key-value list) to store list of stories instead of an array of ids

This way it'll be possible to query a story in O(1), while still being able to iterate over a given subspace using a range query.

• integrate with Github
• enforce go fmt
• enforce go lint
• run unit tests

https://github.com/cosmos/cosmos-sdk/blob/develop/.circleci/config.yml

Two options:

1. setup a tmp GOPATH and pull in all dependencies
2. vendor dependencies

Probably best to wait until #13 is done.

There'll be better separation of concerns and make the app more modularized.

Something like:

x/backing
x/category
x/challenge
x/profile
x/story
x/vote
x/wallet

• x/story
• x/category
• x/backing
• utils for common functionality
• re-wire app
• delete x/truchain
• update README

Running into issues because of cosmos/cosmos-sdk#1081

Our dAppChain gives TruStory users openness, transparency, and censorship-resistance because the state machine is being validated by a distributed set of nodes. The cost of this to the user is a small fee per transaction.

CosmosSDK allows us to incorporate this functionality into our dAppChain via the StdTx (which is what we use to wrap a Msg with a Fee and Signatures).

Let's start implementing a small fee for the following mutations:

1. create story
2. vote on story
3. back a story
4. challenge story

For adding evidence and adding comments, we can set the fee 0 for now.

All fees must be paid in TruStake.

An enum gives us type safety, and methods to operate on the enum, but also prevents dynamically adding new ones.

Is there a way we can have both?

// StoryCategory is a type that defines a story category
type StoryCategory int

// List of accepted categories
const (
	Unknown StoryCategory = iota
	Bitcoin
	Consensus
	DEX
	Ethereum
	StableCoins
)

// IsValid returns true if the value is listed in the enum defintion, false otherwise.
func (i StoryCategory) IsValid() bool {
	switch i {
	case Unknown, Bitcoin, Consensus, DEX, Ethereum, StableCoins:
		return true
	}
	return false
}

// CoinDenom is the coin denomination for the category (trubtc, trustablecoins, etc)
func (i StoryCategory) CoinDenom() string {
	return "tru" + i.Slug()
}

// Slug is the short name for a category
func (i StoryCategory) Slug() string {
	return [...]string{"unknown", "btc", "consensus", "dex", "eth", "stablecoins"}[i]
}

func (i StoryCategory) String() string {
	return [...]string{"Unknown", "Bitcoin", "Consensus", "Decentralized Exchanges", "Ethereum", "Stable Coins"}[i]
}

https://blog.learngoprogramming.com/golang-const-type-enums-iota-bc4befd096d3

• use iterator to return list of stories
• create queues for each category or see if there's another way to do advanced queries
• create category key categories:id:5:stories -> [int64, int64, etc.]
• getter in keeper for getting stories by category
• test to get a 100 fake stories
• add new errors
• add sdk.Querier
• querier tests
• wire querier to app
• refactor: add GetCodec() to base keeper

• getter for amount staked by backers
• check if challenge amount meets this threshold, or MIN_CHALLENGE_STAKE if there are no backers
• add tests

• source
• evidence
• argument

• types
• keyspace design and README
• keeper crud
• add list for all votes on a story
• make app.List type?
• make Game it's own module (#100)
• refactor types (Backing and Challenge are just specialized Votes, embed Vote)
• figure out how to do commit-reveal voting, don't want validators to see votes
• move queue inside existing KVStore
• add back expiry queue checker
• errors
• tests

Currently keepers are built around one main store key. Make them more flexible to handle more than one store key.

Make folders for:

• types
• db

etc.

• read about Cosmos key management
• create a new account in AccountMapper
• add fields to AppAccount

As part of the effort to document our architecture, there should be something in our README that describes how the API works, how to run tests for it, makes some reference to Paw, describes the client, etc.

/github.com/tendermint/iavl/proof_range.go:368:6: lastDepth declared but not used vet: typecheck failures

• message (vote true/false, etc.)
• handler
• wire up app
• errors
• tests

There were some errors in checking for expiring challenges. They weren't caught in tests, so have to make sure #44 adds a test for it. Should be able to do this in app_test.go without running the actual chain.

Having New* constructor functions for every data type is very verbose. The type checking on initialization is nice, but it litters the code with excessive boilerplate. Also the pattern of having two functions named like NewStory(), one to create the type and another as a method instance on keeper, is confusing.

Use composite literals instead. We still get type checking on initialization. Can use fillstruct tool to create defaults if needed. Less code. I think it's cleaner.

This will help with separation of concerns since we will use GraphQL for reading and REST for mutations.

Add all dependencies in vendor for ease of development and deployment.

cosmos/cosmos-sdk#2253 (comment)

So we can do something like:

trucli categories new --title "bitcoin" --slug "btc"

• create trucli command line client using Cobra
• parse title and slug to create NewCreateCategoryMsg
• build tx and broadcoast
• create user/key

A keeper is a wrapper around the key-value store of Cosmos to read and write to the DB.

A handler takes a Msg and accesses the keeper to save or retrieve some data, a story in this case.

Implement both of these for creating a story.

https://circleci.com/gh/TruStory/truchain/46

This is why checks are running so slow and not getting reported.

Option A: Implement it for Cosmos SDK and get PR approved:
cosmos/cosmos-sdk#1980

Option B: Build our own bank module that routes through x/bank but keeps track of metadata like total supply in KVStore

HTTP API needs to implement the following response headers:

• X-Cosmos-Account-Coins
• X-Cosmos-Account-Sequence

Need to figure out what properties make a story trending.

• trending story queue
• endblocker to process trending queue (i.e: add new stories, delete non-trending ones, and move stories up/down)

• keeper getters needed for queries
• queriers

• challenge module scaffold
• types
• keeper
• abstract marshaling up a level
• challenge message (with evidence, etc)
• handler
• mutate story.state
• querier for getting all challenged stories for a certain category
• querier for feed with challenged stories first first
• errors
• codec
• challenge tests
• tests for stuff added to x/story
• add MIN_CHALLENGE_STAKE param
• add reason
• add users, since multiple users can challenge
• logic for new types
• add challenge id to story
• keeper refactor (move storeyKey up to base keeper, provide getters)
• check threshold and start game
• add challenge period
• upgrade dependencies to latest versions and make any necessary changes
• challenge expiry queue (abstract out queue and share with modules?)
• challengers should be stored as {addr: coin} pairs to allow for challenging with different amounts (as a bonus it should fix task below as well if implemented as map)
• prevent same person from challenging more than once
• end blocker to refund challengers if game isn't started in a certain amount of time (10 days)
• bring package test coverage up to at least 80%
• update challenge msg and handler
• run both backing and challenge end blockers, collecting tags

• Dockerfile: install dependencies
• Dockerfile: build truchaind
• Dockerfile: mount data directory
• Setup deployment to EC2 via AWS ECR: https://circleci.com/blog/aws-ecr-auth-support/
• Update config YML: https://circleci.com/docs/2.0/ecs-ecr/