Content not resolving on IPNS but resolves on IPFS

The js-ipfs code example below shows how to generate some random test content and publush it to IPFS, and then also use name.publish to publish the IPFS CID to IPNS:

https://gateway.ipfs.io/ipfs/QmfQJ5AwLBtG3m784N3ayH1omUD9ZpimXCULTutxKyvkUX/ipfs-ipns.html

It seems working fine for publishing and retrieving the content by any IPFS gateway, the published IPFS content is available. Running the code will give IPFS and IPNS links to access the content, example:

IPFS Content: …/ipfs/QmUYa5LpsEJgRCRStbfRaW46G48asWsbMeXPeF57ZNqnSA

IPNS Content: …/ipns/QmUwWUpyJtzoGx1qa3uiDP3JW57HCRVgRgbBzPMUqzM37

however the IPNS URL is never working. When trying to resolve the IPNS CID QmUwWUpyJtzoGx1qa3uiDP3JW57HCRVgRgbBzPMUqzM37 locally in the same browser window, it does resolve to the IPFS CID QmUYa5LpsEJgRCRStbfRaW46G48asWsbMeXPeF57ZNqnSA, but it seems like there is an issue with IPNS URLs getting published properly using this code. Feeling a bit stuck, any help is welcome.

It might help if you include the actual command (like using command line API for example) that you’re executing and what output you’re getting, and why you consider the output to be incorrect. If you’re doing an IPNS show us the command lines you used to publish, and it’s output too. Included as many ‘verbose’ options as there are on any of the commands.

Sure, the actual command is “node.name.publish”, using js-ipfs in the browser (not command line IPFS).

Here is an example of the output I am getting after visiting the source URL mentioned in my original post.

I don’t belive there are any verbose options when using js-ipfs to publish to IPFS and IPNS, in the browser but I could be wrong.

To clarify, here are some examples of “actual commands”…

When using actual CLI commands on a server running IPFS, the issue does not happen, IPNS links resolve correctly (they do seem to take longer to resolve than IPFS however). The issue we are experiancing only happens in the browser js-ipfs where IPFS works and IPNS does not.

Ok, next you should run command line ‘curl’ with the same url that is failing in browser, and see if that works. If it works with curl that means somewhere the browser must be getting wrong data from some kind of caching or something. Curl should just display the HTML as plain text in your terminal of course. It theoretically should behave the same as thru browser request, even though a couple of things like user-agent string, etc will be different, in curl v.s. browser.

Thanks, it is helpful. Screen shots attached showing result from opening the URL from my original post that run on my local machine in the browser, and right two screen shots show curl command run twice from a remote machine: one showing working for the IPFS URL and the other showing it failing to resolve the IPNS URL.

When you run the publish command you get back in the response an object that contains a resolvable name and a value. You can then ‘resolve’ (which is a separate command from publishing) that name using ipns, but I think any of the CIDs that are generated (or resolved to) still will always use the /ipfs/ path in the gateway. So unless you are doing a resolve you don’t want to use /ipns/ path ever. Once resolved, you have a normal CID that can be used with as /ipfs/ path. I may be wrong that this is the issue, because I have limited ipns experience, even though I’m trying to help. :slight_smile:

Ok, here is an updated screen shot showing what happens when running the publish command and trying to resolve the IPNS CID in another browser tab. One tab creates a file, adds to IPFS, publishes the CID to IPNS, and the IPFS file can be fetched and IPNS CID resolved correctly in Browser tab #1. From Browser tab #2 (in-cognito), the IPFS CID content can be fetched, but the IPNS CID does not resolve.

Updated test code used for the screen shot:
https://ipfs.io/ipfs/QmXf4bsvBfdXA2dw48KUsca7HgpHyEfyANvuBUMKcnFQZi

If you already reproduced this on the command line you should be able to put the entire thing into a shell script and send it to us. I don’t know what those screenshots mean because I can’t tell what commands got ran to create that output.

Unfortunantly there is no issue using the command line (e.g. IPFS node running on a server), IPNS CIDs seem to be properly published and available/resolvable by any IPFS gateway, the issue is not replicatable by command line. The only issue we have is when using js-ipfs in the browser using the source examples provided, in regards to IPNS resolving correctly. This leads us to belive the issue is using js-ipfs itself and not related to core IPFS/IPNS command lines.

That’s great that you understand the command line issue now. Feel free to post the actual code if you have any code that is giving you unexpected results still. Your first 5 words of your initial post imply that you seem to think we know what code you’re running…Maybe I’m confused but I still don’t know what code you are running. lol.

Sure, here is the actual code below in the screen shot that is not working (you can also view the code by right-clicking the page from the links I posted here previously and select View Source in the browser), the red box contains the lines that cause the error. It seems there is an issue while calling “node.name.resolve” to resolve the IPNS CID.

You should resolve just the name. Remove “/ipns/” from your string. :slight_smile: Maybe the command line version tolerates the addition of ‘/ipns/’ in the string, and ignores it, and if so that could be what was so confusing.

Thanks, it is a good idea, however removing “/ipns/” from the string so it is called likethis
“node.name.resolve(ipnscid)” still causes the same error “… was not found in the network”.

I bet this is just a timing issue then, if you have a name that resolves in one place and not another. Supposedly the IPNS has to propagate similar to how a DNS change on the internet takes time to propagate. I noticed my ‘ipns publish’ calls were taking up to 3 minutes to return, and that’s the reason people gave, so I bet you just have a situation where you’re running all this too fast, without waiting long enough maybe?

1 Like

We also thought it could be a timing issue, however the IPFS content is immedialtly available from any gateway, and the IPNS content published at the same time is still not resolvable even after an hour from any gateway like gateway.ipfs.io or another browser on the same macine. However when using the command line, “ipns publish” commands, we had similar results as you had, it would often take a few minutes to eventually resolve, slower than IPFS.

Attached screen shot showing after one hour of publishing IPFS content and IPNS record, the IPFS published content resolves, but IPNS still not resolving.

It sounds like you’re saying it actually works everywhere except for one machine. Maybe the problem truly is with that actual machine? Is this the case? Only one machine has ever exhibited the issue? If so there’s some kind of network configuration problem or internet connectivity on that machine, and you would need to start using ping, tracert, and other network layer tools to discover why that machine isn’t working.

Oh I did not mean it works everywhere except one machine, I mean go-ipfs works fine for IPFS and IPNS publishing/resolving. I mean it is js-ipfs that is not working at all, on any machine and any network for IPNS. It does not seem likely that a networking issue would cause only IPNS to have issues and allow IPFS to work fine when using js-ipfs. We also have not been able to find any working IPNS examples that use js-ipfs.

Searching the github issues for js-ipfs, it seems other users have the same issues. This open issue appears to cover the IPNS issue most clearly, it appears IPNS can not currently be used in the browser with even the latest js-ipfs:

Yeah I wouldn’t be a bit surprised if there’s something that’s not working yet, and none of the documentation explains it. Supposedly IPFS is getting a lot of press, and growing in popularity, but when looking for code examples, I’ve found they are few and far between. The IPFS team can fix this situation any day they want, simply by creating lots more examples.