also, the receiver only knows the IP address of the request for the invoice, not the lightning node that will originate the payment. using tor to fetch invoices closes this hole too.
what's hard about lightning is the implementations have many design features that make them unstable and the source-routed onion design, like all source routed protocols, suffers from the existence of congestion and dead points in the path. this could also be fixed using atomic multipath redundant onions, but isn't possible unless the message size is increased (8kb is a good size) so that you can add a fork and join operation, and an atomic race-based cancellation of the later arriving sidepaths.
there is solutions, just that nobody with an idea is being paid to build them.
instead, at least this person writing it, is stuck building front end GUIs and supporting adoption of my relay project. i love the relay but i wish i could work specifically on lightning.
between taproot and segwit and the slow progress of lightning to solve the obvious problems i'm getting tired of bitcoin too. not to mention the miner centralization problem and this opens up cooption to state-level actors.