Why can you download 2.18.0 Update but not directly from site?

[eddyislame]

[eddyislame]

For example , When I updated Ledger Live to 2.17.1 it asked directly on my desktop application in the past.

It recently did the same with the 2.18.0 Version . I ALWAYS go and double check the main website to see what they are offering to download , then directly from there to verify its the same version I am currently running . BUT on Ledger Live website its only offering 2.17.1 and I also had my friend download his today and they didn't ask if he wanted the 2.18.0 update.

WHY?

[gre]

Our users have experienced some issue with countervalues in 2.18.0, hopefully a temporary issue on back-end side due to the load, but we took the decision to put 2.18 back in pre-reelease until this get resolved.

Thanks

[WXTux]

In v2.18.0 the section on exchange rates has disappeared. Is it intentional or is it a bug?

[gre]

It is intentionally.

previous "direct" paradigm

the previous paradigm was complex to get right, was the cause of many issues, imprecision, and unavailability of rates.
When we worked initially on the paradigm to provide a way to finely configure each exchange to use for each countervalue conversion path, this was to solve the situation of ~2017-2018 where typically some Korean exchange had huge price variation.
Since then the situation has stabilized and there is way less difference. (side note: this is also shown by the fact there are less opportunities for "arbitrage trading").

So after running 2 years into this paradigm of having user's land defining the exchange (which was settled initially a bit arbitrary by taking the last recent volume, which was not always true on the long term), in the end, we found out that that we actually became LESS precise for most of our users (and with holes in our data, creating pikes issue). Indeed, it was also because in this paradigm, we had to use DIRECT pair and each client would configure individually what pair to use for each, we had to go through an intermediary (for instance MANA->EUR would mean configuring for MANA->ETH and ETH->EUR and multiply both – because not a lot of exchange would have MANA->EUR). It's annoying as an UX and also shows imprecision on the big picture.

the new "aggregated price"/indirect paradigm

The new approach is to leverage one single method to fetch the countervalues, independently of any exchanges. So we get a good approximation of what the value of a currency is with "aggregated price". I miss a big the economics fundamental of this approach here but maybe someone from Ledger shall complete this with a blog post.

Essentially from a technical perspective, it's much easier for user (no complex UX to configure and maintain that confirmation), and it was way easier to implement too and drives for better performance.

On client side, we no longer have to deal with calculating the intermediary conversions to go from a given currency to a given fiat. We just ask the server to calc the best path for us.

That also means we have a lot more tokens now supported with this new paradigm.
But also, we can we cover way more fiat currencies now (because we can use FOREX, where before there were no direct exchange to support some fiat VS bitcoin) so we can finally have all the world currency supported:

tradeoff?

Now it's interesting for us to hear feedback about this. On our side, the direction was obvious for both product and technical reasons, but we are eager to know about use case. Were you actively looking at configuring a specific exchange, or what is a reflex due to the trap we created ourselves by introducing the feature in the first place? To us, it appears that for most of our users it would be a big relief to no longer have to deal with this "countervalues problems" and for us to have better quality.

What's next

Now that said, we noticed as I said above some instability that we might have resolved today, but we will be vigilant at double-checking this. Even tho we did our best to anticipate this (beta test way before, internal testing since september) it's hard to simulate the real condition of production environment and various usages of Ledger Live (different timezones, different accounts, different operations side, different countervalues at use).

We have some fixes in the pipe on some issues that might happen too, users might currently need to "clear cache" in case they don't see the full graph (but it's a rarer case).

You may not have noticed it, but in the context of that feature, we also enable "hourly" granularity (when looking in week mode). We will continue in this direction to have better way to see the graph, and the big topic will be to have an "All Time" graph indeed. But also an even more precise graph, maybe a 1D.

We are always happy to hear feedback on what you think should be next.