EDIT: Test 12b is now online. See this forum post for more details.
Today, we are releasing Test 12. 
This will enable some users to run vaults from home. This test doesn’t contain the new client API (with mutable data). It’s purely for testing the features related to the routing update (mainly disjoint sections and resource proof). With such a long period between testnets and a considerable upgrade to the codebase, this test is essential for us to confirm that the network is improving and that we are on track for the remaining features, which required this change. The next target for us in terms of features is data republish and increased security (node ageing and data chains are large parts of the current in house discussions).
As part of the resource proof paradigm, a spot check for bandwidth is carried out when you start a node. This may extend to CPU at a later stage (this is already included as part of the resource_proof library). Your vault will connect to the members of the network’s section that it is trying to join, and will try to upload some verifiable and unique data to each of them within five minutes. If successful, the section will accept your node and it will start routing and handling requests.
Note that each section will only profile one node at a time, so if many users are starting vaults at the same time, many of them will need to retry multiple times until they are accepted as a candidate and start the bandwidth check.
With the Node Ageing RFC, the bandwidth parameters will adjust in real-time based on the network requirements. At the moment, we are using “magic numbers” that we have selected through testing to do these spot checks. We have made these joining node resource checks extremely aggressive to begin with. A large percentage of the community vaults (maybe 50%) may not be able to join Test 12. This affects only the vaults though, clients will not be affected by these spot checks.
Right now, the upload bandwidth requirement is ~6 Mbps. In the long run, we totally intend to make use of every node we can (e.g. for particular specialized tasks). This is just step 1 of the process.
This test represents a huge refactor and we are very keen to confirm that there are no regression or surprises as we move forward towards Alpha 2.
SAFE Vault v0.13.0
You can run only 1 Vault node per LAN – running more than 1 will result in this message:
More than 1 routing node found on LAN. Currently this is not supported
Download
Changelog
- Migrate to routing 0.28.0.
- Use a single event loop for routing and safe_vault.
- Fix issues with account creation and data requests.
SAFE Launcher v0.10.1
To connect to Test 12, you need to use SAFE Launcher v0.10.1.
Each client account is limited to 500 PUTs. A PUT is a request to store a single chunk on the network (a file may contain many chunks). The maximum chunk size is 1 MB.
Please be aware that we might need to restart this test network, wiping all data that is stored on it. We will announce this in a Dev Update (when possible) prior to taking it down.
Download
Documentation
Changelog
- The release binaries uses safe_core v0.22.2 to connect with the Test-12.
- Config file updated to connect with Test-12
SAFE Demo App v0.6.2
The latest version of SAFE Demo App (v0.6.2) should continue to work fine.
When uploading files using SAFE Demo App, the maximum file size is 25 MB per file.
Download
Documentation
SAFE Browser v0.4.3
The latest version of SAFE Browser (v0.4.3) should continue to work fine.
Download
Other apps
Apps that were working with TEST 11 should continue to work fine with TEST 12.
Support
If you need help with anything related to SAFE Vault, SAFE Launcher or SAFE Demo App, please use the Support category of this forum.
Where should I report issues?
If you know which component a bug is associated with, feel free to report it on GitHub in the corresponding repo.
SAFE Authenticator & API
Team leader: Krishna
We made good progress this week resolving the issues we had with the FFI integration. The authenticator plugin is now integrated with the safe_browser and tested. The initial integration looks good and the tests we have carried have exposed a few bugs and corner cases to be handled.
Also, the Node.js API (for app developers) has seen some considerable progress. We now have the majority of the APIs tested manually. The File-related APIs have some integration issues and we are looking into those at the moment. Along with fixing the known issues, we are also expanding the test suite and examples for the Node.js API.
You can take a look at the safe_app_nodejs repository to get a better understanding of how the Node.js API can be used. You can only try it on Linux and macOS at the moment. For Windows we need to finalise the build process. We are hoping to continue the steady progress in the upcoming week and announce a stable API for the next update. It’s worth mentioning also that we started making plans for the documentation. For the Node.js API, we will likely use documentation.js (which uses the JSDoc syntax).
SAFE Client Libs & Crust
Team leader: Spandan
Carl completed the Mio task to provide and test iOS and Android compatibility. We are looking to update Crust to the latest version of Mio. We are currently debugging some bugs/changes in behavior with the latest version of Mio on Windows. We think the bugs might be in Mio, but this is not confirmed yet. Once this is sorted out, we should be good to merge Crust’s port to the latest Mio. Carl is again helping out with those bugs.
Right now, Crust only supports TCP. We are going to work with Carl to support other protocols (e.g. uTP) and improve hole punching as well as some security features we require for “man in the middle” attack avoidance.
The front-end integration with safe_client_libs is the current workload of the rest of our team and this is being done in parallel with Krishna’s team to complete any remaining issues with the new APIs for developers.
Routing & Vault
Team leader: Andreas
We fixed the remaining issues for the bandwidth resource proof and the feature is now ready for a first test with the community.
We are also having lots of discussions and meetings about our medium/long-term plans, both technical and organisational.
Team leaders
The team leaders (Krishna, Spandan and Andreas) are currently in Troon, Scotland for the next 2 weeks. This is the first time that we have the department heads, managers and local dev team all in one place! We’re using the opportunity to discuss: the company roadmap, community engagement (of course 
), documentation (including the website), as well as some ongoing partnership opportunities, including our workshop with Glasgow University which is due to commence in early March. Being the gracious hosts that we are, we will of course show them the local sights, which in Ayrshire boils down to the interior of one of the many local pubs.
Developer outreach
Nikita (@nbaksalyar) is planning to do a presentation on the SAFE Network on February 12 at a local DEF CON group’s mini-conference.
Also, he recently got accepted in the Mozilla Tech Speakers training program. He hopes it will give him more experience for presenting at large events. 
