From lf-lists at mattcorallo.com Wed Oct 13 05:13:53 2021 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Tue, 12 Oct 2021 22:13:53 -0700 Subject: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User... In-Reply-To: References: <141bf953-1d49-eab5-5151-a7b8d1937b52@mattcorallo.com> Message-ID: <4e8d682d-341d-e99a-b054-83e424661bed@mattcorallo.com> On 10/12/21 22:08, Andr?s G. Aragoneses wrote: > Hello Matt, can you clarify what you mean with this particular paragraph?: > > But for some reason those pesky users keep wanting to use lightning for tips, or at least accept > payment on their phones without keeping them unlocked with the lightning app open on the foreground > 24/7. > > > So the use case here is more narrow? You mean that the recipient is a mobile user that has his phone > locked? > Just so I understand better what the problem is. Yes, but not just locked, just "doesn't have the lightning app open and in the foreground when a payment comes in". See this paragraph: > ? ? Several lightning apps do this today, and its somewhat of a stop-gap but does help. On > platforms > where the app gets some meager CPU time in response to a notification, this can even fully solve > the > problem by claiming the HTLC in response to the notification pushed out-of-band. Sadly, the refrain > I've heard repeatedly is, these days, on both Android and especially iOS, you can't even rely on a > microsecond of CPU time in response to a notification. The OS fully expects your app to run code > only when its on and in the foreground, unless you're a VoIP app you're screwed. Relying on the > user > to open the app immediately when they receive a notification is...fine, I guess, absent a better > idea it seems like the best we've got today, but I'm not sure you'd find a UX designer who would > *suggest* this :).