provide more details on the hashmail mailbox proxy config and operation

[AndySchroder]

https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/mailbox shows the config options required to setup the hashmail mailbox proxy.

Wondering, why is port 443 recommended? Is it required to use https for this to be secure? If this is just a dumb proxy, it seems like port 80 could work and then no SSL certificate would be required? I thought a big reason for Lightning Node Connect was to get rid of the need for SSL certificates, yet it seems like aperture and the proxy may be adding them back in.

Also, can the hashmail mailbox proxy be used in addition to the other features of aperture in the same instance? Wondering what http path the hashmail proxy runs under so that if I want to also use aperture for doing the Lightning Service Authentication Token Reverse Proxy (that it is mainly designed for), I can avoid path conflicts.

[guggero]

We needed a server component to run the HashMail proxy in and aperture was the easy choice, even if its core functionality (LSAT reverse proxy) isn't directly related to the HashMail functionality.

The main reason for HTTPS is that gRPC runs on HTTP/2, which by default only works over TLS. There is a non-TLS version called h2c, but that isn't very well supported in some client software or other network components (such as corporate proxies, ingress controllers, load balancers and so on).
But no, for HashMail to be secure, TLS is not required, as the payload itself is encrypted with the Noise framework/protocol.
It's just that we chose gRPC as the HashMail transport protocol (which is translated to REST/WebSockets as well for the browser part), that makes the use of TLS somewhat required.

Also, can the hashmail mailbox proxy be used in addition to the other features of aperture in the same instance?

Yes! The paths used by Hashmail are /hashmailrpc.HashMail/* for the gRPC calls and /v1/lightning-node-connect/* for the REST calls.

[AndySchroder]

It seems a bit messy that you have the LSAT and HashMail stuff in the same project. I'd consider separating the server component out and then layer those two things on top of the server in separate projects (split this project into 3).

When you say that you use gRPC for the hashmail transport protocol, does that mean that you are running gRPC inside of gRPC? Seems a bit convoluted.

It seems to me like doing the hashmail protocol inside https is adding an unnecessary layer of encryption (more CPU usage and more libraries involved) and it introduces a new dependency of the SSL certificate that isn't even needed. https://lightning.engineering/posts/2021-11-30-lightning-node-connect-deep-dive/ even says "LNC uses these long-term public keys to do away with TLS certs", which is misleading because you are still using them for no reason in the proxy server.

It seems like if you are trying to be compatible with other types of proxy servers and load balancers, using unencrypted websockets would achieve that goal instead of using gRPC, especially if you are translating to websockets for the browser part anyway.

[AndySchroder]

Perhaps the dev_server (https://lightning.engineering/api-docs/api/lit/sessions/add-session#litrpcaddsessionrequest) option of litd can work around a dependency on TLS certs on the node side? Is there another option for the WASM lightning node connect client that could just be enabled to also skip verification?

This could be a workaround for needing to get a signed certificate from a certificate authority (much simpler and more decentralized installation), but it wouldn't decrease the complexity of your protocol and code.