Add Settings page with options

[jamaljsr]

Closes #32

This PR adds the settings screen with two options:

1. Choose the Bitcoin unit to use throughout the app (sats, bits, BTC)
2. Choose the Channel Balance Mode that the node operator wants to optimize for (receive, send, routing)

These options are persisted in the browser's local storage and loaded whenever the dashboard is refreshed.

To test, just click on the Settings link in the sidebar nav, change the options and confirm the changes are applied correctly throughout the site.

[jamaljsr]

@alexbosworth @Roasbeef @bryanvu I could use your feedback on the UI copy here.

What do you think of the labels used for the channel optimization setting. Is Channel Balance Mode a good way to describe it? I'm open to suggestions for improvement.

[alexbosworth]

Interesting concept, liquidity equality

I do this on my node sometimes but I'm not sure what I'd call it, generally I do it to encourage them to keep their inbound pointed at me

[jamaljsr]

Also, I forgot to mention. Here are the exact thresholds that determine the status of a channel balance (ok, warn, danger) based on the node's local balance as a percentage of the channel's capacity. These are hard-coded values now, but could be made configurable in the future.

I'd like to ask if anyone has any suggestions for tweaking these values for this first release.

Optimized for Receiving:

• ok: 0% to 33%
• warn: 33% to 66%
• danger: 66% to 100%

Optimized for Sending:

• ok: 66% to 100%
• warn: 33% - 66%
• danger: 0% to 33%

Optimized for Routing:

the percentage represents the largest balance on either side of the channel, so the lowest it can be is 50%

• ok: 50% to 70%
• warn: 70% - 85%
• danger: 85% - 100%

[jamaljsr]

Here are some screens of how the channel list looks using each of the above modes.

Receiving

Sending

Routing

[alexbosworth]

I'd like to ask if anyone has any suggestions for tweaking these values for this first release.

One thing maybe to think about is how fee rate and connectivity relates to this ratio. I don't try to keep channels balanced if the peer is charging a fee rate that makes it cost prohibitive.

I also don't see strong empirical evidence for 1:1 balancing in the current network as far as I can tell this would be invented behavior. It's kind of the same idea as the dual funded channels, because I want to put up capital, does that mean you want to put it up and in equal parts? Not sure

[jamaljsr]

One thing maybe to think about is how fee rate and connectivity relates to this ratio. I don't try to keep channels balanced if the peer is charging a fee rate that makes it cost prohibitive.

Great point! How would you want to see fee factored into the coloring/sorting? Should we weight it based on the fee relative to the node's other channels, or are there specific fee levels where you'd want to just ignore the balance percentage and color the channel green? I'm really interested in know what would make the most sense for operators. Right now, the logic is very basic.

I also don't see strong empirical evidence for 1:1 balancing in the current network as far as I can tell this would be invented behavior. It's kind of the same idea as the dual funded channels, because I want to put up capital, does that mean you want to put it up and in equal parts? Not sure

Oh wow, this is news to me. I've previously read in many places that having 1:1 balanced channels is optimal for efficient routing nodes. What would suggest is ideal in the Routing mode?

[alexbosworth]

How would you want to see fee factored into the coloring/sorting?

It's a bit tricky, that's just kind of what I'm saying as far as the levels of abstraction here maybe hiding some practical important nuances. For fees I like to think of this as related to action/volume, and then have my node react to past actions. What's the point of balancing channels that aren't used? So like the message I like to see is something like "this channel was used to get you 5000 sat in routing fee earnings. It will cost you 500 sat to rebalance it. It's depleted, which could cause a problem for future earnings. You probably want to rebalance it". So like a color/messaging that represents that message. The fee indirectly works there to dictate how much volume and how much cost.

With that being said, the state of routing node operators is pretty basic so the baseline is pretty much do nothing almost all of the time as far as I can tell.

I've previously read in many places that having 1:1 balanced channels is optimal for efficient routing nodes. What would suggest is ideal in the Routing mode?

Well it used to be that having more than the maximum payment shard size in liquidity was pretty much pointless because you would not hit a routing error. Now that this has been removed I would say optimally you want two 0.16777215 channels, each completely unbalanced but in opposite directions. Just talking about the ideal if we remove all variables other than just minimizing temporary channel failures.

[Roasbeef]

I also don't see strong empirical evidence for 1:1 balancing in the current network as far as I can tell this would be invented behavior.

I think it depends. MPP is still in its infancy, and we still need to gather more data about how effective it is in the network as is today. One could say 50:50 balancing is optimal as it reduces the probability of early failures, which lead to splits, which then add more payment latency on the sender's end. In the abstract, it is the case now that it's more a flow problem than having a path, but we still need to factor in things like payment latency and retries.

For the routing mode, do we change up which Loop variant we suggest or pre-select based on the distribution? Depending on where we are in the grand scheme of things, I think it would also be ideal to later follow up with a "rebalance" button shown for the routing view (or maybe all the time).