As everyone who regularly follows these updates will be aware, getting the MVP out is taking a bit longer than we all expected; just now this is mainly due to bugs that we are seeing with uTP, issues that are not reproduced using TCP. So as the Crust team continues to work on these issues the decision has been taken to slightly change direction with the MVP and initially release a TCP only MVP. This may require a little more manual set-up from the user side, but it was felt better to keep the rolling release schedule erm… rolling - rather than lose momentum,as the guys are currently testing this and seeing very positive results. So to be as transparent as we always try to be: the first MVP is going to be initially TCP only, with uTP support to follow.
As you may be aware uTP is a layer on UDP that allows reliable transfer of data, while also allowing better NAT traversal than TCP. Utorrent uses this, but many in that community still use TCP as it’s 20% quicker. uTP following TCP is therefore sensible and it allows all the other libraries and the resources we were pouring into Crust to be pushed into the Client APIs and Beta features (messaging / safecoin / advanced data handling, etc). This is now where we will once more see much faster delivery of components to the community, so we are delighted and excited to be again looking at the innovations and features that will make SAFE very complete and more efficient.
##Crust - uTP / API : Vinicius / Andrew / David
The Crust guys spent the week testing the latest Crust / uTP implementation, with a development version of Routing under various test conditions / environments. Then they focused on fixing bugs related to uTP bootstrap connections. The guys saw unexpected
LostPeer events being raised under some systems and this is currently under investigation, with the aim to have it resolved this week. If everything goes well, we should have uTP enabled for Routing next week. The decision was made by the team to postpone the heartbeat implementation as Routing has implemented a similar mechanism.
##Routing - Vault Integration : Andreas / Adam / David
The Routing team added a network-less test framework to the API, so Routing users can benefit from the faster tests too. The guys have also implemented a heartbeat to detect lost peers even if Crust doesn’t. Routing has gone through pretty extreme testing of overnight networks with high churn rates and then analysed for Kademlia invariant being maintained and it’s very impressive to see that all holding true under what is extreme churn.
##Vaults : Brian / Fraser / Qi
Most of the safe_vault personas have seen some work in the last week, the bulk of which has been applied to the ImmutableDataManager. Preparation for the farming rate calculation has been included, in conjunction with an RFC to Routing covering the various flavours of immutable data. Also implemented was the vault config file as per https://github.com/maidsafe/rfcs/blob/master/active/0015-vault-config-file/0015-vault-config-file.md
Tests have now been upgraded covering the majority of code paths for each persona. Also, still on testing, Routing’s mock of the crust library has been integrated to allow full integration testing of safe_vault in a controlled network environment. This allows very quick accurate testing of vault logic (SD handling, messaging, safecoin and then on to…).
##Client - Launcher : Krishna / Spandan / Shankar
The logger in maidsafe_utilities was not as efficient as we wanted it to be, which was causing the tests to crash. @ustulation (currently flying as he and his wife relocate to Scotland) spent some time working in this area to get it fixed and we now have a complete asynchronous logging module. This change also includes the ability to write to a TCP stream, which can be used to send the logs to the visualiser. We have temporarily parked the visualiser and the focus is now on the dynamic data handling abilities of the network. Towards the tail end of last week we had a few good discussions and finally arrived at the possible approach on how this feature can be enabled. The approach is detailed with a simple use case and also there are few concerns in this approach which is also specified in the RFC. We are looking forward to input / discussion / debate from the community and you can make these within the discuss proposed github issue, or within the already active forum thread. At present, an RFC for exposing the Launcher APIs for structured data and immutable data is being worked on.
##UI Design : Scott / Shankar
We ran into some problems with the roadmap last week and are hoping to have those issues resolved soon. A lot of time has been spent collating the data to be used in the roadmap and once the above issue is resolved we can start to demo it; we look forward to receiving your feedback in due course.
Thanks for your support - here is the link to the weekly transcript