-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion] Remove xucli addcurrency <currency>
+ removecurrency
#896
Comments
Agree to the concept. |
Good point. Maybe:
Other calls can remain the same. |
I agree that skipping |
Outdated stats on erc20 decimals distribution: ethereum/EIPs#724 (comment), so not 9X% with 18 decimals like I thought it would be. I'd indeed want to automate fetching all additional info of a token address:
|
I think it is valid to request raiden when adding an ERC20 token. Don't see a problem with that. Also, as far as I recall, Raiden used to provide token information in their token API. This was removed in one of the latest version. We can ask them to put it in so we can query raiden and not geth/parity/infura/etc. But I'm not sure we should touch this at all.... My question was not about the "how to add a pair" but more about - what is still missing in My question now - what is missing in |
We would also need to specify the swap client (between lnd and raiden for now). It seems more complicated and confusing to me to try to combine adding a currency and adding a trading pair into a single call. In terms of UX, this is something that has to be done rarely and only by administrators. But I do agree that the cli command for add pair should use the |
Not crucial at the moment, just like I said. We can go with a manual addcurrency call specifying all these details including swap client for now. In the long run I would want to get rid of "currencies" altogether and just have pairs once we are able to fetch all info from underlying clients. |
ERC20 and also other token standards contain a name and symbol field. We could just read this directly from the full node (e.g. geth) and use it as ticker symbol for the currency instead of asking the user to enter it manually. User can confirm or alter this. Token addresses without name or symbol require the user to enter a ticker symbol name. |
For this xud would need direct access to geth. Something that we don't have
today. Better to ask `raiden` to add this to their token API.
…On Wed, May 8, 2019 at 9:26 PM Kilian Rausch ⚡️ ***@***.***> wrote:
ERC20 and also other token standards contain a name and symbol field. We
could just read this directly from the full node (e.g. geth) and use it as
ticker symbol for the currency instead of asking the user to enter it
manually. User can confirm or alter this. Token addresses without name or
symbol require the user to enter a ticker symbol name.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#896 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACKDI4SIQKEKEBGPJ6FC63LPUMLOJANCNFSM4HGTCM5Q>
.
|
Pls provide estimate for this task. |
This one needs further discussion if that's even possible @engwarrior |
Abstract: How about we get rid of
xucli addcurrency <currency>
and just add a currency automatically whenxucli addpair <base_currency> <quote_currency>
contains a new currency? The same wayxucli removepair <pair_id>
would remove the currency if it's not used anywhere else.Motivation: As @offerm just discovered, it's not too user-friendly to think of the step of adding a currency first before one is able to
addpair
for such. Others will too.Pro: better UX, wouldn't need to change internals, wouldn't need a new
listcurrencies
call.Alternative would be to get rid of the "currency" concept altogether.
PS: I would also want to straighten the the addpair call and command to:
xucli addpair <pair_id> add a trading pair in the format <base_currency>/<quote_currency>
to be consistent with other<pair_id>
commands. At the moment it'sxucli addpair btc ltc
butxucli removepair btc/ltc
Let's agree on sth first, not high prio obviously, see milestone.
The text was updated successfully, but these errors were encountered: