Resolving IPNS with Helia in browser

Help Helia
1

I’m trying to resolve an IPNS entry with Helia and get the following error:

Could not find record for routing key

Here is what happens in my code:

import { peerIdFromString } from '@libp2p/peer-id'
import { ipns, type IPNS } from '@helia/ipns'

// build name resolver from existing helia instance
const helianame: IPNS = ipns(_helia)

const IPNS_ENTRY = "..." // ipns as given by the kubo node (base36)
const ipns_entry = peerIdFromString(IPNS_ENTRY) // convert to peerid as expected by the resolve method

// try to resolve
helianame.resolve(ipns_entry).then(/* [...] */)

I am connected to a local kubo node through webtransports. Its gateway is able to correctly resolve the ipns entry.
I tried to provide multiple different transports with routers option but event DefaultIPNS should be able to do it, right?

2

There are essentially two ways to resolve an IPNS name in the browser:

We also just announced Verified Fetch which supports IPNS resolution out of the box.

Here’s an example on how to do this.

This is taking the first approach, but essentially just treats your node as a peer rather than a delegated routing endpoint.

To make use of your local Kubo node, you can enable the delegated routing endpoint in Kubo and customize the delegated routing endpoint of the @helia/http (and @helia/verified-fetch) as follows:

import { createHeliaHTTP } from '@helia/http'
import { delegatedHTTPRouting } from '@helia/routers'

const helia = await createHeliaHTTP({
  routers: [
    delegatedHTTPRouting('localhost:8080')
  ]
})
1 Like
3

Thanks a lot for your detailed answer @danieln! What’s fun is that I came to the exact same conclusion by the exact same path. I have been looking at the code of verified fetch and figured out it was using delegated routing, so I added /routing to my kubo config and configured name resolution with delegated routing in my client /src/main.ts#L57-L63.

However it would be nice to succeed with the first option too.

  • chromium has webtransports feature which kubo also has and that’s what I’m using at the moment
  • firefox has webrtc but it seems to be unimplemented in go at the moment

I’ll keep experimenting with all of this, the libs are very good and its a lot of fun to play with those ^^

1 Like
4

Yeah those should enable direct resolution of the IPNS name in the browsers.

WebTransport is still tricky in Chrome due to the following: Too many pending WebTransport sessions in Chromium · Issue #211 · ipfs/in-web-browsers · GitHub

and WebRTC-direct will hopefully land in go-libp2p soon (and Kubo). Even when these two are stable, it will take a while for the network to upgrade. Great that you’re kicking the tires with these.

1 Like