This is interesting. I was thinking along similar lines, but would like to solve the opposite problem. I'm okay running a server, but don't want to link my node id with every invoice. I was envisioning solving this with an invoice bouncer:
Ask a peer node to sign an invoice for you. Add some extra final cltv delta and when the htlc reaches them, they know to forward a final hop to you in exchange for your preimage. This way the node id on the invoice may or may not be the node that's receiving the payment. Fees and payment failures could be tricky, but I'd be much more comfortable handing out lightning addresses if the invoice node id was always correlated to the final recipient in the lightning address. Adoption of BOLT12 could work too.
... of course adding a phantom address to the invoice bouncer solves both the fee and payment error issues.
reply
Your invoice bouncer sounds a little like lnproxy.
reply
Definitely! Thanks for sharing.
reply