The next major subsystem to do is the DHT.

The rough plan in order of importance:

• basic kademlia alg (ipfs-dht) <-- enough for now.
• coral locality clusters (ipfs-dht)
• s/kademlia disjoint path lookups (ipfs-dht)
• s/kademlia peer addressing (ipfs-peer)
• s/kademlia signatures (ipfs-msgproto-crypto)

Note that this module should work on top of a msgproto packet stream. msgproto handles all standard encapsulation (network, integrity, signing, etc).

Add to cli: ipfs pin [-r] <ipfs-path>

node-multistream

https://github.com/diasdavid/node-multistream

Follows https://github.com/jbenet/multistream/tree/master/multistream spec

How you can help

• make code coverage go up to 100%

The swarm API enables IPFS users to learn about their connected peers and connect to other peers if desired

To learn more about the swarm API, you can:

• read about libp2p and how ipfs swarm features are implemented on top of libp2p - https://github.com/ipfs/specs/tree/master/libp2p

Implementation Roadmap

• jsipfs daemon - turn own swarm when it boots up
• jsipfs swarm peers
  • core
  • http-api
  • cli
• jsipfs swarm connect
  • core
  • http-api
  • cli
• jsipfs swarm disconnect
  • core
  • http-api
  • cli
• jsipfs swarm addrs
  • core
  • http-api
  • cli
• jsipfs swarm addrs local
  • core
  • http-api
  • cli

node-libp2p-swarm

https://github.com/diasdavid/node-lib2p-swarm

This module is currently under a major refactoring, keep posted for updates.

Record System

Modules that are part of the Record System are about to change due to recent finding ipfs/specs#24 (comment)

Once we decided on a good solution for this issue, the development will continue and I will update the issue

Aye mates!

This is your captain speaking, the IPFS Node.js ship as been to set sail and good winds are blowing! Thank you for all the messages and enthusiasm shared so far, we truly appreciate your support and since some of you are eager to get their hands on code and help with the development, I'll keep this issue updated every week with what has been going on and where you can help the most. To make sure you don't miss any updates, click the 'watch' button on the repo.

LOG - Week of 21st of September

Plan:

• Finish Swarm revisit
  • https://github.com/diasdavid/node-ipfs-swarm/issues/8
  • https://github.com/diasdavid/node-ipfs-swarm/tree/revisit
• Implement node-libp2p bindings for every other module that is part of libp2p and have a alpha release people can experiment with
  • https://github.com/diasdavid/node-libp2p

Where you can help during this week:

• If crypto is your thing, take a look at
  • daviddias/webcrypto#1
  • nodejs/node#2833
• If dream with tests and code coverage, there is a bunch of repos that could use some love
  • https://github.com/ipfs/node-ipfs#roadmap

Interact with raw blocks in the datastore. It uses IPFS-repo to store and get blocks

To learn more about the Block API, you can

• check out the go impl https://github.com/ipfs/go-ipfs/tree/master/blocks
• read datastore spec https://github.com/ipfs/specs/tree/master/repo#datastore

Implementation Roadmap

• ipfs-blocks JavaScript implementation https://github.com/ipfs/js-ipfs-blocks
• jsipfs block get - Get a raw IPFS block.
  • core
  • http-api
  • cli
• jsipfs block put - Stores input as an IPFS block.
  • core
  • http-api
  • cli
• jsipfs block del - Deletes a stored block.
  • core
  • http-api
  • cli
• jsipfs block stat - Print information of a raw IPFS block.
  • core
  • http-api
  • cli

The files API offers an interface to work with unixfs, a Merklelized Data Structure that represents a typical FileSystem used in a Unix OS. with files, dirs and symlinks. This API is what enables IPFS to add and retrieve files without having to ask the users to convert their data into a graph data structure.

To learn more about the Files API, you can

• watch https://www.youtube.com/watch?v=FX_AXNDsZ9k
• check files (mfs) implementation in go https://github.com/ipfs/go-ipfs/tree/master/mfs
• check unixfs implementation in go https://github.com/ipfs/go-ipfs/tree/master/unixfs

Implementation roadmap

