As we said in some of the previous Dev Updates, the goal of TEST 8 is just to minimally test the network until all the refactors and RFCs (secure name, disjoint groups, data chains, etc.) for routing and safe_vault are tested and implemented.

It has been running for one week and as it is using the same vaults as some of the previous tests, it’s expected that some data is being lost. For example, you might be unable to login into an account you previously created.

Data chain integration is getting focus as a solution to coping with many Vaults of varying capabilities. Routing and Vault teams will be concentrated in this area during this iteration with the goal of getting Alpha 2 all on one network.

Appendable Data RFC

Last week, Spandan submitted a pull request for the Appendable Data RFC. The content of the RFC was reviewed (on Reviewable) by other MaidSafe devs and it was also discussed in this forum topic.

Spandan made a few changes based on the feedback he received:

Appendable Data RFC Hey guys, just finished updating the RFC. So we decided to make what was listed as the Alternative approach as our main approach as it is more type-safe (instead of dealing with Vec<u8> as previously). There were a few other changes regarding how things should be routed to final destination, hint on what APIs to use and how vaults should sort out partial deletion via POST . It would be nice if anybody has any comments before we finalise the rfc.

After most discussions concluding last week, we decided to merge the Appendable Data RFC yesterday. It’s now known as RFC 38 and it can now be accessed here:

github.com maidsafe/rfcs/blob/master/text/0038-appendable-data/0038-appendable-data.md # Appendable Data - Status: implemented - Type: feature - Related components: `safe_core`, `safe_vault`, `safe_launcher`, `routing` - Start Date: 25-August-2016 - Discussion: https://forum.safedev.org/t/rfc-38-appendable-data/72 ## Summary Facility for non-owner updates of owned data for the purposes of information exchange. ## Conventions - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](http://tools.ietf.org/html/rfc2119). ## Motivation `StructuredData` can only be modified by its owners as otherwise the vaults would invalidate the operation. However if `B`, `C`, `D` need to communicate with `A`, there is currently no easy mechanism. If it were possible for `A` to advertise some place where anyone could add information and `A` could retrieve it at will, many forms of information exchange would be immediately realisable. This calls for the need of a new fundamental type with a few new operations and we will have laid the foundation of information exchange in SAFE Network around and upon which exciting apps can be built. This is what Appendable-Data aims to provide. ## Detailed design Some of the features, such as notions of ownership and ability to transfer it etc., are directly borrowed from `StructuredData`. As such we will dive into the type-definition straight away. There shall be two kinds of this new type: ```rust This file has been truncated. show original

Andreas is planning to start the implementation of RFC 38 (Appendable Data) this week.

Routing

Now that Andreas is back, the Routing team is discussing the immediate options and measures we can take to make groups of nodes more secure (there are many approaches here and the implementation schedule is important to get right). - i.e. prevent an attacker from getting enough nodes to reach quorum and control group consensus -, what level of group security can be achieved, and if necessary, how the network can deal with malicious groups.

In parallel, work is ongoing on RFC 37 (Disjoint Groups), and on implementing the routing / safe_vault side of RFC 38 (Appendable Data).

Launcher

Last week, Shankar started refactoring the UI code using React and Redux. Angular 1.0 was becoming hard to manage when there is more constant updates on the UI, for example the list of logs.

This week, Shankar is continuing the work in fixing the last lap of issues to complete the porting of the Launcher UI code. We are planning to work on improving the test module for testing the APIs and also integrate an e2e test suite for safe_launcher .

The RFC for Launcher API v0.6 is being worked on. The major update in the RFC is the exposure of low-level APIs, which should enable developers to create dynamic applications.

Once the Launcher API v0.6 RFC is raised, Krishna will start working on integrating the FFI changes from the latest safe_core master branch.

Core

The FFI interface of safe_core has been updated to a standard C-style interface. Spandan was waiting for this refactor to happen for a while and consciously stalled until the alpha was rolled out. Removing the JSON message pattern from the FFI will improve the efficiency between safe_core and safe_launcher . The current master branch of safe_launcher is not compatible with the changes made in the safe_core .

As a last minute addition to this Dev Update, the initial draft for the Low Level API RFC has just been raised. You can find the pull request here. This details how safe_core plans to give complete low-level access to apps via Launcher .

Dev Tutorials

This week we are starting to work on the first tutorial. There is some backend work needed before we can start working on the code example, but we should still be able to progress on a few aspects of the tutorial (e.g. requirements, overview, introduction, list of topics, placeholders…etc…). We will also decide which tools to use to generate and host the Dev Tutorials.

Team expansion

We are pleased to announce that we have added another engineer to the Crust team: Nikita Baksalyar

He will likely start working at MaidSafe on the 12th of September. He’ll be joining Spandan’s team, working on crust and safe_core . This takes the total team to 17 and something we will continue to grow in the coming months.

He has a very insightful blog, you can check it out here: Rust in Detail: Writing Scalable Chat Service from Scratch.

SAFE Browser RFP

Two days ago, @joshuef released Windows, OS X and Linux binaries for the SAFE Beaker Browser. See this dev update for more details:

SAFE Browser Application Packages || Dev Update Development A wee update for any folks looking to get rid of the proxy setup. I’ve spent the last days setting up basic app provisioning for the SAFE Beaker Browser, with some success. We now have windows, linux and osx builds! (I’ve had no linux feedback yet, but windows/osx are looking good!). Which means you can download a browser and run it alongside the SAFE Launcher to have proxy-free access to the network. Download the SAFE Beaker Browser You can grab the windows build here. And osx/linux package…

Dev Forum

We created a discussion topic for RFC 38 (Appendable Data) and another one for RFC 29 (Data Chains).

We also added a new category called Apps and modified the description of the General category. Thanks to @DavidMtl for his suggestions

And now that the SAFE Dev Forum is open for registration, we are planning to close the original MaidSafe-Development Google Group (by making it read-only). All the content of that Google Group will still be easily accessible and searchable, but users won’t be able to create new topics.

If there are no objections, we will do this next week.