Today we are posting the last dev update of 2016. The team will be working intermittently over the next couple of weeks due to holidays 
The next dev update will be on January 10, 2017 
Let’s start by looking back at what we accomplished in 2016:
-
Test 1: February 26, 2016
- Client test. The release of SAFE Launcher and SAFE Demo App, enabling users to create their own account, and to store/retrieve private data.
-
Test 2: May 7, 2016
- The first iteration of enabling users to run vaults.
-
Test 6: July 15, 2016
- New Launcher UI with dashboard and log history.
-
Alpha 1: August 12, 2016
- Release of the alpha network and SAFE API v0.5.
-
Test 9: September 16, 2016
- New developer tutorial that shows how to build an email app that works entirely on the SAFE Network. This example app demonstrates the usage of private appendable data.
-
Test 11: October 18, 2016
- New/updated developer tutorial that explains the two comments plugins (one for permanent comments and the other for editable comments). These plugins demonstrate the usage of public appendable data.
-
WebRTC video chat demo: November 1, 2016
- New developer tutorial that shows how to establish a WebRTC connection using the SAFE Network.
-
SAFE Markdown Editor: November 15, 2016
- New developer tutorial that shows how to build a text editor that stores its data on the SAFE Network. This example app demonstrates the usage of versioned structured data.
- Release of SAFE API v0.6.
Community Engagement Program
In addition to the milestones mentioned above, another thing to mention is that we started the Community Engagement Program in July 2016. The purpose of this process is to match developers with immediate and fundamental SAFE Network requirements. We are going to expand the CEP process in 2017.
SAFE Browser
The SAFE Browser RFP was the first RFP (Request for Proposals) we posted and @joshuef’s SAFEr Browser(s) Proposal was selected by the community. Huge thanks to @joshuef for helping build the SAFE Browser! As mentioned in the previous updates, we are about to bring the SAFE Browser under the MaidSafe repositories.
Team expansion
We would like to highlight all the new team members that joined the MaidSafe team in 2016 
- Andreas (Routing & Vault)
- Francis (Community/developer support)
- Nikita (SAFE Core)
- Ben (SAFE Authenticator)
- Bart (Routing & Vault)
- Diggory (Routing & Vault)
- Michael (Routing & Vault)
SAFE Network apps
Huge thanks also to all the developers who are building SAFE Network apps 
We are very grateful that developers and community members are using the SAFE API. You can see a list of apps that are compatible with Alpha 1 and Test 11 here.
Current priorities
Our current development focus is to enable users to run vaults from home.
The refactor of routing that we started was not complete when we already started implementing disjoint sections (previously called “disjoint groups”). As this was a much larger task than anticipated it has caused all of us to have an awful lot of pressure to complete it. We feel the pain of the community very clearly and it is in the front of our minds these days. We realise this technology is incredibly powerful and the progress we were making should have only got quicker. Instead the work in routing has really prevented us from maintaining that velocity of releasing examples.
Added to that, the refactor of SAFE Authenticator (previously called “SAFE Launcher”) and the core libraries, whilst happening at a very quick pace and with great progress is also a huge amount of work happening in parallel. This will enable devs to build apps that communicate directly with the SAFE Network, without the need for an intermediary such as SAFE Launcher (SAFE Launcher currently needs to run in the background and continuously proxy HTTP requests to the SAFE Network, but on some mobile platforms that wouldn’t necessarily be possible). SAFE Authenticator will only be used for the authentication/authorization process: Once an app has been authorized, it will be able to directly interact with the SAFE Network (using a language binding). This change will enable us to support mobile platforms (Android/iOS).
Also, on desktop platforms, SAFE Authenticator will be bundled directly within SAFE Browser. That way, users won’t have to download two separate apps. They could simply download SAFE Browser and use it to create an account or log in to an existing account.
And for app developers, it’s worth mentioning that the fundamental mutable data types (StructuredData and AppendableData) all converged into a single type: MutableData. This was a lesser change, but a change nevertheless. The advantage of MutableData is that it provides fine-grained access control and more narrow-scoped data operations. See this Dev Forum topic for more info.
The last few weeks have really tested our team and also the community, but the good news is that this is all getting closer to completion now and the bulk of the changes are behind us. A few of us will work over the holidays to clear some last bugs and ensure 2017 sees that velocity not only returned, but maintained from this point on.
A really tough one has been trying to not introduce data chains, which will bring us some critical features (such as data republish), but just adds a lot into the mix of this already huge change set. It keeps rearing its head showing us why some bugs would not happen with that design pattern. So this is also a consideration we watch, but are keen to phase in and not rush in with all the existing changes. Meanwhile, resource proof should allow us to resume testing vaults from home, in an initial form (later, nodes will be continually monitored and not only spot checked at startup).
This is why many of the keen observers will see huge amounts of work in the development branches of routing, safe_vault and the restructured client libraries. The team have scrambled like possessed beasts in the background whilst having nothing huge to tell everyone in terms of weekly deliverables.
2017 though sees the fruits of all this labour and the return to the rollout velocity we started this year. We are confident we will now be in a good place with all these pretty dramatic changes and not only that, also be able to handle all of the platforms we need to run on and allow developers to easily create more of the already growing number of apps, although some alterations will have to be made from the new APIs we will have. This will all lead to simpler more secure apps though and this is what we all want.
In summary, 2016 was tough, very tough but you reap what you sow and we feel we have got great foundations now with all the testing and feedback from everyone here, so thanks for that and we will all now begin to feel the benefits of this gruelling period we hope to complete in the (very) near future.
SAFE Authenticator
Team leader: @Krishna_Kumar
We are starting the FFI integration with safe_client_libs. Also, we are creating a new Node.js module called safe_app. We will be integrating it with safe_client_libs to expose the SAFE API to Node.js developers. Devs will be able to install safe_app from the npm registry and use it as a dependency for their apps. The example app will be using this Node.js dependency to connect with the SAFE Network.
In addition to starting the safe_app Node.js module, we are hoping to complete the implementation of SAFE Authenticator this week.
SAFE Core
Team leader: @ustulation
safe_core was renamed to safe_client_libs since it’s now a workspace repository (it will be used to hold other client-side modules in addition to safe_core). Internally it has a crate called safe_app for integration with applications and a crate called safe_authenticator for integration with the frontend of SAFE Authenticator. These can be navigated from the dev branch of safe_client_libs if you’re interested to know more about them.
safe_app and safe_authenticator are now both ready for consumption and other languages should be able to tap into all their functionalities. Testing however needs to be done much more thoroughly for safe_authenticator and those tasks are detailed in JIRA (MAID-1903, MAID-1904, MAID-1909 and MAID-1910) and can be tackled in parallel to the frontend integrating with the given crates.
Although there are a few further tasks in JIRA for some additional features (MAID-1909, MAID-1899, MAID-1902 and MAID-1776), the way these crates currently are should address most of the features intended for the first iteration. The remaining JIRA tasks related to the additional features should be completed within this week anyway (so hopefully before frontend finishes their integration).
Routing & Vault
Team leader: @AndreasF
This week, we made some good progress with secure message routing, and the next-to-last chunk of work is now in review: The code is in place for sections to exchange their signatures of members of neighbouring sections, and to add the right signatures of the message itself for all kinds of authorities (groups, sections, sets of sections and individual nodes). What remains is inserting the signed member lists in each hop and validating the full chain of signatures in the recipient, linking trusted keys back to the message signatures.
The resource proof implementation is also step-by-step nearing its completion, as is the single event thread. And at the same time, we are continuing to test vaults with disjoint sections on droplet nodes.
.
because for sure we’ll have a SAFE Network with our superhero devs
Good luck!