Closed tiero closed 1 year ago
It seems to me 2) goes against?
This allows separating the duty of WHO is packaging & deploying the instance and WHO instead is the market maker using it via clients.
Daemon's configuration is related to deploying the instance, while the market maker uses RPCs.
Instead, I agree with 1). We can add a message like the following to InitWallet:
message FixedAsset {
enum AssetType {
BASE = 1;
QUOTE = 2;
}
string hash = 1;
AssetType type = 2;
}
This way it becomes essential to persist the fixed asset in the db.
could we theoretically allow different combos of markets in the same provider/market?
we can map the bip32 account index to the FixedAsset
ie. map<uint64, FixedAsset> fixed_asset_per_market_account_index = N;
or we can simply delegate user to keep track of the markets? map<uint64, Market> market_per_account_index = N;
I am aware would be a bit of leaky abstraction to expose the account index, maybe we could take the extra step to simply let the user tell us in an array the possible tuple of market combos, and we will scan each account for all possible market combos given.
In v1 we don't have the concept of fixed asset anymore. @tiero can this be closed?
Whats the restore backup file process? I guess we should define that and open an issue after closing this.
Why
The end goal is to be able to allow the operator to totally control his TDEX daemon instance entirely from RPC (therefore GUIs, dashboards) without having to mess with SSH command-line. This allows separating the duty of WHO is packaging & deploying the instance and WHO instead is the market maker using it via clients.
What
Currently, the restore scans for all addresses and uses some constants such as
TDEX_BASE_ASSET
orTDEX_QUOTE_ASSET
to know which asset to be fixed for market discovery.Proposal 1
I propose to pass wither of the two variables ALSO via RPC when user is invoking the
InitWallet
RPC withrestore=true
.This will make sure to override via RPC whatever is set (or not set) via config/env
Propoasl 2
Persist and allow to set/unset the entirety of the
config
via RPC. Maybe this is more future-proof for other things we want to expose to operators' UIs?