> It should be therefore a top priority to make the UX of connecting my
mobile LN client to my home full node extremely easy, so that
centralised services can't improve much on that step. Especially if I
already run a full node.
For what it's worth, this is a main research area for us at Start9 Labs.
> Could someone briefly describe how this UX looks currently? And if it's not as seamless as it could, what blockers are there?
At the root of all of these problems is that a "private server" is considered inconvenient. There is no fundamental reason this has to be the case. The main UX challenges we've found are around installation and configuration of server applications, not to mention, that users don't have an existing mental model for how to imagine applications. Most people who do not work on computers for a living have heard of servers but their firsthand experience with software is "apps". The fact that there is a component of their applications that runs remotely on computers they don't own.
So in short:
1. Educating on the distinction between client and server apps is an open question whose burden will likely fall on the entire industry if we want to get this right and not have an exchange takeover of Bitcoin.
2. Apps that either require "zero configuration" or have very easy in-app walkthroughs of the bare essentials of configuration
3. GUI style installs of server applications familiar to those who have installed desktop or mobile software.
I'm sure there are more things we'll learn as we grow but these are the top three observations we've made and this is our primary area of work.
> Private full nodes serving headers to a handful of weak devices have
been mentioned many times as a good solution against all sorts of
problems in a future full of LN + SPV nodes. I agree.
This is the main thesis I've been going on for a while. Once your full node has synced the whole blockchain and the total set of headers is known, you don't actually even need to carry 100% of the block data, as you can re-fetch a needed block from elsewhere and verify the block data matches the header you've already checked for consensus. From there the header chain can serve as base truth for a whole set of L2+ services or L1 SPV wallets. Ideally, in a model like this, more expensive peer services would be authenticated so that your other applications could get the data they need without exposing your full node to the extra costs of those who are not running their own nodes. Typically we've used Core's RPC API for this but as others have mentioned upthread JSON is a wasteful format and there are good reasons that you'd want Lightning to be able to request peer services without necessarily having ownership control over the node.
The other thing I wanted to note is the fact that the issue isn't that Lightning does SPV, the issue is around whether or not the node it is tethered to is actually trusted since SPV necessarily trusts some dimensions of the information supplied to it. Doing SPV against a full node you own is no more dangerous than indexing watch only addresses in Core and then asking for wallet/utxo information over RPC.
Keagan