EDIT: Please download the new binaries for TEST 7 (only client applications for now).
Hi everyone, today we are releasing TEST 7 
The primary focus of this test is bug fixes in client applications. There is some refactoring in lower layers, but it will be mainly invisible to end users. What will be very visible is the work the front-end team has been doing in the Demo App and Launcher. Whereas Launcher is growing into a fully functional and important application and gateway to the SAFE Network for application developers, the demo apps are ā¦ simply that ā a demonstration of basic use of the API to create examples of applications that would normally require back-end infrastructure.
In any case these demos have been updated and contain a new flow to enable developers to see more accurately what happens in registering a Public ID (e.g. frabrunelle) and then mapping a service (e.g. www) to an existing public folder.
This test, again, will lose data and accounts over time. It is not yet secured for either anonymity or security of data transfer. So please expect data loss, but we hope everyone can now clearly see what is coming and how it will work, in its most unoptimised manner.
Please note that TEST 6 will be taken offline tomorrow as this new network becomes the new standard we wish people to develop apps with. We will likely re-enable a new client test network, or provide instructions for app developers to use a local network to develop applications with a stable API and storage back end.
Whatās new?
Client: Krishna (tl), Scott & Shankar
Many UI related improvements and bug fixes have made Launcher much more usable and stable. All identified places where it crashed have been addressed. Progress indication is more accurate. The āCreate Accountā screen has also been reworked.
The upload limit of the demo app was decreased from 50 MB to 25 MB. This will help spread the load and also reduce impact in churn (since there arenāt that many nodes).
Previously Demo App and Launcher combined the nfs and dns operations. The formation of such composite operations lead to cases like service name could not be registered if the previous attempt was partially a success (i.e. if nfs succeeded but dns timed out, etc.). This also had the downside of hiding the nfs API that Launcher exposes to 3rd party applications. These are now separated and the demo app exemplifies the usage of nfs invocation. So user must create/upload a directory via āManage Network Dataā and only then can they use āManage Websitesā to register services. This separation of concerns makes error recovery very robust as in if previously the nfs succeeded and dns failed, the next time only the dns subset needs to be re-performed.
The mapping between dns and nfs is now visible to the user. The list of all services and what directory path they map to is displayed in the āManage Websitesā section of the demo app. Also present is the facility to edit this mapping.
Launcher now gives an option to logout (in the āAccountā section).
Launcherās proxy setting is now on by default.
Known limitations
-
If Launcher crashes or becomes unresponsive and you need to force kill, make sure that the process is killed from task-manager/system-monitor, etc. (depending on your OS). Otherwise the next start of Launcher will show weird behaviour.
-
The NFS modify file API has been temporarily deprecated. Currently
SequentialEncryptoris used viasafe_coreto write chunks as and when available which does not support taking offsets. Once theself_encryptioncrate can support taking offsets while also writing chunks to the network as and when chunks are formed, the modify file API will be re-enabled. At present the workaround for modifying a file will be to delete and create it again as a new file.
Core: Spandan (tl) & Vinicius
Core has added support for timeouts. So if messages are dropped by the network and responses donāt make it back to Core, it will timeout (currently after 2 min) and inform the front end.
self_encryption has also undergone some changes. Previously that crate used to keep the data in a memory map as one kept writing to it and flush it to the network only when close() was called on it. This lead to difficulty in propagating the progress indication to the front end. The current modification means that each write() will try to write data immediately to the network if it can, which means more accurate progress indicator for the front end. Core has been modified accordingly to use this new facility where required.
Apart from that there was a minor fix in the DNS module of Core which was exposed during our testing as well as general code improvements. Core now has much better logs.
Routing, Vaults: Adam, Andreas (tl), Fraser & Qi
In Routing, a lot of refactoring is going on under the hood, and we are doing lots of security-related planning, but apart from that, the network should behave mostly like TEST 6.
Get involved in TEST 7!
Please be aware that this release will not allow older nodes or clients to connect to the network. You must use the new binaries below to connect to the TEST 7 network.
This is a test network and comes with the normal risks of using pre-release software. Please also be aware that this test network will be reset, wiping all data that is stored on it.
Download
Documentation
Where should I report issues?
GitHub is the best place to report issues and bugs. Using GitHub will help us (MaidSafe) manage issues and prioritise work within the Dev team faster.
If you are not sure if you are experiencing a real bug or if you have a question, the forumās #support category is a great place to post this. As we know this is a friendly and responsive community and someone will help you out.
And of course, as always, thank you for participating in TEST 7 
that is if Iām correctly interpreting the terminal window for the Launcher. I mean the errors of course, not the load times per se.
