SDK Requirements

[faboweb]

• historical transactions
• send/receive in one transactions
• filter by
  • block-height (start and end)
  • limit (default 50)
  • cap by some maximum
• output in JSON
• stream new transactions
  • MVP: refresh button
  • desired: via Websockets
• delegation
  • all candidates

[jbibla]

i think ideally this would link to ticket #'s in the SDK repo... 🌮

[rigelrozanski]

Awesome I will keep this is mind

[faboweb]

Ethan and me aligned on following requirements for the LCD:

The LCD provides following endpoints:
// for wallet transactions
GET /tx/coins/{address of sender or receiver}

// for staking transactions
GET /tx/bondings/delegator/{address of delegator bonding / unbonding}
GET /tx/bondings/validator/{address of validator delegators bond to or unbond from}

// for fee withdrawal transactions
GET /tx/cashout/delegator/{address of delegator}
GET /tx/cashout/validator/{address of validator}

// for proposal transactions
GET /tx/votes/{proposal}

All of those queries take following optional arguments:
minheight, maxheight

Coin-transactions look like this:

[{
  tx: {
    inputs: [{
      sender: String,
      coins: [{
        amount: Number,
        denom: String
      }]
    }],
    outputs [{
      receiver: String,
      coins: [{
        amount: Number,
        denom: String
      }]
    }]
  },
  time: DateTime,
  height: Number
}]

Tags to index those are:
coin.sender, coin.receiver, tx.height

Bonding-transactions look like this:

[{
  tx: {
    type: "bond" | "unbond",
    validator: String,
    address: String, // of delegator
    shares: Number
  },
  time: DateTime,
  height: Number
}]

Tags to index those are:
bond.delegator, bond.validator, tx.height

Cashout-transactions look like this:

[{
  tx: {
    address: String, // of validator
    receiver: String,
    outputs [{
      address: String,
      coins: [{
        amount: Number,
        denom: String
      }]
    }]
  },
  time: DateTime,
  height: Number
}]

Tags to index those are:
cashout.delegator, cashout.validator, tx.height

We probably need as well:

// for proposals
GET /proposals?status='active'|'closed'

// TO BE DEFINED

// for candidates
GET /candidates

Candidate-records look like this: (extracted from Spec)

[{
  address: String,
  owner: String, // address
  shares: Number,
  votingPower: Number,
  since: DateTime,
  description: {
    name: String,
    website: String,
    details: String
  },
  commissionRate: Number,
  commissionMax: Number,
  status: 'active' | 'bonding' | 'unbonding',
  slashRatio: Number,
  reDelegatingShares: Number
}]

Let me know what you guys think. @mappum @nylira @jolesbi @ethanfrey @rigelrozanski @melekes

[melekes]

Tags to index those are:
coin.sender, coin.receiver, height

should not it be tx.height?

[rigelrozanski]

@faboweb there is no commission min (min no commission!)

[mappum]

Was there any discussion around a websocket API to subscribe to new transactions for the types of filters we listed?

[faboweb]

@mappum bucky said we get it. So I think we can annoy people until it is there.
@rigelrozanski I removed min commission, thx for the hint
@melekes I updated all the height labels to tx.height

[ebuchman]

You can subscribe to the filters via Tendermint websockets. What's the best way to proxy that through the LCD to the UI ?

[mappum]

You can subscribe to the filters via Tendermint websockets. What's the best way to proxy that through the LCD to the UI ?

Would be cool to have a LCD websocket proxy that verifies proofs for every tx emitted from the upstream Tendermint full node. But until then, the UI could get the txs from Tendermint WS, and just use a LCD REST endpoint to verify the tx is in a block.

[jbibla]

@faboweb @mappum i think it would be good to close this "issue" and make actionable tickets for the outcome of the conversations here...

[faboweb]

Linked this in the open issues regarding the topics.