• Files API spec ipfs/specs#88
• Unixfs Spec
• jsipfs files add (current ipfs add)
  • #67
• jsipfs files cat (current ipfs cat)
  • cat subfiles
• jsipfs files get (current ipfs get)
• jsipfs files mv - Move files.
• jsipfs files cp - Copy files into mfs.
• jsipfs files ls - List directories.
• jsipfs files mkdir - Make directories.
• jsipfs files stat - Display file status.
• jsipfs files rm ... - Remove a file.
• jsipfs files read - Read a file in a given mfs.
• jsipfs files write - Write to a mutable file in a given filesystem.

As discussed on the Oct 26 Sprint meeting, we will be renaming the prefix of any of our github repos that contain any JavaScript module, from 'node-' to 'js-'.

This decision came from hearing the feedback from the IPFS community, where there was always some confusion with the words 'node' and 'ipfs' and also a the lack of clarity if a module is supposed to be Node.js only. 'node' is a very overloaded word in the IPFS context.

This doesn't mean however that we will be leaving the npm ecosystem, npm will still be the tool of choice when it comes to publishing and installing this JavaScript modules.

We will be rotating the repo names starting of today, this should not change the behaviour when installing one of these modules or break any CI tools, since we always published to npm without the prefix.

List of repos suffering this change (let us know if we miss any):

• https://github.com/ipfs/node-ipfs
  • open issue to link to this one
  • rename
  • update README
• https://github.com/diasdavid/node-libp2p
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-peer-info
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-peer-id
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-kad-routing
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-mdns-discovery
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-random-walk
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-railing
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-swarm
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-ipfs-ping
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-tcp
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-udp
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-udt
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-utp
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-spdy-stream-muxer
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-multistream
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-record
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-distributed-record-store
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-libp2p-kad-record-store
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-bitswap
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-ipld
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/diasdavid/node-merkledag-store
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/jbenet/node-multihash
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/jbenet/node-multihashing
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/jbenet/node-multiaddr
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/ipfs/node-ipfs-api
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/ipfs/node-ipfs-path
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm
• https://github.com/ipfs/node-ipfsd-ctl
  • open issue to link to this one
  • rename
  • update README
  • update github link on package.json
  • publish to npm

One of the core pieces to get jsipfs working, is having a IPLD importer (file -> chunker -> merkleDAG), so that we can create MerkleDAG structures that can be used to be moved around bitswap.

The goals of the importers are described here - https://github.com/ipfs/specs/blob/master/overviews/implement-ipfs.md#ipld-data-importing

Probably it is possible to use some of the work developed by @mafintosh on his hyperdrive module, which although focuses on rabin chunking, should be easy to detach and use another chunking algorithm.

This takes me to my next point. It would be great to have a set of primitives to digest, chunk and parse files, so that different chunkers can be replaced/added without any trouble. Similar to the efforts we've been doing for libp2p interfaces.

(repo, config, fs, etc)

This issue focus on detailing the improvements we are committing to do for js-ipfs milestone 1.

ipfs-blocks holds the Block data structure and the block-service.

https://github.com/ipfs/js-ipfs-blocks

TODO list:

• increase code coverage to 100%
• enable circle-ci
• update release process to the dignified pipeline
• examples
  • creating and manipulating a Block
  • using the Block Service
• ensure that every API call is documented

I've started working on this on #45, but as the HTTP API is in flux/being written (between a RPC vs REStful discussion), I'm going to defer this until that part is spec.

Whole spec ipfs/specs#65
HTTP API spec - https://github.com/ipfs/api

• add
  • core
    • tests
  • http-api
    • tests
  • cli
    • tests
• rm
  • core
    • tests
  • http-api
    • tests
  • cli
    • tests
• list
  • core
    • tests
  • http-api
    • tests
  • cli
    • tests

Via @diasdavid:

It would be pretty sweet to grab this func and also the logic to 'inject' a go-ipfs repo (found in index.js and browser.js) and make a utils file that can be used across tests that can 'create and teardown a go-ipfs generated repo' and 'create and teardown a fresh baked repo.

