allow me to do everything at https://localhost:8443

[AndySchroder]

When I go to https://127.0.0.1:8443 it says "In the web based Terminal experience, you can expect new features like: Visually focused loop experience with Autoloop built-in." and "Easily monitor routing activity and manage your channels through the dashboard.". If I'm already connected on localhost, why do I need to go to a third party website to do this? For one thing, it seems confusing to segregate features for no apparent reason. Also, it seems like a privacy invasion, even if you say at https://terminal.lightning.engineering/connect/pair/ that Lightning Labs can only see the size of data packets and if the node is connected. Seems like you can also see where my node is, when I use lightning terminal, etc..

Lightning Node Connect is a cool feature, but I don't know why it's required to see additional features.

[levmi]

Hi Andy, thanks so much for the feedback! As always, it's greatly appreciated. And sorry for the delayed response due to the US holiday! This feedback is especially helpful as we're in the middle of some conversations about how to move forward with the self-hosted Terminal UX. I'll go into detail below about why the current setup exists, but in case you're not interested in the full explainer, I'll provide a quick TLDR.

TLDR: We're actively exploring backporting some or most of the functionality of the web-based version of Terminal to the self-hosted version. It's a non-trivial amount of work, but we're leaning towards that path, mostly based on feedback like yours.

The relevant history is that after countless user interviews and feedback from node operators, we moved forward with a web-based solution for node management in an attempt to make managing a node more accessible, simple, and straightforward. Web development also allowed for us to move a bit quicker and give everyone the latest and greatest at the same time. terminal.lightning.engineering is a UI interface that LL quickly improves (without requiring users update their litd binaries) which communicates with user's machines running litd. If a user doesn't have an internet connection ( to access the terminal.lightning.engineering UI ) or doesn't want end-to-end encrypted traffic pass through LL's servers to their own node, they have the option to use the HTTP server in litd which we haven't been actively updating (but as mentioned above, that could change soon). It's always been a delicate balance of extending features for node's self-sovereign operational mode but delivering a UX that's on par with traditional web2 experiences.

In summary, historically, it was not trivial to keep both experiences updated with a bunch of new features. It was more of a resourcing question for us along with a strategic question whereby most users felt like a web-based experience would be more useful for their needs. However, as of late, we've heard more feedback around this and we feel like we have a path forward on a backport that wouldn't require a huge amount of resourcing so keep an eye out as we'll likely begin work on that this summer.

[AndySchroder]

Actually, this may be a duplicate of https://github.com/lightninglabs/lightning-terminal/issues/556 .

Generally, I understand your desire to rapidly evolve the GUI on a hosted server. That service has some value for people who don't have a static IP address, but I don't see why we need a hosted server to have the features and it's also just really confusing to people (especially people who are setting up their node for the first time), especially if they only want to manage their lightning node from home. If you want to provide features first on your hosted server (for QA testing and also as a perk of using your hosted services), that might make sense, but I would only do that for a few weeks until they are proven and then push the changes to litd so everyone can use them. Right now it appears as though you aren't just behind pushing changes to litd, it seems like you have two completely different applications.

If you provide people an option to opt out of your hosted services, they will trust you more than if you make it mandatory.

[AndySchroder]

Another thing that makes it really confusing is when you initially go to https://localhost:8443, the upper 50% of the screen implies that you must use the hosted server, then the lower 50% you are confused with something better you might get out of using the hosted server but because the sidebar on the left is collapsed you don't even know where to find those basic features you can currently get on https://localhost:8443 without poking around on every button until you figure it out.

[levmi]

Yes, it is a little bit of a duplicate of #556 and I pulled some of the responses from there into my initial response here. To be clear, it's not that we necessarily need the web architecture for certain features. It's just, in our initial user interviews in starting to push to resource the Terminal project, most of our interviewees indicated a strong desire for something like the web experience. Then, the practical reality is that we do have limited resourcing for the Terminal team overall. So, we made an initial decision to prioritize web given the gains it gave us from a speed, iteration, and consistency perspective (consistency here meaning being able to ship new features on top of older binaries rather than requiring binary updates to get the latest features).

Given this feedback and #556, which is good feedback and accurate, I do think we're clearly reaching a point where there's a strong desire for the feature set that exists on web in the locally hosted version. And, like you mentioned, a more consistent experience across both mediums would be best. As a thought exercise, IMO, if we started with split resourcing on web/local version with continuous updates for the latter, then we would've lost a good chunk of development time and I don't know if we would have been able to iterate with user feedback as quickly. Thus, we may not have even gotten to the point we are now where there is this pull demand for that feature set in the locally hosted version. So, I view it as an exciting opportunity that people really want those web features and are pushing us to backport those into the local version.

All that said, given this feedback, we have been actively exploring a path forward for a backport of the web feature set to the locally hosted version. But, not just a backport, our current favorite path forward would create an architecture that would allow for continuous updates on both user experiences in parallel. As you suggested, the local version would still lag behind slightly, but mostly due to the binary release/update cycle. We're prioritizing this path forward over the summer and should have something to address this in the fall. Again, really appreciate the feedback and thoughts here as it definitely helps us prioritize resourcing for the path forward.

For your second comment above, I see what you're saying and it wasn't our intent to signal that you must use the web version. I think we can improve the copy to make it more clear that some subset of the features still exists on the local version.

[AndySchroder]

All your points sound fairly valid from a development perspective.

So, one thing you may want to choose a different name besides "web version". To me, the local instance can be exposed on the web too, so that gets confusing. Might be better to call it the hosted version.

One thing to note: I've never actually tried your hosted version so I don't even know what I'm missing (well, I might have popped it up for a minute when I was exploring someone else's umbrel that they just installed that had 0 channels setup yet). I like the idea of using swap services that your company may offer like loop and pool, but I have confidence in using those services because I can locally audit the software (choosing when I upgrade that software) to know the terms that we are doing business under. It's my understanding that your hosted service is providing software updates on the fly, but it is then doing local processing of encrypted data it gets from the node (through LNC). Since you have the ability to swap out that software at any time on me through the browser in your hosted version, it doesn't honestly make a difference to be whether the data is encrypted or not in transit, I still don't feel comfortable using such a service. Everybody has different needs though, so that's why I think a lot of people may prefer the hosted service instead.