To reflect the fact that each dev update is a collaborative effort between multiple members of the MaidSafe team, we are going to start using this forum account (@maidsafe) to publish the MaidSafe Dev Updates. Also, to give us additional time to write them, upcoming dev updates will be posted on Thursdays instead of Tuesdays. This means that the next dev update will be on Thursday, January 19, 2017.
First, we would like to wish a happy new year to everyone involved in the SAFE Network community!
Our main priority is still to get users running vaults from home. We are getting very close now. The disjoint sections implementation is pretty much done (the first droplet tests are looking good so far) and we are now working on resource proof.
SAFE Authenticator
Team leader: @Krishna_Kumar
We are integrating beaker-plugin-safe-authenticator and safe_app_nodejs with the FFI bindings for the authenticator and the Node.js API. We are hoping to wrap the initial implementation of the authenticator browser add-on by the end of this week and to complete the Node.js API by mid of next week. Once we have these ready, we will begin to integrate the Node.js API with a demo application and we will do end-to-end testing against mock-routing.
We also created a new MaidSafe repository for the SAFE Browser application.
SAFE Core
Team leader: @ustulation
So we’re a bit short staffed this week with both Adam and Spandan on annual leave. Spandan is back this Friday and Adam is back in February. However, we’re not delayed by any means since we’re done with all our estimated tasks to support Mutable Data 
We’ve got the dev branch updated to support the new data type and also got the project structure in place to provide the FFI libs for the various sections such as Authenticator and App modules. The FFI (foreign function interface) allows integration of SAFE easily into many developer platforms, such as JavaScript, Java, Python, etc. The front-end team is using this to create npm modules for easy integration into existing applications (e.g. desktop apps built with Electron).
All our previous tests and new tests have been updated and work fine against the updated mock-routing implementation in safe_core. Once the new data type is tested against the live network, we’ll get the dev branch merged to master.
Currently we’re working to provide the front-end team with any missing features we might have missed and also looking into helping the Routing & Vault team with the implementation of Mutable Data for safe_vault. As it stands, the front-end team would be able to test the new APIs with the mock-routing interface and once we get support for Mutable Data in the network, the APIs should remain the same while working against a live network.
We’re also currently updating the master branch of safe_client_libs to compile against routing master to allow for network tests with the new version of routing currently against the disjoint sections implementation and soon the resource proof implementation too.
Routing & Vault
Team leader: @AndreasF
The first droplet tests with the mostly finished disjoint sections implementation are looking good: The routing invariant as well as the data chunks survived simultaneously starting nodes and a small amount of churn. We are now starting to port safe_client_libs to the new routing version, and once that is done, we will intensify the tests, use actual vaults instead of the routing example application, use the safe_core example client to automatically store thousands of data chunks, and run with increased churn.
We merged the huge PR that merged the routing and safe_vault event handling threads, and already replaced two messages that were sent between them with simple method calls.
The first step of resource proof will be merged soon as well: It will adapt the join process and introduce a voting system so that the new node’s section can approve or disapprove of it, depending on its capabilities. The actual resource challenge itself will be inserted in a later change, after we’ve tested this on droplets and determined what the minimal requirements for a routing node are.
Glasgow University
As we mentioned in the Autumn, MaidSafe are partnering with Glasgow University, a world renowned and local University, to work with their professors and students to enhance their understanding of decentralised infrastructure and of course the SAFE Network.
Under the guidance of Dr Inah Omoronyia, Lecturer in Software Engineering and Information Security, MaidSafe will be providing a workshop to the University’s 170 second year Computing Science students. The workshop is scheduled to be delivered during the first week of March, from which the students will have a further 3 weeks to submit their assignments.
While we still need agree on the specific assignments, the students are working in Java so we will need to cater for that in the run up to the workshop. We anticipate this being the first step with the University and we have discussed scaling this learning to the rest of the students, specifically with regard to working with teams of their third year students on long term (1 year) projects within a Professional Software Development (PSD) program. We’ll continue to keep you updated as things develop.
Recruitment
There are currently 14 candidates going through the initial stages of the recruitment process. And 2 developers are currently in the final interview stages (to join the Rust side of the team).
Over the last few months we added 3 new team members to Andreas’ team (Routing & Vault). Now we are focussing on adding more resources to Spandan’s team (SAFE Core) and Krishna’s team (SAFE Authenticator).
then with these partnerships and CEP on top of marketing the ecosystem will grow beautifully. Obviously the groundwork is still being laid with resource proof, node aging, data chains but after that and testsafecoin I think speculative interest will spike the price of maid and hopefully the team can further benefit from that, not only financially but also from the added attention it will bring.