In order for IPFS to reach its maturity state, going from Alpha, to Beta and to v1.0.0, the project will need:
Here you will find a comprehensive list of the various challenges and milestones in the IPFS Project to reach version 1.0.0. They are not ordered in any way at the moment, merely grouped.
These are some of the milestones to hit to create a active, sustainable, inclusive and participatory governance model for IPFS.
These are some use case milestones to drive development.
These are some basic performance milestones to hit.
These are some libraries that must exist to make developers' lives easy. It is critical that making fully dynamic apps on IPFS should be just as easy or easier than traditional systems.
The scalability of the IPFS protocol depends on careful design of algorithms and models, careful optimization of our implementations, and careful attention to the security properties of the protocols. Reaching high scalability for self-organizing peer-to-peer protocols is HARD, though definitely achievable. We measure scalability in orders of magnitude, as larger thresholds will require revisiting various parts of our codebase.
Please bear in mind that we are currently still implementing major features of the protocols and reaching implementation completion. We have not yet turned our focus towards scalability, thus there are LOTS of low hanging fruit to optimize and likely many scalability bugs to be worked out. The most important part is to make sure all protocols are meant to scale to billions of nodes, and that they make no centralizing assumptions. All protocols we have chosen make no small scale assumptions and are meant to scale well (typically log(n)).
Our scalability observations are divided into simulations, real network tests, and production networks.
The polish level achieved defined how much effort has gone into polishing all the corners of the tools, APIs, documentation, and so on. Early on, things will be much more rough as we need to focus on implementation speed over final polish. As we reach completion of the implementations, we turn our focus towards scalability, stability, and security. After that, we focus on end user polish.
The multiformats are a set of self-describing protocols/formats for future-proofed or "upgradable systems" (systems that make no silly assumptions that are likely to break over time).
The libp2p protocols are the protocol stack for the modular p2p protocols library spun out of IPFS. These form a p2p-first network stack, with no assumptions, self description, and modular interfaces. More at https://github.com/ipfs/specs/tree/master/libp2p
Consult libp2p Requirements here
Bitswap is the exchange protocol of IPFS. It simulates a data market.
The IPFS DHT is (today) a Kademlia based DHT implementing several libp2p protocols: Peer Discovery, Peer Routing, Content Routing, and some NAT Traversal assistance.
The IPFS pub/sub service will provide fast delivery and routing for subnets of ipfs nodes. This is critical for dynamic applications. pub/sub (or multicast) will implement: Peer Discovery, Peer Routing, Content Routing, and some NAT Traversal assistance. It fulfills similar roles as the IPFS DHT, but with drastically different performance, security, and scalability guarantees. IPFS Pub/Sub is currently in development.
IPLD is the core format for data on IPFS. More at https://github.com/ipfs/specs/tree/master/ipld
IPLD data structures and importers are various data structures and programs that covert data or files from other native representations to and from IPLD graphs. Think of these as both the graph representation datastructs, and conversion codecs.
More at https://github.com/ipfs/specs and https://github.com/ipfs/fs-repo-migrations
The go-ipfs effort is the Go implementation of IPFS. It is meant to run as a commandline tool, as a background service, as a programmatic embedded node, through an RPC API, and to be used as part of other tools. go-ipfs is the reference implementation of IPFS. It includes the HTTP-to-IPFS Gateway implementation. More at https://github.com/ipfs/go-ipfs
The js-ipfs effort is the javascript implementation of IPFS. It is meant to run on both node.js and today's regular web browsers. It is close, but not yet ready. More at https://github.com/ipfs/js-ipfs
As a protocol for the web, the ultimate goal of IPFS is to run directly in the browsers. We are achieving this through a four-step plan:
We have finished step (1). We are currently working on steps (2) and (3). Step (4) is likely a 2017 endeavor.
We have an ipfs node "management console" GUI, delivered as a distributed webapp (dapp). This shows information about an ipfs node, and allows issuing some commands. The webui is entirely hosted and distributed through IPFS itself, demonstrating dynamic web applications on IPFS. More at https://github.com/ipfs/webui
In order to ease the adoption and deployment of IPFS, we have HTTP-to-IPFS Gateways. This means two related things: (a) implementation of an HTTP-to-IPFS gateway server (currently part of go-ipfs), and (b) a globally accessible service Protocol Labs runs for the community. All of the official IPFS websites are now self-hosted directly on IPFS.
IPFS Distributions is the distribution model for IPFS Project programs. This means a repository of pages, source, binaries, and links for all programs officially distributed by the project.
In order to keep the community updated, we run a blog. This blog is distributed through IPFS itself, and through an email newsletter.