Uploaded file via Spawned Node not accessible via public gateway

[hhff]

I'm building a deploy step for a simple JS app. My understanding of the steps required to propogate something to IPFS via the JS wrapper is:

1. Build App (via Webpack etc)
2. Create buffers / readable streams for built files
3. Spawn IPFS node via `let node = new IPFS()`
4. Upload files via `node.files.add`

Write now, the code is as follows:

let node;
return new RSVP.Promise(function(resolve, reject) {
  node = new IPFS();
  node.on('ready', () => {
    // file here will eventually comprise a built web app
    let file = new node.types.Buffer('/hello.txt');
    node.files.add([{
      path: '/hello.txt',
      content: file
    }], function(err, files) {
      if (err) { return reject(err); }
      return resolve(files);
    });
  });
}).finally(() => {
  if (node) node.stop();
});

This resolves a hash successfully without throwing err. However, when I navigate to
https://gateway.ipfs.io/ipfs/${files[0].hash}, the file doesn't actually resolve.

What am I missing here?

I'm guessing that while the file has uploaded to the local node, it gets stopped before the file has propagated to a permanent node on the network. If that's correct, how do I know how to keep the local node alive long enough for it to propagate to the gateway?

[victorb]

Files are not automatically propagated to other nodes but rather fetched when requested. So you will have to run your node until the other party have fetched the content. In this case, you seem to call `node.stop()` as soon as the `add` call is done, which means you add the file to your local node correctly, but you stop it as soon as it's been added, making it so you cannot fetch the file from any other node.

…

On Fri, Jun 30, 2017 at 1:51 AM, Hugh Francis ***@***.***> wrote: I'm building a deploy step for a simple JS app. My understanding of the steps required to propogate something to IPFS via the JS wrapper is: 1. Build App (via Webpack etc) 2. Create buffers / readable streams for built files 3. Spawn IPFS node via `let node = new IPFS()` 4. Upload files via `node.files.add` Write now, the code is as follows: let node;return new RSVP.Promise(function(resolve, reject) { node = new IPFS(); node.on('ready', () => { // file here will eventually comprise a built web app let file = new node.types.Buffer('/hello.txt'); node.files.add([{ path: '/hello.txt', content: file }], function(err, files) { if (err) { return reject(err); } return resolve(files); }); }); }).finally(() => { if (node) node.stop(); }); This resolves a hash successfully without throwing err. However, when I navigate to https://gateway.ipfs.io/ipfs/${files[0].hash}, the file doesn't actually resolve. What am I missing here? I'm guessing that while the file has uploaded to the local node, it gets stopped before the file has propagated to a permanent node on the network. If that's correct, how do I know how to keep the local node alive long enough for it to propagate to the gateway? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#886>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcD9C0EskR-T5ZyGcBIjoqlPcj30sQKks5sJDh1gaJpZM4OJ_63> .

[hhff]

Thanks @victorbjelkholm - makes sense!

I'll add a step that fetches the file from the public gateway (probably just via a HEAD request) after I receive the hash, and keep the node alive until that's successful.

Does that seem like a sane approach?

Also, if I uploaded a directory, would I need to make that HEAD request for each file, or is it fine to just make it once for the hash that corresponds to the root directory?

[victorb]

Yeah, that's a way you can cache content on the public gateways. Please note that the content can be removed from the public gateways at any time, since GC will clear data that has not be pinned on the gateway nodes. For directories, yes, request per file since otherwise the gateway will just cache the directory listing and not the files themselves.

…

On Fri, Jun 30, 2017 at 6:54 PM, Hugh Francis ***@***.***> wrote: Thanks @victorbjelkholm <https://github.com/victorbjelkholm> - makes sense! I'll add a step that fetches the file from the public gateway (probably just via a HEAD request) after I receive the hash, and keep the node alive until that's successful. Does that seem like a sane approach? Also, if I uploaded a directory, would I need to make that HEAD request for each file, or is it fine to just make it once for the hash that corresponds to the root directory? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#886 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAcD9KLqFEnQYiX4s7vVyEM7D4SQORrsks5sJSgygaJpZM4OJ_63> .

[hhff]

Ah! Thankyou.

How do I go about pinning content via JS? I want to be sure the deploy is permanent.

I'm also running a node on a VPS (digital ocean) - but haven't made it accessible to the outside world yet.

(Going to write an article about this so will link back here to help others understand!)

[hhff]

Success! Thanks @victorbjelkhom ! Built app is available here: www.ember-cli-deploy-ipfs.com (although IPNS seems very slow).

Am I right in thinking that running:
ipfs name publish ${rootHash}

Is the same as "pinning"? Or is that a different concept?

[daviddias]

Hi @hhff! great to see that this got figured out, thanks @victorbjelkholm for jumping in :)

ipfs name is for IPNS names, our distributed naming system that gives you mutable pointers in the network. What you are looking is for ipfs pin.

We have a WIP PR for the pinning API in js #107, it is missing the update to use the new IPFS Repo datastore and more tests. If you wanna help on that, it will be hugely appreciated :)

[hhff]

Thanks @diasdavid - I'll take a look at the pinning PR and see if I can lend a hand.

Naming is another important part of the deploy step (that's how we'll do the activation of the new deploy) - are there any plans to supporting ipfs name in the JS lib?

[victorb]

@hhff currently, we have this issue to track the work on IPNS: #209

But I think that issue needs an update. Last time I've spoken with @diasdavid and @dignifiedquire we're planning to start working on IPNS once dht is ready and done for js-ipfs, dht work is being tracked here: #856

Edit: just updated the issue

[daviddias]

Closing this issue, track IPNS at #209 :)

[hhff]

Awesome - TY!

…

On Fri, 7 Jul 2017 at 9:19 am, David Dias ***@***.***> wrote: Closing this issue, track IPNS at #209 <#209> :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#886 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACu4_GQqzYYRFhiTDlQAfBO_S4QxpZPmks5sLjBCgaJpZM4OJ_63> .