feat: support users without a local Kubo instance

[oed]

Is your feature request related to a problem? Please describe.
I've built an application called Dapp Rank where people can browse applications deployed on IPFS + ENS. For every dapp there is a report page. In the detailed report section there is a button to "🔍 Explore IPFS" which when clicked launches the IPFS Webui (e.g. https://dapprank.eth.link/dapprank-eth). This is a super cool feature, but unfortunately it only works for people that run Kubo locally. That means that probably most of my users won't get a working experience of exploring the IPFS content.

Describe the solution you'd like
Ideally there's a version of the Webui that works even if you don't have a Kubo instance on your machine. I imagine there could be a few different ways of solving this:

1. Use Helia to fetch data directly from ipfs
   Similarly to how inbrowser.link works. This seems like it would be a fair amount of effort. Also unclear if it really would make sense to add to this repo or should be a separate project.
2. Load CAR-file from gateway
   Another way could be to use the ?format=car flag to download the content directly from a gateway. If we'd like to avoid using a default gateway maybe a url can be passed as a query param.

[aschmahmann]

@oed a lot of webui is about managing your kubo node. What are the types of functionality you're looking to use without it?

For example, are you looking for the IPLD explorer? If so that's separately accessible via explore.ipld.io and doesn't require a local kubo node.

Side note: very cool site!

[oed]

Yeah if the IPLD explorer worked reliably I think it might be fine. The functionality I want is to be able to explore the folder structure basically.

Seems to be broken rn though?
https://explore.ipld.io/#/explore/bafybeiahtlgk2xhjl7eveyfplbsqo6ztdb72wonlrednz5sk4x3ieofy6m

[aschmahmann]

Yeah if the IPLD explorer worked reliably I think it might be fine.

Interesting, do you tend to replicate this frequently? It works fine for me, but it's not out of the question that there could've been some infra issues.

The infra explore.ipld.io relies on (if you don't have a local gateway running on port 8080):

• A delegated routing endpoint (i.e.. delegated-ipfs.dev)
• If none of the hosting nodes speak a transport the browser node speaks then it needs an intermediary (for lack of better term, a recursive trustless gateway) like trustless-gateway.link to fetch the blocks and serve them over HTTP
  • It looks to me like none of the providers (discovered with the checker tool serve using HTTPS or WSS. A few have WebTransport enabled, but I'm not sure if it's enabled (@SgtPooki or @achingbrain could probably clarify) .... browsers still have some WebTransport bugs which at one point caused the team to disable it by default.

Having a host with AutoTLS enabled or serving over HTTPS (as some groups like Storacha will do) will help if the issue is with trustless-gateway.link moving your bytes around. Although if there are issues with trustless-gateway.link or delegated-ipfs.dev we want to know 😄, they can be reported at https://github.com/ipshipyard/waterworks-community or in the waterworks-community Slack channel on Filecoin Slack.

The functionality I want is to be able to explore the folder structure basically.

Ah... so is it correct to say that what you're asking for isn't quite the IPLD explorer, which is maybe close but will show you the blocks inside HAMTs rather than just enumerating the files, but instead one of:

• The Files panel from WebUI
• The Gateway API, but where you can force the directory view even if there's an index.html file in the directory

[oed]

Interesting, do you tend to replicate this frequently? It works fine for me, but it's not out of the question that there could've been some infra issues.

It had been the case every time I tried to use it, but now when trying again after your message I see this error less frequently.

The infra explore.ipld.io relies on (if you don't have a local gateway running on port 8080)

My local gateway runs on 8082 for some reason, but I would assume it would just use the defaults if it's not on 8080?

Having a host with AutoTLS enabled or serving over HTTPS (as some groups like Storacha will do) will help if the issue is with trustless-gateway.link moving your bytes around.

The thing is that I don't control where the data of each dapp is available. Dapp Rank just provides analysis of dapps. It doesn't pin any dapp (besides dapprank itself).

Interestingly I do have AutoTLS enabled on my node, but the peer only appears as:

{
  "Addrs": [
    "/ip4/139.59.202.248/tcp/4001"
  ],
  "ID": "12D3KooWC7YM6zibmL3W25WxDVYxMK7xcdnaGaQoVv1JFaoHE14u",
  "Schema": "peer"
},

Ah... so is it correct to say that what you're asking for isn't quite the IPLD explorer, which is maybe close but will show you the blocks inside HAMTs rather than just enumerating the files, but instead one of:

Yes the blocks / HAMTs is a bit too low level for the average user. The WebuUI Files panel is exactly what I would want.

[SgtPooki]

Use Helia to fetch data directly from ipfs
Similarly to how inbrowser.link works. This seems like it would be a fair amount of effort. Also unclear if it really would make sense to add to this repo or should be a separate project.

It sounds like we may want to pull out the files screen into it's own component.. that would be a significant effort I don't think we could take on right now though.

---

Sidenote

You can adjust the local gateway used by explore.ipld.io by setting a value in local storage, see https://github.com/ipfs/ipld-explorer-components/blob/c82d7bec376779e194d4c19c9d5afddcdd5d9427/src/providers/helia.tsx#L17-L39

localStorage.setItem('kuboGateway', JSON.stringify({
  host: '127.0.0.1',
  port: '8082',
  protocol: 'http',
  trustlessBlockBrokerConfig: {
    init: {
      allowLocal: true,
    }
  }
}))

[oed]

It sounds like we may want to pull out the files screen into it's own component.. that would be a significant effort I don't think we could take on right now though.

Ok, good to have clarity on this regardless. So basically this is what need to happen?

1. Make the Files screen into a separate component
2. Use this component in https://github.com/ipld/explore.ipld.io

[lidel]

You could do all that, but frankly, at that point it will be an order of magnitude easier for you to implement a simple file browser from scratch, only using Helia.

Check https://www.npmjs.com/package/@helia/verified-fetch, and its support for plugins + recently added support for directory listings there + inbrowser.link.
Starting fresh will be less work.

Closing this, as WebUI requires Kubo to function, and we won't be investing time into extracting Files screen into reusable component – if someone needs one, it will be more efficient to create it from scratch.