Thank you!
Yes, the fee is tricky. Currently it's set at 0.7% but for small payments that's sometimes not enough to complete the route. This makes the UX worse, but I'd rather not overcharge on fees too much either. I'm thinking now that the right way to do it would be to add an option on the web interface and the api to let the user set the max fee.
Your second point is good but the service is actually quite a bit better than a VPN since the onion routing prevents the lnproxy server from knowing who paid the wrapped invoice. Thus, reconstructing the full payment details would require collusion between the lnproxy server and one of the payment counter-parties. (In the case of a VPN, the VPN provider knows everything: your IP address and the IP addresses of the sites you visit.)
That would be a good way to handle fee, I think trampolines would do a similar thing when that feature gets added to LN. One thing about them and the model you laid out is that you could not guarantee that less of a fee is paid. If a user sets a max fee, that's basically the fee charged to the sender that they probably won't get back if it's actually less than that in practice.
Perhaps you could do JIT route calculations to make it dynamic, or even do a probe to find a route that would work first. Maybe a route doesn't even exist, so you could fail fast and not provide an invoice back to the user at all. Either way, I think it's a great service.
Yeah you have a good point, it's like half of the visibility the VPN has if you want to think of it that way.
reply