Port features from pl-diagnose

[laurentsenta]

We implemented pl-diagnose during launchpad as a "ipfs-check but easier to use",
We want to merge its features back into ipfs-check.

https://github.com/laurentsenta/pl-diagnose

API endpoints:

https://github.com/laurentsenta/pl-diagnose/blob/32be4cf13db63da02a5f626215f849c60f80a1b2/backend/main.go#L31-L49

• /find?cid={cid}: Find a piece of content in the DHT
• /find-peer?addr={peer-multiaddress}: Find a peer in the DHT
• /identify?addr={peer-multiaddress}: Dial into the peer and use the identify protocol
• /bitswap?addr={peer-multiaddress}&cid={cid}: Dial into the peer and try getting the content identified by the cid

Outputs & Implementations can be found in the daemon file.

UI / UX

Not sure what we want to do with the frontend. It made sense to use something familiar during launchpad,
a few things probably worth saving:

• pl-diagnose is literally "ipfs-check but with smaller steps",
  • we try our best to test only 1 thing per step so that if something goes wrong, it's easier to tell why and how to fix it.
• There is a link ❓ Need help with this result? Ask for help on github that generates an issue for the user.
  • I think that's the killer feature, we're targeting beginners, and as a user, there's always one clear path to fix my issue. as a developer, I get an issue I can use to improve the app.
  • Example: [help] I need help with node availability laurentsenta/pl-diagnose#6
• Parameters are stored in the URI, easy to share,
• We hoped to create a single location to share pl's diagnostics-related tools and made sure there's an easy way to contribute (https://pl-diagnose.on.fleek.co/#/toolbox)

[SgtPooki]

@laurentsenta @aschmahmann I think we should port ipfs-check to pl-diagnose tbh. The front-end code in pl-diagnose is much more friendly for devs.

I haven't looked at the backend of pl-diagnose, but ipfs-check backend is pretty straightforward. However, here are some problems I see with this repo:

• missing a good development workflow (changes to backend and frontend both require manually rebuilding)
  • Note that the front-end did not require building prior to feat: add telemetry #30, but that is also a flaw in my book. The code is all in an HTML file which is not ideal. pl-diagnose is much more modern and maintainable.
• missing deployment workflows & documentation (how is this deployed? where is that documented? How do I test it? is the process manual?)
• missing interop instructions

[aschmahmann]

The front-end code in pl-diagnose is much more friendly for devs.

🤣 I'm sure. I haven't done any JS UX much of anything, the only reason the website doesn't look awful at the moment is someone with better skills than me (olizilla) spruced it up. @laurentsenta's front end for working through the steps is also just better (e.g. resolves #6).

IIRC the pl-diagnose backend is very slow compared to the one here (probably due to not using the accelerated DHT client). So I wouldn't want to swap backends until that's resolved.

---

Side note about the backend: There might be users other than people who visit check.ipfs.network that hit the backend. If we break the backend that's probably fine, but maybe cut a release of the repo with some release notes documenting the change or at least describe the changes well in a commit message. Also ping @TheDiscordian since IIRC he'd have a bot to update.

[laurentsenta]

😄 From your comments @aschmahmann, @SgtPooki it looks like we could start with porting the API here and eventually merge the pl-diagnose frontend. There's also an env variable in pl-diagnose that we can use to hit ipfs-check when the backend is ready.

@aschmahmann, we'll add more endpoints to that project, do you have a preference/recommendation for the approach (maybe a framework, library, or sticking to stdlib)?