Webook for receiving payments

[roeierez]

This feature set the basis of the ability to receive funds when the user node is offline.
Event though lots of the end users nodes are operated from mobile, we can't use mobile notifications directly as there are multiple apps involved and the LSP doesn't have the certificates

An optional flow when there are already channels:

1. LSP receive htlc to forward.
2. LSP detects the channel to forward is not active.
3. LSP notifies the webhooks associated with this channel.
4. LSP waits a certain time for the channel to be active, then forward the htlcs.

An optional flow when there is no channel:

1. LSP receive htlc to forward.
2. LSP needs to open a channel but the peer is offline.
3. LSP fetch the webhook associated with the registered invoice and notifies it.
4. LSP waits a certain time for the channel to be active, then forward the htlcs.

[JssDWt]

Some thoughts of things to build:

• endpoint for registering webhook subscriptions
• table to store the relation node id/webhook
• maintain a log of published notifications (for diagnostics/support)
• mechanism to remove webhook subscriptions by expiry and/or when the webhook call fails
• usually some retry mechanism is useful when interacting with third party services (so webhook data needs an identifier for deduplication?)
• could be useful to send an initial 'subscribed' notification when ready.
• the time when waiting for the channel to be active is interesting, especially regarding restarts of lspd/the underlying lightning node.

[roeierez]

Nice points @JssDWt !

• mechanism to remove webhook subscriptions by expiry and/or when the webhook call fails

I think at the LSP level expiry is enough. Only the actual delivery service has feedback on whether the hook is delivered or not.
We can require the delivery service return that feedback backwards but might be too much IMO (especially because of the async nature of such service).

[JssDWt]

I think at the LSP level expiry is enough. Only the actual delivery service has feedback on whether the hook is delivered or not.
We can require the delivery service return that feedback backwards but might be too much IMO (especially because of the async nature of such service).

I was thinking about the case where the LSP calls the webhook, but the call is not successful (non-200 statuscode). I agree there is no way to determine delivery all the way to the client from the LSP point-of-view. If the Notification Delivery Service receives it, that's enough.

[JssDWt]

Fixed in #88
Followup in #103