So for the last time this year, thank you to the team for their contributions to this week’s dev update. We will not have a dev update for the next couple of weeks due to holidays. As we are a global team, however, not everyone will be downing tools over Christmas and New Year so progress shall continue, which we will report back on at the beginning of January 2016. So from me and the entire MaidSafe team a big thanks for all the contributions and support we have received over the course of this phenomenally busy year.
CHEERS! 
Refactor of Routing is drawing to a close. By now It has stabilised enough to allow the dependent crates (all the client modules) to code their interfaces and operations against it. The implementation has very strong adherence to the concepts discussed and put as a flowchart and also documented thoroughly.
What remains is churn handling, the process during which Vaults come to know which nodes are in their close groups and get refreshed data every time a member of the close group was lost or a new node joined the close group. A new approach is now being evaluated and will be scoped out in detail, prior to implementation in the New Year.
Previously, the list of close group peers would be passed to Vaults via an event which fired every time churn happened on the network close to them. Vaults would keep a copy of this list. On each churn event, Vaults would then need to compare the old list with the new to calculate which peer had left the close group, then start the process of relocating chunks if required.
Under the proposed new approach, the churn event sent from Routing tells the Vaults which peer has left the group, making life easier for the Vaults. This does, however, require a new API function to let Vaults find out their close group, but overall it’s anticipated that this approach will be simpler.
Last week we started to implement the code changes that were identified from the investigation into the rust-utp issues. The timeout code that was added to support concurrent reads and writes started to be refactored and we aim to have this completed by the end of this week.
Also this week we see Andrew and Peter back at the Crust coalface and Adam joining the team here as well - welcome aboard Adam! So a fully powered-up Crust team going into 2016.
##Client
Since the refactor of the Routing API has been completed sufficiently, all the client modules, namely safe_core, safe_nfs, safe_dns, and safe_launcher, have been updated to conform with the new Routing. The safe_ffi module, which the Firefox add-on uses at present, has also been updated to work with the latest version of Routing. All tests in all client modules now pass with the new Mock Routing.
The latest version of Firefox (Version 43), as a security restrict does not allow the installation of unsigned add-ons. We will be publishing the add-on to the Mozilla store, once the add-on approach has been confirmed and implemented, which will mean it has been reviewed and signed by Mozilla. In the meantime, if anyone would like to work or try the add-on, then the workaround would be to install the add-on on the nightly or developer edition of Firefox.
The Mozilla wiki for extension signing details more on the Signing procedure. In this wiki page, the fifth point in the FAQ section explains how to enable the installation of unsigned add-ons:
"What are my options if I want to install unsigned extensions in Firefox?
- The Developer Edition and Nightly versions of Firefox will have a setting to disable signature enforcement. There will also be special unbranded versions of Release and Beta that will have this setting, so that add-on developers can work on their add-ons without having to sign every build. To disable signature checks, you will need to set the xpinstall.signatures.required preference to “false”.*
- type about:config into the URL bar in Firefox*
- in the Search box type xpinstall.signatures.required*
- double-click the preference, or right-click and selected “Toggle”, to set it to false."
This week the work on defining the approach for the add-on is continuing and we hope to have this completed and be able to showcase a working proof of concept very soon.
The Vault project has undergone the initial rework to accommodate the recent changes made in Routing. The plan is to treat the Vaults in much the same way as Routing was handled, namely to step through the logical flow, updating or creating documentation as required. Any fixes will be noted and handled once this is complete.
The expectation is that the existing code will be largely unchanged; certainly it will undergo significantly less refactoring than the Routing library. Initial basic testing (using Client tests from the Core library) shows that Vaults are in reasonably good order. The self_authentication example runs correctly against a small local network of updated Vaults.
We still have to finalise the preferred method of handling churn. This affects Routing and Vaults and we’re midway through that process now.
#MaidSafe website / development roadmap
As per last week’s update the site was at tweaking stage and Krishna has been making some last minute changes and additions. As many of you will have noticed, the new site went live today!
Meanwhile, Scott has been turning his attention to a new and improved roadmap, which is being implemented to provide all stakeholders with greater information about the current development status, as well as what features are in the pipeline and the potential order in which they will be tackled. This roadmap will take a form similar to a Gantt chart and will show each dependency and the workflow between each feature and sub-feature being developed. This should show the relationship between features and give a clue to the work that needs to be done before each feature can be completed.
##Documentation
We plan to share documentation as it is completed; so far published on MaidSafe Developer Hub is the documentation for SAFE Launcher using mock Routing (the API docs are still currently in progress so those are currently hidden). This will give you a feel for the direction we are taking and allow for community feedback via the Suggest edits function or here in the forum. The plan is to grow this hub incrementally rather than go for the big bang approach, so as new features are completed, corresponding documentation shall be released alongside it.
So, it has been a very interesting year to say the least, a complete rewrite of the network and significant changes within the development team was not on the cards at the start of the year, but we will be starting 2016 in a much stronger place as a result. Our priorities entering the New Year will be to produce the Rust 5 deliverables, publish the first iteration of the Launcher API, as well as add a much more detailed roadmap to the new website so that everyone knows where we are, where we are going and how we plan on getting there. There is everything to be positive about for 2016 and we look forward to continuing this amazing journey with you all!
[Link to the Team Update] (https://docs.google.com/document/d/13AK8vPcDWxWBZi6XdQp6ta0WPRNzzCvQepdyYSp0KoY/edit?ts=5677dfa2)
It can be painful and rewarding experience the BUG Dance.
The idea of nearly immaculate code is frankly titillating. Rust has truly struck a near perfect balance. This text cannot adequately convey the depth of my excitement! SAFE is just beginning…
I’m eager to witness the next 5 years. I really believe it will be amazing!