search

ipfs / ipfs-webui

A frontend for an IPFS Kubo and IPFS Desktop
https://webui.ipfs.io
MIT License
1.53k stars 474 forks source link

Feature: Diagnostics view #1925

Open SgtPooki opened 2 years ago

SgtPooki commented 2 years ago

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

Additional context

Ideas for supported functionality:

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

What/Why/How

SgtPooki commented 2 years ago

@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 commented 2 years ago

@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:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 1 year ago
meandavejustice commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Related: @juliaxbow survey and user research: image

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 commented 1 year ago

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 commented 1 year ago

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