ipfs-cluster/ROADMAP.md
Hector Sanjuan 21d4105867 Updated Captain's log and added Q3 Roadmap (#134)
* Updated Captain's log and added Q3 Roadmap

License: MIT
Signed-off-by: Hector Sanjuan <hector@protocol.ai>
2017-07-27 14:20:59 +02:00

2.0 KiB

IPFS Cluster - Roadmap

Q3 2017

Since Q1 ipfs-cluster has made some progress with a strong effort in reaching a minimal feature set that allows to use it in production settings along with lots of focus on testing. The summary of what has been achieved can be seen in the Captain's Log.

For Q3, this is the tentative roadmap of things on which ipfs-cluster will focus on:

  • Making all the ipfs-kubernetes tests fit
  • Working on low-hanging fruit: easy features with significant impact
  • Adopting ipfs-cluster as a replacement for the ipfs pin-bot (or deploying a production-maintained ipfs-cluster)
  • Outlining more a Q4 roadmap where development efforts come back in-full to ipfs-cluster

Q1 2017

This quarter is going to be focused on bringing ipfs-cluster to life as a usable product in the IPFS ecosystem. That means:

  • It should be hard to crash
  • It shouldn't lose track of content
  • It should play well with go-ipfs
  • It should support a replication-factor
  • It should be very well tested
  • It should be very easy to setup and manage
  • It should have stable APIs

On these lines, there are several endeavours which stand out for themselves and are officially part of the general IPFS Roadmaps:

This involves easily adding a peer (or removing) from a running cluster. ipfs-cluster-service peer add <maddress> should work and should update the peer set of all components of all peers, along with their configurations.

This involves being able to pin an item in, say, 2 nodes only. Cluster should re-pin whenever an item is found to be underpinned, which means that monitoring of pinsets must exist and be automated.

In the context of the Interplanetary Test Lab, there should be tests end to end tests in which cluster is tested, benchmarked along with IPFS.