Closed tiero closed 1 year ago
I would still retain the price.macaroon and the external feeder, as advancement deployments can benefit to reuse custom feeder/externa software to push prices.
This only helps solo-operator and "one-shot" deployments, that will only have one single instance anyway
As per RPC, from my experience as "operator" I would say we may want:
we should still have well known asset pairs and automatically bind to symbols (ie. XBT-USDT > L-BTC-USDT)
Not sure the well-known-market thing is a great feature actually. With all the stablecoins that are constantly being minted out there we must then keep this list of well-known assets up-to-date, which sounds annoying from a maintainability POV.
I would just keep it simple and since the operator would still need to provide both source and ticker for a non-well-known market, i think it's better to maintain this also for the well-known ones.
Ref for api-spec and implementation: https://github.com/tdex-network/tdex-daemon/pull/688#issuecomment-1481417016
Logic for managing price feeds, inspired by the management of a market:
No more constraints for now since in a second iteration we will detect market strategy changes via events and make the feeder to properly stop a price feed for a market that has no more pluggable strategy.
Closed by #691.
Since now the daemon doensn't take care of managing the wallet anymore, the idea is that we can extend its scope to market-related operations like those performed currently by the feeder standalone service, ie. forwarding market price feeds taken from a source like for example kraken or bitfinex to the markets opened on the daemon that have PLUGGABLE strategy set.
This means that we can add new RPCs to the tdex-daemon protos in order to replicate the original work done by the feeder and get rid of that service at the same time - we can prevent creating the price macaroon file made, in origin, ad hoc for it.