We ought to gracefully use port zero (like go-ipfs).

  1) http api "before all" hook:
     Uncaught AssertionError: expected [Error: listen EADDRINUSE 127.0.0.1:9090] to not exist
      at tests/test-http-api/index.js:18:27
      at src/http-api/index.js:55:18
      at node_modules/hapi/lib/server.js:269:20
      at done (node_modules/hapi/node_modules/items/lib/index.js:23:21)
      at Server.onError (node_modules/hapi/lib/connection.js:163:16)
      at emitErrorNT (net.js:1253:8)

node-libp2p-mdns-discovery

https://github.com/diasdavid/node-libp2p-mdns-discovery

Node.js libp2p mDNS discovery implementation. mDNS is used to discover IPFS peers in a local area network.

How can you help

• Add more tests for code coverage to 100%

node-ipfs-railing

https://github.com/diasdavid/node-ipfs-railing

Simple module to parse a list of bootstrap peers list, attempt to connect to them and return which ones are reachable and valid, so that we can populate our DHT initially. This process is known on the P2P literature as Railing

How you can help

• Write tests to 100% coverage
• Add CI

minimum spec

• network
  • NAT Traversal
  • TCP
• routing
  • mDNS
  • DHT
• exchange
  • bitswap
• merkleDAG

validate the usefulness of code already created (deprecate/rebuild/good)

• network
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-network-pipe
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-network
• routing
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-peer-book
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-peer
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-dht-routing
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-dht
  • ~~https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-message~~(deprecated)
• exchange
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-storage
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-bitswap
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-block
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-blocks
• merkleDAG
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-object
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-objects-git
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-path-resolver
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-path
• not a concern for now or didn't understand what they were
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-cli
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-core
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-errors
  • https://github.com/ipfs/node-ipfs/tree/master/submodules/ipfs-mount

The go is to go through these modules, understand what stays, what leaves and what is missing compared to the go-ipfs. (probably will draw some ASCII art after I get this into my head, sometimes helps to think and communicate better)

candidate attack plan:

• Write down the spec of what is necessary to get a working node-ipfs node ( @jbenet )
• Write down (or point out) the spec for how things are put on the wire by go-ipfs, so we can do a tiny node thing that assures that we are using the same. @whyrusleeping @jbenet maybe it would be cool to strip out a tiny test example from go-ipfs just to make sure we get node-ipfs right. note: consider if spdy is going to be a concern of this first impl. - https://github.com/ipfs/specs/blob/wire/protocol/network/wire.md
• Get go-ipfs and node-ipfs talking (based on the previous item) (@diasdavid )
• Get DHT working over local network (@diasdavid )
• Get mDNS working (@diasdavid)
• Get NAT traversal working
• Get bitswap working
• Get MerkleDAG working

I understand you want to modularize the project, but breaking up into a huge tree of git submodules is a little insane. Node already uses a module system by default, so we can put the same module structure you designed into directories. Each one as its own repo just makes the project a pain to maintain and to contribute to. If we move the modules into directories we will barely need to change the code, since the modules can still be loaded via require.

