ack API call improvement

[ilzheev]

According to current documentation of ack call (https://docs.factom.com/api#ack), it seems like you need to know chainID of the entry for get entry information.

I always thought, that I need chainID of entry to get it's status via ack API call, but it turned out, that I don't need to know chainID for it.

Maybe the solution will be:

1. allow to not provide chainid param
2. If no chainid, then use factom.ZeroHash
   In other words, set factom.ZeroHash as default chainid value in case user don't provide it

That shouldn't affect any existing libs & apps, but we definitely may make API simpler:

By default, this API call returns reveal transaction of entry/chain, but you have to specify the type of the transaction for factoid/entry credit txs:

No chainid: for reveal entry/chain
chainid:f for factoid transactions
chainid:c for entry credit transactions (commit entry/chain)

[ilzheev]

I would probably change param from chainid to type and make a refactoring of this function.
We may keep chainid fallback for existing apps/libs, but in updated version we may use
type: {reveal|factoid|commit)

(I haven't dig into code deeply, so it probably won't work, but we may discuss it and explore)

[WhoSoup]

Summarizing what I found in discord:

• the same ack request is used for factoids, ecs, and reveal/entry
• the chain id is only used to determine if the Ack is for factoids (....000f) or entry credits (....000c), see

  factomd/wsapi/ack.go

  Line 129 in d2e5799

  switch ackReq.ChainID {

• the chain id parameter is not even passed to the function that returns the ack for reveal/entry

[PaulBernier]

Slightly different proposal:
having "no chain id" for entry/chains would make that interface asymmetric though which, as developer always in research of beauty, is not very satisfying. What do you think of requiring the chain ID value to be e instead? We would have all the cases consistently handled. (Also the beauty of it is that approach is that it technically requires no code change just updating the doc ^^' )

[ilzheev]

Additionally, I noticed, that deprecated entry-ack call returns more information, than new ack call.

entry-ack includes TransactionDate & TransactionDateString, that reflects the timestamp of entry commit.

So, in my opinion, new ack API call should also include this params and into "commit" ack.

[ilzheev]

We have sent a PR for addition of TransactionDate & TransactionDateString into ack method.
#815

[bombadile]

A proposal for refactoring of ack method of factomd API

This API call is used to find the status of a transaction, whether it be a factoid, reveal entry, or commit entry.
https://docs.factomprotocol.org/start/factom-api-docs/factomd-api#ack

When using this, you must specify the type of the transaction by giving the chainid field 1 of 3 values:

• f for factoid transactions
• c for entry credit transactions (commit entry/chain)
• ################################################################ for reveal entry/chain
  Where # is the ChainID of the entry

The refactoring proposal consists of 5 parts

We need to discuss and find a consensus for each point.

1. When looking for the status of entry, you don't need to specify chainID at all – right now API call works the same when you post EntryHash + ChainID 000…000 / real ChainID / random ChainID. I agree with Paul's proposal to use e into chainId field for ack of reveal chain/entry. We keep consistency and will not confuse developers.

2. Add commitdata with transactiondate into acknowledge of entry/chain reveal.
   I have already sent PR for this: Added of date for data commit entry to endpoint "ack" #815

3. Fix bug with commitdata of entry/chain commit — the entryblock timestamp is returned instead of tx (commit) timestamp;

4. Remove transactiondatestring from all ack API responses as a redundant information;

5. Write a test for function HandleV2ACKWithChain - (endpoint ack don't have a test at all).

New description of API request:

When using this, you must specify the type of the transaction by giving the chainid field 1 of 3 values:

• f for factoid transactions
• c for entry credit transactions (commit entry/chain)
• e for reveal entry/chain

P.S. ################################################################ also works for reveal entry/chain, so existing clients/libs won't be broken. (But you don't have to specify ChainID at all - only if for beauty and understanding of code)

[Emyrk]

I would like to chime in that adding the chainid was intended for future support of this call if lite nodes are introduced. If a node is only tracking certain chains, then it can only respond to an ack call for certain chains.

If you don't specify the chain, the node has no way of knowing if it is missing the entry because it does not exist, or because it is not tracking it.

[ilzheev]

@Emyrk But we still may implement shorthand e for reveal entry/chain (for full nodes) and keep the real chainid (for future light nodes).

That would make API call documentation clearer.

When I used this API call first time, it was confusing for me, that chainid required for reveal entry/chain, but not actually used.

p.1 eliminates this confusion and keeps ################################################################ for future light nodes.