IPNS Publish Does not work in JS-IPFS 0.54.2

[TJKoury]

Publish doesn't work (jsipfs name publish $(CID)) using Ubuntu 18.04 LTS, Node 15, js-ipfs 0.54.2.

Running two physical servers, both can see each other (jsipfs swarm peers |grep $(peerID)), both running RSA keys, both can resolve the IPFS CID for the content, but both report record requested for $(IPNS_hash) was not found on the network.

Both can resolve their own IPNS hash.

Go-IPFS can also see the peers but fails after about 30 seconds with the go-equivalent error Error: could not resolve name.

I have not tested any other version of js-ipfs.

Originally posted by @TJKoury in ipfs/kubo#7965 (comment)

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[TJKoury]

In addition, did force dht by setting Routing.Type to dht (tried dhtclient / dhtserver as well).

[TJKoury]

Also, tried setting libp2p.config.dht.enabled to true.

[vasco-santos]

Hey @TJKoury
The js DHT implementation needs some work to be fully functional and it is disabled by default for now as the reasoning. People can experiment with it, but not recommended for production yet.
Did you try using IPNS over Pubsub instead?

[TJKoury]

I have not, it’s next in my list. I have tried everything to be able to use it without actually changing any code; it’s safe to say that by “experiment” you mean making code changes, I’m assuming to lib-p2p?

…

On Tue, Mar 9, 2021 at 8:37 AM Vasco Santos ***@***.***> wrote: Hey @TJKoury <https://github.com/TJKoury> The js DHT implementation needs some work to be fully functional and it is disabled by default for now as the reasoning. People can experiment with it, but not recommended for production yet. Did you try using IPNS over Pubsub instead? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFW4KA4UITGBLXGGIJOABLTCYQBJANCNFSM4Y2GNV7A> .

[vasco-santos]

I have not, it’s next in my list. I have tried everything to be able to

You can have a look in this: https://github.com/ipfs/js-ipfs/tree/master/examples/browser-ipns-publish (it is in the browser though)

“experiment” you mean making code changes

experiment I mean to try out stuff using the current implementation by manually enabling it like you mentioned. We need to get the DHT updated like go-libp2p DHT was last year and get it properly tested in a larger scale before recommending its usage and eventually have it enabled by default.

Anyway, the insights I have from the go team is that IPNS is performing way better when using pubsub (they also have added a pubsub fallback that we need to add in JS)

[TJKoury]

Yup, already checked that out and will try today. Good to hear about the performance, makes sense when switching to a reactive model.

…

On Tue, Mar 9, 2021 at 9:17 AM Vasco Santos ***@***.***> wrote: I have not, it’s next in my list. I have tried everything to be able to You can have a look in this: https://github.com/ipfs/js-ipfs/tree/master/examples/browser-ipns-publish (it is in the browser though) “experiment” you mean making code changes experiment I mean to try out stuff using the current implementation by manually enabling it like you mentioned. We need to get the DHT updated like go-libp2p DHT was last year and get it properly tested in a larger scale before recommending its usage and eventually have it enabled by default. Anyway, the insights I have from the go team is that IPNS is performing way better when using pubsub (they also have added a pubsub fallback that we need to add in JS) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3584 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFW4KG2W45MPRWVACCVU63TCYUW3ANCNFSM4Y2GNV7A> .

[TJKoury]

FYI, due to this issue, need to downgrade parcel-bundler to 1.12.3 for this example to run. Not submitting a pull because the issue is being actively worked over at parcel, will probably be ok soon.

[TJKoury]

API connection works ok, websockets error Error: No transport available for address. Tried manually connecting a socket, was able to open a connection from browser console and telnet.

[TJKoury]

Still not working, using the same settings in the example folder. Before I deconstruct the entire example for debugging, @vasco-santos anything obvious I'm missing?

[TJKoury]

Test still failing on fresh install.

