Is there a reason why no timeout implemented on the http.request? My problem is: If I request an unavailable hash, the request and its socket stays open forever, which causes problems.

Tested on DigitalOcean Ubuntu 14.04 and OS X 10.10 With node 4.0.0 and ipfs version 0.3.8-dev.
In the following code the callback is never called:

var ipfsApi = require('ipfs-api');

var ipfs = ipfsApi('localhost','5001');

var start = (new Date());
console.log( 'started on ' + start );

ipfs.ls("QmPzWqn4ZRhGFJCTnNvaz3Wwe6inKQ4n6nJic4bAw3maz3", function( err, res ) {
  console.log('got error after '+((new Date() - start)), err );
});

Hello to you all.
I am failry new with IPFS, and I am still strugling with things...

Right now, I am trying to make a very simple web service to post any file in ipfs.
Cool.

My apache configuration is the following:

• I have a domain: http://ipfs.stadja.net
• this domain is used to serve the html file post form AND the IPFS api.
• so in my domain I have a proxypass from / to my ipfs listening port
• and i have a /local alias to serve my form

my form is the following and is accessible at http://ipfs.stadja.net/local

<form action="/api/v0/add" method="post" enctype="multipart/form-data">
    Select image to upload:
    <input type="file" name="fileToUpload" id="fileToUpload">
    <input type="submit" value="Upload Image" name="submit">
</form>

So when I submit my form, the response I have is:

403 forbidden

Why ???????

My configuration works well,
http://ipfs.stadja.net/webui serves me the webui right...
Any one have any idea ? :)

Request:

http://127.0.0.1:56191/api/v0/ping?n=1&arg=QmWkMgYviPiHjfCdKkG4mmYotr5zJ

Response:

{
  "Success": false,
  "Time": 0,
  "Text": "PING QmWkMgYviPiHjfCdKkG4mmYotr5zJn3vVpMpYFCaezFQVH."
}{
  "Success": true,
  "Time": 1341453,
  "Text": ""
}{
  "Success": false,
  "Time": 0,
  "Text": "Average latency: 1.34ms"
}

When doing ipfs.add we should allow buffers to be named.

ipfs.add([{name: 'filename.txt', data: new Buffer('file contents')}], function(...) {}

This will bring the supported input to

• Filename
• Raw buffer
• Named buffer

The webui uses standard for linting.

I would support using this for all of the javascript in the ipfs ecosystem, and will prepare a pull request if noone opposes this.

Running ipfs-api from an on-disk "file:///.../index.html" does not work. Calling http.request without passing a protocol in the opts, it will default to window.location.protocol. This causes the following error:
TypeError: Failed to execute 'fetch' on 'Window': Failed to parse URL from file://127.0.0.1:5001/api/...

see dist/ipfsapi.js:5837

Could we add a way to explicitly set this protocol option? It could be passed as an opt in the requestAPI or included as a param of IpfsAPI. The latter might be preferable for this scenario so not to require a protocol opt for every method.. maybe it could be IpfsAPI(host_or_multiaddr, port, opts)?

snipped taken from circleCI logs. @dignifiedquire @victorbjelkholm thoughts? :)

> gulp test

[16:20:06] Using gulpfile ~/js-ipfs-api/gulpfile.js
[16:20:06] Starting 'test'...
[16:20:06] Starting 'test:node'...
[16:20:06] Starting 'daemons:start'...

/home/ubuntu/js-ipfs-api/node_modules/ipfsd-ctl/node_modules/ipfs-api/src/request-api.js:3
const request = require('request')
^^^^^
[16:20:07] 'daemons:start' errored after 233 ms
[16:20:07] SyntaxError: Use of const in strict mode.
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)

Add the files API option to node-ipfs-api

» ipfs files --help                                            

    ipfs files - Manipulate unixfs files

SUBCOMMANDS:

    ipfs files cp <source> <dest>  - copy files into mfs
    ipfs files ls <path>           - List directories
    ipfs files mkdir <path>        - make directories
    ipfs files stat <path>         - display file status
    ipfs files rm <path>...        - remove a file
    ipfs files read <path>         - Read a file in a given mfs
    ipfs files write <path> <data> - Write to a mutable file in a given filesystem
    ipfs files mv <source> <dest>  - Move files

    Use 'ipfs files <subcmd> --help' for more information about each command.

