Add channel age column

[rkfg]

Fixes #82. This PR adds a new column that shows the approximate age of the channel. It's calculated from the number of blocks since it was opened. The precision is dynamic and varies from minutes for very young channels to years/months/days for very old ones. Tha error can be around 10-30 days per year depending on the hash rate volatility. Calculating the precise age isn't possible without querying bitcoind API directly because lnd doesn't expose API for querying historical block/tx with actual timestamps.

[rkfg]

Hmm, I think this can be further improved with color codes but I guess it needs to be discussed. For example, maybe highlight years with bright white? Or yellow? 😄 And young channels (<1m) with green? I think it's best to avoid red so it doesn't look like an error or something "bad". Anyway, ideas welcome! I want it to look as intuitive as possible so that with just one glance you can "feel" how old every channel is without reading the actual numbers.

[rkfg]

Does this look better when the list isn't sorted, huh?

[hieblmi]

Very nice! Thank you for the quick response.

[rkfg]

I'd still like to get feedback about the colors, whether it's needed and if it's good!

[hieblmi]

Oh right - I think what might work well is instead of different colors(which might make the screen look crowded) we could use one color - say orange - and indicate via a gradient the age... So light orange being young to dark orange being old... maybe good to avoid the alerting dark orange.... What do you think?

[rkfg]

It would be really good but I don't think it's that easy to implement because not all terminals support so many colors. I know xterm can show 256 colors and I believe it's possible to use in this case. However, we need a fallback variant for 16 color terminals.

This looks well supported and has all that's needed. Maybe it's worth replacing fatih/color with it?

Overall support isn't bad btw. Even on Windows it's all supported and the library I linked says it can output true color in cmd/powershell. For now I think we can just add that library for this feature and later replace fatih/color completely if nothing else breaks.

[rkfg]

I actually replaced the library and what worked still works... but 256 colors or full RGB don't. Will keep looking into it, seems worth it.

[hieblmi]

For now I think we can just add that library for this feature and later replace fatih/color completely if nothing else breaks.

Yes I think that's a good approach - I didn't consider the color constraints.

[rkfg]

I can say it looks quite awesome! Sorted:

GOCUI doesn't support true colors so I decided to use 256 colors instead. Not all shades map perfectly, however, you can notice a green tint in some lines. The replacement library is quite flexible and can map colors back and forth. There's also a small hack for 16 color displays like TTY, took me a while to find a more or less good solution: the young channels were rendered as black if the column isn't highlighted (otherwise they're dark gray). So I increase the lightness parameter slightly for those younger than 2 months. It doesn't change much in 256 color terminals but in 16 color they now render as white.

I didn't use the exact same colors as in your proposed table because with it all channel ages render as red in 16 color mode. So I chose almost the identical top orange color and changed saturation from 0 to 1 as it approaches 1 year (and it stays 1 after that). We can choose more interesting gradients though. For example, start with green, make it yellow at 6 months and orange after 1 year.

[rkfg]

I like this more because it doesn't need a hack for 16 color terminals and just maps to green/yellow/red there. Also looks fine in 256 colors. Maybe this should be behind a separate setting like "advanced colors"?

[hieblmi]

I think you nailed it in the last screenshot. I like that scheme a lot. So are you saying that the behavior in the last screenshot would be available behind a flag for advanced colors and default would be 16-bit? Maybe we can detect the capabilities of the term during initialization? But don't know how much effort that is.

[rkfg]

The library can detect that, yes, but it's not very reliable. For example, if the program runs in tmux the user can connect to it from different terminals with different capabilities so it's reported as supporting 256 colors. But my main concern is that some users might not like that this one column is so colorful while the rest is much more plain. And if it's behind a setting they would be able to turn it off and see just regular white characters in that column.

Another idea is actually using node colors for aliases. It's a bit weird parameter because I wouldn't expect to have it at the protocol level but here we are. And it's quite trivial to read the color and apply it to the alias since the library automatically chooses the closest color from the palette (we can't use true color because of the gocui limitation).

[hieblmi]

But my main concern is that some users might not like that this one column is so colorful while the rest is much more plain. And if it's behind a setting they would be able to turn it off and see just regular white characters in that column.

Sounds reasonable.

