client UI and backend: server setting and dialog

[chappjc]

We will need backend methods to change various client settings pertaining to configured DEX servers, and a UI redesign to collect all operations related to a given server.

This would house the existing export/disable buttons, as well as the following new features:

• updating a server's TLS certificate client: support server TLS certificate change #1571
• changing a server's host name e.g. to/from regular internet and .onion Hidden service support for server #1569
• configuring fidelity bond settings such as tier level to maintain, showing a list of active bonds, etc. fidelity bonds foundation - DCR only, no frontend, manual bond replacement #1480

I suggest starting a UI redesign with these things in mind. It will take some time to implement the backend bits described above, so let's just plan on needing a place for them.

[martonp]

I'll start on this as well since I'm working on #1571. I'm thinking to put a settings gear icon next to the server address on the settings page. Clicking the gear will open a new page which will have all the settings specific to that server.

[martonp]

@chappjc I'm looking into updating the server's host name from regular internet to .onion. Currently the host name is used as the identifier in the client to identify the server, and the host name is stored with both the orders and matches. Since the host name can change, the server's public key should be the identifier for a server, and the client db needs to be updated to use the public key as the foreign key in the match/order buckets. So, there must be an upgrade process for the database when the user's upgrade their client. Do you agree with this, or do you think there's an easier way?

[chappjc]

Since the host name can change, the server's public key should be the identifier for a server, and the client db needs to be updated to use the public key as the foreign key in the match/order buckets. So, there must be an upgrade process for the database when the user's upgrade their client. Do you agree with this, or do you think there's an easier way?

Yes, related: Related: #433

In the sense of account recovery, that issue was closed. However, in terms of the client's operation, your assessment is correct that we're keying on the host name when we probably shouldn't.

That said, my feeling is that changing that is not worth the effort and upheaval. Since a host name change can be worked around by disabling the existing account that's keyed by host name A and re-registering (via account discovery and no fee) with host name B as long as they share the same public key, I think there needs to be a strong reason to resolve this the hard way. (As an aside, we should perhaps see what happens when you try to add the same dex with two host names simultaneously, like is possible with dex-test, and see if there need to be any sanity checks to prevent it.)

You could briefly investigate this in case it's not as extensive as it seems. Or if perhaps there's a more compelling reason to go to those lengths.

[martonp]

So there definitely cannot be any active orders when updating the host. I'll investigate more, but that might be the only real limitation. Also, in the user's order history, it wouldn't be obvious that trades that came from the same server were actually from the same server.

I guess it's not that important for now, but is this not the type of thing that is good to fix before a 1.0 release though?