Show proposals/validators

[ilblackdragon]

Add an option to query validators from the node:

• proposals
• current_validators
• next_validators

E.g. better output of http post https://rpc.tatooine.nearprotocol.com/ method=query params:='["validators/", ""]' id=123 jsonrpc=2.0 command

From @jimmy3dita :

• As a CLI user, I want to know the per-seat cost, such that I don't risk to stake a too small amount
• As a CLI user, I want to know if my stake transaction was included in the proposals, such that I know that I will become validator
• As a CLI user, I want to know if my "state" is [no stake, proposal, validator, future validator, future kicked out, past kicked out], such that I can plan my actions accordingly
• As a CLI user, I want to know my "rewards" and performance from the last epoch, such that I can easily report my rewards

[amgando]

can you describe the interface?

maybe near <command> <subcommand> [options]

like
near show validators defaults to show all (current and next validators)
near show validators --current shows only current
near show validators --next shows only next
near show proposals shows all proposals

question: any other filters or options to include?

• would it be useful to augment account IDs with more account details?

question: what is useful to show?

• maybe raw JSON because the user wants to copy it somewhere else?
• maybe a table using one of these packages (there are a few table drawing packages) https://www.npmjs.com/package/cli-table

question: what is the returned shape of a proposal?

• response object includes current and next validator account_id, amount in attoNEAR and public_key with curve prefix

---

http post https://rpc.tatooine.nearprotocol.com/ method=query params:='["validators/", ""]' id=123 jsonrpc=2.0

is

{
    "id": "123",
    "jsonrpc": "2.0",
    "result": {
        "current_proposals": [],
        "current_validators": [
            {
                "account_id": "far",
                "amount": "23753072163917273312",
                "public_key": "ed25519:7WwXZVD8TGhj2DGtCPpgQhqcbLN6yB2YgLxW7CGuVWGw"
            },
            ...
        ],
        "next_validators": [
            {
                "account_id": "far",
                "amount": "23785274317909681208",
                "public_key": "ed25519:7WwXZVD8TGhj2DGtCPpgQhqcbLN6yB2YgLxW7CGuVWGw"
            },
            ...
        ]
    }
}

[vgrichina]

I think it's best to just have near validators, near proposals, etc. show command seems redundant.

[amgando]

i disagree on the basis that we're aiming to make it as easy as possible to learn and use our platform.

today there are many related top level commands in NEAR Shell with potential for categorization into a command language that would make it much easier to understand at first glance. the same command language could be reused used throughout our interfaces.

i'm not sure what this looks like exactly, it's more of an intuition at this point. here's a dart at the dartboard

our primitives should be visible to help people learn to "think on our terms" so things like account, transaction and contract should be first class cli language

# account management
near account login
near account create <account> <sponsor> <fund>
near account delete <account> <beneficiary>
near account transfer <fromAccount> <toAccount> <amount>
near account status <account>
near account keys <account> [--new]
near account stake <account> <publicKey>

# contract development and execution
near contract build
near contract deploy
near contract view <contract> <method> [args]
near contract call <contract> <method> [args]
near contract execute <contract> <method> [args]    #(? do we need to surface view / call)
near contract new                                   #(? generate stubs for new contract)

# transaction management
near transaction send <fromAccount> <toAccount> <amount>  #(alias: near account transfer)
near transaction status <transaction>

# system visibility
near show validators [--next]
near show proposals
near show account <account>                         #(alias: near account status)
near show keys <account>                            #(alias: near account keys)
near show network                                   #(output of /status, /metrics and /network_info)

# utility functions
near repl   
near dash                                           #(a fanciful idea i have)

i know that's a lot of work. happy to chip away if it's a welcome effort

[ilblackdragon]

@amgando

Obviously there is no good answer here, but given your (and @damons near/NEPs#31) proposal of grouping near account and near contract commands, wouldn't it also make sense near validators?
E.g. I agree with @vgrichina that extra show seems redundant. Instead grouping proposal/validators and even possibly staking under one group would make sense.

near validators            # current validators & fisherman
near validators next       # next validators & fisherman
near validators proposals  # current proposals, also shows prospective threshold

Especially given you yourself mostly used show as aliases, which IMO is a bad practice ("there should be one way to do thing" https://www.python.org/dev/peps/pep-0020/).

[mikedotexe]

What does the term proposal mean here? I've searched our Slack history and don't understand. This relates to validators?

[bowenwang1996]

@mikedotexe yes you can think of them as the output of staking transactions. When you stake, you essentially send a proposal for becoming a validator.

[mikedotexe]

@mikedotexe yes you can think of them as the output of staking transactions. When you stake, you essentially send a proposal for becoming a validator.

Great, thank you.

[behaviary]

Fixed in #328