Thanks for the feedback Tony. I'm familiar with LNProxy, but did not want to touch the users' sats if at all possible. I'm going to read up on voltage flow 2.0.
Regarding the payee public key, I think I should have specified that (at least to my understanding) this would only reveal the node, not the user of the node, assuming the user is using a custodial wallet, which I assume most lightning address users are, this may not pierce the privacy veil as much as I implied in the OP.
All invoices I've asked Stacker.news to create have had the same payee pub key, for different users, so perhaps this is less privacy revealing than my original post makes clear.
Someone snooping around may be able to tell that a alias points to a Stacker News user, but would they be able to tell which Stacker News user, based on the invoice? If not, this may be acceptable to many users.
I assume there is some other information in the invoice that may, potentially, be linkable to a user, but I need to do more research on lightning invoice format to get to the bottom of that.
If the main solutions this solves is on the custodian side, then can't the user make a bunch of custodian accounts anyways? It wouldn't really be much different than making a bunch of proxy.ln accounts that point to the same custodian.
Yes, with LNProxy / Flow 2.0, there is someone that touches the sats, but only in terms of forwarding them. They can't take the funds, only the user has the preimage.
reply
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!
reply
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