Improve user experience following hydraw experiment

[ch1bo]

Why

When actually using our own stuff in #189 we stumbled upon many things. Not all of them need to be addressed right now, but we want to put in one round of effort to improve.

What

We might want to split this into multiple tasks, but this is what we collected these things so far:

• Have the TUI to not allow multiple transaction submissions and show a client-side pending status. Introduce a pending state in the TUI #522
  • Based on the API behavior specified here Add a page for API Behavior #513
  • Introduce a Pending state on the client side until we see the expected server outputs, or any of the failure cases: CommandFailed, PostTxOnChainFailed or RolledBack (not definite, but we might need to re-send a client input)
• Optimistic removal of UTxO from the TinyWallet is problematic if an error happens down the line Not update wallet utxo on coverFee #525
• The ping hostnames are overlapping  #538
• Use text envelopes for hydra keys #530
• Disallow initializing heads which will be too expensive to collect/abort (e.g. > 4 parties). #564
  • Hard-coded bound, documented well and communicated to the user (api docs).
• Better error reporting in the TUI when transaction posting fails on chain #531
• Log and send client output when some keys don't match #529
• Extend the TUI (as it is already available on the target) to prepare commit UTxOs and mark UTxOs as fuel
  • Becomes irrelevant if we do Commit from external wallet #215

Out of scope

Requires more details

• Display a HeadId in the TUI
  • This might be a bit more involved, but likely other users will wish for this (we have reports on a Gap analysis where a "Managed Head" solution would be referring to heads by their id, necessarily needing something like this on the API)

Not actionable right away

• Make aborts individual - by changing the protocol of abort to not redeem all, but only "own things".
  • Might impact specification Create updated specification for coordinated head protocol #448, but could be small enough of a change
• Have an index/discovery mechanism to find peers from their cardano verification key
• Share peers connection info between peers

[pgrange]

Lot of time taken to find each others IPs:

• have some sort of index or something to find peers from their cardano verification key for instance
• share peers connection info between peers so that we can find each other quicker

We had several heads initiated in parallel with not exactly the same peers, probably because we had different configuration in each of our nodes:

• we should show the head ID in tui so that we can quickly figure out we're not on the same page
• we should display all init transactions that involve us, not only the ones that involves all the peers that we have in configuration

We lost funds because we tried to initiate a head with too many people, ending with overspend budget errors:

• we should protect the user against opening to expensive hydra head.

[ch1bo]

@pgrange incorporated your feedback into the issue, we ought to prioritize and filter it a bit. Feel free to move your list to the logbook or just keep it here.

[pgrange]

I've logged mode details in the logbook

[pgrange]

Also, when I was trying to setup my own personal docker image, installing cardano-node was straightforward thanks the statically linked binaries available at https://hydra.iohk.io/build/16338142/download/1/cardano-node-1.35.0-linux.tar.gz

I believe it would help if we shared a static binary to the community like what is done with cardano-node.

• share a static binary to the community like what is done with cardano-node. EDIT: this is already tracked in Static Linux binaries #200