Today, we are releasing Test 16. 
See this topic to download the binaries for Test 16:
This testnet makes use of the invitation-based accounts feature we explained in last week’s update. This is a temporary solution that aims to prevent account-spam creation. We chose a solution that’s not too complicated and that we can easily remove later on when we start implementing test safecoin (see this dev update for more info on our short-term roadmap).
Since the invitation system has not been tested before, we’re starting off with 200 tokens split equally between the OAuth server and the forum mods. We’ll be watching the usage of tokens closely and, on a day-to-day basis, we’ll update available tokens accordingly.
Also, we are planning to bring Test 15 down tonight or tomorrow.
SAFE Authenticator & API
@Shankar and @Krishna_kumar have been working on implementing invitation-based account creation for SAFE Launcher. With this one out of the way, our focus shifts back to the new APIs and examples.
@bochaco has been exploring Redux and wiring up the email app to use the new Node.js APIs. @lightyear spotted an issue with the API on a Windows 32-bit machine and he’s trying to figure out the cause.
We finished porting the Markdown editor web example to use the new DOM APIs exposed by the SAFE Browser. @bochaco will be able to complete the email application porting to the new APIs by next week.
A new team member (@Kumar) joined our team earlier this week. He will be working on the Java side. He has been setting up some samples using Maven for dependency management and also to figure out the best possible approaches for distributing the Java safe_app library.
SAFE Client Libs & Crust
Invitation-based account creation is completed in Clients. It mainly affects the account creation functions and it is exposed via FFI for the frontend to consume. We have also updated the production code to use serde instead of rustc-serialize as that is planned to be deprecated in Rust 1.18. There were a few bug fixes that went into safe_client_libs, related to unclaimable StructuredData and re-claiming of deleted StructuredData.
Mutable-data support in routing is about to be merged into the mutable-data branch after a couple more changes (removing the requirement from clients to specify minimum section size) and safe_client_libs will be updated accordingly.
This Mutable-data PR is ready to be merged to safe_vault’s mutable-data branch. It’s a big PR and awaiting review at the moment, but we’re hoping to be feature complete with the initial proposal that we have for MutableData support and operations. We’ll then be able to move onto the initial stages of testing the same.
Routing & Vault
Continuing our work from the last few weeks, we extended our tests and fixed issues, particularly regarding tunnel nodes. New scenarios include unidirectionally blocked and delayed connections (e.g. A can establish a connection to B, but not the other way round).
We completed invitation-based account creation, so that test and alpha networks cannot be spammed by creating thousands of fake accounts, even before the introduction of Safecoin.
Using our new fake clock, tests can now precisely control the time seen by the production code, and can, for example, call some function, advance the time by exactly 300 seconds (without actually waiting for five minutes!) and then call another function. With that and other fixes, we hope to remove the last sources of nondeterminism from our automated tests, so that if a test fails somewhere, we can run the exact same scenario with enabled logs and test fixes with it.
.
Happy birthday 