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>

CAPTAIN.LOG.md

@@ -1,5 +1,22 @@
 # IPFS Cluster - Captain's log
 
+## 20170726 | @hsanjuan
+
+Unfortunately, I have not thought of updating the Captain's log for some months. The Coinlist effort has had me very busy, which means that my time and mind were not fully focused on cluster as before. That said, there has been significant progress during this period. Much of that progress has happened thanks to @Zenground0 and @dgrisham, who have been working on cluster for most of Q2 making valuable contributions (many of them on the testing front).
+
+As a summary, since my last update, we have:
+
+* [A guide to running IPFS Cluster](docs/ipfs-cluster-guide.md), with detailed information on how cluster works, what behaviours to expect and why. It should answer many questions which are not covered by the getting-started-quickly guides.
+* Added sharness tests, which make sure that `ìpfs-cluster-ctl` and `ipfs-cluster-service` are tested and not broken in obvious ways at least and complement our testing pipeline.
+* Pushed the [kubernetes-ipfs](https://github.com/ipfs/kubernetes-ipfs) project great lengths, adding a lot of features to its DSL and a bunch of highly advanced ipfs-cluster tests. The goal is to be able to test deployments layouts which are closer to reality, including escalability tests.
+* The extra tests uncovered and allowed us to fix a number of nasty bugs, usually around the ipfs-cluster behaviour when peers go down or stop responding.
+* Added CID re-allocation on peer removal.
+* Added "Private Networks" support to ipfs-cluster. Private Networks is a libp2p feature which allows to secure a libp2p connection with a key. This means that inter-peer communication is now protected and isolated with a `cluster_secret`. This brings a significant reduction on the security pitfalls of running ipfs-cluster: default setup does not allow anymore remote control of a cluster peer. More information on security can be read on the [guide](docs/ipfs-cluster-guide.md).
+* Added HTTPs support for the REST API endpoint. This facilitates exposing the API endpoints directly and is a necessary preamble to supporting basic authentication (in the works).
+
+All the above changes are about to crystallize in the `v0.1.0` release, which we'll publish in the next days.
+
+
 ## 20170328 | @hsanjuan
 
 The last weeks were spent on improving go-ipfs/libp2p/multiformats documentation as part of the [documentation sprint](https://github.com/ipfs/pm/issues/357) mentioned earlier.

ROADMAP.md

@@ -1,10 +1,22 @@
 # 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](CAPTAIN.log.md).
+
+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 shouldn't hard to crash
+* 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