📅 Original date posted:2021-10-13
📝 Original message:
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 :).
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 13:04:14
in reply to nevent1q…hxya
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 13:04:14Event JSON
{
"id": "22eef2ec5f37ac91dcad22026675e62895b8a419b868d85b3778b91db7b2b643",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315854,
"kind": 1,
"tags": [
[
"e",
"a45d159e19433c7f6deb510f4e3d721b133919f795d30ba6b0ff4c3a08e6ef97",
"",
"root"
],
[
"e",
"8d0dd7885253b25b5e4df0af374eb688addee949a1fae1fc5f8f985668d205d8",
"",
"reply"
],
[
"p",
"8e5fc86df9a80e0d9988200f4374243d6e385a112063ed34067efb4edf2d802b"
]
],
"content": "📅 Original date posted:2021-10-13\n📝 Original message:\nOn 10/12/21 22:08, Andrés G. Aragoneses wrote:\n\u003e Hello Matt, can you clarify what you mean with this particular paragraph?:\n\u003e \n\u003e But for some reason those pesky users keep wanting to use lightning for tips, or at least accept\n\u003e payment on their phones without keeping them unlocked with the lightning app open on the foreground\n\u003e 24/7.\n\u003e \n\u003e \n\u003e So the use case here is more narrow? You mean that the recipient is a mobile user that has his phone \n\u003e locked?\n\u003e Just so I understand better what the problem is.\n\nYes, but not just locked, just \"doesn't have the lightning app open and in the foreground when a \npayment comes in\". See this paragraph:\n\n\u003e Several lightning apps do this today, and its somewhat of a stop-gap but does help. On\n\u003e platforms\n\u003e where the app gets some meager CPU time in response to a notification, this can even fully solve\n\u003e the\n\u003e problem by claiming the HTLC in response to the notification pushed out-of-band. Sadly, the refrain\n\u003e I've heard repeatedly is, these days, on both Android and especially iOS, you can't even rely on a\n\u003e microsecond of CPU time in response to a notification. The OS fully expects your app to run code\n\u003e only when its on and in the foreground, unless you're a VoIP app you're screwed. Relying on the\n\u003e user\n\u003e to open the app immediately when they receive a notification is...fine, I guess, absent a better\n\u003e idea it seems like the best we've got today, but I'm not sure you'd find a UX designer who would\n\u003e *suggest* this :).",
"sig": "50bf9c0b24ec33221b406394b477a0e7ca82e9ce82775ab1a77317ecdbcaeb2d3c7b694de47c5d64d9619fa531269463c81f4c9a93cd5e42ff171dace4506b9f"
}