makeInvoice and not specifying an amount

[wbobeirne]

BOLT-11 payment requests don't require the invoice to specify an amount, which means clients should be able to create invoices that don't have an amount specified. Right now the interface more or less assumes an amount is going to be provided, but we should try to allow for that not to be the case. This poses a few questions:

• Should clients allow any call to makeInvoice return an amount-less payment request? Or should it be an explicit option?
  • I can imagine there being many applications that don't account for this case, and their code doesn't provide a default amount if one is not provided.
• Should there be an option that requires the client to return an amount-less invoice? Or should it always be optional?
  • Some apps may only function if the amount is unspecified, and would have to reject the user's payment request if it included an amount.

My thought for covering these two cases is to add two new options to makeInvoice:

{
  allowAnyAmount?: boolean; // If true, the client should allow the user to not specify an amount
  requireAnyAmount?: boolean; // If true, all other options are ignored, and client should
                              // only return a payment request without an amount specified
}

But I'm open to any and all opinions!

[Christewart]

Just for some context of other possible use cases, our lapp allows for users to be refunded for market data subscriptions that are not completely consumed.

For instance, if a user subscribes to 60 seconds of market data from the suredbits api, and they want to cancel the subscription after 30 seconds, we will refund half of the original amount paid.

At a technical level, this means the user has to provide us with a refund invoice that has no amount specified, as we can't know at the time of the market data subscription when (or if) they are going to cancel the subscription for whatever reason.

[Christewart]

An example of what a websocket market data subscription request looks like

{
  "event": "subscribe",
  "channel": "tickers",
  "symbol": "BTCUSDT",
  "exchange": "binance",
  "duration": 120000,
  "refundInvoice": "lnbc1pw80c5app58wamf585fnw5h4fagnqc4tf05mv2mvjuz3qvuhgdu9ur6psmmjvqdpl235hqurfdcs8gmmjddjkcun0vaehgctyyq58g6tswp5kutndv55jsaf3xcenz2gcqzysxqyz5vqe8clzl393uhp3m42k98h4we72ceetrsts3pj0h5w9efklltunk7hfv0g8qjv4dtelxnq0cl0l7ejs9we2kwrr5wguf3rnu8uq5q90uqq8ed279",
  "uuid": "f3dd7508-8f50-40b3-be51-5ec853f1a546"
}

and the refund invoice does not have an amount specified.

[wbobeirne]

Thanks for presenting your use-case! Exactly what I'd have in mind for any amount invoices. It seems to me that in cases like that, a requireAnyAmount (does that name make sense? Should it be no amount, or undefined amount?) is a lot more useful than an allowAnyAmount since having guaranteed any amount invoices enables more use cases.

I'll see what this would look like in Joule, and come back with a WebLN pr if it works out!

[juscamarena]

I don't think 0-amount invoices are safe at this point in the current way used, so probably best not to implement this.