Feature: Diagnostics view

[SgtPooki]

Is your feature request related to a problem? Please describe. Creating a diagnostic view in the webui and desktop app

Describe the solution you'd like Additional metrics desired can be found in https://github.com/ipfs/ipfs-webui/issues/1220, but this issue covers the diagnostics view we wish to have in the webui and ipfs-desktop.

This view would not be focused on metrics, instead, view #1220 for that. This view would be focused on process/tooling on top of those metrics and/or other data.

Describe alternatives you've considered

• https://pl-diagnose.on.fleek.co/
• https://ipfs-check.on.fleek.co/

Additional context

Ideas for supported functionality:

• [ ] network connection view to support users determining why or whether they're experiencing network connectivity issues.
  • see https://github.com/ipfs/ipfs-desktop/search?q=context+deadline+exceeded&type=issues
• [ ] We could use IPFS Desktop to get some diagnostic data about the gateways with user's permission. That would allow us to get some info on why are is the gateway so slow at some times and really fast on others. (https://github.com/ipfs/ipfs-desktop/issues/1140)
• [ ] command line interface to ipfs inside ipfs-desktop - ipfs/ipfs-webui#1931
• [ ] Health Check - See https://github.com/ipfs/ipfs-desktop/issues/2181
  • [ ] check if there are public providers for a CID
  • [ ] Are those providers dialable from my node
  • [ ] Trace route for DHT

---

Looking for community and IPFS Implementers' feedback on this issue.

Here are some questions to help get the ideas flowing.

What kind of diagnostics should we focus on

• How do you currently diagnose issues with your IPFS node/CID/etc?
  • Could this process be improved with a targeted solution in IPFS desktop and the webui?
  • What is the most difficult part of this process?
  • What problems have you run into that you have been unable to solve yourself, and how could a diagnostics view help to prevent a similar situation in the future?

What/Why/How

• Do we need a separate diagnostics & metrics view? Would a single diagnostics view that allows us to view the metrics we need be sufficient?
• What problems do you currently have that a specific diagnostics view in the webui and IPFS desktop could help you solve?
• Do you agree/disagree with the Ideas for supported functionality list above?
• Would you use the diagnostics view instead of your current tool of choice if the metrics were available in the IPFS desktop and webui?

[SgtPooki]

