Thanks. That doesn't answer my question however. If I'm developing an app that needs a lightning wallet baked in, that is, the wallet is only one aspect (albeit the main feature ultimately) where a user needs to send sats to a device (that does something in exchange for small amount of sats), or at a terminal in a shop (think loyalty punch cards except sats is the perk), how do you envision native lightning wallet being part of it? Because, there are ultimately thousands of apps, that could be built in this way, using a flow of sats (small and large amounts), that are just the 'value communication' layer, of what the app (as a product) does, some functionality or other in the app, that requires the flow of sats (instantly), to work. Is there a way to achieve this currently i.e. is there an SDK that can have native lightning support out of the box, where liquidity management isn't something the end user (or the app owner/maintainer/server) has to continually grapple with? The article continually says "you might have well have had opened a channel" as a counter-argument to Ark/Spark, but that's the whole UX/UI issue. We want "normies" to open a new app on their phone, experience the real flow of sats happening instantly, and for them to "get it", not spend a month learning the oddities, of liquidity management / LSPs, paying fees to LSPs, moving onchain bitcoin into the wallet etc etc Can you describe in detail yourself, what exactly such a user normie, is giving up when using Ark/Spark under the hood in an app, especially if they have unilateral exit. Even the OP says that LSP is itself centralisaiton, so if Ark/Spark is also centralistion, the overhead is dramatically reduced when using it, such that the above mentioned apps become viable use cases, with normies.