Need stats reports for electron-app

[dignifiedquire]

It would be great to have the following data exposed to display them as stats:

• Local storage size
• Object count
• Location

[jbenet]

For "Local storage size" and "Object count" we could add an ipfs repo stat command to go-ipfs.

For "Location" -- can use the local node's addresses, and geocode them the same way the peers are.

[dignifiedquire]

I've pulled https://github.com/Dignifiedquire/electron-app/blob/settings-hot/app/helpers.js from the webui into the electron-app. So the question is where to best have this code to avoid this duplication, maybe it makes sense to have it in here, or just as a format function of https://github.com/krl/ipfs-geoip. Thoughts?

[jbenet]

yeah probably makes sense to put in geoip.

also -- https://github.com/Dignifiedquire/electron-app/blob/settings-hot/app/helpers.js#L1 is that ES6? or what? are we compiling into regular js for now, or what's the goal?

[jbenet]

@krl would you mind moving ipfs-geoip into ipfs/ org? or do you want to keep maintaining it? either way is fine but we probably will need to fork it to ipfs org to ensure it survives and gets long term maintained, etc

[daviddias]

Seems that Location is done https://github.com/ipfs/ipfs-geoip , ^5 to @dignifiedquire

For the other two, @whyrusleeping what you think of adding those as CLI commands and exposing them through the http API as well?

[whyrusleeping]

local storage size is implemented in a PR by @rht (ipfs/kubo#1495) but i dont think its exposed via command line quite yet.

object count can be retrieved naively by piping ipfs refs local to wc. And any command we write for getting that number will do the same under the hood.

[daviddias]

object count can be retrieved naively by piping ipfs refs local to wc. And any command we write for getting that number will do the same under the hood.

Sounds good, we can use the node-ipfs-api to fetch that info :) //cc @dignifiedquire

[jbenet]

object count can be retrieved naively by piping ipfs refs local to wc. And any command we write for getting that number will do the same under the hood.

counting internal to the node would avoid piping a ton of data out.

wonder if we should keep these counts in a repo object somewhere, cached and recomputed every once in a while.