types: Investigate whether to use tmjson encoding on types shared between node + celestia-core

[renaynay]

We currently have a feature branch feature/api-breaks that will contain several breaking changes to the way some types are encoded in json, introduced by the Eiger team. The purpose of those changes was to ensure parity between the way types shared by node and celestia-core are encoded/decoded.

We currently have some fields (namely inside ExtendedHeader) that are tmjson encoded, so the proposal is just to tmjson the whole struct.

Originally, Preston from sovereign asked for parity encoding for those fields in #1476, referencing https://github.com/tendermint/tendermint/pull/7670/files which actually never ended up in celestia-core.

AFAIU, it seems the one thing that needs to be done to ensure parity between the encoding of types is to string marshal 64-bit integers which begs the question of whether we actually need to use tmjson at all, but rather just enforce string conversion for int64.

---

[cmwaters]

I would advocate that we remove tmjson in core. Modify all JSON struct tags such that any int64 or uint64 (I don't think there's any of these) are represented as strings in json (this should keep parity with how tmjson does it but now we're using encoding/json).

Then I think this rule should be applied throughout for all requests and responses that use the Node's JSON RPC. Do you know @renaynay which methods this would break? i.e. ones that use int64 I imagine?

cc @evan-forbes

[renaynay]

Related:
#3928

[rootulp]

Notes from call:

• Preserve wire compatibility. All int64s returned by API would be strings in JSON serialization.
• Remove usage of tmjson library from celestia-core and celestia-node.
• Does the celestia-node API return any int64s as numbers instead of strings because they would have to break?
  • p2p API has int64s serialized as numbers. Seems tedious to identify and resolve all of those individually. Can we change the JSON serialization library instead?