Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JS-IPFS now incompatible with https://ipfs.io gateway #1380

Closed
rodkeys opened this issue Jun 4, 2018 · 7 comments
Closed

JS-IPFS now incompatible with https://ipfs.io gateway #1380

rodkeys opened this issue Jun 4, 2018 · 7 comments
Labels
kind/bug A bug in existing code (including security flaws) P0 Critical: Tackled by core team ASAP

Comments

@rodkeys
Copy link
Contributor

rodkeys commented Jun 4, 2018

Version: 0.29.1
Platform: 64-bit (Windows)
Subsystem: XXX

Type: Bug

Severity: High

Description: A few weeks ago I was able to successfully add files from JS-IPFS and access them from public gateways such as ipfs.io. I am no longer able to have my files found from any of the public gateways. I am connected to approximately 100 peers on average. I have tested this issue on multiple VPS's in different locations.

Steps to reproduce the error: Add a unique file and try to access its hash through the ipfs.io gateway. My node initialization code is listed below.

const IPFS = require('ipfs');
node = new IPFS({
  config: {
    EXPERIMENTAL: {
      pubsub: true
    },
    repo: 'ipfs-' + Math.random(),
    Addresses: {
      Swarm: [
        '/dns4/ws-star.discovery.libp2p.io/tcp/443/wss/p2p-websocket-star'
      ]
    }
  }
});
@daviddias daviddias added kind/bug A bug in existing code (including security flaws) P0 Critical: Tackled by core team ASAP labels Jun 4, 2018
@daviddias
Copy link
Member

daviddias commented Jun 4, 2018

Hi @rodkeys. There has been a needed infrastructure change on the IPFS Gateways. This change means that a js-ipfs node doesn't connect to the Gateway nodes anymore.

Once #856 and/or libp2p/js-libp2p#120 + go-ipfs 0.4.15 is released, you will be able to access files from the ipfs.io gateways again.

@daviddias daviddias added the status/ready Ready to be worked label Jun 4, 2018
@daviddias
Copy link
Member

daviddias commented Jun 4, 2018

More context given @alanshaw's ping on IRC:

10:29 <alanshaw> daviddias: can you fill me in on what happened here: https://github.com/ipfs/js-ipfs/issues/1380 ?
10:34 <@daviddias> alanshaw the Summary is that the ipfs.io Gateways changed its setup to use Anycast
10:34 <@daviddias> And so, when you ping ipfs.io, you now get routed around the world to the best gateway to attend
10:35 <@daviddias> This gives the infrateam a way to scale up and down the number of gateways
10:35 <@daviddias> what it also means is that we don't know how many are there and so the js-ipfs node doesn't know who to connect
10:35 <@daviddias> A potential patch is to just let DNS tell us how many there are at any given moment -- https://github.com/ipfs/infrastructure/issues/410 -- so that we can connect
10:36 <@daviddias> but ideally what we should is have DHT + Circuit Relay finalized

@mitra42
Copy link

mitra42 commented Jun 4, 2018

It looks like this is blocking the opposite as well - could this be causing the problem where files added on the go nodes are no longer retrievable from the js-ipfs. Since we've seen other bugs with that route I'm not sure its this Issue causing what appears to be files not being found.

@parkan
Copy link
Contributor

parkan commented Jun 4, 2018

I think we can work around this by directly dialing a wss go-ipfs node from js in the meanwhile, does that make sense @diasdavid? (for demo purposes, aware that this would be fragile)

@daviddias
Copy link
Member

daviddias commented Jun 4, 2018

Indeed we can as long as those Infra nodes are easy to find -- ipfs/infra#410 -- and they are listening on websocket secure multiaddrs.

@daviddias
Copy link
Member

daviddias commented Jul 29, 2018

It's compatible again with #1458, try it out and let us know how it goes :)

@ghost ghost removed the status/ready Ready to be worked label Jul 29, 2018
@buzz
Copy link

buzz commented Jul 29, 2018

Confirming it works! Yeah! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug A bug in existing code (including security flaws) P0 Critical: Tackled by core team ASAP
Projects
None yet
Development

No branches or pull requests

5 participants