The plan would be that this info would be included as a memo/note, yes.

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.

Do you know the service you saw? I can't find anything.

LNURL Auth would be an easy add, will definitely do that.

I'm considering making a service that does exactly this. You could make unlimited lightning addresses that all pointed to a single address. The invoices generated by any of the aliases, or the main address, would be identical.

Not sure if this would help in your case though, if they are blacklisting something in the invoice like your nodes public key (since you aren't using a custodial service where all the public keys are the same), it wouldn't help.

More here #223185

Thanks for the feedback!

For users using a custodial wallet, such as Alby, WoS, right here on SN, etc. All invoices generated by those services contain the same payee public key. So you could certainly link an alias to a wallet service. But there are tens, or hundreds of thousands of users using the popular wallet services.

I'm struggling to find a way to link two invoices, from a custodial service like above, to a single user. Honestly, I'm not very familiar with how accounts work for these custodial services where many users share a single node and whether any user info is included in the invoice. Perhaps they just link the invoice to the user account on the backend, when the invoice is generated, and credit the account when the invoice is paid. @TonyGiorgio, as a wallet developer, do you have any idea?

If anyone else has any insight around that, it would be very helpful!

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!

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.

I haven't seen anything else like this, but it's possible I have missed it. There are services like https://satspay.to/ which allow you to create a lightning address and point it at your own lightning node, but that is quite a bit different than the aliases I have planned.

Regarding Drawbacks: #1: Agreed, we would probably just refer users to a service such as Alby or even Stacker News to get their first lightning address if they did not already have one. #2: I'm still debating internally whether this drawback defeats the entire point of the aliases. If you are using aliases to stay 100% private, any way to pierce that privacy veil, no matter how difficult or theoretical that threat is, is likely a deal-breaker. But if you simply wanted aliases to add a bit of privacy and the ability to use multiple lightning addresses that point to a single wallet, I can see that use case. I'd love more feedback and thoughts on this, to anyone lurking.

I'm just not sure how many people would use the aliases if they were not 100% private, it's probably a pretty big drawback.

I really, really appreciate your feedback @BBitcoinUSA

I will need to look into whether or not I could support lnurl-auth (the flow used to log in with lightning) with my planned approach, I'm not sure that I could.

My focus, initially, at least, would be on aliases receiving payments.

That's good to hear. What would you use lightning address aliases for? Anything that wasn't mentioned above?

Understanding all the potential use cases will help me build a better product if I push forward with this.