Creating many custodial accounts is certainly an option and I bet it is what most users do today that are lightning address users and have this privacy concern. My goal with the aliases was to offer an easier path.
Which is easier, having 20 accounts, all with different amounts of sats that you have to log into and log out of. Or having 20 aliases that all send your sats to a single account you are always logged into?
I find the latter much more user friendly, and that's why I built it for myself. If custodial LSPs allowed you to create unlimited lightning addresses that all pointed to 1 account, this would be a moot point. But I haven't seen any that do that, yet.
Taking it from something I built for my own personal use, to a product that is user friendly for everyone is a big lift, and will cost me to run monthly.
If others, like yourself, don't find it useful, that's perfectly fine and I get it. It just means I probably shouldn't waste time productizing it and just keep using my personal version.
I really appreciate your feedback, Tony. It, and the lack of comments from others so far (apart from @BBitcoinUSA) is making me lean towards shelving this project for now and keeping it personal-use only. I'm not sure many would find it useful other than a privacy nut like myself!
If privacy is what they're seeking but they're collecting all those sats onto a single custodian then they're not really going to get much at that point. If it was combined with LNProxy then it would be better. You don't have to touch the sats at all yourself. It's a simple 2 step process. Create normal invoice, then post it to LNProxy and use the returned one. They offer APIs for that. That would allow for easy alias management with invoices that look like they're coming from LNProxy. It would actually be a good offering and something I wanted to build for myself to protect my node identity but still have an LNURL. Just never had the time.
reply
How does LNProxy handle liquidity, fees, etc? The main reason I didn't want to touch the sats was to not inject an additional point of failure for the payment.
I'm looking into LNProxy more, you might have convinced me if there aren't fee, liquidity, or other issues that may cause the payment to fail.
Thanks Tony.
reply