As explained by @dirvine here, there were some issues during TEST 7 and therefore we decided to start a new test network (TEST 7b) that depends on the latest stable version of Routing, prior to the recent refactor.
We will now have two test networks: one for testing Client applications (Network A) and one for testing Vault functionality (Network B).
Having two parallel networks lets us provide a stable test network for end users and app developers (Network A) while also testing Vaults as more updates are made (Network B). That way, all the refactors and RFCs (e.g. Disjoint Groups, Data Chains, etc.) happening in Routing and Vaults won’t affect developers and users who want to use SAFE Launcher and other SAFE apps.
For Network A, we have decided to use the latest stable version of Routing and to only release Client applications (no Vault binaries) in order to provide a good end-user experience as well as a stable network for app developers.
For Network B, we will release both Vault binaries and Client binaries (Network B will have its own Client binaries). The performance will likely not be as good as Network A, but the goal is just to minimally test the network until all the refactors and RFCs are implemented and tested. At this point we will revert back to having one network.
We would like to announce our intention to launch a developer forum. This new forum would also use the Discourse forum software, but would be hosted on a different domain (e.g. dev.safenetwork.org). This forum will be a place where core contributors can discuss with the MaidSafe core team and where app developers can get help and give feedback on the Launcher API.
SAFE Browser RFP
There’s one week left to make final comments/requests into the SAFEr Browser(s) Proposal topic. At the end of the discussion period, we will publish a MaidSafeCoin address that can be used by anyone who wants to contribute to the development of this new browser.
Crust, Core: Spandan (tl) & Vinicius
The work in safe_core is focussed on general code improvements and bug fixing. Internally the deletion of directories have changed a little so that the metadata is returned for each delete. This will help locate the structured data that is now orphan, and in future we will use this information to delete the structured data. We are also discussing the idea of deletable immutable data. It is very much in its infancy right now and needs proper RFC to fully assess its viability. The very nature of immutable data makes it hard to delete, but if we can come up with ways to do it properly it will reduce data in churn. Also, currently safe_core creates immutable data to deal with versioned directories, so every change in version results in a new immutable data and the previous one continues to exist without ever being used. These are non-trivial issues to solve and this is what we will be going over in the next few days.
To ensure requests don’t hang without response, the request timeout has been increased to 2 minutes, so Routing will be given 120 seconds by safe_core to perform a request and if within that time we do not get a response, the front end will be notified of a permanent failure of that particular request.
Routing, Vaults: Adam, Andreas (tl), Fraser & Qi
We have branched routing 0.23 which is going to be used in the next few versions of the binaries we release, while a lot of changes are going on in the master branch:
Adam is putting the finishing touches on a huge reorganisation of routing core code to better separate the bootstrapping, client and node logic.
Fraser has started with the implementation of RFC 37 that redefines the concept of a ‘close group’ of nodes, and will make several features we plan to add later a lot simpler or even feasible in the first place.
Qi is implementing RFC 30, which will tie the node name to the node’s public signing key.
(Andreas is typing this dev update section and leaving nit-picky comments in code reviews.)
Once these changes are complete, we will continue to break the Data Chain integration into small RFCs, work out all the details and implement them. This will take some time, but it should enable us to make Routing a lot more secure and at the same time increase its performance and improve utilisation of nodes with different bandwidths and storage space.
Once all the aforementioned RFCs are implemented, we will again release Vaults with new functionalities. This is along with community parallel networks testing Vaults as we move along and makes sense as users will really want safecoin farming to run Vaults. We realise that many people will want to run Vaults prior to safecoin farming to help and get ready for farming. These people will be a great help as we move through the Alpha releases (more on that later).
Client: Krishna (tl), Scott & Shankar
Last week after the v0.7.1 release of Launcher, we started working on fixing the limitations and also few minor nitpicks.
We have fixed the issue where the user had to manually kill the hanging process from the system process list on OS X and Linux when the Launcher crashed. Along with this fix, this GitHub issue is also being addressed.
With continued testing, we have also identified a few minor issues with Launcher and these are expected to be fixed in the next couple of days.
A few additional tasks that we plan on addressing over the next couple of days:
- Updating the applications to use latest dependencies.
- Gray screen is visible until the application is loaded.
- Fix warning messages from React components.
- In relation to this issue, we are planning to provide an option for starting the launcher in dev mode where the proxy will not inject the CSP headers. We are planning to support this by passing a command line argument while starting the launcher.
- Integrate version update checking mechanism for the launcher and demo apps.
- API bug fixes.
The API documentation is also being updated to reflect the changes in Launcher API version 0.5.
We are also looking forward to start the discussion on the SAFEr Browser(s) Proposal (at the earliest later this week).