Thanks for your insights! Regarding this point, honestly no matter how much I love Lightning, it's one of my biggest issues with it.
I've been looking for solutions (like BOLT12:
https://bitcointalk.org/index.php?topic=5383567.0) for a while now. The interactive element is eliminated (automated) once you run your own full node, but that is really a non-insignificant hurdle, especially for new users.
It's definitely easier setting a friend of family member up with a pure on-chain wallet, pointed to my private Electrum server instance, at least for the start.
But I've yet to fully look through the solutions Grin, Litecoin and others came up with and judge what looks acceptable and what doesn't.
I can answer about Grin. Please correct me if I'm wrong about BOLT12 as I've only skimmed over it. The main concept of BOLT12 seems to be to share information from A to B directly through some hops, in this case by routing over the lightning network.
The first thing to note in a lightning environment is that you must have something online to sign the transfer which I guess in this case is the lightning node. In Grin, we have a Slatepack standard (
https://docs.grin.mw/grin-rfcs/text/0015-slatepack/) which does something similar.
When someone wants to send some coins from address A to B (address is an offchain information) it derives an onion service address from the address and attempts to share the information by trying to communicate with the onion url.
The other party needs to run the listener on the other end by running that onion service so it has a similar online requirement to the lightning network and it hops over Tor rather than the lightning network. This functionality is supported by the wallet.
If it succeeds in finding the service, the two parties exchange the messages over this communication channel, otherwise you receive an encrypted message for that recipient address to copy/paste to them on whatever communication channel you want (yes, manually copy pasting).
I think both LN and Grin are in the process of figuring out which transport methods work best and iterating on these. There will be something better than BOLT12 and there will be something better than Slatepacks, but both are a great start in the right direction.
This sounds very similar to a static LN invoice. But yes, as you noted, BOLT12 doesn't eliminate the need to run an always-online full node with Lightning on top. The interactive element is just automated.
It is obvious how the number of Bitcoin users in relation to the number of full nodes is huge.
And a lot of full nodes may not even hold personal balances as they may be a business node or an Electrum server node serving lots of users (like family members).
I guess it may be worth considering a 'delegation of trust' similar to using a single full node to serve a whole family's SPV wallets; it would require some sort of accounting on the node if this scheme were to be considered for Lightning and / or an interactive privacy coin such as Grin / equivalent Bitcoin upgrade.