Client-side LN address support
A while back we implemented LN receives mediated by third parties (https://github.com/fedimint/fedimint/pull/3820) to support LN addresses/LNURL. While the support is kinda there, there is no standard way for the client to notice such receives and it's left to integrators to figure this out.
I'd like to implement an algorithm that doesn't rely on the third party telling us the number of invoices they generated for us since we last asked, but would rather scan for incoming offers that have to be created for each invoice, so we can even detect unpaid invoices and just start state machines for all of them. If the LNURL server is implemented correctly we don't even need to add a gap limit, but we could do so just in case (and it should also make parallelizing requests easier).
The benefit of this approach is that we don't have to standardize an API between LNURL server and fedimint client, giving us more flexibility to use the same functionality for other use cases.
@benthecarman @joschisan thoughts on that high-level design?
I'm theory I like it, however having to do the scanning client side could be very intensive
I see a few problems with this with respect to bandwidth and DOS. I have thought about it quite a bit and left it to the integrators for those reasons. We should do a call on this. I think that the only proper way to do it is a web socket connection with the lnurl server where we can query for incoming contracts that were created for a given ln address. This seems like the only way to enable minimal latency with efficient bandwidth. Lnurl server should maybe even only send incoming contracts it has seen seen them confirmed for DOS reasons.
If we fetch them via polling we would have to poll every second or so.
If we fetch them via polling we would have to poll every second or so.
We could add an API for subscribing to offers that blocks if an offer doesn't exist yet and returns once it does. Would it still be a DoS concern then?
@elsirion what do you mean by offers?
@joschisan https://github.com/fedimint/fedimint/blob/debbc144022b3fa2cafa73666f305aebf63d3e22/modules/fedimint-ln-common/src/contracts/incoming.rs#L14-L20
Fixed by #6855