Notes for 2nd wax review meeting

Problems:

1. fromApi (change name to fromJsonFormattedTransaction) takes a json-formatted transaction and makes a structured Transaction object.
2. when constructing a Transaction, the constructor is dynamicly overloaded to take tapos,expiration id or a json-formatted transaction/Transaction? and in the transaction-case any optionally passed expiration date gets ignored.
3. there's also some weird } bracket indentation (maybe everywhere maybe just on this constructor)
4. Encryption requires coder to specify public keys to use and has no "smarts", likely no one should use it now, it needs to be re-designed, but this is low priority I think.
5. Syntax for creating a transaction seems wrong: trx = wax.Transaction.fromapi({jsonformattedtransaction}) a. Transaction appears a get property, seems like a strange way to do it, and of course no setter. This also probably needs to be re-designed (this is probably duplicate of 16 below).
6. Remove build from public interface (if it is needed at all, otherwise just eliminate it entirely).
7. Does fromApi implicitly validate the transaction, if so, why do we have an example that calls validate after? wax\examples\ts\assets\proto_validate_api_response.example.html

      const transaction = wax.Transaction.fromApi(apiData);
      transaction.validate();

8. Why do we have html examples built from our tests? Tests don't make good examples.
9. We have two sets of wax docs (md + wax_docs). Is md form one required to publish the package or put in docker registry?
10. Does createTransaction function still need to exist? (referenced in npm.ts.md) No apparent uses, probably dead code. This is also related to point 16, of course.
11. Does validate happen automatically before I sign a transaction or must it be done explicitly first with a validate call? If so, why in npm example?
12. How exactly are we going to have wax do auto-signing and manual signing (right now we only have manual signing)? This is pending issue, in the sense that we need that code added to wasm first, but this question is more how it is going to work in wax.
13. Review BroadcastTransactionRequest mechanism again eventually (just a note for me)
14. Formatters probably a bad name, they are probably validating parsers (and probably they also support formatting the structured objects that get generated, into forms such as strings). Docs for formatters are useless, to the point I can't fix yet, so I'm asking to clarify my understanding prior to documenting.
15. The code where DefaultFormatter @WaxFormattable transactionFormatter is defined needs documentation.
16. Why did we change from chainApi.createTransaction syntax to chainApi.Transacion syntax?

chainApi = new createHiveChain();
const transaction = new chainApi.Transaction;
const transaction = chainApi.createTransaction();

17. Do we have any tests where we use the new Transaction syntax but without using fromApi? In other words, where we create transactions the way most users will do it?

Encryption specification for wax:

1. By default, all transfer encryption should be done with sender's memo key + recipient of transers.
2. Custom_json encryption should be done based on rules associated with the "real operation" performed by the custom_json. For example, if it is a game operation and the idea is to hide actions by each player until a game is over, so only the game server knows the moves during the game (and only publishes "results" of player moves during the game's duration), the game server could provide an API to the game players to fetch the game's official public key (which players would use to encrypt their moves). After the game is over, the game server would publish the private key for the game to decode all player's moves and prove the game was fair.
3. In addition to default encryption mode that uses memo key, we could allow for specifying a callback object on the api object to determine what key to use based on the operation. Such callbacks could have state, allowing for one-time-use keys, key usage that depends on operation type and fields (e.g. recipient on the transfer), etc. The callback would also support the type of custom_json encryption described in 2, where the callback would examine the custom_json to determine the "game server" and fetch the key to be used for subsequent game moves.
4. The model described above doesn't match well with the existing encryption scheme, where the coder explicitly marks operations in transactions for encryption, so it doesn't seem logical to build this mechanism on top of the existing one.