Another idea is actually using node colors for aliases. It's a bit weird parameter because I wouldn't expect to have it at the protocol level but here we are. And it's quite trivial to read the color and apply it to the alias since the library automatically chooses the closest color from the palette (we can't use true color because of the gocui limitation).

As someone once mentioned the devs must've been high when introducing the color parameter :-). And nice with the automatic adjustment of the color when resolution is low...

Another area where we could apply colors are the SENT/RECEIVED columns - balanced flows appear maybe green, no flows some darker color. But maybe then we just get too crowded with the colors and it would need a user selectable flag for sure.

[rkfg]

Another area where we could apply colors is the SENT/RECEIVED column - balanced flows appear maybe green, no flows some darker color. But maybe then we just get too crowded with the colors and it would need a user selectable flag for sure.

Good idea! I think the default should be like it is now, I myself don't like it when something changes radically in the new version and the UI becomes distracting. This can be solved politely with:

1. multiple screenshots showing the default, more traditional and calm UI as it is now and the alternate colorful UI
2. per column color options that enable these butterflies and rainbows™, off by default but with commented out lines in the config, just like it is now for some columns not shown by default; a lot of colors might cause fatigue so enabling them only in some columns that matter to the user makes sense

Users who like the feature would be interested by the screenshots and easily turn it on by uncommenting some lines in the config. Others will be greeted with the default experience they're familiar with from htop.

I strongly believe color-based information representation is underutilized currently in many CLI/TUI programs. High color support is widely available in all modern terminals (I even checked tmux on mobile, works fine), so let's use it! Human eye reacts to different colors much faster than to characters themselves. And still most programs only use colors to differentiate between captions, data and borders.

[rkfg]

Thinking about column color options, I need some input. There could be more column options in the future, for example, width or value precision (msat for HTLCs when they start to matter?). So constraining options to something like column_name.colors = true might be not wise. I propose the following options structure:

[views.channels.options]
AGE = { colors = true, width = 15, ... }
ALIAS = { last_update = "color", ... }
HTLC = { precision = 3, ... }
...

Those are non-existent options, just as an example. Sane defaults would be like it is now and put to the config, uncommented.

I realize it kinda dilutes this PR, if needed I can make another one just for the options. But it wouldn't make sense without this one as there would be no options, just a structure for them.

[hieblmi]

Hi, sorry for the delayed response. I am still tied up a bit and need a little to review your comments.

[rkfg]

No worries, this one isn't quite ready for upstream anyway. Unfortunately, it's not possible to change the PR status to draft. EDIT: found a very small button to do just that lol, looked for a while before and failed. GitHub UX is unmatched somethimes...

[rkfg]

If needed these commits can be squashed into one.

[rkfg]

Added the color option to the config, fixed age updating (should now update on every channel list refresh)

[hieblmi]

This looks slick, thank you very much for this feature.

[hieblmi]

I propose the following options structure:

[views.channels.options]
AGE = { colors = true, width = 15, ... }
ALIAS = { last_update = "color", ... }
HTLC = { precision = 3, ... }
...

I think structuring the options this way is a good idea, although I wonder if we somehow could integrate it into the [views.channels] section so that we only have to edit the column that we are interested in in one place(say if we want to enable/disable or change position AND tweak options). Not sure if it's wise to interpret the order of keys in the map as positions of columns in the view... something like

[views.channels]
{ AGE = { colors = true, width = 15, ... }},
{ALIAS = { last_update = "color", ... }},
{HTLC = { precision = 3, ... }},
.
.
.

Resulting in the expected order AGE | ALIAS | HTLC.

[rkfg]

Not sure if it's wise to interpret the order of keys in the map as positions of columns in the view... something like

Generally, the map key order is neither defined nor stable in most languages, except if the map is explicitly ordered. Would be great to have everything in one place but alas. I'd use JSON instead of TOML myself as it feels much easier to write and extend (personally) but we have to work with what we have. TOML doesn't allow multiline key-value tables and I'm not sure you can put tables like that in a section without corresponding keys.

Glad you like this feature, I find it eye pleasing as well. But I understand if some people wouldn't want to see it like that by default, htop-like programs are usually much less fancy, no need to break traditions.

[edouardparis]

I am ok for the current options strings, I like that you keep it simple. If in the future more options are added, the options system will be improved to "fail fast" at startup after options parsing. (Same for channel names: the "column does not exist" message should not exist, lntop should fail at startup with an error message)