We've been testing these binaries in a few internal networks since last week. The test we ran over the weekend and through this week went through about 8500 churn events, so roughly 4250 nodes added/removed respectively. The network state has been stable through the duration of the test and data relocation functioned as expected too.

Log file management has also been updated. Previously when a vault process quits and restarts, it'd overwrite the old log file. Now, log files also include a timestamp as part of their name which should help prevent this. This should help debugging issues if the need arises, especially if people wish to share their log files. There is a log file issue here as currently the process also creates an empty Node.log file (please ignore this file).

From what we saw in the user run network topic after Test 12b and limited space availability, we've also reduced the default vault storage capacity from 20 GiB to 5 GiB.

SAFE Vault v0.13.1

Only people who either have a TCP port forwarded and specify it in their Crust config file OR people who have UPnP enabled will be able to participate as a vault.

If you forwarded a TCP port on your router (see this website for more information on how to do this), you need to specify the port in the safe_vault.crust.config file (which is located in the same directory as the safe_vault binary) in the tcp_acceptor_port field.

Just a reminder: 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

SAFE Authenticator & API

The dependency downloader is now integrated with safe_app_nodejs. It downloads system_uri on installation (npm install) of the safe_app_nodejs library. We're also planning to do the same thing for safe_app (it will be downloaded using the dependency downloader). safe_app_nodejs can be installed for now by adding the repository in the package.json of the application as shown in the example application.

On a few Linux versions, the URI gets registered but the app/authenticator is not being invoked. @lightyear has identified the issue and has raised a ticket to fix the issue.

We also had internal team discussions on improving the APIs and also to move certain helper functions to the Rust FFI layer. The discussion mainly focussed on providing more sophisticated functions on top of the existing available APIs. For example, the API can abstract the exposure of versions. The changes won't be breaking to the current available APIs. This will help us stabilise the API in one language (Node.js) for now and the same can be easily ported to other languages. @bochaco has been detailing the changes and improvements for the API.

The example application is being tested with Electron Forge to make it easier to package the application. On Windows, the package script hangs, but we are still able to run the application locally.

A new Java implementation of the Email example was added to the safe_examples repository. This was added to help demonstrate the SAFE Network to the Glasgow University students in the upcoming talks that we're about to give them. New examples are very much going to be tailored for the Authenticator paradigm and this was just a one-off example created to help explain some backend parts of the system to the univeristy students. See this blog post for more info about our partnership with Glasgow University.

SAFE Client Libs & Crust

We are continuing with what we started last week. The mutable data implementation in safe_vault has progressed and the parts that have been done include passing tests. A work-in-progress PR was raised. We also intend to have our first uTP spec discussion on Friday. We expect to break work into week long chunks, starting with a working uTP, moving to an integration with Crust, in addition to accepting UDP hole punched sockets. We do expect several weeks of intense testing there. On completion of that, we will enable key passing from Routing (to ensure man in the middle attack resistance (no key exchange at network layer)) as well as re-enable bootstrap cache (automatic seed nodes if you prefer). Crust will see a lot of activity in the coming weeks below its API to routing. While these are going to be great features to increase the user base that can run vaults and work with the network, it's also going to have the advantage of being seamless updates to most libraries above Crust.

Apart from that there were various changes carried out in maidsafe_utilities and crust. For instance, it's now possible to create log files with timestamps if the file_timestamp key is specified in log.toml. If this key is supplied, maidsafe_utilities will provide timestamped filenames so that we don't overwrite the previous files in case there is a vault restart.

Routing & Vault

We continued improving our tests and fixing issues to get routing ready for Test 12c. Much of the work has been dealing much more effectivly with network growth and decay, merge and splitting of sections. This was an intense period as some of the bugs we chased down were extremely difficult to find. A parallel task of message flow simplification has also meant that almost half of the team have been focussed there. This relates to security and eventually data chains type integration and the consequent data republish.

#1380 addresses some bugs in the peer manager, which handles connection states.

Developer outreach

As many of you will be aware, @dirvine and @nicklambert spent the last 2 weeks touring Asia. This included Penang, Jakarta (where @Krishna_Kumar also attended) and Shanghai. The trip is discussed here. Nick also described the trip in our blog here. Needless to say, this was a busy trip and very enlightening. It represents the tip of the iceberg for us in terms of outreach in that part of the world though.

@nbaksalyar is also continuing outreach in Russia and beyond from the Rust perspective. @lightyear is also continually on alert to spread the word. Gabriel is arranging a meetup as well. Much of this is individuals just doing their bit and it's working. We will again though regroup and try and push outreach further as we go. The balance between talking the talk and walking the walk is a continuous challenge for us. All in all the word is spreading, but Alpha 2 and Beta will spread it much faster

We also had internal team discussions on improving the APIs and also to move certain helper functions to the Rust FFI layer.

hmhmm - yeah i was looking into how to connect to the api via cffi in python and have to admit i got a little bit stuck where i had to define the data structure the API exposes (i'm not any experienced in writing C API connections for python .. so not really surprising)I'll have a look into it again within the next days ... but no promises if i'll find much time in the near future :-... i wasn't sure after all if i was looking at the right places in the rust code (then i decided to learning rust basics last weekend to understand the data structure i wanted to connect to)

Is there already a description of how the structs exposed by the api are looking inside that i didn't see ...?

All the testnets in reality are short lived (maybe a week or so) as we move to Alpha II which will be longer lived. The new client API's right now are looming so I would expect that we move rather quickly, but I always think that

I would imagine a testnet will go away in a few days, but recently the community keep them going with varying results. We have a couple of parts disabled like bootstrap cache that would allow folks to share a file simply that uses existing nodes on the network to seed of off.

So long winded and I am sorry, but bottom line testnets are probably considered short lived. Alpha/Beta will be much longer lived though.

We really need to get to secured data republish though to save everyone continually uploading again, we know it's a pita, but we have to prioritise other things right now. More interviews this week though so hopefully more resources will help us, the recent hires have all proven very valuable, although a lot of the work is not yet visible to the community.

We are simplifying the cloud. One Login, Eight Countries, Fifteen Cities, Infinite Possibilities.

Deploy New Server/InstanceVultr Cloud Compute[Any location][Ubuntu 16.10]20GB SSD $2.50/month[scroll down and enter a server hostname][deploy now]=================manageget IP address and a copy of the password

[start a local terminal..]ssh root@999.888.777.66[password][you are now logged in to your server!]

[wait a while..(410s)..for resource proof.. ta da!][detach from screen and leave it running with “Ctrl-a” “d”]================

then "exit" will drop your ssh connection and the vault will be there when you ssh again and "screen -r" to return to the screen with whatever is the latest output from the vault.There are other options to screen but I can't recall atm the detail of nohup etc to advise those.also that setup is for a short burn and not as secure as I'd make a long standing server with new user and ssh only etc.=================