DESCRIPTION:

    Files is an API for manipulating ipfs objects as if they were a unix filesystem.

/api/files/{ls,read,write,mkdir,rm...}

note: only available on dev0.4.0 branch for now

would be nice if test config randomized ports or used different ports than default cause i cant run tests when my node is running

At the moment we have an examples folder but they might be outdated or broken without us knowing, so we should set up our tests to execute them to ensure they do what is expected.

ipfs add in the cli can add from the filesystem (makes sense, given the cli context). I think the js api on the browser should be able to add from the web (makes sense, given the web context).

So, i would like this to work:

ipfs.add('http://i.imgur.com/YTSpZdP.gif', function(err, res) { ... })

I think it should work on Node, too, given that node is js and already straddles the boundaries between unix and the web.

There is also an argument to be made re adding this natively to the go-ipfs cli too. (i.e. making the cmds lib accept files on http as just other files)

Currently everywhere in this module requires either a buffer or a file on disk to be used. I think we should switch to this take streams and allow the user to decide how to create that stream to pass in. This will greatly help with the ipfs-blob-store module, as well as allow this module to be more versatile.

Streams are easy to make from buffers and strings

var stream = require('stream')
var buffer = new Buffer('foo')
var bufferStream = new stream.PassThrough()
bufferStream.end(buffer)
bufferStream.pipe(process.stdout)

Source: http://stackoverflow.com/a/27964353/1489655

Thoughts?

/cc @krl

On Circle CI the tests are failing to start up, in the before block:

npm test

> [email protected] test /home/ubuntu/node-ipfs-api
> mocha

pfs node api
    1) "before all" hook

  1) ipfs node api "before all" hook:
     Uncaught Error: spawn ENOENT
      at errnoException (child_process.js:1001:11)
      at Process.ChildProcess._handle.onexit (child_process.js:792:34)

Not sure why. Googled some, but still not sure. Anyone feeling more clueful on this? @krl or @travisperson perhaps?

ipfs.add when in recursive mode fails, sometimes silently, sometimes with a EPIPE error

