Gateway APIs for melting external ecash

[otech47]

Would be nice to have a way for the gateway to simply "melt" any ecash without having to instantiate a client & join a federation basically by paying an invoice if ecash is provided. Could work something like this:

1. /deposit
   • params
   • fedimint_ecash
   • secret
   • returns
   • 200 OK: now the secret can be used in the /melt API
   • consider: return the suggested amount for invoice based on fees
2. /melt
   • params
   • secret: from /deposit
   • ln_invoice
   • returns
   • 200 OK: invoice has been paid, melt successful
   • 200: invoice already paid
   • failures
     • could not pay invoice
     • ecash already melted (if a different invoice was paid)
     • payment in progress

[m1sterc001guy]

Why is the deposit endpoint even necessary? Couldn't the melt endpoint just take the fedimint_ecash, reissue it, then immediately pay an invoice afterwards? (as discussed on the call today, this would be a trusted operation)

[otech47]

I think the main problem is we need the ability to retry with a new invoice if the payment can't find a route. If there's a clean way to do that all in one endpoint I think that would work fine? Also the recommended amount on the invoice is a nice perk for UX

Cc @Kodylow

[otech47]

@alexlwn123 any thoughts here?

[alexlwn123]

Why is the deposit endpoint even necessary? Couldn't the melt endpoint just take the fedimint_ecash, reissue it, then immediately pay an invoice afterwards? (as discussed on the call today, this would be a trusted operation)

re: @m1sterc001guy

The main reason to have 2 steps is for fee estimation. Step 1 returns a "suggested" invoice amount (fees deducted), then the user creates an invoice for step 2

Is there any way for the user to estimate lightning fees before asking the mint?

[m1sterc001guy]

I don't think we can guarantee a specific fee amount because we do not control the route that the Lightning node will select. We might be able to estimate it with probing.

Dealing with fees and failures is a good reason though to separate it into 2 steps IMO. Even if we don't estimate fees, as long as there's the ability to retry, the user can retry with a lower invoice amount to manually account for fees.

[Kodylow]

Cashu uses a "fee reserve" where it's supposed to be a minimum at which you guarantee you'll do the payment even if it goes above the fee, we do it similarly with the gateway fee rates and it seems to work relatively well, not sure if we're tracking refund rates anywhere (@elsirion would that be something fmo could do?)