1.3.0-0.1.0: Enhancement - Allow DNS Address

[lnbc1QWFyb24]

• Modify the client side validation to allow both an IP address and a DNS address in the address connection string. (closes Client application does not validate DNS names in the node URI #89)
• Add error handling for local storage calls to not fail when access is blocked (like in TOR browser).
• General linting fixes.
• Update to latest Lnmessage which also now allows DNS addresses.
• Fixes bug so that on the connect screen, every new attempt to connect will start with a fresh instance of the CoreLN instance so that it always connects to the updated address.

[johngribbin]

looks good, how can I test this on staging?

[lnbc1QWFyb24]

looks good, how can I test this on staging?

First we want to test that this does not break anything for existing users. So just general testing will be helpful here. You can then test trying to use a domain (i was just using a random one) instead of an IP and observe if it passes the validation and attempts to connect.

To really verify this works, we could use some help from @farscapian to try it out.

[farscapian]

I tried testing this on a new Firefox instance with the following input: '0224818c362a6e6886ed1d233047dd45dd78c329e1eb20af5de9b8cf6d279c2de6@btcpay.farscapian.com:9735'. It does seem to validate on the client side, but I get a red "Connection error". No error output in the vConsole, but in the browser debug environment I see a network request to wss://wsproxy.clams.tech/btcpay.farscapian.com:9735 with no response from wsproxy.clams.tech. Assuming ln-ws-proxy needs DNS hostname support also?

[lnbc1QWFyb24]

Yeah the wsproxy should already be upgraded to handle this, but it must be having some issues. I'll try debugging with those connection details and see what I come up with.

[lnbc1QWFyb24]

@farscapian it looks like the wsproxy deploy failed. Redeployed and it is working now if you would like to try again on the staging app.

[farscapian]

Connection confirmed! Everything seems much snappier now too. I tried this on Firefox on Ubuntu and tried with and without the default port.

Thank you very much for implementing this! For me, this functionality is helpful in two areas: 1) in some cases people will be using DDNS on their external firewall to update the hostname associated with their public IP address. Using a DNS name allows the Clams app to always reach the correct endpoint. 2) In the case where you are on-premise with your lightning node, often you will have a different internal 1918 IP address assigned to your node and your internal DNS server will point to that rather than returning the public DNS records. This allows Clams clients sitting on your local network to make a direct connection to the lightning node. (of course you will need to host your own ln-ws-proxy to avoid the websocket connection wsproxy.clams.tech).

Thanks again!

[lnbc1QWFyb24]

No worries! I am also working on adding direct connections and custom WS proxies at the moment as well, so we should be able to also get that in to the next release.