Example from ipsurge (which does ipfs.add(config.project, { recursive: true }, function (err, res) {}) to the project folder

» ipsurge publish                                                                           
project: src/public
[ { Name: 'bootstrap-3.3.1/css/bootstrap-theme.css',
    Hash: 'QmYxvCd18WxWiKENoVaQWc28GWBZGa2fhTtFSRejhSwFj7' },
  { Name: 'bootstrap-3.3.1/css/bootstrap-theme.css.map',
    Hash: 'QmX6HipPP2vgx49MMkR6d5U3pocEZu6QJ3SpD72cWYaVbT' },
  { Name: 'bootstrap-3.3.1/css/bootstrap-theme.min.css',
    Hash: 'Qme5EFm8fgraoXKTUNDZZPJ6qdrjABxnyPQWUob5MsP1Gu' },
  { Name: 'bootstrap-3.3.1/css/bootstrap.css',
    Hash: 'QmVNfoG6KQ9bfkAi3Hj5vNGr6cB3NXHW3Vi9Wa4hVMCfgL' },
  { Name: 'bootstrap-3.3.1/css/bootstrap.css.map',
    Hash: 'QmRoVxqYhK8jgMedNwG8rCvvx6AbJzhBKx1tsRdv8ohV86' },
  { Name: 'bootstrap-3.3.1/css/bootstrap.min.css',
    Hash: 'QmfQorLd6NvVB53MKfSLGL2ZSgGZMWrF85qyWbB3vScvkX' },
  { Name: 'bootstrap-3.3.1/css',
    Hash: 'QmRFipREcWDPhSpxb5pEAbnxxRLcQgRoyxen5VWGyiZj4q' },
  { Name: 'bootstrap-3.3.1/fonts/glyphicons-halflings-regular.eot',
    Hash: 'Qmbn92gFfZ6Pte6NYgJisE4yBA7Km1zPbkW6xscpFBB9yX' },
  { Name: 'bootstrap-3.3.1/fonts/glyphicons-halflings-regular.svg',
    Hash: 'QmVYcwoiq3JeRHj38JhioijZju4ZJHHQZGbmpPykRtvD13' },
  { Name: 'bootstrap-3.3.1/fonts/glyphicons-halflings-regular.ttf',
    Hash: 'QmPrrwHNiSVDKn7xyLxkoeS9qQh3rkE96PfMGmTUTXQXx2' },
  { Name: 'bootstrap-3.3.1/fonts/glyphicons-halflings-regular.woff',
    Hash: 'Qmac6nKjPgEMDPg8MuEfgJskonyxLX5vR8phJ6cDqE9Zgc' },
  { Name: 'bootstrap-3.3.1/fonts',
    Hash: 'QmfYd1zuEoxjSK4FoH578vDQrfJ3zeM6EN52HWYP2EN7Ue' } ]
# note: there was more files to add, but it just exited

» ipsurge publish                                                                           
project: src/public
[ { Name: 'bootstrap-3.3.1/css/bootstrap-theme.css',
    Hash: 'QmYxvCd18WxWiKENoVaQWc28GWBZGa2fhTtFSRejhSwFj7' },
  { Name: 'bootstrap-3.3.1/css/bootstrap-theme.css.map',
    Hash: 'QmX6HipPP2vgx49MMkR6d5U3pocEZu6QJ3SpD72cWYaVbT' },
  { Name: 'bootstrap-3.3.1/css/bootstrap-theme.min.css',
    Hash: 'Qme5EFm8fgraoXKTUNDZZPJ6qdrjABxnyPQWUob5MsP1Gu' } ]
err { [Error: write EPIPE]
  code: 'EPIPE',
  errno: 'EPIPE',
  syscall: 'write',
  address: undefined }

Only works well with fewer files

for example:

https://github.com/ipfs/node-ipfs-api/blob/master/examples/add.js

i am getting this error trace:

path.js:439
throw new TypeError('Arguments to path.resolve must be strings');
^
TypeError: Arguments to path.resolve must be strings
at Object.posix.resolve (path.js:439:13)
at Object.posix.relative (path.js:505:16)
at addFile (/home/dan/node_modules/ipfs-api/multipartdir.js:56:23)
at MultipartDir (/home/dan/node_modules/ipfs-api/multipartdir.js:14:5)
at getFileStream (/home/dan/node_modules/ipfs-api/index.js:151:12)
at send (/home/dan/node_modules/ipfs-api/index.js:47:16)
at Object.add (/home/dan/node_modules/ipfs-api/index.js:170:14)
at Object. (/home/dan/repos/haskell-ipfs-api/playground/contact_ipfs.js:15:6)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)

When compiling to a browser module, to then be imported to my app
example... import ipfsApi from 'ipfs-api/browser-ipfs';
where I tuck the compiled browser-ipfs file inside the node_modules/ folder and import aka require.

I get nothing. I log ipfsApi I get an empty object.

Can you provide a working example where its not just sitting as script tag in an html file, not sure if it works that way but thats what browserify suggest to do.

Would like to see it actually getting pulled into a proper ES6/Webpack/Gulp etc app that aims to spit out one JS file. Thats how modern development work for browsers these days.

Thanks!
Jeff

Hey @mappum do you still want to maintain this? or hand it off to someone else?

Could we:

• migrate this repo to ipfs org?
• add others (like @travisperson and @jbenet) as collabs in npm so we can publish?

thx

For ref: https://github.com/ipfs/node-ipfs-api/blob/solid-tests/gulpfile.js#L14-L19

Happens when trying to use ipfs-api on a stopped daemon. In the browser, with ipfsapi.min.js, it is "Uncaught (in promise) TypeError: Failed to fetch"

Would be nice to trap this so I can prompt user to check their ipfs connection

@lgierth would you handle this?

using the method ipfs.dht.findprovs in node environment does not work like one would expect. Using the following code:

var ipfsAPI = require('ipfs-api')

var ipfs = ipfsAPI('localhost', '5001')

const hash = "QmXFmCEhamPHvpbzQ3HMFABrpAXgE7D9jzp6QtvyC8Xp55"

