Group-income-simple: Bug: Improve UX of mincome inputs

[sandrina-p]

Problem

Currently, the inputs to insert the mincome don't work correctly for everyone:

• Some inputs only accept numbers up to 2 decimals. But if the currency is BTC, 2 decimals aren't enough.
• In some countries (ex: Portugal) we use a comma instead of dot to write numbers. Currently, we don't support comma (it shows an inline error). On a PT mobile keyboard, it only shows the comma option, so it's impossible to write decimals there.

Solution

Implement correctly the inputs to support all scenarios regardless of the currency or browser.

• It should limit the decimals based on currency (limit TBD, cc @taoeffect )
• It should accept both comma or dots. 10.5 and 10,5 are both valid mincomes.
• Bonus: Improve input usability with inputmode='decimal'. See reference

[sandrina-p]

@taoeffect could you tell how many decimals should Bitcoin have?

[taoeffect]

@sandrina-p let's say we want to send $1, at today's price that's 1/7265.5 = .000138

So let's say 0.00001 will be the lowest amount we'll allow sent. In the future we might switch to mBTC. Here's a handy converter: https://youmeandbtc.com/bitcoin-converter/convert-btc-mbtc-bits-satoshis-usd/

[mmbotelho]

How divisible are bitcoins?
A bitcoin can be divided down to 8 decimal places. Therefore, 0.00000001 BTC is the smallest amount that can be handled in a transaction.

Source

I don't think we should tie this limit to dollars because GI might be used in other countries where the 1$ value does not mean much. For example, in Angola, the minimum wage is around 15,000 kwanzas, which is around $26. So $1 is worth much more there.

I would say that we should stick to the current Bitcoin limit which is 8 decimal places.

cc @sandrina-p @taoeffect

[dotmacro]

For example, in Angola, the minimum wage is around 15,000 kwanzas, which is around $26.

Just to clarify, that's $26/month. ("Minimum wage" in the US is given per hour, so I was confused because $26/hr is >3x the current US minimum wage of $7.25/hr.)

Since Bitcoin has 8 decimal places, it makes sense to allow up to 8 decimal places. But Monero has 12 decimal places... and Ethereum has 18! 😱

Alternatively, the group can change its currency to a smaller unit (e.g. mBTC, Satoshi, piconero, wei, cents, kopecs) so they can work with numbers and units that make sense to them and their situation.

Unless we'll support the max decimals possible (18 is the most I know of), we're making a cutoff somewhere. [5 and 8 both seem like reasonable cutoff points to me, because most [ISO-4217 currencies](https://en.wikipedia.org/wiki/ISO_4217) have 2 or fewer, with max 4.]

[taoeffect]

Hey folks, all of your comments above are spot on, well thought-out.

I have to pardon all of our deliberations here with a brief technical interruption though, because I have just realized that due to technical considerations related to how floating point numbers are stored in computers we actually have to restrict the number of decimals to about 2 anyway.

This means that we will go with the mBTC style approach for each currency we pick, such that the number of decimals should not exceed 2.

[sandrina-p]

Hum... if every other website can do the math with 8 digits (ex: coinbase), why can't we? I'm sure there's some solution out there in the JS world ;)

[taoeffect]

Hum... if every other website can do the math with 8 digits (ex: coinbase), why can't we?

Please see the link I gave for an explanation. I think you may be right that we can go up to say 8 decimal places fairly safely, but the farther out we go the fewer architectures we are guaranteed to support. Some architectures (some embedded systems), don't support decimals at all, but the likelihood that Group Income will be used on them is pretty small.

So... 8 decimal places is OK. Another approach is to use a different level of scale, like mBTC. We definitely cannot support 18 decimal places because as per that link the math even for different versions of the same JS engine starts breaking after 15.

Also, I just created #886 — we need to the ability to propose a change to the currency type.

[sandrina-p]

I believe 8 is enough. It's the decimals max used on coinbase and other crypto platforms.

So, my idea to solve this issue:
Add a new property decimals to each currency at currencies.js and store its respective decimal places limit. Then use it across the mincome inputs to have a correct validation. In the future it can also be used in other places to do any math operation (ex: #887). What do you think @taoeffect?

[taoeffect]

@sandrina-p we already do that sortof... e.g.:

    displayWithCurrency: n => '€' + decimalsOrInt(n, 2),

vs

    displayWithCurrency: n => decimalsOrInt(n, 6) + 'Ƀ',

Note one uses 2 and the other 6.

Yes, I do think that maybe it makes sense to move that constant into a decimalsMax property.

EDIT: OK, I've gone ahead and done that in my PR (which I haven't yet submitted).

[sandrina-p]

When do you plan to submit the PR @taoeffect?

[taoeffect]

@sandrina-p Heh, great question! I'm implementing it as part of the Payments stuff, but if you need it sooner let me know! Payments PR hopefully this week...

[sandrina-p]

This week is okay! I'll be busy with other stuff!