web GUI Lightning Node Connect QR code does not use the mailbox proxy I specified

[AndySchroder]

To reproduce

1. Go to https://localhost:8443/connect
2. Create a new session
3. Custom permissions
4. Advanced
5. Enter https://localhost as the custom Lightning Node Connect proxy server
6. Create a custodial LND account.
7. Go back to https://localhost:8443/connect
8. Show the QR code
9. Scan the QR code
10. https://terminal.lightning.engineering is presented instead of https://localhost

However, litcli sessions list created does show the correct mailbox proxy.

System information

Standalone install on ubuntu

Remote lnd

v0.10.1-alpha, self compiled

[levmi]

If I understand correctly, the use case that you're trying to support here is an LNC pairing phrase that gives access to your web litd instance? Is that correct? If so, I'm not sure that's really properly supported on our side and would love to hear more about the intended use case there.

Also, I think we're conflating a few things here in that case... The custom mailbox proxy is slightly different than what I think you're referencing in that it essentially allows for a developer to run LNC through their own Aperture/mailbox proxy server rather than relying on the default Lightning Labs one (can read more on that here: https://docs.lightning.engineering/lightning-network-tools/aperture/mailbox). That config won't actually change where the LNC pairing phrase is directing users to from a UX perspective, but rather which proxy server the encrypted traffic flows through.

On the QR code side of things, yes, right now, QR codes on litd lead to the Terminal Web experience as that is by far the most popular flow. But, we could explore extending the functionality of the QR codes to lead to other endpoints in the future.

As a final aside, if you specify a custom proxy mailbox server in the custom settings when setting up an LNC pairing phrase, that proxy server will be used even if you're connecting to Terminal Web.

[AndySchroder]

If I understand correctly, the use case that you're trying to support here is an LNC pairing phrase that gives access to your web litd instance? Is that correct? If so, I'm not sure that's really properly supported on our side and would love to hear more about the intended use case there.

Also, I think we're conflating a few things here in that case... The custom mailbox proxy is slightly different than what I think you're referencing in that it essentially allows for a developer to run LNC through their own Aperture/mailbox proxy server rather than relying on the default Lightning Labs one (can read more on that here: https://docs.lightning.engineering/lightning-network-tools/aperture/mailbox). That config won't actually change where the LNC pairing phrase is directing users to from a UX perspective, but rather which proxy server the encrypted traffic flows through.

Lightning Node Connect could be useful for connecting other types of services, it's an interesting protocol, but no, that's now what this issue is about. What I'd like to do is be able to use LNC without requiring the https://terminal.lightning.engineering/ proxy to be used to connect to LND. I'd like to be able to self host the proxy or have other third party options so this doesn't become a centralized thing (which is also some motive for https://github.com/lightninglabs/lightning-terminal/issues/586). Right now this is a service that is subsidized by Lightning Labs, so we don't know if it will be there forever and it seems risky to standardize on a proxy protocol and server that you don't have backup options for.

I do realize the pairing phrase is independent of the proxy, but the client and the lnd/litd instance need to both be expecting to use the same mailbox proxy. Note: I never did install the aperture mailbox yet. I was looking into doing it, but because of this bug and https://github.com/lightninglabs/lightning-terminal/issues/586 the QR code that is generated looks like it won't even send me to a private install if I had one.

There's a lot of words here written by both you and me, but I think this issue is just a super simple problem: you might just have that proxy server address hard coded in your QR code generator since litcli sessions list created seems to show the right proxy servers. As a workaround for this bug, we can manually type in the pairing phrase and mailbox proxy, but it would be better if the QR code were just generated properly (we are not actually locked into a single proxy server, but it just appears that way because your QR code generator doesn't seem to be working properly).

On the QR code side of things, yes, right now, QR codes on litd lead to the Terminal Web experience as that is by far the most popular flow. But, we could explore extending the functionality of the QR codes to lead to other endpoints in the future.

As a final aside, if you specify a custom proxy mailbox server in the custom settings when setting up an LNC pairing phrase, that proxy server will be used even if you're connecting to Terminal Web.

I think our conversation diverged, so not sure exactly what you meant. Just to clarify I'm trying to use LNC to connect to LND, not Terminal Web. Could you clarify your points after reading my other replies here?

[ellemouton]

https://terminal.lightning.engineering/ proxy to be used to connect to LND

https://terminal.lightning.engineering/ is not the proxy. It is just a page that is fetched from our servers and then you can within this page specify the mailbox proxy to be used (which may be your own proxy server).

it won't even send me to a private install if I had one.

You can specify your own mailbox proxy today when creating a session.

QR code were just generated properly

The QR code is generated fine: it just links you to https://terminal.lightning.engineering/ which is not the proxy. It is just a frontend which you can then point to your own proxy server.

[AndySchroder]

Okay, so why do I need to be pointed to https://terminal.lightning.engineering/ by the QR code? It seems like this QR code should contain the relevant information for a Lightning Node Connect enabled client to the mailbox proxy that has been specified when creating the session, but no other unrelated websites.

As discussed in https://github.com/lightninglabs/lightning-terminal/issues/576 , there seems to be some confusion on the purpose of your hosted version of Lightning Terminal. It seems like you might be promoting the use of that hosted version of Lightning Terminal through the QR code, but why do I need to scan a QR code if I'm already on a computer in a web browser? It seems like that should be a simple link and the QR code should be generic Lightning Node Connect pairing information that isn't specific to any particular application.

It is my understanding that Lightning Node Connect is supposed to be a way to make gRPC connections through a proxy server if you need it, and it provides a simpler authentication using PAKE. Your hosted version of Lightning Terminal seems to be a particular application that uses Lightning Node Connect, but you appear to be combining the two together with the purpose of this QR code. Is this correct?

[levmi]

The initial MVP version of using the QR code came from a lot of user feedback about making it easier to connect to Terminal on the web. It's introduction greatly increased the simplicity of making that connection. There really weren't any other use cases for LNC at that time. So, that's why it initially defaults/directs there.

But, it is already the case that the QR code structure is flexible and allows for connections to other applications pretty easily. The QR code just encodes the URL like https://terminal.lightning.engineering#/connect/pair/ZHVtYiBtaXN0YWtlIGxhbXAgY2hlZXNlIGNhYmxlIHNrYXRlIGZpZWxkIHRpZGUgcmV0cmVhdCBtZWF0fHxsbmMuemV1c2xuLmFwcDo0N as a made up example. The relevant LNC pairing data after the backslash is base64 encoded, so applications can ignore the first part of the URL and just use the pairing data. For instance, Zeus does for their connection flows: https://docs.zeusln.app/for-users/connecting-zeus/connect-umbrel. Zeus users scan the QR code presented by litd and are connected to Zeus over LNC. I think that example meets the use case that you're looking for.

That said, we can certainly explore the possibilities around making the QR code more disparate from Terminal Web over time if developers need that. But, if I understand your ask correctly, it's already possible by what's outlined above. Please correct me if I'm misinterpreting though. And, again, I do acknowledge that there is some overlap here which is just a legacy of MVPs of things that likely will need to be cleaned up over time.

[AndySchroder]

So the base64 encoded data includes the pairing phrase and the mailbox proxy server within it? If so, where is the documentation for the structure of that message so that other applications can decode it?

[levmi]

It does, yes. We need to spin up the documentation for that. Will create an issue for it and let you know when we have the docs ready. Thanks for the feedback to get us to push this forward and apologies that the documentation doesn't cleanly exist anywhere already!

[AndySchroder]

Okay, that makes more sense. This does seem like a nice hack you put together because the QR code works to jumpstart you into a normal browser for the terminal web experience before any special software existed that could use LNC.

As good of a hack that it is, it is a bit confusing and misleading of a format to users who may scan the QR code. Say someone doesn't want to use https://terminal.lightning.engineering with their node at all, they may still be hesitant to scan the QR code with other specialized software that is smart enough to ignore that first part. Also, say you do follow through with what you say in https://github.com/lightninglabs/lightning-terminal/issues/576 and make all the features available on a self hosted platform, what QR code format should be used for that case?

[levmi]

Yep, we'd certainly have to cross the QR code flexibility/format bridge when we come to it wrt #576. Understand your concerns and they make sense. We'll explore a few options on our end from quick fixes all the way to what happens in the case of #576.