ipfs.dht.findprovs(hash, (err, res) => {
    if(err) throw err
    console.log(res)
    console.log(typeof res)
    console.log("Streamable?", !!res.readable)
    console.log('So what to do with `res` here?')
})

I get the following output sometimes (which works correctly):

object
Streamable? false
So what to do with `res` here?

but other times, it returns this (which is neither streamable or valid json)

string
Streamable? false
So what to do with `res` here?

Originally open issue ipfs/kubo#1851 on go-ipfs but seems to be a bug in this library.

Node.js 4.1 came out and:

Buffers are now created in JavaScript, rather than C++. This increases the speed of buffer creation (Trevor Norris) #2866.
https://github.com/nodejs/node/blob/v4.1.0/CHANGELOG.md

This doesn't mean we will have the type Buffer as native in JS, but it does mean that the perf between browser and Node.js will be the same (or at least very close).

Just wanted to make sure that one touches this module, knows it :) //cc @krl

how do i call the equivalent of ipfs add -r ?

passing the filenames is not enough as i may not be in the same machine.

is there vinyl-fs support?

What

A CLI for node-ipfs-api

Why

I want to write better docs for this, although that may be being worked on in #58. I was looking through the code line by line, and I think that it would be useful to have the methods docs I am writing in not only README, but in some sort of CLI, like we have with ipfs/go-ipfs.

How

It wouldn't be too hard to get a CLI going for this, and that might be useful for running tests and checking docs before using this in the browser.

Open questions

• Would this result in confusion, given that go-ipfs already has a CLI?
• Would this result in code duplication?
• Is there a better way to display and test methods than in a CLI and a README.md combo?

The way i do ipfs-api webcomponent now is like this:

<script src='ipfsapi.min.js'></script>
<dom-module id="ipfs-api">
  <script>
    (function () {
      Polymer({
        is: 'ipfs-api',
        properties: {
          host: String,
          port: Number
        },
        url: function (path) {
          return 'http://' + this.host + ':' + this.port + path
        },
        ready: function() {
          if (!this.host) {
            var split = window.location.host.split(":")
            this.host = split[0]
            this.port = split[1] || 80
          }
          this.api = ipfsAPI(this.host, this.port)
        }
      });
    })();
  </script>
</dom-module>

This is non-ideal since it also exposes a global ipfsAPI, for self-containing reasons it would therefore be nice to have a build step, that browserifies the code + adds the polymer init stuff. We should probably also add the api commands directly to the webmodule object, instead of in .api

The reason i think it makes sense to actually publish the api as a webcomponent, is that you can use it in your browser directly, without any build steps required.

Any thought on this?
@diasdavid @jbenet

Looking at the ipfs object methods, it seems that ipfs object patch is not supported.

This would be super-useful for partial updates to IPFS hashes.

SyntaxError: /Users/aakilfernandes/projects/safemarket/grunt-ipfs/node_modules/ipfs-api/src/request-api.js:3
const request = require('request')
^^^^^
Use of const in strict mode.

using 0.12.7

Only sometimes I get this error on ipfs.ls(<hash>, cb ) and sometimes on ipfs.pin. In special when a set of executions is run.

I20151004-17:56:25.538(2)? catched error on ipfs ls { [Error: read ECONNRESET] code: 'ECONNRESET', errno: 'ECONNRESET', syscall: 'read' }
W20151004-17:56:25.539(2)? (STDERR) Possibly unhandled Error: read ECONNRESET
W20151004-17:56:25.539(2)? (STDERR)     at errnoException (net.js:905:11)
W20151004-17:56:25.539(2)? (STDERR)     at TCP.onread (net.js:559:19)

Any Idea what this could be?

ipfs/js-ipfs#32

As we already restrict the node version to be > 4 it seems very reasonable to me to start using the available ES2015 features shipping with v8 (list can be found here)

This means adding two things to support it:

1. Use babel-eslint parser for eslint instead of the standard one, as that supports all features needed.
2. Add babelify to the browserify toolchain to ensure the code still works in all browsers.

Re docs:

Make the ipfsapi.min.js available through your server and load it using a normal <script> tag, this will export the ipfsAPI constructor on the window object, such that...

However, I am seeing console.log(window.ipfsAPI) // undefined

Is documentation up to date for in-browser usage? I am trying to test out #55 (comment)

