Transaction History about lunie HOT 11 CLOSED

Summing up a discussion with Frey:

• There will be no default availability of transaction history
  • Only selected nodes will provide a full history you can query
  • You can setup you own full-node that provides you with the history
    • This appears to be desired so people setup full-nodes...
    • We then strongly need to have a manual selection of the full-node
• You can subscribe to transactions based on sender/receiver
  • You will only get those transactions you are currently subscribed on (no historical ones)
• Identifying use cases
  • Get transactions by sender X
  • Get transactions by receiver X

from lunie.

First proposal for transactions-format (extracted from CardTransaction.vue and extended):
(Please revise critical, as I am a noob on the topic)

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

from lunie.

We'll probably want a height field in there somewhere, possibly in the outer object

from lunie.

That would be the block height of the transaction?
I revised the format.

from lunie.

What about transaction-id and fees?

from lunie.

First look seems okay. Question about multi-input/outputs. Either we support them fully or not at all. The simple form is:

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

which is perfect for one sender and receiver (turned array of inputs into one item).

If we want to support multiple senders/receivers (which is allowed in the app, but not exposed in the ui at all):

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

then we show every transaction that includes this account as any input or any output.

Note: I discussed the indexing with anton, and it seems the indexer doesn't support indexing multiple sender and receivers on one transaction. It might be simple to enforce only one sender and receiver, in the ui and the api. The app supports this since forever, but it is never used afaik. But enforcing only one in the UI would require approval from someone (probably @jaekwon )

from lunie.

I also think we should allow attaching short notes to each tx (data field to be processed by receiver eg. ref number for paying an invoice), but that is not supported in the backend

from lunie.

I vote for the complex format you posted. If it is possible to have multiple in- and outputs (using the cli) this needs to be reflected in the UI somehow or users will miss crucial information.
@melekes is it possible, that the indexer supports multiple senders/receivers in the future or will this never be possible?

from lunie.

@nylira here we discussed the transaction format

from lunie.

that the indexer supports multiple senders/receivers in the future or will this never be possible?

so multiple keys can be indexed

  "sender": "Adam",
  "sender": "John"
}

but there is no way right now to query for both
ideally, we need OR

sender = 'Adam' OR sender = 'John'

or IN

sender IN ('Adam', 'John')

In the future, it will be totally possible to provide complex queries. I am going to push for implementing https://github.com/postgrespro/jsquery format (or a subset), which allows for building complex queries.

from lunie.

All single parts are tested. Waiting for the release of gaia-2-dev network with activated indexing.

from lunie.