@lidel @BigLep what do you think about prompting current IPFS desktop & webui users to respond on this and the metrics (#1220) view issue?

@lidel do we have any current methods to prompt users for one-time feedback? i.e. surveys, etc..?

[lidel]

@SgtPooki we have no methods like that for GUIs, but in the past we used surveys with tools like https://www.typeform.com (PL has account iirc) for sourcing feedback from community.

Perhaps create a survey with questions you want answered, and then post it in community venues:

• Create a topic in https://discuss.ipfs.io/c/help/13 (new topic from Help category is automatically linked by a bot on Matrix community chat)
• Include it in https://docs.ipfs.io/community/#ipfs-newsletter

This way you will get feedback from active community members passionate about IPFS enough to respond, and you won't have to deal with frustrated users who got interrupted with some unprompted popup :)

---

In case it helps, the most useful diagnostics I'd like to see is a streamlined version of 4 tests at https://pl-diagnose.on.fleek.co/#/diagnose/access-content where UI is a box for CID and "Find providers" button:

1. user enters a CID and clicks "Find providers"
2. use different routing methods to find providers for the CID
3. connect to providers
4. confirm each provider still has the data, without fetching it (ask via bitswap with WantType=Have)
5. a report with successful peerids/multiaddrs is presented

Every step is either error or pass, and UI should indicate progress, so if somehting goes wrong, user knows which stage of content/peer routing is at fault.

MVP could use the same backed as existing diagnostic websites.

In the future we could create a new protocol/service similar to AutoNAT, allowing peers to use long-running, publicly diallable nodes instead of a hardcoded diagnostic endpoint, but this should be out of the scope for ipfs-webui work discussed here.

[SgtPooki]

Thanks for the great insight! I think adding pl-diagnose into the webui is a great idea. If pl-diagnose's components were abstracted, we could both benefit from the work already done on pl-diagnose.

@laurentsenta are you still actively working on that project? How hard do you think it would be to pull out some components from pl-diagnose so we could re-use them in ipfs-webui?

@lidel @laurentsenta would it make sense to fully consume pl-diagnose (the https://pl-diagnose.on.fleek.co/#/diagnose/access-content page) as a screen in the webui and ipfs-desktop? If there are still plans to expand pl-diagnose, maybe it doesn't make sense, but hosting pl-diagnose within the webui, desktop app, and at ipns://webui.ipfs.io/#/diagnose seems like a great idea to me.

I feel like it would be a natural progression for the webui and desktop diagnostics screen to expand beyond simply troubleshooting content accessibility, but I would love to hear what the future for pl-diagnose is.

[BigLep]

Cc @aschmahmann since would ideally like to see convergence around one main IPFS diagnostics tool in EngRes. I believe https://github.com/ipfs-shipyard/ipfs-check has been the one to get the most investment.

[aschmahmann]

Agreed, from a practical perspective I'd rather only have to maintain one tool.

Happy to take PRs to ipfs-check. Will also allow some feedback from the other folks who have contributed to ipfs-check

[laurentsenta]

Thanks for bringing up pl-diagnose, sorry I missed the notification on this ticket,

+1 to gather everything into ipfs-check, we already have a plan to merge the API (related ticket). We still have to figure out a plan for the frontend part. So we will be able to use ipfs-check's backend until we have the protocol @lidel described.

Regarding the feature in https://github.com/ipfs/ipfs-webui/issues/1925#issuecomment-1167930487 :

I guess you'd need a routing parameter with the /find endpoint, and we'd need to change the /bitswap endpoint to NOT download the data (a good thing anyway). The frontend is 4 (rushed) react components and some state management feel free to ping me @SgtPooki if you want to port it into ipfs-webui.

I'm curious about the idea of embedding the frontend from another project (ideally ipfs-check) into the webui, Can we do this? What would you need?

[SgtPooki]

@laurentsenta it would be great if we could simply import pl-diagnose as a full-page view. This is probably the quickest and easiest option.

Moving forward, having that view be separated into different imported components would allow us to control the flow better as our diagnostic needs change .

It sounds like you've already got four react components, so releasing those as a library to npm should probably be our first step.

[SgtPooki]

• Should webui/desktop have dev tools, or should we have a separate app for devs and end-users?

[meandavejustice]

We chatted at dinner last night about our shared goals for diagnostic/tooling for ipfs.

Dropping a document for the ipfs-toolbox web extension https://hackmd.io/sJZib5iiShGxmQ2x-OD8SQ

[juliaxbow]

re: user research around webui/desktop diagnostics view

I'm still hoping to get more survey responses as well as source additional participants for addt'l user testing but will deliver some research findings next week, fyi

[SgtPooki]

Cc @aschmahmann since would ideally like to see convergence around one main IPFS diagnostics tool in EngRes. I believe https://github.com/ipfs-shipyard/ipfs-check has been the one to get the most investment.

Agreed, from a practical perspective I'd rather only have to maintain one tool.

Happy to take PRs to ipfs-check. Will also allow some feedback from the other folks who have contributed to ipfs-check

@BigLep @tinytb @lidel

I agree that maintaining a single tool is ideal. The problem is where that tool exists in the stack and what diagnostics tooling is needed specifically within IPFS desktop and webui because they may not make sense elsewhere:

1. CLI/REPL inside desktop/webui to assist with learning/debugging/other
2. Network troubleshooting of the kubo daemon controlled by ipfs desktop
3. Diagnostics tooling for troubleshooting of MFS files added via IPFS Desktop
4. Other issues we're having trouble gathering (maybe they don't exist?)

To get our "one tool" we need to consolidate ipfs-check, pl-diagnose, and the needs of webui+desktop. If ipfs-check is the best place for that, great. I don't see that being our(webui & ipfs in general) path to success, but I'm open to being convinced.

If we need to separate the discussion of general ipfs diagnostics tooling, and this issue -- which I intended to be specific to the tooling that would be useful in IPFS Desktop&webui -- then let's do that. If we've reached the end of the discussion because there aren't any diagnostics tooling that makes the most sense inside of IPFS desktop and webui, then I'm good with closing this issue and pushing on consolidation of diagnostics tooling inside of ipfs-check.

[SgtPooki]

Related: @juliaxbow survey and user research:

The users we heard back from seem to want diagnostics inside desktop/webui. So are the following next steps valid?

1. Consolidate diagnostics in ipfs-check
2. Render ipfs-check inside webui&desktop

Or should we skip the second item altogether?

[2color]

Consolidate diagnostics in ipfs-check

Yes! I think we all agree on this one.

Render ipfs-check inside webui&desktop

I think it would be useful to have something inside the webui. The challenge is that ipfs-check relies on its own backend so if you render it do you use the centralised backend? Because technically if you have access to the webui, you probably have access to Kubo's RPC API which you can use to debug too.

[SgtPooki]

FYI to all following this thread that this "diagnostics view" may well turn more into an effort of building some consolidated diagnostics tooling rather than a specific "diagnostics view" within webui. I feel like both efforts have merit, but from discussions during roadmap planning that seems like where we're going

p.s. discovered a tool that I hadn't seen before, https://dag.ipfs.tech/, which has source at https://github.com/ipfs-shipyard/ipfs-dag-builder-vis, that would make sense in either effort