The files dist/ipfsapi.min.js and dist/ipfsapi.js are not containing the libraries code anymore, since commit f6a7da6. The only thing I can see in the files is the standard browserify code, without anything about ipfs. Seems like we're missing to source the correct files in the build-step.

/Users/david/Documents/code/ipfs/node-ipfs-api/src/index.js:25
    window && window.location) {
    ^

ReferenceError: window is not defined

with:

var ipfsAPI = require('./src')()

running on Node.js

I'd love to build off of this for a gulp plugin, but I don't see any documentation.

Looking up a base64 encoded buffer works fine with the node ipfs-api module. In the browser, it appears there's a problem converting it to a string from Uint8Array. Here is some code that encounters this

var gifData = 'R0lGODlhAQABAIAAAAUEBAAAACwAAAAAAQABAAACAkQBADs=';

ipfsApi.add(new Buffer(gifData, 'base64'), function(err, ipfsArr) {
    if (err) throw err;

    ipfsApi.cat(ipfsArr[0].Hash, function(err, blobStr) {
      if (err) throw err;
      console.log('equal:', Buffer(blobStr, 'ascii').toString('base64') === gifData);   // false
    });
});

This change -- [https://github.com/ckeenan/node-ipfs-api/commit/0a9290a17e970b8a447cd0ba4b3a202693a1dcb5] -- resolves it, but unsure if best solution

I am integrating node-ipfs-api with http://github.com/fedwiki/wiki-node and would be very thankful if the API documentation could be improved. Specifically, I would like to have the complete list of API methods with its docs and examples...

thanks!

Waiting for 0.3.9 release //cc @whyrusleeping

The pin.remove command needs to be able to send the recursive options, and probably the pin.add command as well.

Something along the lines

remove: function(hash, opts, cb) {
  if(typeof opts === 'function') {
    cb = opts
    opts = null
  }

  send('pin/rm', hash, opts, null, cb)
}

This will be possible given #3 is incorporated. Folder sturctures can be send to IFPS by nesting multipart/form-data structures into a single part.

Example request:

User-Agent: /node-ipfs-webui/0.1.0
Content-Type: multipart/form-data; boundary=knyfc6alrmu9dx6rfis020litgknvcxr

--knyfc6alrmu9dx6rfis020litgknvcxr
Content-Type: multipart/form-data; boundary=lugqob2u0zjb57b9nz5l6ggohxrjxlxr
Content-Disposition: folder; name="folder"; filename="afolder"

--lugqob2u0zjb57b9nz5l6ggohxrjxlxr
Content-Type: application/octet-stream
Content-Disposition: file; name="file"; filename="FileA.txt"

A file inside of a folder!
--lugqob2u0zjb57b9nz5l6ggohxrjxlxr
Content-Type: application/octet-stream
Content-Disposition: file; name="file"; filename="FileB.txt"

Another file inside of a folder!
--lugqob2u0zjb57b9nz5l6ggohxrjxlxr--
--knyfc6alrmu9dx6rfis020litgknvcxr--

Most environments now support the more pleasant API of Promise ( https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Promise.jsm/Promise ), that is easier to handle and chain together. We should think about migrating to start using promises instead of callbacks where applicable.

List of browsers that supports it current: https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Promise.jsm/Promise
(IE doesn't support it + some olders versions of other browsers, probably have to provide an existing shim as well...)

In node, promises have been natively supported since 0.12 so shouldn't be an issue there.

The add method (with recursive: true) isn't returning properly-formatted JSON for me. Instead I get a string that almost looks like JSON, but isn't actually, so to parse it I have to do some string mangling. Example:

var ipfs = require("ipfs-api")("localhost", "5001");
ipfs.add("./ipfs", {recursive: true}, function (err, res) {
            if (err || !res) return console.error(err);
            console.log(res);
});

This prints out:

{
  "Name": "funcrusher.json",
  "Hash": "QmUSpeNRKrYHRG55WvYTi5u3VVHaP3uHtH1mDKCB9Qa9AJ"
}{
  "Name": "ipfs",
  "Hash": "QmYuDw2SxfWkFasmmenzsdKSV7QVHAEuevAuCjcDh8kEYt"
}{
  "Name": "",
  "Hash": "QmWike1KhJRzY4EMtreidZDgq1EhYpLY444pfVJxxD3wSp"
}

(Note the lack of commas between the objects, and lack of enclosing array brackets.)

As some might have seen or read I'm currently suggesting to move away from using raw http.request and if possible to drop the code in src/get-files-stream.js, which is mostly using vinyl to generate a nested multipart requests of the files to be uploaded to the API. But as @jbenet pointed out on IRC I have not properly explained why I make these suggestions and why I think doing so would be very beneficial for this module.

To understand my reasoning let me formulate the main goals for this project as I understand them:

1. Provide a small and simple wrapper around the http API of ipfs daemon
2. 100% compatibility between node and browser
3. Do not reinvent/reimplement the wheel, unless there is a very good reason to do so

Part 1: Drop direct usage of http.request

A lot of the code in this project is reimplementing things that already have been implemented and battle tested in other modules, when it comes to the usage of http.request. Two main projects come here to mind request and superagent. As explored in #92 the only request module that will do everything we need and has excellent support for node and browser seems to be request. The initial reason for exploring these options for me was #69 which has strong implications for the stability of station.

Part 2: Drop vinyl if possible

First vinyl on its own is a representation of the file system in memory and a nice API around it to access it. This taken on itself is nothing bad in any way, but does not need to be in this module in my opinion as it adds additional bloat which in the browser has very little relevance, as the power of vinyl comes from it being able to actually access the file system in the background to read it in.

we'll still need something like it (a js object to represent a file before reading it all in).
@jbenet (IRC)

From my understanding, we do not need a representation of a file object in this API wrapper. Application code around this API might very well need it, but for the purposes of uploading files via the http API there are more straight forward ways to do it:

1. [browser][node]: The content of a file and the filename are passed: We can directly generate a multipart request from this.
2. [node]: The path to a file is passed: Use fs.createReadStream to read the file from the file system and generate the multipart stream
3. [node]: The path of a directory is passed: Use something like glob to walk the directory and convert into the same structure as 2.
4. [browser]: The content of a directory of files is passed: Use the conversion from 3. to generate the multipart request.

I hope this explanation makes my thinking and efforts more understandable and sorry again for not writing this up earlier but parts of this were simply only understood by me when doing the research and work.

Adding a file at a path that contains open and close square brackets doesn't work. No error, but the response name is blank and the hash points to an empty directory.

Steps to reproduce:

ipfs.add('[TEST]/test.txt', function(err, res) {
    console.log(err, res);
})

I'm expecting this response:

[ { Name: 'text.txt',
Hash: 'Qmazm4yVXBrbJfLsscsNdTUwZ6yFMfjNoV26vKHMyjm9qw' } ]

but get this instead:

[ { Name: '',
Hash: 'QmUNLLsPACCz1vLxQVkXqqLX5R1X345qqfHbsf67hvA3Nn' } ]

which points to an empty directory.

So, I'm trying to have a couple of IPFS machines to mirror some content. So I've setup two boxes to test, and assign them to different variables and I expected that I would be able to call them separately but there is apparently some sharing in between them...

Example:

var ipfsAPI = require('ipfs-api')

var d1 = ipfsAPI('/ip4/127.0.0.1/tcp/5001')
var d2 = ipfsAPI('/ip4/127.0.0.2/tcp/5001')

d1.id(function(err, res) {
    console.log(res.ID) // => id for d2
})
d2.id(function(err, res) {
    console.log(res.ID) // => id for d2
})

The last one is the one being used.

The add method no longer works.
The simple test case is to run the 'add.js' example.
1.1.2 used to work

ipfs.add have a kind of confused API (the same with some other methods), that it's sometimes returning a stream and sometimes an object. I think this is because of the environment but we should try to make sure that inside the callback, users don't have to try to figure out what type it is, it should always be the same type.

Will also help simplifying the tests for browser/node environments.

I am using this package in combination with Meteor. The latest version will crash in Safari with the following error: Cannot declare a parameter named 'mask' as it shadows the name of a strict mode function. So far, I traced it back to this function on line 30299 in the ipfsapi.js:
ip.mask = function mask(addr, mask) {