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:
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:
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.
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.
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.
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. 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?
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.
