Home

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: https://github.com/FactomProject/factomd/pull/815

3. Fix bug with commitdata of entry/chain commit — the entryblock timestamp is shown 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)