There are projects with similar scope/size, and they all work great with the standard Node way of organizing modules. (E.g. Dat, which I know you've contributed to).

Overall, the current structure adds painful management overhead, will likely scare off contributors, and doesn't provide anything over the built-in Node module system. Should I go ahead and refactor?

The pin command let's you control what hashes (blocks) are not garbage collected, meaning that they are not removed unless you specifically tell the IPFS node to do so.

To learn more about the pinning, you can

• check go implementation https://github.com/ipfs/go-ipfs/tree/master/pin

Implementation Roadmap

• complemente core object implementation #58
• jsipfs pin add ... - Pins objects to local storage.
• jsipfs pin rm ... - Removes the pinned object from local storage. (By default, recursively. Use -r=false for direct pins).
• jsipfs pin ls []... - List objects pinned to local storage.

Once js-ipfs milestone 1 is reached, we will start seeing more applications that will use IPFS and perhaps even depend fully on it in order to work. It is very important that we standardise as most as possible the core-API, so that we save our users from countless upgrading hurdles.

This will also help us identify how IPFS should be used directly. While we are at it, we must update js-ipfs-api to expose the same interface, so that apps can exchange between a full node and one accessible through an http-api without a problem.

TODO list:

• define the core-api spec ipfs/specs#85
• update all of js-ipfs core api calls to follow the spec
• update all of js-ipfs-api core api calls to follow the spec

node-ipfs-random-walk

https://github.com/diasdavid/node-ipfs-random-walk

Node.js IPFS implementation of the discovery service through DHT random walking

In order to refresh the peers in our k-buckets for the Kademlia DHT, we perform 'random-walks' on the DHT, finding leaf peers, so that we can consider them for our k-buckets.

How you can help

• build the module
  • write the docs
  • write the tests
  • 100% code coverage

What are the things that occur during a ipfs init? (From key generation, if those base files are c&p or fetched from the network, etc). It would be good to make this part of IPFS spec itself.

Implementation roadmap

• define/list what happens on an ipfs init
• jsipfs init
  • core
  • http-api
  • cli

node-multihashing and multihash

https://github.com/jbenet/node-multihashing
https://github.com/jbenet/node-multihash

Use all the functions in multihash.

Wait, why, how is this different from Node crypto?
This module just makes working with multihashes a bit nicer. node-multihash is only for encoding/decoding multihashes, and does not depend on other libs. This module will depend on various implementations for each hash. For now, it just uses crypto, but will use sha3 and blake2, etc.

How you can help

• Make tests
• Code Coverage to 100%

stream-muxing

https://github.com/diasdavid/node-spdy-stream-muxer
https://github.com/diasdavid/abstract-stream-muxer
https://github.com/indutny/spdy-transport

How can you help

• It would be amazing if spdy-transport started returning a duplex stream spdy-http2/spdy-transport#14

@RichardLitt, thank you so much for helping me review stuff, as I explain in IRC, there isn't exactly PR to review, since I'm pretty much the only one maintaining the code and I just keep iterating over master till we hit a alpha version.

There is a simple 'roadmap' in this repo's Readme, however, if it is the first time you are dialing in to libp2p, it might not be clear what is going on. For that, I've a WIP of the libp2p spec, it does explain a lot, unfortunately not all, yet. You can find it here - ipfs/specs#19

In terms of reviewing code, the best place to start would be by the Swarm components, which handles dialing, protocol muxing, stream muxing and Identify. It is what every other component uses so that they can open streams between peers.

The commands command simply prints out all the available commands (and their subcommands). It is part of tooling.

• jsipfs commands

webcrypto

https://github.com/diasdavid/webcrypto

WebCryptoAPI polyfil to work in Node.js in the Browser (so that you don't have to be concerned about moving crypto code between a browser and server side app)

Context: nodejs/node#2833

How can you help

• The module is still being made, if someone wants to take the lead, it would be great :)

ipfsd-ctl

https://github.com/ipfs/js-ipfsd-ctl

How can you help

https://github.com/ipfs/js-ipfsd-ctl/issues

It is time to give js-multiaddr a spin and upgrade it to support uTP, WebSockets and IPFS.

multiaddr spec - https://github.com/jbenet/multiaddr
js impl - https://github.com/jbenet/js-multiaddr
go impl - https://github.com/jbenet/go-multiaddr

Note how uTP, WebSockets and IPFS are not yet recognized by multiaddr https://github.com/jbenet/js-multiaddr/blob/master/src/protocols.js#L29-L37. We need to add support for:

• uTP
• WebSockets
• IPFS

After this, we need to add support to js-mafmt to be able to validate uTP, WebSockets and IPFS too

• https://github.com/whyrusleeping/js-mafmt/blob/master/tests/test.js#L77-L83

While we are at it, we should also support WebSockets on the go-multiaddr, //cc @whyrusleeping

On a mac, el capitan. IPFS installed fine. All command line tests run fine.
Video streaming works fine
Only ada.jpg loads on the photo demo (I may not have tried all)

Trying to load http://localhost:5001/webui. It stalls on
http://localhost:5001/ipfs/QmRyWyKWmphamkMRnJVjUTzSFSAAZowYP4rnbgnfMXC9Mr/#/?_k=***
It fails on three browsers : Firefox, Safari and Chrome. Chrome reports "waiting for localhost".
I have this error:
12:23:08.514 ERROR core/serve: Path Resolve error: context deadline exceeded gateway_handler.go:472

Regards
Laurent

I want to get up on speed with js-ipfs and ran into a few small issues.

package.json

reads "main": "src/index.js" I changed it locally to "main": "src/ipfs-core/index.js" to be able to follow the README usage:

var IPFS = require('ipfs')

var node = new IPFS()

otherwise yields error: ipfs module not found

missing dependency

Should this be added to package.json?
'fs-blob-store'

jsipfs daemon

Initializing daemon... error listen EAFNOSUPPORT :::4001

if run a second time

Initializing daemon... This repo is currently being used by another daemon

Then I rm -r ~/.ipfs and ipfs init using go-ipfs, but can't get jsipf daemon working because of the EAFNOSUPPORT error

I want to run js-ipfs daemon in the browser, but can't even get it to work in node. Is it usable to a degree even if just for basic operations like fetching objects? I tried browserify but get all sort of dependency issues like:

Error: Cannot find module 'buffer!./pb/crypto.proto'

That I'm not sure how to resolve.

Thanks for any pointers on how to get js-ipfs daemon up and running, ideally in the browser!

The project currently uses Make to automate installation. This hurts portability, since Windows developers would need Cygwin or something similar. Grunt is a much better alternative since Node developers are used to it and it is fully cross-platform (since it's Node-based).

Resolving #11 would eliminate the need for a build system since the project could be installed via NPM.

jsipfs node is the interface that enables us to start and stop a daemon and also get some information about it

• id
• daemon

The object API enables IPFS users to create graph structures with IPFS were links are MerkleLinks (multihashes)

To learn more about the object API, you can

• check go implementation of the MerkleDAG https://github.com/ipfs/go-ipfs/tree/master/merkledag
• check the MerkleDAG spec https://github.com/ipfs/specs/tree/master/merkledag
• see the http-api spec for the object API ipfs-inactive/http-api-spec#32

Implementation Roadmap

• MerkleDAG JS implementation https://github.com/vijayee/js-ipfs-merkle-dag
• jsipfs object new [template] - Creates a new object from an ipfs template.
  • core
  • http-api
  • cli
• jsipfs object get - Get and serialize the DAG node named by .
  • core
  • http-api
  • cli
• jsipfs object put - Stores input as a DAG object, outputs its key.
  • core
  • http-api
  • cli
• jsipfs object stat - Get stats for the DAG node named by .
  • core
  • http-api
  • cli
• jsipfs object data - Outputs the raw bytes in an IPFS object.
  • core
  • http-api
  • cli
• jsipfs object links - Outputs the links pointed to by the specified object.
  • core
  • http-api
  • cli
• jsipfs object patch append-data - Append data to the data segment of a dag node.
  • core
  • http-api
  • cli
• jsipfs object patch add-link - Add a link to a given object.
  • core
  • http-api
  • cli
• jsipfs object patch rm-link - Remove a link from an object.
  • core
  • http-api
  • cli
• jsipfs object patch set-data - Set data field of an ipfs object.
  • core
  • http-api
  • cli

This issue focus on detailing the improvements we are committing to do for js-ipfs milestone 1.

js-ipfs-api is the IPFS HTTP-API client library used by js-ipfs cli and a ton of other applications that want to interact with an IPFS node through HTTP (mostly go-ipfs nodes). Currently, for js-ipfs we have to use a branch of js-ipfs-api since IPFS 0.3.11 and 0.4.0 versions different in how the http-api endpoints work. We want to support 0.4.0 http api spec, which is standardised on https://github.com/ipfs/http-api-spec.

You can find js-ipfs-api at https://github.com/ipfs/js-ipfs-api

TODO list:

• get ipfs-inactive/js-ipfs-http-client#74 merged. It depends on go-ipfs 0.4.0 being released.
• implement remaining swarm features (ipfs-inactive/js-ipfs-http-client#252)
• increase code coverage to 100%
• feature GET ipfs-inactive/js-ipfs-http-client#263
• enable circle-ci to run our tests as well
• update release process to the dignified pipeline
• create an examples folder that demonstrates how to:
  • use it with browserify
  • use it with webpack
  • link examples in the README
• ensure that every API call is well documented ipfs-inactive/js-ipfs-http-client#58 (note that the feat/files-api has more docs than master

As with ipfs/kubo#9, the app fails to build on Windows due to the dependency on fuse (fuse4js).

This issue focus on detailing the improvements we are committing to do for js-ipfs milestone 1.

unixfs is one of the Data Structures that gets mounted on top of the MerkleDAG, it is what enables ipfs to handle files, like adding and getting them to IPFS. Currently this module is pretty close to finished, only requiring a second (or third) pair of eyes to go through the code, increase the code coverage and make sure everything feels right.

https://github.com/ipfs/js-ipfs-unixfs

TODO list:

• increase code coverage to 100%
• enable circle-ci
• update release process to the dignified pipeline
• examples
• ensure that every API call is documented ipfs-inactive/js-ipfs-http-client#58 (note that the feat/files-api has more docs than master

IPFS Repo is the storage driver for IPFS.

To learn more about the repo, you can

• Read the IPFS Repo Spec https://github.com/ipfs/specs/tree/master/repo

Implementation Roadmap

• IPFS Repo JS Implementation https://github.com/ipfs/js-ipfs-repo
• Integration of BlockService with IPFS Repo https://github.com/ipfs/js-ipfs-blocks
• Integration of IPFS Repo with js-ipfs https://github.com/ipfs/js-ipfs/blob/master/src/ipfs-core/index.js
• jsipfs repo init Not used anymore
  • core
  • http-api
  • cli
• jsipfs repo stat
  • core
  • http-api
  • cli
• jsipfs repo gc {difficulty: moderate} requires storage of refs (#59)
  • core
  • http-api
  • cli

ipfs-repo is the module that implements and offers the functionality offer in repo spec

git repo: https://github.com/ipfs/js-ipfs-repo

It should work natively using the fs or in the browser using local storage

js-ipfs-repo should be able to grab an ipfs repo generated by go-ipfs and manipulate it without breaking interopability.

https://github.com/ipfs/js-ipfs#per-component-view

Network layer - See hhttps://github.com/diasdavid/js-libp2p

node-ipfs-kad-router

https://github.com/diasdavid/node-ipfs-kad-router

Module to perform lookup for peers in a Kademlia DHT. For a given 'key' it must return a pq(priority queue) of peers that are the closest to that key - https://github.com/diasdavid/node-ipfs-kad-router/blob/master/src/index.js#L79

How you can help?

• Adding more tests for code coverage (target 100%)
• Adding documentation

This issue focus on detailing the improvements we are committing to do for js-ipfs milestone 1.

Currently, @nginnever is leading the charge on data-importing + files API. It would be excellent to have a couple of extra hands with the list of tasks below.

https://github.com/ipfs/js-ipfs-data-importing

TODO list:

• increase code coverage to 100%
• enable circle-ci
• update release process to the dignified pipeline
• docs for the API calls
• docs for the Importing pipeline (ASCII graphs would be great, I recommend monodraw for the http://monodraw.helftone.com)
• examples
  • import a dir with files
  • export a dir with files

Read only mounting works now:

in one term:

mkdir -p foo
echo "bar" > foo/bar
echo "baz" > foo/baz
# foo/baz: added block /XLM1ZETht3wv8vUPXMkx3JZGP5T9txAz782
# foo/bar: added block /XLMCA8WXBNRBwFhzRnHgHFLwGmQzkAQELH7
# foo: added tree /XLNUfxWCtidC125VaSgtM6yM1VRs7PcGvzq
ipfs add -r foo
ipfs mount /ipfs

in another:

# finding files by hash
cat /ipfs/XLMCA8WXBNRBwFhzRnHgHFLwGmQzkAQELH7
# bar
cat /ipfs/XLM1ZETht3wv8vUPXMkx3JZGP5T9txAz782
# baz

# listing directories
ls /ipfs
# ls: ipfs: Permission denied
ls -l /ipfs/XLNUfxWCtidC125VaSgtM6yM1VRs7PcGvzq
# -r--r--r--  0 root  wheel  4 Dec 31  1969 bar
# -r--r--r--  0 root  wheel  4 Dec 31  1969 baz

# path resolution
cat /ipfs/XLNUfxWCtidC125VaSgtM6yM1VRs7PcGvzq/bar
# bar
cat /ipfs/XLNUfxWCtidC125VaSgtM6yM1VRs7PcGvzq/baz
# baz

# symlinks work :)
ln -s /ipfs/XLNUfxWCtidC125VaSgtM6yM1VRs7PcGvzq foo
ls foo
# baz
# bar
cat foo/bar
# bar

wow, thanks unix :) ❤️

todo

• service/daemonize
• listing root shows things available locally
• leveldb not re-entrant, so ipfs cli should check if a service is running.
• mount subdirectories. e.g. ipfs mount <ipfs-path> <os-path>

@diasdavid Bitswap doesn't have a repository associated with it. (Neither does Peer routing, but I'm not sure if that is top-level and if it needs one yet or not).

Has work been started on it yet? @mafintosh is keen to help now, if so, or to just start cracking.

To learn more about config, you can

• try out the ipfs config command with a go-ipfs daemon
• check the config http-api-spec ipfs-inactive/http-api-spec#29

Implementation Roadmap

• jsipfs config - Gets or sets the value of a given key of the config file.
  • core
  • http-api (#72)
  • cli
• jsipfs config show - Outputs the content of the config file.
  • core
  • http-api (#74)
  • cli
• jsipfs config edit - Opens the config file for editing in $EDITOR.
  • cli (#77)
• jsipfs config replace - Replaces the config with .
  • core
  • http-api (#75)
  • cli

TEST

https://github.com/ipfs/js-ipfs/blob/master/tests/test-http-api/test-version.js#L38-L47

LOG

Debug: internal, implementation, error 
    AssertionError: expected [Error: Client request error: Parse Error] to not exist
    at /home/travis/build/ipfs/js-ipfs/tests/test-http-api/test-version.js:40:27
    at /home/travis/build/ipfs/js-ipfs/node_modules/ipfs-api/src/request-api.js:23:14
    at finish (/home/travis/build/ipfs/js-ipfs/node_modules/wreck/lib/index.js:146:20)
    at wrapped (/home/travis/build/ipfs/js-ipfs/node_modules/hoek/lib/index.js:867:20)
    at ClientRequest.onError (/home/travis/build/ipfs/js-ipfs/node_modules/wreck/lib/index.js:155:16)
    at ClientRequest.g (events.js:260:16)
    at emitOne (events.js:77:13)
    at ClientRequest.emit (events.js:169:7)
    at Socket.socketOnData (_http_client.js:307:9)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at readableAddChunk (_stream_readable.js:146:16)
    at Socket.Readable.push (_stream_readable.js:110:10)
    at TCP.onread (net.js:523:20)

This issue focus on detailing the improvements we are committing to do for js-ipfs milestone 1.

ipfs-repo is one of the core pieces of js-ipfs. It enables js-ipfs to use different storage backends without having to introduce any complex logic for the other IPFS subsystems. Although this module is quite stable at the time, its performance has room for improvement and documentation needs some love.

https://github.com/ipfs/js-ipfs-repo

TODO list:

• increase code coverage to 100%
• enable circle-ci
• update release process to the dignified pipeline
• examples
  • using with fs-blob-store
  • using it in the browser with indexedDB-blob-store
• ensure that every API call is documented

Extra:

• benchmarks and increase performance

I'm not sure what this repo is doing. Can I use any of the stuff here? Can I install and help out? If so, how?

The top description is also confusing: ipfs implementation in node https://github.com/jbenet/ipfs. Does that mean that https://github.com/jbenet/ipfs is a more up-to-date version of this? Or is that just a link to what IPFS is?