Browser IPFS ready! Node id: Qmajeh6MvDHucLvyfEEH7cxTKXmxUZyE7h9kTbFxFeAnXx
   Connecting to /ip4/127.0.0.1/tcp/42245
   Success!
   Version go-ipfs/0.8.0/
   Peer ID 12D3KooWGVTSyhvFQVMZQVF55cFhZd9FUpk2RimyxvRY22hXBEZy
   Connecting to peer /ip4/127.0.0.1/tcp/41633/ws/p2p/12D3KooWGVTSyhvFQVMZQVF55cFhZd9FUpk2RimyxvRY22hXBEZy
   Error: No transport available for address /ip4/127.0.0.1/tcp/41633/ws/p2p/12D3KooWGVTSyhvFQVMZQVF55cFhZd9FUpk2RimyxvRY22hXBEZy at c.dial (http://127.0.0.1:57565/browser-ipns-publish.0579e265.js:2039:1958) at l.dialAction (http://127.0.0.1:57565/browser-ipns-publish.0579e265.js:2093:2581) at http://127.0.0.1:57565/browser-ipns-publish.0579e265.js:2091:1283 at async http://127.0.0.1:57565/browser-ipns-publish.0579e265.js:2087:505" (60099ms)
       at AsyncFunction.module.exports.<computed> [as browser-ipns-publish] (/home/tj/software/js-ipfs/examples/browser-ipns-publish/test.js:118:6)
       at processTicksAndRejections (node:internal/process/task_queues:94:5)

[vasco-santos]

There is no transport available for that address mean the transports you have configured do not support tcp.

Browser does not support TCP, so you will need to configure websockets on your go-ipfs node. You can add in your configuration file:

"Addresses": {
    "Swarm": [
      "/ip4/0.0.0.0/tcp/4001",
      "/ip4/0.0.0.0/tcp/4010/ws",

This will mean that go-ipfs will have a listener for websocket connections on port 4010. Browser nodes will be able to use this for establishing connections with it.

[TJKoury]

So does this mean the example is not supposed to run out of the box? If I get it working by changing the config in the test file using the go-ipfs package, should I submit a pull?

[vasco-santos]

The example has instructions for setting up the websocket transport on https://github.com/ipfs/js-ipfs/tree/master/examples/browser-ipns-publish#install-and-start-the-go-ipfs-node

[TJKoury]

@vasco-santos Talking about the example in the folder that has this in the config:

 Swarm: [
            "/ip4/127.0.0.1/tcp/0/ws",
          ]

Still failing with this config.

[TJKoury]

Even putting in hard-coded ports instead of '0' gets the same error with those ports:

Error: No transport available for address /ip4/192.168.1.227/tcp/4010/ws/p2p/12D3KooWNMPCseLnP8GvxuxEDCeTgL7EV1RLdtWBMt6vDwQPiGG6 at c.dial

From what I can tell the example just does not work.

[vasco-santos]

Ok, so I imagine that when you start your go node now, you can see it is listening on websockets, is this correct?

There is also a problem on the JS side. Apologies for not going directly into this particularity, but I did not realize we did not update this in this example. The websockets transport is not being used and the problem is related to the usage of a local address. Long story short, browser policies only allow dials when using WSS+DNS addresses, which is a pain because you need to configure that yourself on the go node. More context: protocol/web3-dev-team#70

With the above in mind, we blocked these types of dial by default in libp2p. For local experimenting, you can have this changed. You can check how to do this here. This basically allows localhost experimentation. You will probably need to use a localhost address for the go-ipfs node, in order to properly dial it.

If you are interested in updating the IPNS example with this configuration, it would be super helpful

[alensiljak]

You will probably need to use a localhost address for the go-ipfs node, in order to properly dial it.

Thanks for all the tips! I got it working using all of the above plus referencing the go node (2nd step) with

/ip4/127.0.0.1/tcp/4003/ws/p2p/12D3KooWSa7rHTYFw7aDmZv6SqosyY8HeLstqhon4nJ68rfVJ7wo

since it seemed to be hanging with /wss.

Results: