BOLT 12: re-add recurrence support.

[rustyrussell]

This is taken from the old draft, and updated with modern field numbers and names.

I've made some minor changes:

1. The proportional_amount field comes before seconds_before which seems more logical to me.
2. The offer_absolute_expiry is clarified to only apply to the initial invoice request: once you're recurring the other fields take over.

The complexities mainly come from two sources:

1. A requirement to be precise about when recurrence happens. This is because we want a push system, not a pull, since only the former allows for real authorization by the user, and there are many different reasonable ways to do recurrence.
2. This is the first wallet feature which isn't just "fire and forget", but requires them to keep state and do unprompted actions.

One proposal I would like to add is a courtesy onion message when a user cancels a periodic payment. This is generally useful to tell the difference between a deliberate cancellation and a user-related failure.

[rustyrussell]

OK, updated. I will need to rework the test vectors, however!

[GBKS]

One proposal I would like to add is a courtesy onion message when a user cancels a periodic payment. This is generally useful to tell the difference between a deliberate cancellation and a user-related failure.

Subscriptions likely require more communication. From the initial sharing of the offer, to price changes, to notifying a user about a missed payment, providing a receipt, etc. Maybe best to leave this type of communication up to the participants to handle in their medium of choice?

[sbddesign]

Subscriptions likely require more communication. From the initial sharing of the offer, to price changes, to notifying a user about a missed payment, providing a receipt, etc. Maybe best to leave this type of communication up to the participants to handle in their medium of choice?

@GBKS I agree that from a UX perspective there is always going to be more communication required between the subscriber and the recipient. However, if there is a protocol-native way to create a subscription, I think there also needs to be a protocol-native way to cancel the subscription.

[GBKS]

However, if there is a protocol-native way to create a subscription, I think there also needs to be a protocol-native way to cancel the subscription.

Maybe. You're creating a subscription proposal, but it's not active until the payee accepts it and acts on it. It's more like a subscription request, like we have payment requests. So if you want a "subscription cancelled" message, you may also want a "subscription accepted" message. But TBH, I don't have a super strong opinion. Just doesn't seem 100% right to exclusively have the cancel message.

[rustyrussell]

Note: @TheBlueMatt pointed out that the correct behavior is to send the courtesy "cancel" message in place of the next request. Slightly more complex to implement (your wallet now needs to remember cancelled subscriptions), but it's a nice balance between letting the vendor know, and not letting them cut you off early. Apparently Apple Pay does something similar, and I can see the logic.

From an implementation POV, this may simply look like a stub invoice_request?

[rustyrussell]

One proposal I would like to add is a courtesy onion message when a user cancels a periodic payment. This is generally useful to tell the difference between a deliberate cancellation and a user-related failure.

Subscriptions likely require more communication. From the initial sharing of the offer, to price changes, to notifying a user about a missed payment, providing a receipt, etc. Maybe best to leave this type of communication up to the participants to handle in their medium of choice?

That, however, has proven to be a centralized disaster, and severely limits interoperation. You cannot automate this unspecified stuff...

Eventually we will probably want offer replacement (where we reject an invoice_request and optionally refers to an updated offer), but one step at a time!

[rustyrussell]

Added the "cancel" flag. You basically send an invreq like normal, but it says "cancel" instead of "send me the next invoice".

Also added the requirement to fetch the next invoice explicitly to the requirements for recurring payments!