Send "stable" amount based on fiat currency

[rolznz]

Some people want to send an amount in fiat. If they choose a fiat currency we can do the conversion for each payment. Related to #35

[hvoecking]

I would also be interested in this feature. I'd even attempt an implementation, but I have no experience in this project yet, so no idea how ambitious my approach would be, but if I have some time I'll look into it

[rolznz]

@hvoecking this is difficult because ZapPlanner is designed to work with a budgeted NWC connection. Currently there is no implementation that supports fiat budgeting, which could cause connection to have more (giving ZapPlanner access to more funds than necessary) or less (inability to make the payment).

In order to do this I think either:

• The user accepts to give a larger budget in sats (e.g. 50%) to allow for short-term price volatility - but maybe this is ok.
• NWC budgets support fiat amounts e.g. in Alby Hub. I doubt this will be implemented though as it seems to increase complexity a lot. CC @bumi

[matjaz]

I think first option is enough.

[matjaz]

More important is to get notified of a failed schedule and retry mechanism.

[rolznz]

@matjaz you will get automated emails from Alby Hub as long as you connect your Alby Account, so that should be ok!

[rolznz]

Regarding retries: I think if ZapPlanner fails, it will wait a month before it retries (or however long the normal payment interval is). 🙈

If it fails 3 times, it will stop retrying.

[matjaz]

Connection/friend should receive an notification/email, not node owner.
Maybe add email to friends and family connection.

[jmultanen]

* The user accepts to give a larger budget in sats (e.g. 50%) to allow for short-term price volatility - but maybe this is ok.

* NWC budgets support fiat amounts e.g. in Alby Hub. I doubt this will be implemented though as it seems to increase complexity a lot. CC [@bumi](https://github.com/bumi)

As Matjaz said, the first option should be enough. From a user perspective, if/when they can trust that the sat amount will be defined by the fiat price, higher budget shouldn't be an issue.

There are a couple of issues though: flash crashes (or glitches with the price feed), and short-term dips.

Flash crashes could be solved by using average prices instead of spot prices (averaging from multiple exchanges might not be enough, as arbitrage bots can temporarily spread the crashes from one exchange to others).

If the fiat amount was defined by an average bitcoin price, for example "previous 24h average", then flash crashes would have no effect. Dips would still matter, and it might be annoying if a large monthly subscription hits on a temporary low dip day.

Therefore, I think it would be great to have a "fiat price dollar cost average" as a pricing option. Using a monthly average for monthly subscriptions would solve both flash crashes and short-term dips.

This would mean having three different ways to calculate the sat amount:

1. Spot price according to whatever source (Dangerous! At least some basic sanity checks should be in place.)
2. Short-term average, let's say the previous 24 hours
3. Long-term average price, probably defined by the subscription length, ie. the previous months average price

Having the user decide between these different options is not a great user experience. This adds friction when compared to credit card payments: users don't need to think about these things.

Bitcoin is different though and SOME choice needs to be made. Spot is simple but not great. I think maybe the best option would be for the merchant to suggest a default (with perhaps the subscription length average being the default?), and this could be overridden by the user if they so wish.

Where to get the data? It seems Alby already has API's set up to get the fiat price, so it would only be a matter of keeping track of the prices and calculating the average. Sort of like this: https://www.investing.com/crypto/bitcoin/btc-usd-historical-data (they don't seem to have an API so that's just an example).

I think this is a very important thing to solve, as this would bring bitcoin payments on par with the credit card payments. ZapPlanner already solves a huge issue (lack of pull payments in bitcoin, something that every credit card user is used to), so solving this fiat price conversion seems to be the only remaining technical challenge...