Show number of discovered nodes in the taskbar menu under the running status indicator

[shoce]

That is important to see not only that IPFS is running but if it is online i.e. connected to any other nodes. Would be nice to have the number of nodes connected in the menu under the "running" indicator.

[jessicaschilling]

Thanks, @shoce, and apologies for the delayed response. Might this be something you'd be willing to PR?

[jessicaschilling]

@hacdias Wanted to get your opinion on this if you had a minute ...

• Seems reasonable that we could include this either in the "IPFS is Running" indicator in the menu, or maybe in the "Nodes" menu item that brings up Web UI's Nodes screen (though the former probably makes more sense) ...
  • But how often would we want to update this (assuming we get this number from Web UI)?
  • Are there performance implications?
• Also, this approach would be visually different than Companion, which indicates the number of nodes in the cube icon itself. The little bit of digging I did (and admittedly regarding MacOS only) indicated that trying a similar approach of having the menubar icon change dynamically to reflect the number of nodes was impractical or maybe even impossible. Is that true, in your opinion?

[hacdias]

Hey!

But how often would we want to update this (assuming we get this number from Web UI)?

That only depends on how often you need the peers count to update. Maybe we could use the same value as IPFS Companion (which by just looking at it seems to be 1 second).

Are there performance implications?

Great question. It would need us to rebuild the entire menu every time. Since it is not visible most of the time, I'm not sure if there are any practical implications.

Is that true, in your opinion?

What I remember reading the last time I searched about it is that it is hard, really really hard. So I'd not go for it.

[lidel]

Could this be in the tooltip that is displayed when user hovers over the icon (without clicking on it)? I think that would be more useful than adding it to menu which requires a click.

[jessicaschilling]

What about doing both? Just from generalized user testing, someone's tendency to actually use hover hints is a pretty personal trait.

[jessicaschilling]

https://github.com/ipfs-shipyard/ipfs-desktop/pull/1599 stubs out how this would appear in both locations:

That said, I'm afraid I'll need some help getting the peer count out of Web UI. @lidel and/or @hacdias, thoughts? If you're OK with the approach, would either of you be willing to wire up the peer count?

[hacdias]

@jessicaschilling you can probably get the ipfsd object via context after everything is initialized via ctx.getIpfsd() if I'm not wrong. From that, you have to use the API. Something like ipfs.swarm.peers() should give a list of the peers i think.

[lidel]

Note that src/daemon/index.js emits status change event only when daemon starts/stops, and that triggers menu refresh.

IIUC to have the peer count available for tooltip and menu we would have to periodically poll the /api/v0/swarm/peers endpoint, count unique PeerIds and emit the latest count, then update tooltip+tray menu in response to that event (IPFS Companion does something like this every 3 seconds).

Is there a better way that I don't see?

@Gozala noted some alternatives to polling in https://github.com/ipfs-shipyard/ipfs-webui/issues/1536 but it requires go-ipfs changes and unsure if we want to block #1599 on that.

[sutartmelson]

I spent some time working on this. The primary hurdle being, as discussed in https://github.com/electron/electron/issues/12633#issuecomment-381872869 and specified in the electron docs, menu labels cannot be dynamically changed.

I believe a workaround might be rebuilding the menu each time the peer count is polled, but I assume rebuilding the menu with such frequency wouldn't be desirable.

Tooltip works out great, though!

[jessicaschilling]

A tooltip alone would be better than nothing 😊 as long as it's not too expensive ...

@lidel, any thoughts?

[lidel]

The tooltip is not worth it imo: rebuilding menu is not really much more work than the polling itself (sending HTTP request to go-ipfs and parsing response), so if we poll, then it is ok to rebuild menu.

But IPFS Desktop is already heavy, and I would like to avoid constant polling for a value that the user will see maybe once a day, or once a week.

@sutartmelson are we able to rebuild menu after it is opened? Ideally we would refresh count only when needed.

Something like:

• detect menu got opened
• check if 10 seconds passed since peer count was refreshed
  • if so, spawn asynchronous task to fetch updated peer count
  • compare it with old one
  • if values are different, rebuild the menu
    • i suspect on some platforms rebuilt of menu does not update the labels in UI, but perhaps we can programmatically close&reopen menu on those platforms to trigger label refresh?